https://s3-us-west-2.amazonaws.com/secure.notion-static.com/10008e94-c5e7-4367-be1f-2b27d33a0dac/1_xu1Ge_Cew0DHdSU6ETcpLQ.png

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?

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:

Kekurangan Mircoservices

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

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:

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.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/6c3b18a9-e4a9-4d36-a89e-c198fc2bdd77/Evolusi-Arsitektur-Microservices_(Orchestration).png

Pola orchestration

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/70c21e7b-8c1a-4244-8f74-e6aa3ff6e9b5/Evolusi-Arsitektur-Microservices_(Choreography).png

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 🙂.