Microservices adalah Pajak yang Tak Mampu Ditanggung Startup

• Memisahkan kode menjadi microservices terlalu dini di startup tahap awal menyebabkan penurunan produktivitas tim yang serius dan peningkatan kompleksitas
• Arsitektur monolitik memberikan optimasi untuk bertahan hidup melalui deployment yang sederhana, rilis fitur baru yang cepat, dan kolaborasi yang efisien
• Microservices hanya memberikan manfaat pemisahan saat ada kebutuhan skalabilitas besar, workload yang beragam, atau kebutuhan runtime yang terpisah
• Pemisahan layanan yang berlebihan, repositori yang bertebaran, lingkungan pengembangan lokal yang tidak stabil, dan ketidaksesuaian tech stack berujung pada perlambatan dan turunnya moral tim
• Startup sebaiknya memulai dengan monolit dan mengambil pendekatan hati-hati dengan memisahkan hanya saat bottleneck yang jelas muncul

---

Pendahuluan dan latar belakang

• Kelangsungan hidup startup ditentukan oleh iterasi yang cepat, pengiriman fitur baru, dan penciptaan nilai bagi pengguna
• Pemilihan arsitektur dasar proyek, tech stack, dan bahasa pemrograman memengaruhi kecepatan tim
• Adopsi microservices terlalu dini secara formal terlihat canggih, tetapi dalam praktik justru menyebabkan penurunan produktivitas, layanan yang belum matang, dan kompleksitas berlebihan
• Data: muncul berbagai biaya pengembangan seperti orkestrasi layanan, masalah Docker/skrip, CI/CD yang terduplikasi, coupling antar layanan, biaya observability, dan pengujian yang tersebar
• Alih-alih gegabah menuju arsitektur yang rumit, penting untuk menekankan arsitektur yang pragmatis

Kekuatan monolit

• Baik itu SaaS maupun wrapper database sederhana, aplikasi akan makin kompleks seiring waktu, tetapi arsitektur monolit lebih mudah dipertahankan agar tetap sederhana dan fleksibel
• Deployment mudah, didukung framework populer (Django, ASP.Net, Nest.js, dll.), dan mendapat banyak manfaat dari komunitas open source
• Contoh nyata: sebuah startup properti menggunakan monolit Laravel untuk dengan mudah mencapai banyak integrasi pihak ketiga dan perluasan fitur
• Tanpa memperkenalkan infrastruktur yang rumit atau memecah ke microservices, tim bisa fokus memenuhi kebutuhan bisnis dan ekspektasi
• Pelajaran: kesederhanaan arsitektur membantu tim fokus pada deployment, dan skalanya pun cukup asalkan berhati-hati agar modularisasi internal tidak gagal

Apakah microservices selalu yang terbaik?

• Banyak engineer menganggap microservices adalah jawaban terbaik, tetapi kenyataannya nilainya baru benar-benar terlihat saat ada alasan khusus seperti kebutuhan scaling
• Pada tahap dengan anggota sedikit, skala kecil, dan perubahan cepat, pendekatan ini justru menimbulkan efek sebaliknya berupa infrastruktur yang terduplikasi, pengembangan lokal yang lambat, dan siklus iterasi yang lambat
• Perusahaan seperti Segment juga pernah mengalami transisi akibat struktur yang tidak efisien
• Pelajaran: microservices hanyalah alat untuk menyelesaikan bottleneck, bukan template awal

Mengapa microservices sering gagal khususnya pada tahap awal

1. Batas layanan yang arbitrer

• Upaya membagi layanan berdasarkan logika bisnis dengan meminjam teori domain-driven design dan clean architecture → batas antara logika nyata dan layanan sering tidak benar-benar selaras
• Contoh: pemisahan pengguna, autentikasi, dan otorisasi meningkatkan kompleksitas deployment serta kesulitan pengembangan API
• Pemisahan pada tahap ketika bottleneck nyata belum muncul membuat sistem menjadi tidak stabil dan lambat
• Mensimulasikan pemisahan di masa depan dengan flag atau toggle internal, sambil mengeksplorasi batas yang organik alih-alih buru-buru mengerjakan infrastruktur, lebih efektif
• Pelajaran: keputusan pemisahan harus didasarkan pada bottleneck nyata, bukan teori

2. Repositori/infrastruktur yang berlebihan

• Gaya kode, pengujian, konfigurasi, dokumentasi, dan CI/CD semuanya bertambah seiring jumlah layanan
• Jika menggunakan struktur monorepo, semua konfigurasi bisa dikelola di satu tempat untuk meningkatkan konsistensi kode dan efisiensi kolaborasi
• Dalam kasus Node.js, alat seperti nx atau turborepo mempermudah pengelolaan dependensi dan build antar layanan internal
• Kekurangannya termasuk dependensi yang rumit, kebutuhan tuning performa CI, dan perlunya alat build yang lebih cepat
• Ekosistem Go juga dapat dikelola dalam satu workspace pada awalnya, lalu mempertimbangkan pemisahan modul saat skala membesar
• Pelajaran: tim kecil bisa menghemat waktu dengan monorepo dan infrastruktur bersama

3. Lingkungan pengembangan lokal yang tidak stabil

• Waktu yang berlebihan untuk menjalankan secara lokal, skrip yang rumit, dan dependensi spesifik sistem menyebabkan onboarding melambat dan produktivitas menurun
• Kurangnya dokumentasi, masalah kompatibilitas, dan hack khusus OS (misalnya skrip khusus macOS) menjadi hambatan
• Dalam satu proyek, kompleksitas Docker dikurangi lewat proxy Node.js sehingga waktu onboarding developer berkurang
• Pelajaran: jika aplikasi hanya berjalan di satu OS, produktivitas tim pada akhirnya bergantung pada keandalan satu laptop

4. Ketidaksesuaian tech stack

• Node.js dan Python bagus untuk iterasi cepat, tetapi dalam lingkungan microservices sering memunculkan masalah ketidaksesuaian build/runtime
• Go unggul dalam binary statis, build cepat, dan kesederhanaan operasional
• Pemilihan tech stack harus dilakukan dengan hati-hati sejak awal, dan jika perlu, bahasa campuran bisa digunakan lewat protokol seperti gRPC
• Jika tidak ada kebutuhan khusus seperti ML atau ETL, mencampur stack justru hanya menambah kompleksitas
• Pelajaran: pilih stack yang sesuai dengan realitas tim, bukan sekadar ambisi

5. Kompleksitas tersembunyi: komunikasi dan monitoring

• Dalam microservices, service discovery, versioning API, distributed tracing, pengelolaan log terpusat, dan lain-lain menjadi kebutuhan wajib
• Jika di monolit pelacakan bug atau gangguan cukup dengan satu stack trace, di lingkungan terdistribusi semuanya jauh lebih rumit
• Untuk melakukannya dengan benar, perlu adopsi alat khusus seperti OpenTelemetry dan pembangunan stack observability
• Harus disadari bahwa sistem terdistribusi adalah investasi wajib untuk tantangan engineering tambahan

Situasi ketika microservices memang efektif

• Isolasi workload: memisahkan pekerjaan asinkron tertentu seperti pemrosesan gambar atau OCR bisa efisien
• Ketimpangan kebutuhan scaling: jika web API dan workload ML memiliki kebutuhan hardware dan operasi yang berbeda, masing-masing sebaiknya dipisah
• Kebutuhan runtime yang berbeda: komponen seperti kode legacy C++ yang tidak kompatibel dengan runtime aplikasi utama sebaiknya dipertahankan sebagai layanan terpisah
• Dari contoh organisasi engineering besar (misalnya Uber), pendekatan ini hanya cocok ketika ada kebutuhan organisasional yang jelas dan kemampuan operasi yang matang
• Bahkan di tim kecil pun, pemisahan kadang praktis jika pengelolaannya sederhana seperti layanan analitik eksternal
• Pelajaran: adopsi hanya pada workload yang benar-benar memiliki manfaat pemisahan yang jelas

Panduan praktis untuk startup

• Mulailah dengan monolit, dan fokus bekerja dengan framework yang sudah terbukti
• Satu repositori lebih menguntungkan bagi tim tahap awal dari sisi efisiensi operasional, pengelolaan, dan keamanan
• Menyederhanakan lingkungan pengembangan lokal itu penting, dan jika sulit, dokumentasi serta video panduan yang detail wajib disediakan
• Berinvestasilah lebih awal di CI/CD untuk mengotomatisasi pekerjaan berulang dan mengurangi beban mental tim
• Pisahkan secara selektif hanya saat bottleneck yang jelas muncul, dan jika tidak, fokuslah pada modularisasi di dalam monolit serta penguatan pengujian
• Tujuan utama adalah menjaga kecepatan pengembangan
• Pelajaran: mulai dari kesederhanaan, lalu scale sesuai kebutuhan pemisahan yang nyata

Jika tetap harus memakai microservices

• Evaluasi tech stack dan investasi pada alat developer experience: perlu menyiapkan otomatisasi per layanan, skrip yang jelas, dan alat manajemen deployment terintegrasi
• Protokol komunikasi layanan yang andal dan standardisasi: perlu memahami tambahan implementasi seperti konsistensi skema pesan, dokumentasi, dan penanganan error
• Stabilisasi infrastruktur testing: pengujian unit, integrasi, dan E2E harus diperluas agar sesuai dengan pemisahan layanan
• Pertimbangkan library bersama: kode umum untuk observability dan komunikasi harus dijaga seminimal mungkin agar tidak memicu rebuild semua layanan terlalu sering
• Observability harus diadopsi sejak awal: mulai dari alat logging dasar seperti log JSON terstruktur dan correlation ID
• Kesimpulannya, saat memilih menerima kompleksitas, yang penting adalah merancang sistem yang tetap bisa dikelola dengan disiplin penuh

Kesimpulan

• Adopsi microservices secara tergesa-gesa hanya menambah beban, jadi kesederhanaan harus menjadi prioritas utama
• Jangan memisahkan tanpa pain point yang jelas; yang penting adalah menambahkan kompleksitas minimum yang diperlukan untuk bertahan dan tumbuh
• Bertahan hidup dulu, scaling belakangan

[kuil09]

Saya secara umum setuju dengan isi tulisan aslinya.
Saya rasa ini adalah masalah pengalaman dalam organisasi.
Coba bayangkan berjualan makanan dari food truck lalu berkembang menjadi restoran.
Sejak awal, pengalaman para pemangku kepentingan benar-benar belum cukup untuk mempertimbangkan pembagian kerja dan spesialisasi.

[dhlee0305]

Menurut saya, startup harus memilih cara yang berbiaya rendah untuk memperpanjang masa bertahan hidup. Microservices sama sekali tidak murah. Saat benar-benar diterapkan di lapangan, pendekatan ini menimbulkan biaya yang cukup besar. Sebisa mungkin, merancang arsitektur yang sesuai dengan layanan perusahaan sendiri adalah cara untuk mendapatkan efek serupa dengan biaya yang lebih rendah.
Bukan berarti microservices itu buruk. Ini adalah model yang membutuhkan biaya besar.

[mhj5730]

Menurut saya, cukup punya dua saja: monolitik khusus sinkron dan monolitik khusus asinkron... Saya melihat penerapan microservices pada akhirnya bergantung pada skala tabel yang harus dikelola di DB. Jika jumlah tabelnya sangat banyak dan kompleks, barulah perlu mempertimbangkan MSA; kalau sederhana, monolitik adalah pilihan yang paling pas.

[roxie]

Ketika semua gelombang ini telah berlalu, bagaimana generasi mendatang akan mengingat era ini?

[n1ghtc4t]

Saat itu pun ada gelombangnya sendiri...

[bungker]

Saya juga berpikir microservice punya banyak kelebihan di startup. Pertama, saya benar-benar merekomendasikan kelebihan menggunakan monorepo.

• Saat arah produk berubah, bagian yang perlu diubah pada microservice lebih jelas dan lebih sedikit dibanding monolith. Menurut saya ini sangat besar nilainya.
• Di era pengembangan berbasis AI, unit kecil pada microservice lebih mudah dikembangkan dengan bantuan AI. (Bukan berarti monolith tidak bisa)
• Saya mengakui beban CI/CD, tetapi ada juga layanan yang dihentikan pada tahap penentuan arah. Bahkan jika dibangun setelah arah akhirnya ditetapkan, tingkatnya hampir seperti copy-paste sehingga bisa dibangun dalam waktu kurang dari seminggu.
• Kekuatan open source yang unggul per bahasa sangat jelas. Security dan business logic bisa memakai Java, AI memakai Python; dalam struktur microservice, kita bisa memanfaatkan open source sebanyak mungkin.

[andone]

Saya setuju bahwa di era pengembangan AI saat ini, menerapkan sistem dalam unit-unit kecil dengan tanggung jawab tunggal adalah hal yang esensial.

[bus710]

Ini sempat sedikit muncul di kolom opini juga, tetapi ekosistem beam/otp memang terasa cukup fleksibel dan bagus. Dalam kasus Gleam, sintaks bagus dari Go dan Rust dipadukan dengan stabilitas beam, sehingga menjadi bahasa yang cukup mengesankan. Sepertinya saya ingin mulai mencobanya pelan-pelan untuk proyek skala kecil.

[ndrgrd]

Kalau tim dipecah-pecah sembarangan, bahkan sekadar berkumpul dan bertukar pendapat pun jadi pekerjaan yang sangat besar.

[GN⁺]

Opini Hacker News

• Menyadari bahwa tanpa masalah skala nyata, tim besar, atau domain yang perlu berkembang secara independen, microservices hanya menambah biaya tanpa memberi manfaat; bahkan Segment juga membatalkan pemisahan microservices karena alasan ini. Intinya ini adalah pola organisasi, bukan teknologi. Biasanya lebih masuk akal menjalankan satu monolit terlebih dahulu, lalu hanya memisahkan frontend, backend, atau pekerjaan yang memakan waktu lama (mis. pembuatan PDF) menjadi layanan terpisah. Setelah jumlah layanan bertambah, barulah mulai perlu memikirkan standardisasi dan arsitektur. Untuk organisasi dengan kurang dari 200 engineer, justru sering terjadi penurunan produktivitas. Bukan karena perusahaan bertahan berkat microservices, melainkan tetap bertahan meski ada microservices.
  • Ada kecenderungan sebagian developer ingin mengadopsi microservices demi portofolio untuk karier di perusahaan besar di masa depan, padahal untuk startup nyata biasanya tidak banyak membantu. Untuk mencegah hal seperti ini dibutuhkan kepemimpinan teknis yang benar-benar bijak.
  • Pernah melihat startup dengan sekitar 50 engineer memecah sistem menjadi puluhan layanan; butuh setidaknya 6 bulan bagi orang baru untuk memahami sistem, padahal penggunanya hanya beberapa ratus, tetapi kompleksitasnya luar biasa. Setelah membakar dana VC sebesar $50 juta, akhirnya perusahaan itu gagal. Produknya inovatif dan dirancang dengan baik, tetapi semua itu tidak berarti.
  • Saat memecah layanan, ada juga pendekatan untuk tidak membagi kode, melainkan men-deploy monolit biasa secara terpisah hanya dengan flag peran. Background worker pun dijalankan bersama web server, memanfaatkan health check dan metrik, sementara load balancer membagi trafik berdasarkan peran.
  • Seperti kasus yang dialami Khan Academy, setelah monolit diskalakan cukup jauh, pengalaman yang terkumpul memungkinkan penentuan batas layanan dengan lebih tepat; pada saat itulah adopsi microservices menjadi cocok.
  • Ada alasan teknis untuk memisahkan sistem, tetapi layanan memang pada dasarnya pekerjaan yang sulit. Jika memang diperlukan, yang penting adalah sikap untuk meningkatkan kematangan, bukan menolaknya mentah-mentah hanya karena sedang tren; yang perlu dilakukan adalah menimbang trade-off.
  • Hanya karena ada "beberapa tim" bukan berarti organisasi harus langsung dipecah. Ada direktur yang begitu terbentuk dua squad kecil langsung ingin memisahkan monolit. Karena tim sering direorganisasi (setiap 9 bulan), jika batas arsitektur dipasang terlalu dini justru bisa jadi bencana. Perlu dibuktikan dulu bahwa sebuah tim layak berjalan stabil setidaknya sekitar 18 bulan sebelum dijadikan batas arsitektur.
  • Definisi microservices sejak awal memang tentang "domain yang bisa berkembang secara independen", jadi terasa tidak ada hal yang benar-benar baru di sini.
  • Ada kasus di mana hanya satu URL yang sangat khusus memiliki kebutuhan trafik/memori berbeda, sehingga tidak cocok dijalankan di server PHP dan cukup ditambahkan satu server dengan bahasa lain; hasilnya ada peningkatan performa/biaya hingga 1000 kali. Perlu juga mempertimbangkan konsep layanan ala Java/Spring/Guava apakah diwujudkan "di luar proses" atau "di dalam". Jika standardisasi stack teknis/versi dan serialisasi dilakukan dengan baik, produktivitas justru bisa naik, tetapi bila tidak ada standardisasi akan muncul kekacauan seperti miskomunikasi dan masalah kompatibilitas.
  • Conway's law (struktur kode mencerminkan struktur organisasi) memang benar adanya.
  • Layanan adalah sesuatu yang disediakan oleh manusia, dan microservices adalah layanan dalam ekonomi internal perusahaan.
  • Pengalaman 15 tahun lalu: tim kecil dengan satu solusi tunggal bisa berjalan mudah, tetapi setelah mengadopsi microservices harus susah payah menyalakan dan mengoordinasikan tiap layanan. Dari sana jadi benar-benar memahami pentingnya YAGNI (jangan membuat sesuatu sebelum benar-benar diperlukan).
  • Ada banyak alasan teknis untuk memisahkan, misalnya hanya jalur dengan trafik tinggi atau yang sangat kritikal. Di organisasi kecil biasanya bukan pilihan ideal, tetapi jika hanya jalur beban tinggi yang dipotong keluar, startup pun bisa mendapat manfaat besar.
  • Dalam praktiknya, manfaat utama microservices adalah memungkinkan kelompok kecil bekerja mandiri tanpa saling mengganggu. Namun ketika banyak tim masing-masing memiliki microservice sendiri, rapat standardisasi jadi tidak ada habisnya, dan alih-alih kolaborasi, kemampuan diplomasi seperti "jangan ikut campur urusan tim lain" justru menjadi lebih penting.
• Meski sudah disarankan bahwa tim 2-3 developer tidak perlu memakai microservices hanya karena terlihat keren, mereka tetap menjalankannya. Dua tahun kemudian mereka baru membangun ulang kode lama, dan bahkan setelah 3 tahun masih belum bisa menyelesaikan masalah deployment dan persoalan lain. Kalau sejak awal memilih modular monolith dan tidak mengabaikan nasihat, masalah seperti ini tidak akan terjadi. Sangat setuju dengan tulisan ini.
  • Orang bisa meninggalkan jejak proyek/teknologi yang terlihat mewah lalu cepat pindah kerja, sementara dampak buruknya ditanggung orang lain.
  • Microservices benar-benar berguna hanya jika tiap layanan ditangani satu tim tersendiri; belum pernah melihat contoh bagus ketika satu tim harus merawat banyak layanan sekaligus.
  • Banyak masalah muncul karena anggota tim tetap memandang microservices sebagai satu sistem tunggal (monolit). Dari desain sampai deployment, gesekan terjadi di mana-mana. Ini hanya bisa berhasil jika seluruh organisasi benar-benar punya pemahaman yang sama; ketika sistem lama diubah menjadi microservices, resistensi internal biasanya besar.
  • Pada akhirnya rasanya semua startup melewati jalan penderitaan yang mirip.
  • Bahkan pada proyek UI internal dengan 8-12 microservices, pengguna nyatanya cuma 5-10 orang, dan yang bertambah hanya kompleksitas yang tidak perlu. Tidak jelas alasannya.
  • Pernah mengadopsi microservices+Java berkat konsultasi Thoughtworks. Perusahaan konsultan itu menghasilkan uang lalu pergi, sementara organisasinya sendiri tersesat mencoba mengimplementasikan ulang monolit kaya fitur menjadi microservices terdistribusi. Proyek itu akhirnya gagal, dan perusahaannya pun hilang. Sejak itu jadi tidak percaya pada konsultan besar.
• Dengan gaya otak grug, muncul pertanyaan kenapa sengaja memilih cara yang lebih sulit dengan memecah sistem dan bahkan menambah network call.
  • Rasanya seperti menambahkan fitur "monkey patch" ke bahasa yang tadinya tidak punya itu, seperti Python.
  • Ada pendapat bahwa network call mengubah aturan (rule) menjadi hukum yang memaksa (law).
  • Dengan humor grug: ketika semakin banyak grug berotak grug, mereka jadi terjebak dalam ilusi bahwa supergrup berisi 9 grug bisa membuat bayi grug dalam 1 bulan.
• Microservices efektif untuk menyelesaikan masalah manusia dalam organisasi besar, menghilangkan hambatan birokrasi, dan memberi otonomi kepada developer. Di startup kecil manfaat nyatanya tidak besar. Meski begitu, jika pada domain tertentu perlu campuran stack teknis (mis. Elixir dan Python/Go), pemisahan seperti ini bisa diperlukan.
  • Jika aplikasi memiliki beban atau kebutuhan resource yang berbeda-beda, bahkan startup kecil pun bisa diuntungkan dengan membuat layanan terpisah. Sebagian besar logika bisnis tetap dibiarkan di monolit, dan hanya pekerjaan khusus seperti GPU yang dipisahkan. Namun pola ini sebaiknya tidak berkembang menjadi pemeliharaan 100 layanan; secara default tetap lebih baik memilih monolit dan memisahkan hanya saat benar-benar perlu.
  • Microservices justru bisa menciptakan ketergantungan organisasi dan kebutuhan koordinasi baru. Misalnya, kebijakan "pakai layanan mana saja sesukamu" sangat meningkatkan beban pemeliharaan, dan membuat sistem hanya bisa berjalan jika semua orang mempelajari semuanya. Pada akhirnya waktu malah habis untuk mencari orang yang tepat.
  • Jika ada tim yang saling bertentangan atau tumpang tindih, inefisiensi akan membesar.
• Microservices dalam arsitektur perangkat lunak mirip dengan Conway's Law (struktur organisasi memengaruhi struktur kode): setiap batas tim menciptakan batas yang harus dilintasi, dan secara internal membuat batas arsitektur besar secara artifisial biasanya tidak produktif. Sebagai gantinya, sistem bisa dikelola sebagai modular monolith dengan dependency injection, perancangan batas modul, dan penggunaan actor model; kalau nanti benar-benar perlu, pemisahan layanan pun jadi lebih mudah. Pendekatan ini memberi rasio biaya-manfaat yang baik. Ada pengalaman langsung memotong monolit 3-4 kali dengan cara ini.
  • Conway's Law adalah hukum tentang batas komunikasi. Tidak semua batas tim perlu disentuh; justru organisasi perlu disusun ulang agar sesuai dengan perangkat lunak. Artinya, setiap kali arsitektur diubah, perusahaan juga perlu reorg. Pola seperti ini malah memperparah keterputusan antara tim dan tujuan bisnis, sehingga tidak perlu membabi buta memuja gaya Amazon.
• Secara teknis, kasus microservices cocok di startup adalah ketika (1) aplikasi inti harus memakai bahasa lain (mis. Rails+R), (2) hanya sebagian layanan yang punya perbedaan skala sangat besar, atau (3) data tertentu memiliki kebutuhan keamanan/umur simpan yang berbeda (mis. data medis). Di luar itu, hampir tidak ada alasan untuk melakukan pemecahan sedetail itu; untuk organisasi kecil justru biasanya merugikan.
  • Membagi beberapa layanan baru tidak sama dengan microservices yang sesungguhnya; microservices nyata bahkan memisahkan hal-hal yang di aplikasi biasa cukup dijadikan modul.
  • Bukan hanya skala, jika kebutuhan keandalan dan ketersediaan juga sangat berbeda secara ekstrem, pemisahan layanan terpisah masuk akal. Dengan memisahkan concern untuk menjaga SLA, diharapkan risiko berkurang dan kecepatan deployment meningkat.
  • Bahkan dalam kasus seperti ini pun, ada yang melihatnya tidak jauh berbeda dari sekadar menjalankan server database secara terpisah.
• Hasil nyata microservices sebenarnya ada di sisi organisasi: masalah dipecah, tiap tim memiliki satu bagian secara penuh, dan bertanggung jawab sampai pengiriman end-to-end sehingga spesialisasi menjadi mungkin. Perubahan pada dasarnya dilakukan secara bertahap, dan API menjadi satu-satunya jalur interaksi; tidak ada berbagi database, file system, atau API tunggal. Sebagai gantinya, standardisasi dan tooling pengelolaan (termasuk monitoring, testing, CI/CD) menjadi penting, meski ini juga sampai taraf tertentu tetap dibutuhkan pada monolit maupun pendekatan lain.
  • Infrastruktur, logging, autentikasi, dan sebagainya dikelola dengan paket atau melalui gRPC, message queue, dan lain-lain. Pembuatan layanan baru jadi cepat, merge request dalam tim juga menjadi lebih kecil sehingga konflik berkurang dan produktivitas meningkat. Saat tim masih berukuran 5-10 orang dan memakai monolit, konflik, deployment, dan rilis sering bermasalah; setelah beralih ke microservices, produktivitas dan readme kolaborasi meningkat, meski aturan tentang testing, dokumentasi, endpoint, dan sebagainya tetap penting.
  • Ada juga kasus pemisahan teknis demi performa seperti pemisahan database, tetapi untuk startup pada umumnya hal ini mungkin jarang terjadi.
• Kekuatan ekosistem BEAM/OTP (Erlang, Elixir) adalah memungkinkan mempertahankan monolit sambil melatih desain yang "mirip microservices", lalu dengan mudah beralih saat pemisahan sungguhan diperlukan. Saat skala masih kecil, manfaat monolit tetap didapat; ketika membesar, scaling dan independensi bisa diperoleh sekaligus. Namun tetap perlu mempelajari objek immutable, komunikasi konkurensi, penanganan kegagalan, dan rekrutmen karyawan juga bisa lebih sulit.
• Sebagian besar setuju: di lingkungan startup, hampir mustahil menentukan batas layanan sejak awal. Namun pada tim kecil, kadang microservices menguntungkan karena API eksternal atau dependensi yang rumit. Dalam kasus seperti itu, batas jaringan memang wajib ada, sehingga menjadikannya layanan terpisah tidak terlalu menambah kompleksitas. Atau, jika ada kompleksitas build/deployment, pemisahan juga bisa menyederhanakan monolit.
• Microservices cocok hanya saat perlu skala besar atau micromanagement tim. Batas modul yang jelas tetap tidak boleh ditinggalkan. Keunggulan microservices juga bisa dimanfaatkan di dalam monolit dengan object-oriented bergaya message passing. Perlu dibiasakan untuk tidak menyentuh database secara langsung. Di bahasa seperti Java, modularisasi, namespace skema database, dan hanya mengekspos interface minimum memungkinkan testing/monitoring yang independen, dan deployment beberapa layanan sekaligus juga menjadi lebih mudah.
  • Jika batas logisnya sudah benar-benar dipahami, ada juga cara untuk menegakkannya dengan tool seperti ArchUnit.