Aaargh..gw benci sama diri gw., susah move on, masih teringat dengan mantan.

krik…krik..krik…

Pelan-pelan saja., lupakan sedikit demi sedikit.. buka hati untuk yang lain, tak usah benci dan dendam.

– Suara hati mantan

Pendahuluan

Mengubah aplikasi yang dulunya Monolitik ke arsitektur bertipe Microservice memang tidak semudah membalikkan telapak tangan.

Ada banyak hal yang harus kita perhatikan.

Dahulunya dengan aplikasi Monolitik kita hanya memikirkan perubahan di satu code Repository saja.

Tidak perlu adanya integrasi yang banyak dan kompleks.

Dengan mengubah arsitekturnya menjadi Microservices, maka harus dipikirkan adalah :

  • Penentuan business context yang mau dijadikan sebuah microservices.
  • Pemecahan aplikasi monolitik menjadi modul modul terpisah dalam bentuk microservices.
  • Integrasi dengan microservice yang baru dibuat.

Intinya pengubahan aplikasi dari arsitektur Monolitik menjadi Microservices membutuhkan pemecahan aplikasi awal yang Monolitik menjadi aplikasi-aplikasi kecil yang banyak.

Hmmm.., tapi bagaimana strategi untuk melakukan pemecahan aplikasi ini ?

Apakah kita langsung memecah satu aplikasi monolitik diatas menjadi aplikasi-aplikasi kecil, lalu langsung membuang aplikasi monolitiknya ?

Yang tentunya membutuhkan waktu cukup lama.

Atau bisakah secara bertahap ?

Secara logika , mestinya akan ada 2 cara :


1. Buat sebuah project baru, untuk menggantikan aplikasi Monolitik ke Microservice.

Hal ini biasanya muncul di pikiran project management dan level teknikal menengah keatas.

Perubahan yang Bigbang dan Revolusioner.

Membuat aplikasi baru dengan arsitektur baru dan bisa saja dengan branding baru, untuk bisnis lama yang sedang berjalan di aplikasi monolitik yang lama.

Tujuannya tentu saja untuk mengubah mindset, semangat, dan mungkin ada sedikit ego disana :D.

Apakah dengan nama product yang baru, menggunakan software design pattern yang baru, membuat framework sistem yang baru.

Dan ini harus dibikin dalam sebuah project baru.

Yaaa., betul.. project baru karena ini akan cukup besar mesti mengubah aplikasi Monolitik ke banyak Microservices.

Harus ada alokasi biaya, waktu, dan juga sumberdaya Software Engineer yang dibutuhkan untuk melakukan hal ini.

Boleh dibilang, ini adalah project migrasi dari Monolitik ke Microservice.

Artinya akan ada 2 tim, satu tim untuk projek migrasi ini, satu tim lagi untuk tetap maintain/mengelola aplikasi yang lama.

Hire seorang Project Manager, Scrum Master, atau apalah namanya agar proses migrasi ini berjalan sukses.

Bagaimana dengan aplikasi monolitik yang lama ? kalau ada perubahan alur baru dll ketika dilakukan migrasi ?

Untuk hal diatas, tentu saja kita harus mengelola 2 aplikasi secra terpisah.

Selama aplikasi dengan arsitektur microservice belum selesai, maka aplikasi lama yang Monolitik tetap dipakai dan tentu saja akan ada penambahakn fitur, perbaikan bug, dan atau production support.

Kalau ada perubahan alur baru atau fitur di aplikasi monolitik yang lama, maka harus segera diinformasikan ke tim project migrasi agar bisa diadaptasi juga di aplikasi Microservice yang baru.

Berapa lama kita akan mengelola 2 aplikasi ini ?

Tergantung dari project migrasinya tentunya.

Besarnya aplikasi Monolitik yang mau dipecah.

Seberapa paham tim migrasi dalam melakukan migrasi didalamnya.

Seberapa lengkap testing dari QA/Tester, dan seberapa lengkap pula transisi dari alur yang ada di aplikasi yang lama ke aplikasi yang baru.

Cukup banyak yang harus diperhatikan ketika kita membuat project Migrasi cuma untuk menjadikan aplikasi lama yang Monolitik menjadi aplikasi berbasis Microservices

Dan tentunya akan butuh Biaya, Waktu, dan juga Scope seperti layaknya menangani Project Management Triangle (baca sekilas)


2. Copotin secara bertahap bagian dari Monolitik untuk dijadikan Microservice dan integrasikan.

Cara kedua ini idenya biasanya muncul dari developer, Software Enginner, Teknikal level operasional.

Yang biasanya merasakan sulitnya ketika mengelola 2 aplikasi yang berbeda dan tidak sinkron antara keduanya.

Walaupun tidak menutup kemungkinan level teknikal atas juga menyetujui hal ini, seperti level CTO dan Solution Arsitek.

Ide dan cara seperti diatas dikenal dengan Strangler pattern.

Strangler kalau dalam bahasa Inggris berarti Pencekik , (translate)

Kata tersebut disematkan sebagai salah satu nama design pattern microservice, karena cara nya adalah dengan pelan-pelan mencekik aplikasi Monolitik yang lama.

Mengeluarkan bagian-bagiannya menjadi aplikasi microservice secara bertahap.

Tetapi tetap terhubung antara aplikasi monolitik dengan aplikasi microservice yang baru, sampai tidak ada lagi aplikasi monolitiknya lagi.


Bagaimana biasanya caranya Strangler pattern ini dilakukan ?

Caranya biasanya dengan :

  • Membuat sebuah logic Facade di aplikasi Monolitik yang lama.
  • Facade ini memecah logic aplikasi menjadi bagian-bagian terpisah sesuai fungsinya.
  • Pemisahan bisa dilakukan sesuai dengan microservice yang akan dibuat.
  • Sehingga code Facade yang dibuat tidaklah mesti sempurna, cukup sesuai dengan kebutuhan.
  • Untuk bagian logic di Facade yang didelegasikan ke microservice yang baru, bisa dibuat class interface/adapter/bridge/feign, dll.
  • Lakukan test dan pastikan logicnya sudah sesuai dan berjalan semestinya.