Strategi Mengurai Monolith menjadi Microservice
Decomposition Strategy — Mono to Micro
Untuk dapat mengurai monolith ke dalam banyak service dan berubah menjadi sebuah microservice, kita perlu mengetahui dahulu pengertian dari istilah-istilah yang terkait dengan microservice ini. Tanpa mengetahui istilah-istilah yang digunakan dan pengertiannya maka sangat kecil kemungkinan kita dapat mengurai monolith menjadi microservice dengan benar.
Kata micro dalam istilah microservice menuntut kita untuk membuat service dari hasil migrasi monolith ke microservce sedapat mungkin semakin kecil ukurannya. Seberapa kecilkah ukuran service tersebut? Jawabannya adalah sekecil mungkin yang bisa ditangani, didevelop, dan di deploy oleh satu tim kecil developer (programmer).
Apabila dilihat dari ukuran waktu, service yang akan dibuat haruslah seukuran yang membutuhkan rata-rata kurun waktu pengerjaan yang singkat. Apabila dilihat dari hubungan team maka service yang dibuat membutuhkan minimal sekali kolaborasi antar tim di luar service. Kita dapat simpulkan satu tim tersebut dalam teorinya hanya bertanggung jawab untuk satu service dalam waktu yang sama dan autonomy.
Apabila suatu service dikerjakan oleh tim dengan jumlah yang banyak atau membutuhkan waktu yang lebih lama untuk di tes maka saatnya ini untuk memecah tim dan service lebih kecil lagi.
Apabila kita mendapatkan kenyataan, ternyata secara terus menerus kita melakukan update atau perubahan pada satu service yang diakibatkan oleh perubahan service lainnya maka ini menunjukkan bahwa service yang kita buat tidak loosely coupled atau memiliki ketergantungan tinggi satu sama lain. Apabila keadaan ini terjadi, maka yang kita lakukan adalah membuat distribusi monolith bukannya microservice. Kita harus memecah kembali menjadi lebih kecil dan mendesain ulah service komunikasinya.
Kesuksesan dari proses migrasi dari monolith ke microservice dapat diukur dari beberapa metrik berikut.
- Service-service yang dihasilkan harus dapat mempercepat proses development dan jika experiment dibutuhkan maka prosesnya bisa lebih cepat dan tidak terlalu lama.
- Arsitektur microservice yang dihasilkan harus bisa membuat inovasi lebih berkembang dan lebih mudah.
- Service-service yang dihasilkan memiliki life cycle sendiri dan tidak saling bergantung satu sama lain.
- Service-service yang dihasilkan dapat dibuat dengan bahasa pemrograman yang berbeda. Jadi, tidak harus semua service dibuat seragam menggunakan bahasa pemrograman tertentu.
Berikut digambarkan langkah-langkah dalam mengurai monolith ke dalam microservice. Perlu diperhatikan bahwa langkah-langkah tersebut bukanlah suatu langkah yang sekali jalan dan beres tetapi lebih ke proses iterasi yang membutuhkan banyak kreativitas.
Langkah pertama adalah melakukan identifikasi dari operasi yang terjadi pada sistem atau aplikasi kita. Misalkan, kita memiliki sebuah user story dengan proses yang dibutuhkan yaitu creat_order dan accept_order.
Langkah kedua adalah menentukan servis-servis yang terlibat yang ada dalam sistem monolith kita. Strategi yang digunakan dapat berupa pendekatan business model atau pendekatan domain dan subdomain model. Perlu diperhatikan bahwa hasil yang kita dapatkan dari prosess kedua ini adalah service-service yang kita pecah yang diorganisasikan berdasarkan business konsep bukan berdasarkan sudut pandang teknis. Kalau melihat dari gambar diatas service-sevice dikelompokkan kedalam Order, Restaurant, dan Kitchen.
Langkah ketiga adalah sebuah proses yang kita lakukan terus-menerus sampai kita mendapatkan model yang kita rasa model terbaik. Pada langkah ini kita perlu menentukan service API dan kolaborasi antar service yang kita pecah. Pada tahap ketiga perlu juga untuk menentukan mekanisme komunikasi antar service yang terjadi. Kita perlu menentukan pendekatan terbaik satu service berkomunikasi dengan service lainnya. Pada artikel Service Komunikasi pada Microservice dapat diketahui bagaimana satu service berkomunikasi dengan service lainnya.
Hambatan dan Tantangan
Pada proses mengurai monolith menjadi microservice tidaklah mudah walaupun kita telah mengikuti langkah-langkah di atas. Terdapat hambatan atau tantangan yang perlu kita perhatikan dan cari solusinya. Hambatan dan tantangan yang akan terjadi beberapa contohnya sebagai berikut.
- Permasalahan pertama dan utama dalam microservice adalah terjadinya network latency. Apalagi ketika terjadi jumlah user yang mengakses sistem kita meningkat atau dengan kata lain terjadi concurrent yang tinggi. Apabila latency tidak kita handle dengan baik maka bisa mengakibatkan permasalahan yang serius pada sistem kita bahkan dapat mengakibatkan blocking serta bencana berantai yang pada akhirnya membuat sistem kita menjadi down. Kita harus bisa seminimal mungkin membatasi banyaknya service call service lainnya. Untuk ini kita dapat menerapkan konsep bounded context dan duplikasi.
- Komunikasi antar service yang bersifat synchronous akan menurunkan tingkat availability dari sistem kita.
- Menjaga konsistensi data pada microservice bukan suatu hal yang mudah. Karena data adalah yang utama dalam semua aplikasi maka kita musti merencanakan dan mengurus konsistensi data ini dengan benar dan lebih seksama. Pembahasan mengenai management data pada microservice dapat kita pelajari dari artikel yang berjudul “Data Management pada Microservice”.
- God Class terjadi karena berisi banyak field yang kita mapping kedalam satu tabel database. Dengan demikian, table tersebut menjadi banyak sekali kolom. Hal ini terjadi karena god class ini merupakan gabungan implementasi business process dari berbagai aspek dan fungsi. Rata-rata satu aplikasi minimal memiliki satu jenis god class ini. God class ini yang akan menghambat proses dekomposisi yang akan kita lakukan. Teknik yang bisa kita gunakan sebagai solusi adalah domain-driven design (DDD).
Identifikasi Proses dari Sistem yang Telah Ada
Kita akan mencoba menjelaskan lebih detail mengenai proses yang pertama atau Identifikasi Proses dari Sistem. Sebagai titik awal kita dapat melakukan analisis dari requirement dokumentasi baik BRD, PRD atau TRD. Termasuk didalamnya seperti user story dan user scenario perlu kita perhatikan.
Langkah pertama pada proses ini adalah menentukan gambaran umum dari sistem berdasarkan business model. Dari gambar di atas terlihat ada tiga domain model yaitu Order, Restaurant, dan Delivery.
Langkat kedua berdasarkan user story maka kita akan membuat dua entry point atau API dari sistem kita untuk menerima dua permintaan tersebut, misalkan createOrder dan acceptOrder. Apabila proses ini sudah clear maka kita dapat melanjutkan ke proses menentukan service seperti telah dijelaskan di atas.
Kesuksesan dari proses migrasi dari monolith ke micros service berawal dari suksesnya kita melakukan dekomposisi ini. Result dari proses ini kita mendapatkan diagram arsitektur service service yang akan kita buat lengkap dengan class dan tabel-tabelnya dan tidak lupa juga terdapat rancangan API dan komunikasi strategi antar service yang terjadi.
The Legend Programmer Channel
Sponsor
Membutuhkan kaos dengan tema pemrograman :
Dapat menghubungi The Legend.
