Transformasi ke Cloud Native

Seberapa siap organisasi kita berpindah ke cloud native

Tulisan artikel kali ini didasari oleh pertanyaan beberapa rekan yang menanyakan seberapa siap kah organisasi mereka apabila akan berpindah ke Cloud Native. Disisi lain saya liat banyak perusahan yang sedang bertranformasi menuju cloud native tetapi mereka tidak mengetahui apa yang harus dikerjakan dan bahkan cara yang digunakan cenderung bertolak belakang dengan prinsip-prinsip cloud native.

Pada artikel ini saya mencoba menjelaskan bagaimna cara dan langkah yang tepat untuk melakukan transformasi ke cloud native dengan benar. Tulisan pada artikel ini didasari dari pembahasan yang mendalam dari buku yang berjudul Cloud Native Transformation dan web cnpatterns.org yang membahas hal tersebut.

Apabila kita membicarakan mengenai cloud native maka dapat dikatakan bahwa semua dari kita termasuk saya adalah junior pada hal ini. Teknologi ini masih dibilang sangat baru dan pemahaman kita semua baik terhadap arsitektur atau pattern nya terus berkembang. Sehingga dengan demikian, sharing informasi merupakan key penentu atau hal yang sangat esensial untuk mempercepat mentransformasikan organisasi kita ke cloud native.

Cloud native ini bukanlah hanya sekadar kumpulan teknologi dan tools yang kita gunakan. Ini juga merupakan pendekatan filosofis untuk membangun aplikasi yang sepenuhnya memanfaatkan cloud computing. Paradigma baru ini tidak hanya merangkul teknologi baru tetapi juga cara kerja yang baru. Jadi singkatnya transformasi ke cloud native membutuhkan new way of thinking dan new way of working.

Timbul petanyaan apakah cloud native pattern ini perlu kita gunakan di semua organisasi atau perusahaan-perusahaan sekarang? Apakah untuk orgranisasi yang sudah relative stabil dan mendapatkan revenue yang terukur dan pasti tiap bulannya perlu melakukan transformasi ke cloud native juga?

Saya sangat yakin dan berani menjawab YA. Pada keadaan zaman sekarang dimana semua informasi berjalan dengan cepat, teknologi komputer dan internet sudah sangat berkembang dengan cepat, maka semua kondisi ini menuntun atas jawabannya adalah Ya. Kita musti segera beradaptasi pada cloud native ini sesegera mungkin. Jika terlambat maka organisasi kita akan kalah bersaing dan akan ditinggalkan oleh pasar. Bahkan bisa saja organisasi kita tidak akan bisa survive. Sebutlah sebagai contoh Nokia dikarenakan kurang adaptasi dan inovasi maka mereka tidak bisa survive dan kalah oleh perkembangan zaman.

Apalagi pada organisasi atau perusaahan yang dalam kondisi krisis dan tidak menentu maka adaptasi paradigma dan prinsip-prinsip pada proses transformasi ke cloud native ini sangat berguna untuk di lakukan.

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 dan proses yang sedang berlangsung saat ini, budaya dalam organisasi tersebut, dsb.

Jantung dari cloud native

Berikut adalah matrix yang dapat kita gunakan untuk memantau seberapa dewasa dan siap kita untuk melakukan transformasi. Matrix ini pun dapat kita gunakan untuk mengetahui kondisi sekarang kita berada di posisi mana. sehingga dapat memberikan keputusan kepada kita akan langkah apa yang harus kita lakukan.

Kita dapat menggunakan matrix ini untuk mendefinisikan, menganalisis, dan mendeskripsikan konteks organisasi, baik yang diinginkan maupun tujuan, dan secara terus-menerus menilai ulang ketika proses migrasi berlangsung.

Area 1- No Process

Area pertama adalah area sebuah ogranisasi yang berjalan dengan tidak ada proses yang digunakan atau saya suka menyebutnya area bar-bar. Rata-rata mereka rush dahulu baru berfikir.

Area 2 Waterfall Process

Sudah ada proses yang lebih baik, terencana, dan terukur akan tetapi prosess dan hasil nya lama baru bisa dilihat. Proses ini sudah tidak relevan untuk kondisi sekarang.

Area 3 Agile Process

Proses yang digunakan sudah lebih baik. Proses dan hasil bisa di lihat secepat mungkin dan bisa beradaptasi dengan segala keadaan. Akan tetapi, masih banyak hal yang membuat semua proses tidak bergerak dengan cepat dan cenderung high cost atau biaya masih sangat tinggi.

Area 4 Cloud-Native Process

Merupakan proses yang sangat ideal yang mesti kita capai dan gunakan untuk kondisi sekarang ini. Semua proses berjalan effective dan effisien. Cost juga sudah sangat significant meningkat efisiensinya. Hal ini kenapa terjadi karena semua proses sudah saling mendukung satu sama lain dan bersinergi. Ciri utama adalah terjadinya automation pada beberapa hal yang dulunya di lakukan secara manual.

Kita masuk ke penjelasan mengenai beberapa stage yang ada pada metrix di atas.

Culture atau Habit

Pada bagian ini kita dapat menjelaskannya sebagai bagaimana seorang individu di dalam sebuah organisasi berinteraksi satu sama lain. Dan biasanya hal ini menjadi ciri khas dalam suatu organisasi. Bagian ini juga menjadi modal dasar untuk bagian-baigan lainnya bisa berjalan dengan baik dan lancar.

No Process: Individualist

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

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. Bukan berarti tidak memiliki goal jangka panjang. Akan tetapi goal yang besar kita ubah kedalam goal yang kecil-kecil.
• 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 continuous 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.

Product dan 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.

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.

Team

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

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 Supply Chains

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

Process

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

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).

Architecture

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

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.

Maintenance and Operations

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

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 kontinyu 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).

Delivery

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

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.

Provisioning

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

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.

Infrastructure

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

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.

Pattern Families

Seperti telah digambarkan di bagian awal artikel ini bahwa ketika kita melakukan proses transformasi ke cloud native ada beberapa pattern yang perlu kita perhatikan. Kita kelompokkan patterns tersebut ke dalam empat kelompok besar. Adapun pembagiannya sebagai berikut.

https://www.cnpatterns.org/

1. Strategi dan risk reduksi pattern
2. Organisasi dan cultural pattern
3. Development dan design pattern
4. Infrastruktur dan cloud pattern

Strategi dan Risk Reduksi Pattern

Pola-pola yang secara khusus membentuk dan menggerakkan strategi keseluruhan dalam organisasi Cloud Native: mengurangi risiko dan membangun untuk kesuksesan jangka panjang, baik selama transformasi dan kemudian menjadi apa pun yang terjadi selanjutnya. Lebih detil dan mendalam dapat di pelajari pada link berikut. https://www.cnpatterns.org/strategy-risk-reduction.

Organisasi dan Cultural Pattern

Pola untuk memandu evolusi organisasi: mengurangi ketergantungan dan memberdayakan tim untuk mandiri, proaktif, dan mandiri sambil memberikan dengan cepat dan berulang. Lebih detail dan mendalam dapat dipelajari dari link berikut. https://www.cnpatterns.org/organization-culture.

Development dan Design Pattern

Pola untuk bagaimana merancang, membangun, dan memberikan produk / layanan dalam paradigma baru ini: arsitektur dan proses yang mendukung Cloud Native, pengiriman dinamis yang cepat dan responsif. Lebih detil dan mendalam dapat dipelajari dari link berikut. https://www.cnpatterns.org/development-design.

Infrastruktur dan Cloud Pattern

Pola yang membantu dalam menemukan dan memilih infrastruktur yang tepat, sambil menghindari jebakan umum seperti vendor lock-in dan membangun solusi kustom yang tidak perlu.Lebih detail dan mendalam dapat dipelajari dari link berikut, https://www.cnpatterns.org/infrastructure-cloud.

Begitulah penjelasan secara singkat dan belum detail, semoga bermanfaat bagi kita yang akan berencana untuk bertransformasi ke cloud native.

IT Training

Mau improve skill IT dan pemrograman Anda, Silahkan cek jadwal training berikut.

The Legend Training

Kaos Pemrograman

Membutuhkan kaos dengan tema pemrograman :

Kafka T-shirt

Elastic T-shirt

Dapat menghubungi The Legend.