Microservice sebagai Gaya Arsitektur
Microservice architectural style adalah pendekatan mengembangkan satu aplikasi sebagai suite dari service-service kecil yang independen, di mana masing-masing:
- Berjalan dalam proses sendiri.
- Berkomunikasi lewat mekanisme ringan (lightweight mechanisms), sering berupa HTTP resource API.
- Dibangun di sekitar kapabilitas bisnis.
- Dapat di-deploy secara independen memakai mesin otomasi deployment penuh.
- Punya manajemen data terdesentralisasi minimal.
Cerita sukses microservice (mis. Netflix) sering dibandingkan dengan pendekatan monolitik tradisional.
Monolithic vs Microservices
Karakteristik Monolithic
- Dibangun sebagai satu unit (single codebase).
- Perubahan apa pun pada sistem melibatkan build dan deploy seluruh aplikasi server.
- Scaling dilakukan dengan mereplikasi seluruh aplikasi di banyak server.
| Kelebihan | Kekurangan (pain points) |
|---|---|
| Codebase tunggal → mudah dikembangkan, didukung IDE | Change cycle semua fitur terikat jadi satu (harus deploy semua untuk ubah satu bagian) |
| Mudah scale secara horizontal (replikasi) | Scaling sulit dilakukan granular per komponen |
| Biaya pengembangan & maintenance lebih rendah | Availability jadi masalah karena tight coupling antar komponen |
| Lebih cepat & sederhana di awal | Codebase besar, banyak komponen tanpa ownership yang jelas; siklus deployment jadi panjang seiring aplikasi tumbuh |
Karakteristik Microservice Architecture
- Distributed / componentization via services — komponen di-deploy secara terpisah (separately deployed).
- Infrastructure Automation — mendukung Continuous Integration & Continuous Delivery.
- Decentralized Data Management — setiap service idealnya punya database sendiri (bounded context); super decoupled, mungkin butuh replikasi data antar service.
- Sering dijalankan dalam bentuk containerized.
- Karakteristik desain: smart endpoints, dumb pipes (logika ada di endpoint/service, bukan di pipe/middleware — kebalikan dari filosofi ESB tradisional), API publik yang simple & stateless (RESTful), bullet proof (tahan gagal), didesain “dari luar” (designed from the outside), self-described, reuse tinggal konfigurasi, platform agnostic, siap terhadap constant change, dan self service.
Dua konsep baru yang unik pada microservice dibanding SOA monolitik klasik: Distributed/Separately Deployed (komponen dapat di-deploy terpisah tanpa harus deploy seluruh arsitektur, didukung Continuous Integration/Delivery) dan Decentralized Data Management (database per service, bounded context).
Infrastructure Automation
Untuk mendukung deployment yang sering & independen, dibutuhkan pipeline otomasi mencakup:
- Compile, unit & functional test
- Acceptance test
- Integration test
- User acceptance test
- Performance test
Orchestration Style pada Microservices
Service orchestration tidak lebih disukai (not preferred) dalam microservice — pendekatan yang lebih umum adalah memakai broker/service discovery agent dan/atau Message Queue untuk komunikasi antar service, dibanding satu orchestrator terpusat seperti pada BPEL/SOA klasik.
Styles of Communication in Microservices
| Gaya | Deskripsi | Karakteristik |
|---|---|---|
| Synchronous blocking | Make call and blocks operation menunggu response | Request-response via HTTP; sederhana, tapi bisa membentuk chain of calls yang panjang |
| Asynchronous non-blocking | Microservice yang mengirim call tetap bisa lanjut memproses, terlepas dari apakah call sudah diterima | Bisa berupa Request-response atau Event-driven; cocok untuk proses yang kompleks & tidak butuh jawaban cepat |
- Request-response: microservice mengirim request ke microservice lain meminta sesuatu dilakukan, dan mengharapkan response berisi hasilnya.
- Event-driven: microservice memancarkan (emit) event, microservice lain men-subscribe dan bereaksi sesuai event tersebut.
Aplikasi berbasis microservice harus di-design for failure — karena sifatnya yang terdistribusi, kegagalan salah satu service adalah keniscayaan yang harus diantisipasi (lihat juga pola Circuit Breaker di 13_SOA Performance, Scalability & Availability).
Challenges pada Microservices
- Management harus baik — banyak service kecil butuh pengelolaan yang cermat.
- Butuh service discovery yang baik (karena lokasi service bisa dinamis, terutama di lingkungan container/cloud).
- Fan out bisa menjadi sangat banyak dan crowded (satu request bisa memicu panggilan berantai ke banyak service).
- Dependency antar service harus dikelola dengan baik.
- Data serialization overhead — biaya serialisasi/deserialisasi data meningkat karena komunikasi antar proses/jaringan jauh lebih sering dibanding pemanggilan fungsi lokal pada monolith.
Flashcard
flashcards Apa definisi microservice architectural style? :: Pendekatan mengembangkan satu aplikasi sebagai suite service-service kecil independen, masing-masing berjalan di proses sendiri, berkomunikasi lewat mekanisme ringan (mis. HTTP API), dibangun sekitar kapabilitas bisnis, dan dapat di-deploy independen. Sebutkan 2 karakteristik monolithic (positif dan negatif) :: Positif: codebase tunggal mudah dikembangkan & scale horizontal. Negatif: change cycle semua fitur terikat jadi satu, scaling sulit granular, availability rentan karena tight coupling. Sebutkan 2 konsep yang UNIK pada Microservice dibanding SOA monolitik klasik :: (1) Distributed/Separately Deployed — komponen di-deploy terpisah, didukung CI/CD; (2) Decentralized Data Management — database per service (bounded context). Apa arti filosofi “smart endpoints, dumb pipes” pada microservice? :: Logika bisnis berada di endpoint/service itu sendiri (smart), sedangkan mekanisme komunikasi/pipe dibuat sederhana (dumb) — kebalikan dari pendekatan ESB tradisional yang smart pipe. Apakah service orchestration disukai dalam microservice? Jelaskan :: Tidak lebih disukai (not preferred); microservice lebih memilih pendekatan broker/service discovery agent dan/atau Message Queue dibanding satu orchestrator terpusat. Sebutkan 2 gaya komunikasi utama pada microservice :: Synchronous blocking (request-response HTTP, menunggu response) dan Asynchronous non-blocking (bisa request-response atau event-driven, tidak perlu menunggu). Apa perbedaan request-response dan event-driven pada komunikasi asynchronous? :: Request-response: microservice meminta sesuatu dilakukan dan mengharapkan response hasil. Event-driven: microservice memancarkan event, microservice lain subscribe dan bereaksi. Sebutkan 4 tantangan utama microservice :: Management yang baik, kebutuhan service discovery yang baik, fan out yang bisa jadi sangat banyak, dependency antar service, dan data serialization overhead. Apa maksud “design for failure” pada microservice? :: Karena sifat terdistribusinya, aplikasi microservice harus didesain mengantisipasi kegagalan salah satu service sebagai hal yang lumrah terjadi, bukan kondisi luar biasa.