Strangler Pattern
Cara Terbaik Migrasi dari Monolith ke Microservice
Migrasi dan rewrite proses dari monolith architecture ke microservice architecture merupakan sebuah tantangan dan tugas yang sangat berat. Suatu proses pengerjaan yang penuh dengan risiko dan jika salah proses maka dapat mengakibatkan kegagalan dan pengorbanan yang luar biasa baik waktu maupun resource.
Karena tingkat kesulitan tinggi biasanya jika berhasil akan mendapatkan keuntungan yang sangat banyak dan besar. Apabila kita berhasil melakukan migrasi dari monolith ke microservice akan mendapatkan segala keuntungan dan kelebihan yang dimiliki oleh microservice. Akan tetapi, sekali lagi prosesnya membutuhkan cara yang terbaik agar semuanya berjalan dengan baik dan berhasil.
Terdapat dua hal yang perlu diperhatikan dalam migrasi dan rewrite dari mono to micro ini. Pertama, adalah cara memecah monolith ke microservice dalam hal memecah bagian-bagian source code dan ini telah kita bahas pada artikel yang berjudul Strategi Mengurai Monolith menjadi Microservice. Kedua, adalah cara dalam proses memecahnya dilihat dari urutan. Apakah dari hasil proses pertama harus kita kerjakan sekaligus atau sebagian-sebagian. Pada pembahasan kali ini kita akan membahas proses memecah dan urutan pengerjaannya.
Parasit Proses (Strangler Fig)
Strangler Fig adalah tumbuhan parasit yang akan menggerogoti tumbuhan utama tempat dia hidup. Strangler fig ini akan mengambil sedikit demi sedikit sehingga tumbuhan utamanya diambil alih dan mati.
Strangler Pattern adalah design pattern yang umum digunakan untuk memigrasikan monolith aplikasi ke microservice aplikasi secara bertahap dengan menggantikan beberapa fungsi yang digantikan dengan service baru.
Setelah service baru ini siap maka bagian dari monolith yang bersesuaian akan dikurangi, tidak dipakai,atau di-strangled dan service baru mulai dipakai. Permintaan atau request akan diarahkan ke service baru dan beberapa fungsi yang bersesuaian pada monolith akan dinonaktifkan (tidak dipakai lagi). Proses ini dilakukan secara bertahap sampai semua fungsi yang ada diganti dengan service baru microservice beres terbentuk.
Langkah-Langkah Migration
- Motivasi. Kita harus jelas dahulu alasan kita melakukan migrasi ke microservice dari monolith. Jangan hanya sekadar mengikuti trend teknologi ternyata kebutuhan dan kesiapan team belum ada. Microservice membutuhkan cara berpikir dan jumlah team yang lebih besar dari pada ketika kita menggunakan monolith. Mengenai kesiapan team untuk menggunakan microservice dapat dibaca di artikel berikut : https://medium.com/the-legend/transformasi-ke-cloud-native-82a8afed31e0.
- Tentukan Pilihan. Setelah melakukan dekomposisi strategi kita harus menentukan pilihan beberapa fungsi yang akan kita tarik keluar dari monolith dan memasukkannya ke dalam service yang baru. Perlu diperhatikan pemilihan service sedapat mungkin berdasarkan data dari keperluan bisnis yang ada. Misalkan, sistem sekarang mengalami pencarian yang sangat lama ketika user bertambah banyak maka pilihan query service adalah pilihan bijaksana untuk dimasukan ke dalam urutan pertama.
- Api Gateway. Sebelum memulai migration maka langkah terpenting adalah memasang api gateway sebelum monolith di migrasi ke microservice. Hal ini bertujuan agar memudahkan management API. Terkadang ada kepentingan ketika bagian UI tidak boleh ada perubahan API karena keterbatasan team atau memang belum ada jadwal development atau kita tidak mau mengganggu user dengan mengganti UI ( mobile app) karena adanya migrasi ini. Lebih detail mengenai API gateway dapat di pelajari di artikel berikut: https://medium.com/the-legend/api-gateway-pattern-ef5cd3b2ae50.
- Share State Database. Tentukan bagian database yang digunakan oleh beberapa fungsi yang akan kita tarik keluar. Database ini adalah share state database yang akan digunakan pada service yang akan dibuat.
- Tentukan Jenis Database. Untuk service yang akan dibuat kita harus menentukan jenis database yang akan digunakan dengan seksama. Apakah akan menggunakan RDBMS atau NoSQL. Selain jenis database tentukan juga apakah database yang akan digunakan merupakan primary penyimpanan data atau hanya sekadar secondary penyimpanan data seperti pada penggunaan CQRS pattern. Lebih detail untuk cara pemilihan jenis database yang tepat dapat dipelajari pada artikel berikut: https://medium.com/the-legend/apa-itu-cap-theorem-839dd4a1f798.
- Pembuatan Service. Gunakan scrum methodology pada proses development dan buat minimal ada tiga environment, dev, staging, dan production. Untuk menjaga kualitas dari code gunakan tool untuk menjaga dan memonitor kualitasnya seperti sonar cube.
- Data Migrasi. Lalukan data migrasi dari sistem lama ke sistem baru mulai dari environment dev, staging , dan production. Jika data yang dipindah besar kita dapat menggunakan framework khusus batch proses misal spring batch. Ketika data service baru nanti live kita memerlukan satu layanan sistem yang melakukan sinkronisasi database lama dan baru karena ada kemungkinan pada database lama masih dipanggil oleh beberapa service lain. Kita dapat mencabut service untuk sinkronisasi data ini setelah semua service yang memiliki ketergantungan pindah.
- Test Performa dan Security. Jangan lupa sebelum naik ke production idealnya kita melakukan kedua test ini.
- Live Production dan Monitoring. Setelah naik ke production jangan lupa kita harus memasang tool monitoring dan log analisis.
- Lakukan lagi proses ini untuk fungsi dan service lainnya sampai semua fungsi dapat ditarik keluar dari monolith dan pada akhirnya kita matikan monolith sistem dan berpindah semuanya kepada microservice sistem.
Detil Diagram Migrasi Proses
Kesimpulan
Inti dari strangler pattern adalah kita harus melakukan dekomposisi monolith ke microservice dilakukan secara bertahap satu persatu. Perhatikan semua detail proses migrasi sehingga tidak ada yang tertinggal satupun. Ingatlah sebuah pepatah “Pecah Belah dan Selesaikan”.
The Legend Programmer Channel
Sponsor
Membutuhkan kaos dengan tema pemrograman :
Dapat menghubungi The Legend.
