Belajar Microservices - Sejarah, Latar Belakang & Mengapa Microservices

#Pendahuluan

Setelah di episode 0 kita menyiapkan environment — memastikan Bun, Docker, dan tooling lainnya siap — pada episode ini kita menarik napas sejenak dan memahami mengapa microservices ada. Arsitektur bukan sekadar pilihan gaya; ia adalah jawaban atas masalah nyata yang muncul saat aplikasi dan tim berkembang.

Mengapa harus memahami sejarahnya? Karena keputusan arsitektur paling mahal adalah yang dibuat tanpa memahami konteksnya. Kalian akan sering mendengar "pakai microservices saja" — padahal jawaban yang benar sering kali "mulai dari monolith". Memahami perjalanan dari monolith ke microservices akan memberi kalian naluri kapan harus pindah arsitektur, dan kapan tidak.

#Dari Monolith ke Microservices

#Monolith: Satu Codebase, Satu Deployment, Satu Database

Aplikasi monolitik adalah cara paling alami membangun software: satu codebase, satu proses, satu deployment, dan (umumnya) satu database. Keunggulannya jelas — deployment simpel, debugging mudah karena semua kode di satu tempat, dan transaksi database tetap ACID.

Masalahnya muncul saat skala bertambah. Aplikasi e-commerce besar menjadi fat monolith: ratusan modul dalam satu codebase. Setiap perubahan kecil memaksa build dan deploy seluruh aplikasi. Tim yang bekerja di modul checkout tidak bisa deploy tanpa menunggu tim modul pembayaran. Satu bug di satu fitur bisa membawa seluruh aplikasi down. Skala per-fitur juga mustahil — kalian tidak bisa "menaikkan" hanya bagian keranjang jika menerima lonjakan traffic; yang bisa dinaikkan hanya seluruh aplikasi.

#SOA: Jalan Tengah yang Berat

Sebelum microservices, dunia enterprise mencoba SOA (Service-Oriented Architecture). SOA membawa ide yang sama: pecah aplikasi ke layanan-layanan bisnis yang saling bicara. Tapi implementasi SOA klasik berat: bergantung pada ESB (Enterprise Service Bus) raksasa sebagai middleware terpusat, kontrak XML yang rumit, dan proses governance yang birokratis. Akibatnya, SOA sering terjebak menjadi "pusat kegagalan" baru — satu ESB raksasa yang lambat dan mahal.

Aspek	Monolith	SOA klasik	Microservices
Granularitas	Satu unit besar	Layanan besar + ESB	Layanan kecil mandiri
Komunikasi	Function call	ESB/XML	REST/gRPC/event ringan
Database	Satu database	Shared database	Database per layanan
Deployment	Satu proses	Terpusat via ESB	Independen per layanan

#Ledakan Cloud & Container: Microservices Menjadi Praktis

Ide memecah aplikasi bukan hal baru, tapi microservices baru praktis diadopsi sekitar 2014-2016. Pemicunya dua hal besar:

Cloud computing murah — memprovisi VM atau instance baru dalam hitungan menit, sehingga punya banyak host untuk banyak layanan tidak lagi mahal.
Container (Docker) — mengemas runtime, dependency, dan konfigurasi per layanan ke image yang identik di semua environment. Container membuat deploy satu layanan sekecil mungkin: pull image, kejar versi, replace.

Di masa ini Martin Fowler & James Lewis menulis artikel terkenal Microservices (2014), dan nama tersebut menjadi istilah resmi. Kombinasi cloud + container mengubah microservices dari teori mahal menjadi praktik yang bisa dilakukan tim kecil sekalipun.

#Mengapa Microservices Populer di 2026

#Independensi Setiap Tim, Deploy, dan Skala

Layanan bisa dikembangkan, di-deploy, dan diskalakan secara independen. Tim produk tidak perlu menunggu tim pembayaran; fitur baru order-service bisa rilis minggu ini tanpa menyentuh layanan lain. Ini menyelesaikan masalah utama monolith: bottleneck koordinasi.

#Technology Diversity

Setiap layanan bebas memilih stack terbaik untuk masalahnya. Layanan notifikasi yang I/O-heavy bisa pakai Go; layanan katalog yang butuh data kompleks bisa pakai Python; layanan lain cukup TypeScript. Microservices juga memungkinkan migrasi pelan-pelan — satu layanan di-refactor ke bahasa baru tanpa menulis ulang seluruh aplikasi.

#Skalabilitas Selektif

Kalian hanya menaikkan layanan yang sibuk. Saat campaign berlangsung, hanya product-service dan api-gateway yang di-scale — payment-service yang jarang dipakai tetap ramping. Ini jauh lebih murah dibanding men-skala seluruh monolith.

#Kontra & Kompleksitas yang Harus Jujur Diakui

Microservices membayar kemudahan operasional dengan kompleksitas sistem yang nyata:

#Distributed System: Network Call dan Partial Failure

Panggilan antar layanan melewati jaringan — dan jaringan bisa gagal, lambat, atau mengembalikan hasil tidak sesuai urutan. Konsep partial failure menjadi kenyataan: order-service bisa sukses, tapi payment-service down. Debugging lintas node jauh lebih sulit daripada stack trace satu proses: kalian harus menyusuri trace dari gateway ke database dan kembali.

#Operational Overhead

Setiap layanan butuh CI/CD sendiri, monitoring sendiri, dan pipeline observability sendiri. Satu tim dengan 5 layanan = 5 pipeline, 5 guarded deploy, 5 set dashboard. Inilah mengapa observability, orchestration (Kubernetes), dan platform engineering menjadi profesi tersendiri.

#Network Latency dan Konsistensi

Data tersebar di banyak database. Tidak ada join lintas layanan — kalian butuh event, aggregasi, atau duplikasi data yang disengaja (tentang ini di fase 3-4). Transaksi lintas layanan tidak bisa ACID; butuh saga pattern.

#Modular Monolith: Tren 2026

Tren penting 2026 adalah modular monolith sebagai langkah pertama yang lebih aman. Idenya: mulai dari satu codebase & satu deployment, tapi dengan batas modul yang tegas — setiap modul punya boundary domain sendiri, database schema terpisah di dalam satu database, dan API internal yang jelas. Saat volume tim dan traffic membenarkan, modul-modul ini bisa "diiris" menjadi microservices mandiri tanpa penulisan ulang besar-besaran.

Modular Monolith → Microservices

Modules:  [auth] [product] [cart] [order] [payment] [notification]
                          ↓ (split saat volume tim/traffic memadai)
Services: auth → product → cart → order → payment → notification

Note

Di series ini kita bangun langsung sebagai microservices karena tujuannya belajar arsitekturnya. Tetapi prinsip yang sama berlaku: setiap layanan ditulis dengan boundary domain yang jelas seperti modul — kalian sudah membangun fondasi modular monolith sejak episode pertama, hanya terpisah menjadi proses yang berbeda.

#Penutup

Pada episode 1 ini, kalian telah menelusuri perjalanan arsitektur dari monolith, SOA, hingga microservices yang populer karena cloud dan container pada 2014-2016.

Inti yang harus dibawa pulang:

Monolith simpel tapi sulit diskalakan per-fitur; SOA berat karena ESB terpusat.
Cloud + container (2014-2016) membuat microservices praktis diadopsi.
Keunggulan: independensi tim/deploy/scale, technology diversity, skalabilitas selektif.
Kompleksitas: distributed system, partial failure, operational overhead, konsistensi.
Modular monolith adalah tren 2026 — mulai dari monolith ber-batas modul jelas.

Di episode 2 selanjutnya, kita akan memilih konsep dasar & arsitektur utama microservices — service boundaries dengan DDD/bounded context, database per service, API gateway/BFF, komunikasi sinkron vs asinkron, dan mengenalkan studi kasus utama series: e-commerce tokokita. Sampai jumpa di episode 2!