Memperkenalkan Workflow Engine dalam Arsitektur Microservice
Pendahuluan
Arsitektur Microservice merupakan suatu arsitektur IT yang umum pada era modern. Untuk menghubungkan satu microservice ke microservice lain, kita membutuhkan cara komunikasi yang efisien dan terstruktur. Beberapa cara umumnya digunakan dalam pattern Microservice yaitu berupa Orchestration dan Choreography. Pada pembahasan kali ini, kita akan membahas studi kasus pada arsitektur Microservice, kemudian mengulik peranan Workflow Engine dalam membantu kita menyelesaikan masalah yang ada pada arsitektur Microservice.
Studi Kasus Microservice E-Commerce
Studi kasus microservice yang akan saya bahas adalah dari sektor e-commerce. Di sini, kita berkenalan dengan seseorang, anggap saja namanya William. William adalah seorang co-founder startup e-commerce serta merangkap sekaligus sebagai CTO. E-commerce yang dimiliki William, memiliki fitur e-commerce pada umumnya, yaitu:
- Checkout (kasir),
- Shipping (pengantaran),
- Inventory (pergudangan),
- dan Payment (pembayaran)
William kemudian menggambar alur sederhana yang terjadi pada sistem di belakang layar, ketika user sedang checkout setelah berbelanja seperti di bawah ini:
William telah mempelajari ilmu dasar arsitektur Microservice. Dia memutuskan untuk membuat microservice untuk ke empat fitur di atas. Setelah yakin dengan keputusannya, kemudian dia membuat 4 tim berbeda atau sesuai dengan jumlah microservice yang akan dia buat. Demi mengejar target live yang ketat, komunikasi antar microservice dipilih menggunakan HTTP(S) REST.
Beberapa bulan setelah development, sistem telah go-live. Masalah-masalah mulai muncul, timeout ketika melakukan pembayaran atau shipping, ketidak konsistenan data antar microservice, serta kurangnya dokumentasi alur bisnis.
Berhadapan Dengan Sistem Timeout
William menyadari bahwa masalah-masalah di atas yang dihadapinnya merupakan hal yang umum dalam arsitektur Microservice. Timeout merupakan sesuatu hal yang mustahil untuk kita bedakan, khususnya dari sumber timeout itu sendiri, dan sangatlah susah/tricky untuk kita ketahui.
- Apakah timeout terjadi ketika mengirim data dari client ke service provider?
- Apakah timeout terjadi pada service provider? Tiba-tiba service provider mati listrik / restart.
- Apakah timeout terjadi pada saat ketika service provider mengirim balikan ke client?
Strategi yang umum dilakukan dari permasalahan di atas adalah:
- Retry (Mengulang) permintaan dari client ke service provider
- Clean up (Membersihkan) atau membalikkan data.
Kedua strategi di atas memerlukan sebuah “state control”, yang berarti kita harus menyimpan dan mengintai (tracking) kondisi dari sebuah event di database / tempat penyimpanan khusus.
Demi menjawab permasalahan “Timeout” yaitu dengan “State control”. William dan tim merubah tata cara berkomunikasi dari high-coupling HTTP synchronous menjadi event-based / asynchronous based dan menambahkan satu “Order” service. Tujuan dari order service ini, tidak lain dan tidak bukan adalah untuk mengambil alih tanggung jawab dan mengontrol 4 service lainnya. Order service mempunyai dua fungsi, (1). Mendengarkan event, (2) Membuat perintah ke service lainnya.
Seperti pepatah mengatakan “Tidak ada gading yang tak retak”. Martin Fowler dalam artikelnya, memberikan suatu pendapat yang bagus perihal gaya komunikasi Microservice berbasis notifikasi event / choreography ini.
“The danger is that it’s very easy to make nicely decoupled systems with event notification, without realizing that you’re losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. The pattern is still very useful, but you have to be careful of the trap.” Martin Fowler in What do you mean with “Event Driven”?
William menyadari bahwa cepat atau lambat akan terjebak dalam bahaya, dimana dia kehilangan arah dan visibility alur bisnis atas event-event antar Microservicenya.
Komunikasi antara Microservice di atas dapat kita analogikan seperti halnya pada perlombaan three legged race.
Pada momen inilah, William mencoba merenung sambil mengoprek-oprek teknologi, mencari tahu jawaban dan belajar dari teknologi masa lalu, salah satunya yaitu BPMN atau Business Process Model Notation. Pada umumnya BPMN ini adalah notasi-notasi bisnis yang berstandar ISO. Dengan notasi-notasi standar ISO ini, kita dapat membuat memetakan binis yang lebih rapi dan mudah dipahami.
Untuk menjalankan BPMN, kita membutuhkan Workflow Engine. Workflow Engine dimasa lalu kerap dikaitkan erat oleh sistem yang berat / memakan banyak resource, vendor lock in yang berbayar mahal, serta monolith pada sistem SOA (Service Oriented Architecture). Jaman telah berubah, seperti Microsoft yang tadinya closed source, sekarang mulai berlahan menjadi open source. Begitu juga dengan BPMN, seperti bangkit dari kuburnya, telah terdapat beberapa open source yang umurnya telah bertahun-tahun dan bertahan hingga saat ini. Beberapa contoh software Workflow Engine adalah Camunda, Activiti, jBPMN, Zeebe, dan lain-lain.
Agar pembahasan tidak melebar jauh dari topik penulis, Camunda penulis pilih sebagai Workflow Engine, karena opini pribadi saya menggunakan Camunda yang mudah dan extensible. Bernd Ruecker salah satu author dari Camunda pintar menjelaskan tentang kebutuhan Workflow Engine dalam arsitektur Microservice, serta visi dia dalam membawa Workflow Engine ini kedepannya.
Tanpa basa-basi, pengenalan Workflow Engine dan integrasi dengan sistem yang telah ada haruslah dilakukan dengan prinsip kehati-hatian. William mencoba mengambil satu Microservice untuk dapat diintegrasikan, yaitu payment service. William menggunakan Camunda untuk dapat menyelesaikan permasalahan “Timeout” dan manajemen “State control”.
Gambar di atas merupakan ilustrasi sederhana bagaimana Workflow Engine dari Camunda dapat diintegrasikan dengan Microservice Payment.
Stopp.. kayaknya perkenalan kita tentang Workflow Engine dan Microservice cukup sampai di sini, karena sudah kepanjangan.
Cukup menarik bukan? Kita langsung saja lihat demo Aplikasi dari Bernd Ruecker yang ada di Github.
Tertarik dengan kelanjutan dan aplikasinya pada industri perbankan? Yuk datang ke acara JS Day 2019 https://jsday.id/ dan datang ke tech talk saya.
JS Day akan dilaksanakan pada tanggal 28 Juli 2019, di SCTV Hall, Senayan City, Jakarta, Indonesia. Ambil tiketnya di https://www.loket.com/event/ruby-confid-jsday-2019-wa1
P.S. Jika teman-teman menyukai artikel semacam ini, silakan subscribe ke newsletter kita dan dapatkan notifikasi artikel terbaru langsung di inbox kamu!
