Kita sudah memahami bahwa dalam banyak kasus kita perlu menggunakan arsitektur client-server. Tak hanya itu, backend dan frontend pun perlu dipisahkan satu sama lain. Nah, pada perkembangan selanjutnya, ternyata inipun belum cukup.

Terkadang fitur-fitur pada aplikasi yang sama ternyata diakses secara berbeda dan membutuhkan penggunaan resource (alokasi CPU/RAM) yang berbeda pula.

Coba bayangkan sebuah situs berita, kira-kira mana yang akan lebih sering diakses: fitur untuk menambahkan berita, atau fitur untuk membaca berita?

Tampaknya fitur untuk menambahkan berita akan lebih sedikit diakses, karena satu berita yang sama bisa dibaca oleh ratusan/ribuan user sekaligus. Setiap detik ada user baru yang berniat membaca berita, sedangkan fitur menambah berita mungkin hanya diakses oleh puluhan orang wartawan.

Bagaimana dengan aplikasi pemutar musik semacam spotify? Fitur apa yang kira-kira penting, dan fitur apa yang kira-kira bisa diabaikan? Pengguna spotify umumnya hanya ingin mendengarkan lagu. Tampaknya juga cukup menyenangkan untuk mengetahui apa yang didengarkan oleh teman-teman kita, namun fitur yang terakhir ini bisa kita abaikan. Fitur untuk memutar lagu harus selalu tersedia, apapun yang terjadi. Kepuasan pelanggan sangat bergantung pada fitur ini.

Berkaca dari dua kasus tadi (situs berita dan spotify), apa yang akan terjadi kalau kita menggunakan satu aplikasi backend monolith untuk melayani semua fitur?

• Untuk kasus situs berita, saat kita melakukan scale up pada fitur baca berita, maka fitur tulis berita pun akan ikut ter scale up. Ini bisa menjadi pemborosan, karena sebenarnya fitur tulis berita itu tidak penting-penting amat. Katakan saja fitur tulis berita down selama satu atau dua jam, maka yang akan mengeluh adalah para wartawan. Tapi coba bayangkan sebuah situs berita down selama satu atau dua jam. Maka ini akan menjadi berita baru di situs berita lain. Nama perusahaan pun bisa tercoreng.
• Untuk kasus spotify, saat user hendak menampilkan playlist, maka server harus pula melakukan request ke facebook untuk mendapatkan friendlist dan menampilkan lagu-lagu yang sedang didengarkan oleh mereka. Bagaimana jika karena suatu hal, server facebook down? Sekali request dari server spotify ke server facebook memakan waktu 10 detik, dan itupun selesai karena timeout (tidak mendapatkan response yang diharapkan). Maka seorang user harus menunggu dengan sabar hanya untuk memutar satu lagu.

Solusi yang cukup masuk akal untuk menyelesaikan kedua masalah ini adalah dengan menggunakan arsitektur microservices.

Kini aplikasi backend kita perlu dipecah-pecah sesuai business domain sehingga bisa di scale secara berbeda, bahkand dikembangkan oleh tim yang berbeda.

Keunggulan Microservices

Microservices menjadi salah satu hype dalam beberapa tahun belakangan. Antara lain karena perusahaan-perusahaan seperti Netflix, Google, Facebook dsb mengadopsi arsitektur ini. Kalau kita tahu tentang microservices, tentu saja ini bisa menghiasi CV kita 🙂

Terlepas dari itu, ecara teknis, keunggulan microservices adalah sebagai berikut:

• Memungkinkan scaling setiap fitur/services secara berbeda
• Lebih vault tolerant, jika satu service mati, service yang lain masih bisa diakses
• Jika dilakukan dengan benar dan cermat, bisa menghemat biaya.
• Setiap service bisa dikembangkan oleh tim yang berbeda-beda.

Kekurangan Mircoservices

Keputusan menggunakan microservices selain menyelesaikan banyak masalah, sebenarnya juga menambah banyak masalah baru. Misalnya:

• Bagaimana jika sebuah proses melibatkan beberapa microservices dan salah satunya ada yang gagal? Pada aplikasi konvensional kita bisa menggunakan try-catch dan database-transaction. Pada microservices, tentu saja dibutuhkan mekanisme yang berbeda, misalnya saga pattern.
• Bagaimana antar service bisa saling berkomunikasi? Jika ada satu struktur data yang perlu diubah, kira-kira service mana saja yang akan terdampak? Perubahan yang melibatkan komunikasi antar service bisa jadi bencana jika tidak dikelola dengan baik.
• Pengelolaan microservices mungkin membutuhkan orchestrator khusus seperti kubernetes.
• Tidak bisa lagi pakai shared hosting 🥺
• Adanya komunikasi dalam jaringan internal pasti akan menambah latency

Orchestration vs Choreography

Dalam penerapannya, ada dua macam pola komunikasi pada arsitektur microservices, yakni orchestration dan choreography.

Orchestration

Pada pola orchestration, dibutuhkan satu service yang bertindak sebagai orchestrator. Orchestrator ini yang bertugas mengirimkan request-request ke service lain, menentukan urutan request, dan mengolah response dari service-service lain untuk disatukan dan dikirim kembali ke frontend.

Bayangkan kita memiliki empat buah service:

• gateway: Melayani request dari frontend
• auth: Meng handle masalah authentication
• stock: Melakukan pengecekan stock
• payment-request: Mengirimkan permintaan pembayaran ke user

Saat user berbelanja, maka pertama-tama service gateway akan menanyakan pada service auth apakah user tersebut sudah ter-autentikasi. Dalam service auth, mungkin juga tersimpan informasi rekening bank dari user.

Usai mendapatkan informasi dari auth, gateway akan menanyakan pada service stock, apakah barang yang mau dibeli masih ada. Jika masih ada, maka gateway akan mengirimkan request ke service payment-request untuk menagih pembayaran ke user.

Di sini kita lihat, bahwa gateway juga berfungsi sebagai orchestrator. Sebuah service yang secara khusus mengatur pekerjaan service-service lain.

Setiap service yang berkomunikasi perlu mengetahui lokasi satu sama lain sehingga bisa saling mengirimkan request.

Choreography

Pada pola choreography, setiap service bekerja secara mandiri tanpa ada satu service yang secara khusus bertugas mengatur service-service lain. Pada umumnya, pola choreography juga perlu melibatkan message broker.

Setiap service bisa "mendengarkan" dan "mengirimkan" event ke message broker. Dalam contoh di atas, maka service gateway cukup mengirimkan pesan ke message broker: "ada order dari user A untuk barang C dan D". Setelah itu, gateway tidak perlu lagi melakukan apapun.

Giliran service auth yang mendengarkan pesan "order" dari message broker, dan mengirimkan message "order authenticated" beserta nama user, barang yang dipesan, dan rekening dari yang bersangkutan.

Service stock secara aktif akan mendengarkan event "order authenticated" dan mengirimkan event "order valid".

Saat service payment-request mendengarkan event "order authenticated", maka ia akan mengirimkan tagihan pada user.

Berbeda dengan pola orchestration, setiap service kini hanya perlu mengetahui lokasi message broker dan mendengarkan event-event yang menjadi domain mereka saja.

Pola orchestration

Pola choreography

Penutup

Sama seperti sebelumnya, setiap pola komunikasi dan arsitektur memiliki kelebihan dan kekurangannya masing-masing. Jika kalian baru mulai membuat sebuah aplikasi, saya sangat menyarankan jangan terburu-buru membagi aplikasi kalian dalam bentuk microservices. Kesalahan membagi domain terkadang malah membuat aplikasi microservices kita memiliki kompleksitas yang tidak diperlukan.

Adapun demikian, mulai pertimbangkan supaya kode kita mudah dipecah-pecah seandainya nanti dibutuhkan. Hindari membuat fungsi/class yang tightly-coupled satu sama lain. Penggunaan interface dan dependency injection mungkin saja membantu dalam kasus ini.

Antara orchestration dan choreography pun tidak ada yang seratus persen lebih baik dari yang lain. Choreography terlihat lebih canggih, tapi akan membutuhkan trik khsusus jika kita membutuhkan reqeust-response secara synchronous dari sisi frontend. Beberapa message broker memiliki fitur RPC untuk keperluan ini. Misalnya rabbitmq: https://www.rabbitmq.com/tutorials/tutorial-six-php.html

Dalam banyak kasus, sering sekali dijumpai pola komunikasi microservices yang merupakan kombinasi antara orchestration dan choreography. Tidak ada yang salah, selama berguna dan membantu, mengapa tidak 🙂.