Beberapa waktu lalu gw sempat membaca tentang tulisan di linkedin. Kebetulan gw ga sempet save linknya jadi gak bisa dishare kemari. Tetapi ada yang menarik di tulisan tersebut yang mengatakan bahwa microservice bukan lah sebuah silver bullet untuk menyelesaikan kompleksitas yang terjadi dalam membangun sebuah produk berbasis IT. Tentu saja itu sungguh mengagetkan gw yang tahun ini melakukan rewrite besar-besaran. Perusahaan OTA tempat bekerja sekarang sedang mengalami problem yang mungkin akan dialami semua start up ketika sudah membesar nantinya. Ya hal itu adalah scaling product dimana kebutuhan product akan semakin banyak. Yang paling membahayakan ketika sudah membesar adalah dimana tim bisnis dan jajaran direksi menganggap dengan menambah jumlah resources di development semakin besar maka akan semakin cepat juga dalam hal development. Hal ini ada benar dan ada salah nya juga. Kok bisa begitu? Jadi begini ceritanya.
Tahun 2017 merupakan tahun yang lumayan struggling buat tim development tempat gw bekerja sekarang (sebelum diakusisi). Dimana tim kami harus membangun microservice karena kebutuhan scaling yang lebih baik. Waktu itu belum ada yang ngerti microservice sama sekali, sampai akhirnya para managers mencari orang-orang yang dianggap berpengalaman dalam hal membangun microservices. Dan akhirnya, dapat 1 orang aja ( miris yak ). Lucunya orang ini datang dimana kami sudah 3 bulan development, lalu mengatakan bahwa yang kami buat salah. Ya jadi akhirnya bongkar lagi kodingnya, trus mulai lagi dari awal hehe.. Ya tapi memang pengetahuan kami terhadap microservice saat itu sungguh minim, jadi ya kami menurut saja karena memang beliau sudah pernah membuat microservice dengan struktur yang hampir sama dengan yang telah dirancang para managers sebelumnya. Berikut rancangannya, design ini dulu dibuat oleh para managers. Sayangnya ini sudah tidak dipakai karena para managersnya sudah tidak ada. Bisa lah buat jadi referensi.
Grand Design Microservices
Keren kan ? Kenapa keren? karena waktu itu bisa dibilang kami sudah memikirkan konsep event driven architecture karena semua data sudah kami lewatkan melalui message broker. Pemilihannya waktu itu antara kafka dan rabbit mq. Hanya saja karena lagi-lagi kurang ilmu, jadi dipilihlah pake rabbitmq. Iya konsep diatas memang keren, tapi ga jadi keren karena kami gagal membuatnya. Jadi hanya keren di konsep saja, tidak sampai level implementasi. Pada akhirnya, kami membuang grand design tersebut karena ya seperti yang saya katakan diatas para pelopornya sudah tidak ada. Lalu apa saja yang kami lalui ketika membangun microservices untuk pertama kali? Berdasarkan pengalaman yang gw lalui adalah sebagai berikut.
- Perubahan tech stack.
Ya sebelumnya kami menggunakan php sebagai main language. Nah untuk microservice, kami menggunakan nodejs. Databasenya masih menggunakan mysql. Untuk brokernya sendiri menggunakan rabbitmq. Kami pun juga sudah mulai menggunakan unit test untuk menjaga code quality kami. Tidak main-main, untuk standard coverage kami punya standard 95%. Yang harus mencakup, branch, statement, lines dan 1 lagi apa lupa tuh. Untuk CI nya sendiri kami menggunakan built in travis. Jadi kalau push, dan ada error ga ada yang bisa ngeles. - Perubahan tech team.
Untuk tech team sendiri, kami pun sudah diseparate ke tim khusus microservice. Tapi tentu saja, untuk tim operations yang menjalankan bisnis tetap ada. Karena kalau gak ada, bye bye dah. Cuma sayangnya disini ada problem juga. Kenapa? karena orang yang ngerjain microservices adalah orang yang megang system dari lama dan juga orang yang jago-jago ( termasuk gw hehe ). Jadi kalau ada trouble di sistem yang lama, ujung-ujungnya orang microservice dipanggil lagi ngurusin sistem yang lama. Akibatnya apa ? kami pun maju mundur dalam mengerjakan microservices ini dan berakhir mengenaskan karena sampai diujung akusisi tak ada satu pun microservice yang berhasil kami release. Semua hanya sampai tahap konsep dan development saja. - Glue Code
Ini merupakan salah satu hal yang lumayan membuat pusing. Mengapa? karena bagimana kami menghandle coding yang lama saat akan terintegrasi dengan yang baru. Microservices yang pertama kali kami bangun adalah microservice car. Mengapa car? karena impactnya paling kecil, jadi kalau error ya uda paling kena effect kecil tidak berpengaruh banyak terhadap sales. Seandainya microservice car tersebut berhasil kami development ( anggap aja yang diatas ready buat release ke production ) yang jadi masalah bagaimana dengan komunikasi dengan sistem yang berjalan sekarang? Payment kan belum microservice, order juga belum. Semua masi di system yang lama. Bingung kan? Tenang aja, hal ini sudah bisa kami solve di tahun 2018.
Lalu apa yang terjadi pada tahun 2018 ? Katanya ada jawabannya pada 2018.
Sabar bos, ini kan lagi mau diceritain. Seperti judul yang gw ceritain di atas, microservice bukan lah sebuah silver bullet. Bukan berarti dengan microservice semua masalah selesai. Tentu saja masalah itu ada, hanya pegadaian yang bisa mengatasi masalah tanpa masalah hehe.
Pada tahun 2018, perusahaan melakukan banyak sekali perubahan. Yang paling terasa adalah kami harus mengejar microservice untuk dapat menggantikan sistem yang berjalan sekarang. Hanya saja melihat yang sekarang terjadi, kayaknya agak sulit untuk mengejar hal tersebut karena masih banyak yang harus dikerjakan. Tetapi, bukan itu yang dibahas kan? Ya dari bulan Januari sampai Agustus sudah 6 microservice yang sudah gw dan tim buat. Kalau berkaca terhadap grand design yang dibuat di atas, berarti tim gw udah menyelesaikan setengah dari microservice yang ingin dibangun ya? Mantap kan? Tapi jangan salah, yang baru gw buat hanya microservice payment. Ya hanya payment doank dan sudah ada 6 microservice, tapi jangan kaget itu aja mau gw pecah lagi karena ternyata itu masi blm scalable menurut gw. FYI, sekarang yang bikin grand design untuk microservice bukan lagi manager, CTO or VP, namun leadnya yakni gw. Tentu aja gw juga ga sembarang bisa mecah karena ini juga akan berhubungan dengan cost. Nah bagaimana pengalaman gw setelah 8 bulan mengerjakan microservice. Berikut ulasannya :
- Perubahan tech stack
Tech stacknya berubah lagi, kenapa? karena semenjak di akusisi, perusahaan yang mengakusisi menggunakan java sebagai main language. Apakah boleh menggunakan language yang lain? Boleh, hanya saja untuk corenya disarankan menggunakan java karena memang dari perusahaan sendiri sudah banyak sekali invest untuk development dengan java. Untuk message brokernya sendiri, kami menggunakan kafka. Untuk kafka sendiri juga mengalami problem yang lumayan menjengkelkan. Mungkin akan dibahas di lain waktu. - Glue code
Ya untuk glue code sendiri memang membingungkan, tapi ini sudah terjawab di tahun 2018. Lalu apa yang kami lakukan disini? Ya kami mengintercept semua request yang terjadi sebelum dan sesudah rewrite sendiri. Hal ini memang harus dilakukan di sisi sistem yang lama dengan yang baru. Simple kan? Ga simple juga, karena begitu kalian coba mengerjakan nanti baru berasa ini ga sesimple yang ditulis disini. Tetapi memang solusinya, seperti yang tertulis. Apa ada cara yang lain? Tentu saja ada, tapi mungkin gw blm explore lebih jauh.
Sekarang sudah ada 6 microservice yang sedang gw dan tim maintain. Tetapi kami sedang me-rewrite semua sistem yang di sistem lama. Kemungkinan besar mungkin microservice yang gw handle bisa sampai 20-an microservice. Banyak banget bukan? Lalu benefit & masalah apa yang terjadi dengan semakin banyak microservice? Gw akan mulai dari benefit dahulu mungkin.
- Loose coupling
Kalau ini salah satu kenapa microservice penting. ya karena loose coupling, kapan pun mw deployed ga perlu khawatir karena dependency antar service kecil. - Reliable system
Maksudnya gimana reliable? Dulu sebelum payment dibuat microservice, database kami selalu problem apabila sedang tinggi trafficnya. Hal ini menjadi masalah karena database sifatnya sharing di sistem lama, jadi kalau database down maka a whole new system terkena effectnya. Yang jadi problem adalah kalau misalnya orang sudah checkout untuk pembayaran dan mau bayar, mereka gajadi bisa bayar. kenapa? ya karena down database tadi. Sungguh menjengkelkan bukan? Oleh karena itu pemisahan ini sungguh membuat sistem reliable. Dulu sebelum microservice, mau bayar lewat atm system lama kalau sedang problem bisa meresponse sampai 6-9 s. Gila kan? padahal hanya query untuk ngecek harganya, order dan dicek apa bisa dibayar atau tidak? Kami selalu kena omel dari tim thirdparty karena response terlalu lama. Begitu microservice, kami bisa meningkatkan response time sampai 1000 kali lipat. Dari 9 s menjadi under 10 ms. Luar biasa kan? - Separate tech team
Yang sistem lama bukannya juga bisa? Iya emang bisa, tetapi hasilnya kurang maksimal. kenapa? karena sistem lama tidak bisa mendukung jumlah orang banyak dalam 1 tim. Kalau kebanyakan, nanti malah bingung, gw ngerjain apa. Mau ngerjain halaman itu uda dihandle orang lain. Berakhir gabut. Yang sekarang bukan begitu juga? Oh enggak donk, di microservice kita bisa bagi dua kerjaan, antara yang koding logic dan yang test codingnya. Bukannya di sistem lama juga bisa? sayangnya engga begitu, sistem lama tidak menganut unit test. Jadi pasti berakhir akan ada yang nganggur. Dengan melakukan separate tech team ini juga, maka lebih jelas pembagiannya. Misalnya di tim gw yang sekarang, ada yang handle payment, member, loyalty, order, etc.
Lalu problemnya apa ?
- Hard to maintenance
Loh, katanya dengan microservice bisa dengan gampang deploy kapan aja? Ya emang bener, kalau dokumentasinya benar dan teliti. Kenapa demikian? Di tim gw yang sekarang, gw punya 6 microservice dan menurut gw itu harus well documented karena sekali saja ga well documented percayalah you will bring chaos into your microservices. Bayangkan kalau sekarang punya 20 microservice dan salah deploy begitu juga urutannya. Pasti akan terjadi chaos yang sangat parah. - Separate server system
Dalam mendeploy sistem, kadang sesuatu berjalan tidak mulus. kita juga harus melakukan hotfix, development dan staging. Jika di sistem lama kita hanya mendeploy masing-masing 1 server yang berarti ada 3 server diluar production, maka di microservices kita harus mendeploy sejumlah microservice yang ada. Kalau di payment ada 6 microservice berarti ada 18 server microservice yang harus di buatkan servernya. Dan yang paling menyulitkan adalah untuk deploy jika flow nya belum matang maka akan sangat membingungkan. Contoh ada hotfix di production, tentu saja kita harus menggunakan server hotfix. Hanya saja di system lama yang hotfix sedang digunakan oleh tim lain, yang berakibat kita tidak bisa mengetes sistem yang ada karena kebetulan testnya tidak menjadi apple to apple. Rumit kan? - Highly cost
Kalau yang ini ga perlu ditanya ya? dengan hitungan yang gw kasi diatas harusnya uda bisa diperhitungkan berapa jumlah cost yang keluar. Ga cuma itu, repository yang ada selalu dikali 2 karena bersamaan dengan data migration masing-masing microservice. Jadi siapkan budget yang besar ya.
Ya kalau di artikel yang gw baca sebelumnya, memang tidak serumit ini. Mereka lebih menjelaskan lebih teknis dan dengan bahasa yang agak belibet. Tetapi dari gw pribadi, microservice sendiri bukan menjadi silver bullet yang bisa mengatasi keburukan sistem lama. Karena jika handling yang tidak tepat, maka microservice bisa menjadi pedang bermata dua. So demikian, pembahasan microservice dari gw. Kalau ada yang mau dikoreksi silahkan ya. Gw yakin banyak yang jago-jago microservice, tapi jangan cuma konsep aja ya. Harus dengan implementasi.