- "Monolith > apps > services > microservices"
- Pertama, ini bukan aturan, hanya menurut saya begitu. Orang yang pernah membangun sistem terdistribusi berskala besar tahu bahwa praktiknya tidak benar-benar berjalan persis seperti itu, dan perlu beradaptasi
- Kedua, urutannya penting
- Jika perusahaan beranggotakan 5–50 orang, langsung saja gunakan Monolith
- Jika perusahaan beranggotakan 10 ribu orang, kemungkinan akan memiliki semua hal di atas. Tapi kalau membahas perubahan cara berpikir dibanding dulu...
Mari mulai dari definisi
- monolith - xyz.com
- apps - abc.xyz.com
- services - mendukung app/monolith, infrastruktur inti, fungsi compliance inti, dan bisa jadi tidak ditulis oleh tim app (dipelihara oleh tim infrastruktur)
- microservices - beberapa ratus baris kode, kebanyakan sekali pakai, bisa/seharusnya berupa library atau SDK
Why? : pada dasarnya karena "Speed & Risk"
- #1 Lebih mudah jika seluruh tim pengembang bekerja di satu big app (bayangkan seluruh situs adalah aplikasi Rails)
- #2 Sistem terdistribusi yang pada akhirnya pasti dimiliki saat tumbuh sudah sulit dipahami dengan sendirinya, bahkan tanpa ratusan microservices berisiko tinggi
- #3 Jika benar-benar menjadi serba micro, Anda harus memperkenalkan konsep-konsep baru untuk menangani perluasan yang tak terkendali
- #4 Layanan infrastruktur bespoke atau microservice adalah bentuk ekstrem dari utang. Kode juga adalah utang, tetapi service adalah versi ekstremnya. Pikirkan apa artinya ini. Jadikan itu titik leverage
- Insinyur sistem terdistribusi tidak suka duplikasi, jadi jika sesuatu dilakukan di banyak tempat mereka akan berpikir, "mari kita ekstrak ini dan buat microservice"
- Secara teori ini benar, dan sampai belasan atau dua puluhan masih oke. Tetapi jika sudah melewati puluhan atau dipakai di perusahaan berskala besar, itu bukan lagi masalah teknis melainkan masalah organisasi
- Mungkin yang saya katakan terasa seperti dikotomi yang salah, tetapi pada kenyataannya microservices memang punya tantangan teknis, dan lebih banyak lagi masalah organisasional
Yang saya khawatirkan
- #1 (Kecuali dipimpin CEO berlatar belakang IT yang tidak biasa) infrastruktur selalu mendapat prioritas paling rendah
- #2 Jika service terlalu banyak, biasanya akan muncul masalah kepemilikan dan batas tanggung jawab
- #3 Akan diperkenalkan lebih banyak alat untuk menangani begitu banyak microservices
- #4 Yang paling penting, setiap microservice yang seharusnya menjadi library atau SDK justru menimbulkan risiko produksi
Rekomendasi saya secara umum
- #1 Pertahankan Monolith selama mungkin jika memungkinkan
- #2 Mulailah service dari kebutuhan infrastruktur, bukan dari sisi pengembangan app
- #3 Jika harus memecah Mono, pecahlah menjadi app besar, bukan service kecil
- #4 Anggap setiap app baru sebagai dinding virtual di dalam perusahaan
- #5 Jika memungkinkan, lebih pilih library daripada microservice
13 komentar
Bagian kekhawatiran dan rekomendasi di akhir memang terasa sangat relevan. Sebenarnya, baik skala perusahaan maupun skala layanannya punya konteks yang mirip, dan akan datang saatnya ketika sistem memang harus dipecah, jadi saya merasa dibutuhkan penilaian yang sangat tepat untuk mengantisipasi hal itu sejak dini.
Bukankah seharusnya ini ditentukan berdasarkan skala sistem, bukan skala perusahaan? Atau mungkin selama ini aku salah memahami MSA?
Saya setuju dulu dengan pendapat di komentar atas bahwa
bukankah masalahnya bukan pada microservices itu sendiri, melainkan pada ekspansi layanan yang serampangan?
Karena semakin besar perusahaan, kekurangan monolith itu sendiri seperti masalah deployment + manajemen branch menjadi terlalu jelas terlihat, jadi sepertinya perlu memilih trade-off antara biaya dan produktivitas dengan baik.
Tulisan yang sangat bagus. Terima kasih.
Sepertinya mirip dengan perdebatan soal pentingnya design pattern, ya.
Design pattern itu adalah pola kode yang lahir dari proses menyelesaikan berbagai macam masalah....
Pada akhirnya, itu harus diterapkan dan diadaptasikan sesuai kebutuhan dan konteks.....
Namun, ada juga orang-orang yang sering menganggap design pattern itu wajib dan terlalu tenggelam di dalamnya seolah-olah itu jawaban teladan...
Belakangan ini, untuk MSA juga terasa mirip—semakin banyak orang yang menganggap harus selalu MSA tanpa syarat.
Rasanya seperti perdebatan ayam lebih dulu atau telur lebih dulu.
Bukankah masalahnya bukan pada microservices, melainkan pada ekspansi layanan yang tidak terkendali?
Saya rasa keseimbangan yang tepat itu penting.
Begitu beralih ke microservices, fitur baru bisa berujung pada = microservice baru,
jadi sepertinya pengelolaannya akan makin sulit.
Saya jadi teringat pada tulisan berjudul
Goodbye Microservicesyang sebelumnya pernah dimuat di blog teknis Segment.Meskipun Segment juga merupakan CDP yang memproses sangat banyak data secara real-time, mereka beralih dari arsitektur microservices ke struktur monolit dan merangkum alasan-alasannya di blog tersebut. Menurut saya, ini juga sejalan dengan tulisan ini dalam beberapa hal :)
https://segment.com/blog/goodbye-microservices/
Secara umum saya cukup sependapat.
Developer di perusahaan kami berjumlah 5 orang, jadi saya rasa sampai saat ini masih tepat untuk berorientasi pada monolith (RubyOnRails).
Kalau nanti menjadi proyek yang dikembangkan secara bersamaan oleh lebih dari 50 orang seperti pada tulisan di atas, sepertinya saat itu kami akan mengembangkan monolith kedua.
Kalau perusahaannya berukuran 5-50 orang, sebaiknya pakai Monolith saja << ini maksudnya total jumlah anggota, bukan jumlah developer, kan?
Sepertinya yang dibicarakan adalah skala perusahaan~
Kalau bisa, pertahankan arsitektur monolit selama mungkin < sangat setuju. Saat dipisah, biaya pemeliharaannya memang membengkak.
Saya rasa ini adalah tulisan sebagai reaksi terhadap MSA yang mulai menjadi dogma, dan dalam hal itu tampaknya punya makna tersendiri.