Table of contents:

Pada tulisan ini, kita akan membahas mengenai hal-hal apa saja yang perlu kita perhatikan saat kita ingin melakukan transformasi ke Cloud Native. Hal-hal ini akan dirangkum menjadi sebuah matriks yang menggambarkan “maturity” (kedewasaan) sebuah organisasi, dilihat dari berbagai faktor.

Dikutip dan diterjemahkan dari buku Cloud Native Transformation, cloud native didefinisikan sebagai berikut.

“Sebuah arsitektur dan pendekatan filosofis untuk membangun aplikasi dengan memanfaatkan keuntungan-keuntungan yang ditawarkan oleh komputasi awan (cloud computing).”

Jadi, bagaimana kita bisa tahu bahwa proses transformasi (migrasi) ke cloud akan sukses? Salah satu hal yang perlu kita perhatikan sebelum melakukan proses tersebut adalah mengenal tingkat kedewasaan sebuah organisasi, misalnya arsitektur saat ini, proses yang sedang berlangsung saat ini, budaya dalam organisasi tersebut, dsb.

Menurut Cloud Native Transformation, ada 9 area di dalam Maturity Matrix yang perlu kita perhatikan sebelum kita membuat migration map untuk sebuah organisasi.

Berikut adalah contoh hasil akhir maturity matrix setelah kita melakukan asesmen pada sebuah organisasi. Garis putus-putus berwarna biru menggambarkan kondisi (maturity level) saat ini, dan garis putus-putus berwarna merah adalah tujuan akhir yang akan kita capai, yaitu melakukan transformasi ke cloud native.

img

Area 1 — Culture

Area ini didefinisikan sebagai “bagaimana seorang individu di dalam sebuah organisasi berinteraksi satu sama lain”.

img

No Process: Individualist

  • Komunikasi hanya berdasarkan preferensi personal, tidak ada cara “formal” yang disepakati untuk berkomunikasi.
  • Kultur ini biasanya terjadi di perusahaan rintisan (startups).

Waterfall: Predictive

  • “Long-term planning” dan “firm-deadline”.
  • Fokus untuk deliver complex-system sesuai deadline, dan spesifikasi sistem harus sama persis dengan yang telah disepakati sebelumnya.
  • Cenderung untuk tidak “mencoba-coba” (eksperimen). Segala hal harus “pasti”.
  • Ada banyak sekali dokumentasi, prosedur, pemisahan tim berdasarkan spesialisasi, regular meeting (misalnya meeting mingguan).
  • Kultur ini biasanya terjadi di medium-to-large enterprise.

Agile: Iterative

  • Goal yang lebih kecil dan lebih sederhana.
  • Fokus untuk mencapai goal dalam waktu secepat mungkin.
  • Cenderung fokus ke short-term dibandingkan long-term.
  • Komunikasi dilakukan secara singkat, misalnya daily meeting.

Cloud Native: Collaborative

  • Goal cenderung luas, tetapi tidak dalam. Punya visi yang luas, tetapi biasanya belum di-set detail spesifikasi dan deadline-nya.
  • Menekankan pada continuous learning dan continous improvement.
  • Self-education, eksperimen dan riset.
  • Hasil akan dinilai berdasarkan data di lapangan.
  • Kultur ini penting untuk organisasi di industri yang penuh ketidakpastian dan berubah dengan cepat.

Next: Generative

  • IT akan bertindak sebagai partner, bersama-sama dengan tim bisnis akan melakukan “co-create” sebuah solusi untuk organisasi tersebut.

Area 2 — Product/Service Design

Area ini didefinisikan sebagai “bagaimana sebuah keputusan dibuat di dalam sebuah organisasi, dan apa yang harus dilakukan berikutnya”. Misalnya, produk apa yang harus dibuat selanjutnya, dan fitur apa yang harus ditambahkan.

img

No Process: Arbitrary

  • Desain produk biasanya berasal dari ide founders, terkadang random dan berasal dari keisengan atau “wild-idea driven”.

Waterfall: Long-term Plan

  • Desain produk berfokus pada feature-request dari customers, potential customers (via sales), atau product managers.
  • Ide tersebut akan dikumpulkan, di-assess, dan dijadikan daftar fitur yang akan dirilis berikutnya.
  • Rilis fitur biasanya dilakukan sekaligus dalam jumlah besar setiap 6 atau 12 bulan.

Agile: Feature Driven

  • “Small features, less-planning, fast-release”.
  • Fitur baru biasanya akan dirilis setiap minggu atau setiap bulan.
  • Fokus pada perubahan yang cepat, dan seringkali dilakukan tanpa long-term plan.

Cloud Native: Data Driven

  • Ada proses pengumpulan data dari “real-user” untuk menentukan fitur mana yang akan dipertahankan dan fitur mana yang akan dihilangkan. Proses ini dapat dilakukan secara manual, otomatis, atau kombinasi keduanya.
  • Pemilihan fitur mana yang akan di-develop selanjutnya dilakukan dengan proses yang singkat, dan berdasarkan feedback dari user.
  • Ada proses A/B testing. Jika fitur baru lebih disukai user, fitur akan dipertahankan. Jika tidak, fitur akan dihilangkan atau diperbaiki.

Next: AI Driven

  • Tidak ada interaksi dari manusia terkait fitur.
  • AI akan melakukan evolusi (perubahan secara perlahan) terhadap fitur yang ada pada sistem.

Area 3 — Team

Area ini didefinisikan sebagai “bagaimana tanggung jawab, komunikasi dan kolaborasi antar tim berjalan di dalam sebuah organisasi”.

img

No Process: No Organization, Single Contributor

  • Hanya ada beberapa independent-contributor di dalam organisasi.
  • Tidak ada manajemen yang formal.
  • Biasanya terjadi di perusahaan rintisan (startups).

Waterfall: Hierarchy

  • Top-down order. Keputusan dari top-management atau manager, pelaksanaan oleh anggota tim sesuai fungsinya atau spesialisasinya masing-masing.
  • Tim terpisah-pisah sesuai fungsinya, misalnya software architects, desainer, developers, testers, operations.
  • Komunikasi antar tim biasanya menggunakan tools seperti JIRA, atau dilakukan melalui manager.
  • Biasanya terjadi di organisasi besar.

Agile: Cross-functional Teams

  • “Less-specialization and more cross-capability within teams” — misalnya, development teams terlibat dalam testing.
  • Scrum masters dan product owners sebagai fasilitator komunikasi antar tim.
  • Masih ada struktur yang hirarkikal.

Cloud Native: DevOps/SRE

  • Kolaborasi antara tim developers dan operations.
  • Biasanya tim terlibat mulai dari perencanaan, penentuan arsitektur, testing, development hingga operations.

Next: Internal Suppy Chains

  • Setiap service adalah produk yang terpisah, dan menjadi tanggung jawab sebuah tim, baik dari sisi teknologi, maupun dari sisi bisnis.

Area 4 — Process

Area ini didefinisikan sebagai “bagaimana sebuah organisasi melakukan pembagian tugas, dan mengeksekusi sebuah project”.

img

No Process: Random

  • Tidak ada change-management. Semua perubahan dilakukan secara ad-hoc.
  • Tidak ada versioning yang konsisten.
  • Biasanya terjadi di perusahaan rintisan (startups).

Waterfall: Waterfall

  • Proses pengembangan produk dilakukan melalui kontrol dan change-management yang ketat.
  • Selalu ada perencanaan panjang sebelum produk dikembangkan.
  • Sequential-process, dimulai dari perencanaan, eksekusi, testing dan delivery.
  • Ada proses integrasi, dimana hasil pekerjaan setiap tim akan diintegrasikan menjadi satu kesatuan produk dan di-test secara manual.
  • Ada prosedur serah terima pekerjaan yang sangat well-documented dan melibatkan banyak form.

Agile: Agile (Scrum/Kanban)

  • Proses pengembangan produk dilakukan berdasarkan sprint, menggunakan teknik agile seperti Scrum atau Kanban.
  • Perubahan di tengah sprint sangat dihindari.
  • Tim dilibatkan di dalam manajemen tim itu sendiri.

Cloud Native: Combination of Design Thinking, Agile and Lean

  • Design thinking (atau teknik research lain) digunakan untuk mengurangi resiko ketidakpastian pada sebuah project yang besar dan kompleks.
  • Banyak melakukan POC untuk membandingkan opsi-opsi yang bisa diambil.
  • Menggunakan teknik scrum dan kanban untuk mengeksekusi pengembangan produk.
  • Organisasi yang “highly-proficient” dapat mengadopsi konsep Lean.

Next: Distributed, Self-organized

  • Jarang sekali dilakukan “up-front design” saat melakukan pengembangan produk.
  • Setiap orang atau tim dapat memberikan ide, lalu ide tersebut akan di-deploy ke dalam sebuah platform sebagai sebuah “seed”. Kemudian, seed tersebut akan perlahan-lahan di-improve secara otomatis oleh platform tersebut (tanpa perlu intervensi manusia).

Area 5 — Architecture

Area ini didefinisikan sebagai “struktur keseluruhan sistem dan teknologi” yang saat ini kita adopsi.

img

No Process: Emerging from Trial and Error

  • Tidak ada architectural principles/practices yang diadopsi.
  • Developer menulis kode, dan komunikasi antar-sistem dilakukan secara ad-hoc.
  • Integrasi antar komponen tidak terdokumentasi dengan baik.
  • Sistem sulit untuk di-extend dan di-maintain.

Waterfall: Tightly Coupled Monolith

  • Model arsitektur dimana semua modul akan menjadi satu codebase. Semua developer akan bekerja di dalam codebase yang sama.
  • Monolith biasanya ditulis dalam bahasa pemrograman yang sama.
  • Proses deployment dilakukan dengan proses yang sangat terkoordinasi.

Agile: Client-server

  • Pemisahan antara client dan server. Merupakan bentuk dasar dari sistem terdistribusi.
  • Terkadang dimungkinkan development berjalan secara paralel, untuk modul-modul yang berlainan codebase (antar modul berkomunikasi melalui jaringan).
  • Biasanya tetap ada coupling antar modul, sehingga proses deployment tetap harus dikoordinasikan.

Cloud Native: Microservices

  • “Highly-distributed”.
  • Ada banyak sekali services yang independen, saling berkomunikasi melalui interface yang disetujui (versioned API, streams, dsb).
  • Setiap microservice dapat di-deploy secara independen dan fully-automated.
  • Setiap microservice dapat di-develop menggunakan bahasa pemrograman, database, dan tooling yang berbeda-beda.

Next: Functions-as-a-Service/Serverless

  • Tidak perlu melakukan provision infrastruktur, scaling atau patching.
  • Setiap business logic ditulis dalam fungsi yang berbeda, dan dioperasikan oleh Functions-as-a-Service provider seperti AWS Lambda, Azure Functions atau Google Cloud Functions.

Area 6 — Maintenance and Operations

Area ini didefinisikan sebagai “bagaimana sebuah aplikasi di-deploy dan berjalan di production environment”.

img

No Process: Respond to Users’ Complaints

  • Tim development dan/atau operations mengetahui adanya masalah pada sistem jika ada user yang mengalaminya dan mengajukan komplain.
  • Tidak ada alert system dan monitoring system.
  • Untuk melakukan diagnosa masalah, administrator perlu login ke server dan melakukan troubleshooting secara manual.

Waterfall: Ad-hoc Monitoring

  • Sebagian sistem dan aplikasi sudah ada monitoring, tetapi tidak ada alert, sehingga administrator harus melakukan pengecekkan dashboard monitoring secara berkala untuk memastikan sistem berjalan dengan baik.
  • Biasanya tidak ada centralized logging. Administrator harus login satu per satu ke setiap server untuk melakukan troubleshooting (diagnosa masalah).

Agile: Alerting

  • Ada centralized logging dan centralized monitoring.
  • Tim operations akan merespon jika ada alert, dan melakukan eskalasi ke tim developer jika mereka tidak berhasil menyelesaikan masalah tersebut.
  • Terkadang administrator masih harus login ke server untuk melakukan troubleshooting.

Cloud Native: Full Observability and Self-healing

  • Semua sistem bergantung pada logging, tracing dan alerting yang secara kontinu mengumpulkan informasi mengenai sistem atau service yang sedang berjalan.
  • Banyak masalah yang sudah bisa terselesaikan secara otomatis (“self-healing”). Misalnya, ada health check yang otomatis melakukan restart sistem jika ada masalah yang terdeteksi.
  • Ada status dashboard yang dapat diakses setiap orang untuk melakukan pengecekan availability dari services yang sedang berjalan.
  • Jika ada masalah yang harus diselesaikan secara manual (tidak otomatis), maka tim operations, developers (dan mungkin SRE) tidak perlu (juga tidak diizinkan) mengakses production environment untuk melakukan penyelesaian masalah.

Next: Machine Learning (ML) dan Artificial Intelligence (AI)

  • ML dan AI akan menangani operation dan proses maintenance.
  • Sistem akan belajar secara mandiri untuk menyelesaikan masalah dan mencegah terjadinya kegagalan sistem (system failures).

Area 7 — Delivery

Area ini didefinisikan sebagai “bagaimana dan kapan aplikasi yang dikembangkan di-deploy di production environment”.

img

No Process: Irregular Release

  • Delivery atau deployment atau rilis dilakukan ke production environment secara random, biasanya berdasarkan keputusan manajemen, atau berdasarkan urgency dari rilis tersebut.
  • Jika terjadi issue atau masalah di production, maka fixing akan dilakukan oleh developer langsung di production environment.
  • Hal ini biasanya terjadi di startups atau small enterprise.

Waterfall: Periodic Scheduled Releases

  • Rilis dilakukan secara terjadwal, misalnya setiap 6 bulan atau 12 bulan.
  • Rilis adalah hal yang sangat penting dan perencanaan sudah dilakukan sejak lama.
  • Setiap rilis disertai dengan sebuah dokumen rilis (biasanya disiapkan oleh enterprise architects).
  • Coding tidak dilakukan sebelum full architecture document selesai dibuat.
  • Testing software dilakukan secara manual.
  • Jika ada perubahan pada hal-hal apa saja yang harus dirilis, maka perubahan ini harus disetujui (approval) oleh manajemen.
  • Setelah rilis dilakukan, tim operations bertanggung jawab untuk melakukan support dan maintenance.

Agile: Continuous Integration

  • Proses build aplikasi dari code menjadi runnable application dilakukan secara fully automated.
  • Ada automated testing yang menjadi bagian dari proses build.
  • Setiap developer wajib melakukan submission kode baru (i.e. git push) setiap hari, sehingga bug fixing bisa dilakukan secara incremental.

Cloud Native: Continuous Delivery

  • Proses rilis dilakukan secara otomatis dan dengan frekuensi yang sering. Seringkali rilis dilakukan beberapa kali dalam satu hari.
  • Organisasi di fase ini sering mengombinasikan proses continuous integration dan deployment, sering disebut sebagai CI/CD.
  • Testing dilakukan secara menyeluruh mulai dari unit test, integration test, load test, hingga performance test.
  • Testing tidak hanya dilakukan di development/test environment, tetapi juga di production environment. Misalnya, chaos engineering, dan A/B testing.

Next: Continuous Deployment

  • Sistem dilengkapi dengan auto-rollback jika fitur atau rilis yang dilakukan membawa dampak negatif pada key-metrics, seperti user conversion. Misalnya, jika setelah fitur X dirilis, user conversion rate menjadi menurun, secara otomatis sistem akan rollback untuk melakukan un-install/disable fitur X.

Area 8 — Provisioning

Area ini didefinisikan sebagai “proses dimana kita membuat atau memperbaharui sistem di production environment”.

img

No Process: Manual

  • Dilakukan secara manual (interactive-mode). Developer (yang biasanya juga merangkap operation) melakukan login ke server, menginstall software yang diperlukan, dan menjalankan aplikasi secara manual.
  • Terkadang menggunakan mekanisme seperti FTP untuk melakukan transfer file.

Waterfall: Scripted

  • Ada script yang dibuat untuk melakukan instalasi software yang diperlukan pada production environment.
  • Tim developer akan melakukan proses serah-terima aplikasi kepada tim operations. Kemudian, tim operations akan menggunakan script untuk meng-copy aplikasi dan semua dependency-nya ke dalam production environment.
  • Terkadang terjadi “dev/prod parity” (i.e. aplikasi berjalan dengan baik saat proses development, tetapi gagal berjalan di production environment).

Agile: Configuration Management (Puppet, Chef, Ansible)

  • Menggunakan tools seperti Puppet, Chef, atau Ansible untuk melakukan standarisasi script.
  • Tetap memerlukan manusia untuk menjalankan script, tidak fully automated.

Cloud Native: Dynamic Scheduling/Orchestration (Kubernetes)

  • Melakukan containerized pada aplikasi; sangat mengurangi potensi terjadinya dev/prod parity.
  • Adanya declarative configuration (i.e. kubernetes yaml file), sehingga proses orchestration hardware (server) dilakukan secara otomatis oleh orchestrator, bukan manusia.

Next: Serverless

  • Konfigurasi dan maintenance hardware dilakukan secara otomatis oleh cloud provider.

Area 9 — Infrastructure

Area ini didefinisikan sebagai “physical servers dimana production environment berada (apa bentuknya, dimana lokasinya, dan bagaimana mereka di-manage)”.

img

No Process: Single Server

  • Production environment hanya menggunakan satu physical servers.
  • Tidak ada failover servers (tidak resilience).

Waterfall: Multiple Servers

  • Ada redundancy. Jika satu physical server bermasalah, ada mekanisme failover.
  • Seringkali physical servers diletakkan di co-located data center.
  • Perlu beberapa hari atau beberapa minggu untuk melakukan provision server baru, karena harus melakukan pembelian hardware baru, dan melakukan permintaan rackspace ke co-located data center.

Agile: VMs (“Pets”)

  • Sama seperti kita mempunyai multiple-servers environment, tetapi proses provisioning dapat menjadi lebih cepat karena kita tidak perlu melakukan pembelian hardware baru, dan kita dapat melakukan standarisasi VM Image.
  • Tim operation masih bisa login ke dalam server untuk melakukan troubleshooting, atau melakukan instalasi software.
  • Jika ada masalah dengan salah satu VM, maka tim operation harus melakukan perbaikan secara manual.

Cloud Native: Containers (“Cattle”)

  • Provisioning production environment dilakukan secara fully-automated oleh container orchestration.
  • Jika ada masalah dengan salah satu container, maka secara otomatis container orchestration akan membuat container baru untuk menggantikan container yang bermasalah.
  • Proses provisioning containers sangat cepat, dalam hitungan menit, bahkan detik.

Next: Edge Computing

  • Decentralized computing process yang terjadi di “edge” (lokasi yang dekat dengan user).
  • Edge computing akan mengambil aplikasi, data, dan services dari centralized location, dan mendistribusikannya ke lokasi yang lebih dekat dengan user.
  • Edge computing akan membuat aplikasi lebih cepat diakses oleh user.

Nah, untuk yang penasaran dan ingin mencoba melakukan evaluasi tingkat maturity sebuah organisasi, bisa download matriks kosongnya di info.container-solutions.com.

Selamat mencoba!