Belajar Arsitektur Microservices dari Building Microservices (2nd Edition)

Pernahkah kamu merasa frustrasi karena perubahan kecil pada satu baris kode di aplikasi kantormu harus tertahan berbulan-bulan hanya karena harus menunggu antrean rilis dari belasan tim lain? Masalah ini sering kali muncul ketika sistem yang awalnya rapi perlahan menjadi kaku dan saling mengunci seiring bertumbuhnya organisasi. Dalam buku Building Microservices (2nd Edition), Sam Newman memberikan pandangan yang sangat seimbang mengenai solusi untuk masalah ini.

Buku ini tidak sekadar memuji teknologi baru, melainkan memberikan panduan realistis tentang bagaimana merancang, menerapkan, dan mengelola sistem perangkat lunak terdistribusi. Melalui buku ini, kamu akan belajar bahwa microservices bukan sekadar tren, melainkan sebuah pilihan arsitektur yang memiliki konsekuensi nyata pada cara tim bekerja dan sistem beroperasi.

Memahami Esensi Microservices yang Sebenarnya

Banyak pengembang salah kaprah mengira microservices hanya soal memecah kode menjadi bagian-bagian kecil. Menurut Sam Newman, esensi utama dari microservices adalah kemandirian penerapan (independent deployability). Artinya, kamu harus bisa memperbarui satu layanan tanpa perlu merilis layanan lain secara bersamaan. Jika kamu masih harus merilis banyak layanan secara serentak, maka sistemmu sebenarnya hanyalah kumpulan kode terdistribusi yang tetap saling mengunci.

Untuk mencapai kemandirian ini, kamu perlu menerapkan prinsip penyembunyian informasi (information hiding). Konsep ini menekankan bahwa bagian luar sistem tidak boleh tahu bagaimana cara kerja di bagian dalam. Jika kamu menggunakan Arsitektur Hexagonal, kamu memisahkan logika internal dari antarmuka luar. Dengan begitu, jika kamu mengubah struktur tabel atau kode di dalam satu layanan, bagian lain tidak akan terganggu.

Perbedaan mencolok antara pendekatan ini dengan arsitektur tiga tingkat (three-tiered architecture) tradisional terletak pada cara pemotongan sistemnya:

• Arsitektur Tradisional: Memotong sistem secara horizontal berdasarkan lapisan teknis seperti antarmuka, logika bisnis, dan database. Masalah muncul saat ada perubahan fitur, kamu harus mengubah ketiga lapisan tersebut sekaligus.
• Microservices: Memotong sistem secara vertikal berdasarkan fungsi bisnis. Seluruh kode untuk satu tujuan bisnis tertentu dikumpulkan di satu tempat, sehingga lebih fleksibel terhadap perubahan kebutuhan bisnis.

Menentukan Batas Layanan yang Tepat

Salah satu tantangan terbesar adalah menentukan seberapa besar atau kecil sebuah layanan. Newman menyarankan agar ukuran layanan cukup ringkas agar alur kerjanya bisa dipahami oleh satu tim kecil tanpa membingungkan siapa pun. Jika batas layanan tidak ditentukan dengan baik, kamu akan terjebak dalam "monolit terdistribusi", di mana layanan terpisah di jaringan tetapi perilisannya tetap saling mengunci.

Untuk menentukan batas ini, kamu bisa menggunakan metode Domain-Driven Design (DDD). Ada dua konsep kunci di sini:

• Ubiquitous Language: Istilah di dalam kodemu harus sama persis dengan kata yang diucapkan oleh orang bisnis. Jika orang bisnis menyebut "rekening", maka kodenya harus bernama sama. Ketidakjelasan bahasa dapat membuat kode menjadi sangat rumit dan kehilangan makna bisnisnya.
• Aggregate: Sekelompok data dan aturan bisnis yang harus selalu konsisten bersama. Aturan praktisnya adalah satu aggregate harus dikelola penuh oleh satu layanan saja.

Jika kamu kesulitan menentukan batas-batas ini secara visual, kamu bisa mencoba teknik Event Storming. Dalam teknik ini, tim teknis dan perwakilan bisnis berkumpul untuk menyusun peristiwa penting dalam bisnis secara berurutan menggunakan catatan warna-warni di dinding. Cara ini sangat ampuh untuk menemukan batasan layanan yang alami berdasarkan alur bisnis yang sebenarnya.

Mengelola Data dan Komunikasi antar Layanan

Ketika sistem mulai terpecah, manajemen data menjadi jauh lebih rumit. Satu aturan emas yang ditekankan oleh Newman adalah: jangan pernah berbagi database antar layanan. Begitu dua layanan membaca dan menulis tabel yang sama, batas pemisahnya langsung hilang. Perubahan skema di satu layanan akan langsung merusak layanan lainnya.

Selain masalah database, komunikasi antar layanan juga harus dikelola dengan hati-hati. Menggunakan panggilan sinkron (request-response) secara berlebihan sangat berbahaya. Bayangkan jika layanan pemroses pesanan harus menunggu layanan pembayaran, yang kemudian menunggu layanan deteksi penipuan. Jika satu layanan melambat, seluruh rantai transaksi akan macet. Solusinya adalah beralih ke pola asinkron atau event-driven.

Dalam pola asinkron, layanan cukup mengirimkan pesan ke antrean (queue) dan melanjutkan pekerjaannya. Contohnya, layanan pemesanan cukup mengirim kabar bahwa pesanan telah dibuat, lalu layanan gudang akan memprosesnya secara mandiri saat ia siap. Untuk menangani transaksi yang terpecah di berbagai database, kamu bisa menggunakan pola saga. Pola ini memecah transaksi besar menjadi rangkaian transaksi lokal. Jika salah satu langkah gagal, sistem akan menjalankan transaksi kompensasi untuk membatalkan perubahan sebelumnya, seperti mengembalikan uang pelanggan jika stok barang ternyata habis.

Strategi Transisi dan Operasional Sistem

Jangan terburu-buru merombak seluruh aplikasi lama menjadi ratusan layanan baru dalam semalam. Perubahan mendadak sering kali berakhir dengan kegagalan besar. Newman menyarankan pendekatan bertahap menggunakan pola Strangler Fig. Mirip seperti pohon ara pencekik, kamu membangun layanan baru di samping monolit lama secara perlahan. Mulailah dari fungsi bisnis yang paling mudah dan rendah risikonya untuk membiasakan tim dengan pola kerja baru.

Setelah sistem berjalan, fokusmu harus bergeser ke aspek operasional. Karena sistem terdistribusi sangat kompleks, kamu membutuhkan dua hal utama:

1. Otomatisasi Penuh: Mulai dari pengujian otomatis hingga pembangunan artefak aplikasi. Jangan pernah membuat ulang paket aplikasi saat berpindah dari lingkungan uji ke produksi.
2. Observabilitas: Kamu butuh kemampuan untuk memantau sistem secara menyeluruh. Gunakan nomor identifikasi pelacak pada setiap permintaan agar kamu bisa menelusuri perjalanan data yang melewati belasan layanan berbeda.

Terakhir, kamu harus membangun ketahanan sistem. Di dunia microservices, kegagalan adalah hal yang pasti terjadi. Gunakan pola circuit breaker untuk menghentikan upaya panggilan ke layanan yang sedang bermasalah. Hal ini mencegah penumpukan koneksi yang dapat meruntuhkan seluruh server saat ada satu mitra yang merespons sangat lambat.

Kesimpulan dan Langkah Selanjutnya

Arsitektur microservices adalah pilihan strategis yang sangat kuat, namun ia bukan tanpa biaya. Ia memberikan kecepatan rilis dan skalabilitas, tetapi menuntut kompleksitas tambahan pada komunikasi, data, dan operasional. Kamu harus memastikan bahwa manfaat yang didapat sebanding dengan kerumitan yang harus dikelola oleh timmu.

Ingin mendalami lebih jauh tentang strategi implementasi, pola komunikasi, hingga detail teknis lainnya dalam membangun sistem terdistribusi? Baca ringkasan lengkap Building Microservices (2nd Edition) di BacaApps untuk panduan mendalam yang akan membantumu menjadi pengembang perangkat lunak yang lebih handal.

Baca ringkasan lengkapnya di BacaApps: Building Microservices (2nd Edition) karya Sam Newman