Jika Anda bukan dummies, maka saya rekomendasikan membaca ulasan lengkap Martin Fowler tentang Microservices. Tulisan ini sebagian besar merupakan penerjemahan saya terhadap ulasan tersebut. Mari kita mulai dari penjelasan yang paling basic.

Ada dua minimarket yang akan dibangun secara berdampingan di sebuah kota. Sebut saja Alfafamart dan Indomimart (Disclaimer: nama ini fiktif, tidak ada kaitanya dengan Alfamart dan Indomaret di dunia kita, selain fakta bahwa mereka seringkali dibangun bersebelahan).

Microservices Explained

Untuk membangun minimarket impian dalam waktu satu bulan, mereka perlu membuat beberapa "services" seperti rak, keranjang belanja, mesin kasir, pengelolaan gudang, display, sampai manajemen human resource. Kondisinya adalah: keduanya memiliki jumlah karyawan yang sama: 4 tukang kayu, 4 desainer, dan 10 orang manajemen. Hanya pendekatannya saja yang berbeda.

Microservices Explained

Alfafamart mengelompokkan semua karyawan ke dalam tim yang dibentuk sesuai dengan keahlian mereka: tim manajemen, tim desainer produk, dan tim tukang kayu. Maka, proses untuk membangun rak, keranjang belanja, mesin kasir, pengelolaan gudang, display, sampai manajemen human resource terjadi secara struktural. Dimulai dengan pembuatan blueprint oleh 10 orang manajemen, penerjemahan blueprint kedalam desain produk oleh 4 desainer, dan pengerjaan desain produk oleh 4 tukang kayu. Semuanya terjadi secara sekuensial.

Indomimart mengelompokkan karyawan ke dalam tim-tim kecil sesuai dengan kebutuhan yang diperlukan. Tim pembuat rak berisi 1 tukang kayu, 1 desainer, 1 manajemen. Begitu pula dengan tim lain seperti tim keranjang belanja, tim mesin kasir, dan tim display. Hanya tim pergudangan dan tim human resource yang masing-masing hanya berisi 3 orang manajemen.

Microservices Explained

Nah, Alfafamart menggunakan pendekatan yang monolith. Sedangkan Indomimart menggunakan pendekatan microservices. Cobalah untuk menggarisbawahi pada pernyataan bahwa Indomimart memecah satu assignment besar ke dalam 'services' yang kecil-kecil memenuhi konsep utamanya Microservices: memperlakukan "services" sebagai component.

Setelah satu bulan berlalu, Alfafamart dan Indomimart, dipersenjatai dengan kompetensi tim yang tinggi, berhasil berdiri sesuai tenggat waktu. Tidak ada yang lebih cepat, tidak ada yang lebih lambat. Mereka potong pita bersamaan. Dan kini, Alfafamart dan Indomimart berdiri secara berdampingan, happily ever after dalam suasana pertarungan kapitalistik.

Hukum Conway: Organisasi yang tengah mendesain suatu sistem akan menghasilkan desain yang secara struktur menyalin struktur komunikasi organisasi tersebut.

Monolith VS Microservices

Indomimart dan Alfafamart, hanyalah sebuah contoh yang buruk yang sekedar dihadirkan untuk membenturkan antara microservices melawan monolith. Karena kedua arsitektur ini, meskipun seolah berbeda, nyatanya dipisahkan oleh blurred line. Misalnya pada fakta bahwa alur kerja Indomimart meskipun secara de facto disebut microservices, mungkin terdiri dari beberapa sistem yang dikerjakan secara monolith. Atau Alfafamart, meskipun berupa monolith, akan tetapi mungkin juga merupakan bagian dari sistem microservices yang lebih besar. Tidak ada pedoman khusus yang menyebut bahwa satu sistem adalah microservices dan satu sistem adalah monolith di luar dari fakta bahwa Amazon (penganut microservices) menyebut bahwa setiap tim microservices cukup diberi makan 2 box pizza. Artinya masing-masing tim tidak berjumlah lebih dari dua belas orang.

Tapi dari ulasan Martin Fowler, kita bisa menarik satu kesimpulan bahwa ada satu hal fundamental yang membuat microservices adalah microservices. Yaitu microservices memperlakukan "services" sebagai component. Dari konsep inilah, kemudian muncul beberapa paradigma pengembangan terbaru. Salah satunya ialah pengelolaan yang terdesentralisasi.

Pengelolaan tersentralisasi yang cenderung ada di arsitektur monolith memiliki konsekuensi berupa tendensi untuk membakukan diri pada satu platform teknologi. Pendekatan ini bisa saja dirasa sangat membatasi, karena tidak semua masalah adalah paku, dan tidak semua solusi adalah palu. Anda mungkin membutuhkan alat yang berbeda untuk memecahkan solusi yang berbeda. Misalnya Anda perlu Node.js untuk membuat halaman statistik sederhana, sementara Anda juga perlu C++ untuk membuat komponen yang hampir mendekati realtime.

Atau Anda perlu memakai database yang berbeda-beda, yang paling cocok dengan perilaku komponen? Maka pengelolaan terdesentralisasi, dalam hal ini microservices bisa jadi panasea. Jika sentralisasi dari aplikasi monolith cenderung membuatnya lebih memilih menggunakan satu database logis untuk menghasilkan data yang lebih seragam, atau demi kemudahan dalam lisensi, maka desentralisasi yang dianut microservices justru cenderung melakukan pendekatan yang disebut dengan Polyglot Persistence, yakni membiarkan masing-masing services untuk mengelola database mereka sendiri.

Microservices Database

Desentralisasi dalam beberapa cakupan juga bisa berarti code ownership. Sebagian besar pengembangan aplikasi yang mungkin seringkali kita temui menggunakan model proyekan, dimana tujuannya adalah melakukan coding sampai dianggap selesai. Begitu selesai, maka software itu diserahkan pada bagian maintenance dan tim proyek pun dibubarkan. Microservices cenderung menghindari model ini, dengan menganjurkan satu tim agar merawat sepanjang usianya. Seperti contoh di atas, tim pengembang keranjang belanja di Indomimart akan bertanggung jawab (dan lebih mudah dimintai pertanggungjawaban) penuh jika produk yang mereka buat tidak memenuhi kriteria. “You build, you run it,” begitulah prinsip yang dianut Amazon dimana tim pengembang mengambil tanggung jawab penuh pada produk yang mereka buat. Netflix adalah organisasi lain yang mengadopsi etos kerja ini. Dengan mentalitas seperti ini, pengembang akan dituntut untuk menghasilkan kode yang berkualitas dibanding sekedar menyelesaikan proyek.

Pendekatan ini mungkin saja diterapkan pada aplikasi berbasis monolith. Akan tetapi, dengan membaginya ke dalam skala services yang lebih kecil-kecil akan mampu menciptakan hubungan personal antara pengembang dengan kode yang mereka ciptakan.

Maka sekarang kita masuk ke pertanyaan sesungguhnya: Apakah microservices selalu berarti bagus?

Tidak juga. Ada banyak alasan yang justru memberatkan adopsi microservices. Pertama adalah level koordinasi yang akan jadi lebih kompleks. Ketika membagi services, maka menentukan batasan komponen akan memerlukan upaya koordinasi ekstra. Jika ternyata komponen ini adalah services yang dikomunikasikan secara remote, maka proses refaktur akan jadi lebih kompleks. Memindahkan kode antar batasan service memerlukan koordinasi antar partisipan, lapisan backwards compatibility perlu ditambahkan, dan proses pengujian akan jadi lebih rumit. Masalah lain adalah jika komponen tidak disusun dengan benar, maka Anda akan membuat koneksi antar komponen jadi lebih kompleks. Hubungan antara services akan menjadi lebih berantakan. Terakhir adalah soal kemampuan tim. Teknik terbaru mungkin saja bisa dengan mudah diadopsi oleh tim yang lebih mahir. Akan tetapi bukan berarti ia akan efektif ketika diadopsi pada tim yang kurang mahir. Meskipun ada juga jargon: A poor team will always create a poor system.

Serius deh. Tujuan tulisan ini bukan untuk menemukan manakah pendekatan yang lebih deus ex machina antara microservices atau monolith. Arsitektur monolith pun bisa saja diadaptasi untuk menghasilkan pendekatan yang mirip dengan microservices. Microservices sendiri juga baru populer di beberapa tahun belakangan seiring dengan evolusi teknologi Cloud dan AWS yang secara signifikan telah memangkas kompleksitas operasional dalam membangun, melakukan deploy, dan mengoperasikan microservices. Pionir dari gaya arsitektur ini meliputi Amazon, Netflix, dan The Guardian. Beberapa organisasi mungkin juga melakukan pendekatan ini tanpa menggunakan nama itu, tapi dengan sebutan lain seperti service-oriented architecture (serupa tapi tidak sama). Garis bawahnya, arsitektur microservices adalah ide yang layak untuk dipertimbangkan bisnis Anda. (ilustrasi: vwk, martin fowler)

Sekarang, ada kesempatan untuk belajar microservices secara langsung dari praktisinya di bootcamp pemrograman Refactory. Enroll: https://enroll.refactory.id