Strategi Mengurai Monolith menjadi Microservice
ntuk dapat mengurai monolith menjadi beberapa service dan menjadi sebuah microservice, kita perlu mengetahui dahulu pengertian dari istilah-istilah yang terkait dengan microservice ini.
Kata micro dalam istilah microservice menuntut kita untuk membuat service yang dihasilkan sedapat mungkin semakin kecil ukurannya. Seberapa kecilkah ukuran service tersebut? Jawabannya adalah sekecil mungkin yang bisa ditangani dan di deploy oleh satu team kecil developer (programmer).Dalam hal waktu, service tersebut akan membutuhkan rata-rata kurun waktu pengerjaan yang singkat dan minimal sekali kolaborasi yang terjadi antar team di luar service. Kita dapat simpulkan satu team tersebut dalam teorinya hanya bertanggung jawab untuk satu service dalam waktu yang sama.
Apabila suatu service dikerjakan oleh team dengan jumlah yang banyak atau membutuhkan waktu yang lebih lama untuk di test maka saatnya kita memecah team dan service menjadi lebih kecil. Dan apabila kita mendapatkan ternyata secara terus menerus kita melakukan update atau perubahan pada satu service yang diakibatkan oleh perubahan service lainnya maka ini menunjukan bahwa service yang kita buat tidak loosely coupled dan hanya membuat distribusi monolith bukannya microservice.
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 service-service yang terlibat yang ada dalam sistem monolith kita. Strategi yang digunakan dapat berupa pendekatan business model atau pendekatan domain dan subdomain model. Perlu di perhatikan bahwa hasil yang kita dapatkan dari prosess ketiga ini adalah seqqqrvice-service yang kita pecah diorganisasikan berdasarkan business konsep bukan berdasarkan teknik konsep.
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 kita tentukan mekanisme komunikasi antar service yang terjadi. Kita perlu menentukan pendekatan terbaik satu service berkomunikasi dengan service lainnya. Mungkin dapat kita bahas dalam artikel yang terpisah.
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 adalah 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 pafa sistem kita bahkan dapat mengakibatkan blocking serta bencana yang berantai yang pada akhirya sistem kita menjadi down. Kita harus bisa seminimal mungkin membatasi banyaknya service call service lainnya.
- 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 suatu 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 coloumb. 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 decomposisi 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 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 diatas 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.
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.
Dapatkan konten baru yang dikirim langsung ke kotak masuk Anda.
Microservice 