Opinion

Kenyataan dalam Penerapan Arsitektur Microservices di Startup

[Ilustrasi: dysturb | flickr.com]
Salah seorang teman kerja saya di sebuah startup (ya, startup), pernah berkata seperti ini:

Kalau musim rambutan, banyak orang makan rambutan, kalau musim duren, banyak orang makan duren. Intinya tergantung musimnya apa.

Dan sekarang musimnya adalah microservices.

Apa itu microservices? Seperti biasa, saya mengutip dari situs favorit saya untuk urusan jargon dalam hal programming, apalagi kalau bukan Wikipedia :

Microservices are small, independent processes that communicate with each other to form complex applications which utilize language-agnostic APIs.These services are small building blocks, highly decoupled and focused on doing a small task, facilitating a modular approach to system-building. The microservices architectural style is becoming the standard for building continuously deployed systems.

Ada beberapa faktor penting yang menjadi kelebihan dari arsitektur microservices, yaitu:

  • Language agnostic APIs: API yang tidak bergantung pada pemilihan bahasa program
  • Small building blocks: Pengembangannya dengan membangun blok-blok kecil
  • Highly decoupled: Satu sama lain tidak saling ketergantungan
  • Focused on doing small task: Fokus pada pekerjaan yang lebih spesifik
  • Modular approach: Pendekatannya modular
  • Continuosly deployed systems: Pengimplementasian sistem secara terus menerus

Keenam faktor di atas ini adalah angin-angin surga yang sering menjadi (dunia) impian para engineer/ programmer, terutama di industri startup (saat ini), apalagi disertai kisah sukses startup (besar) yang telah mengadopsi arsitektur ini. Netflix contohnya.

Di tulisan ini, saya bukan bermaksud mengatakan bahwa microservices itu buruk atau jelek entah dengan bahasa yang terang-terangan, ataupun dengan sarkasme. Saya hanya ingin menceritakan bagaimana kehidupan engineer/ programmer di startup setelah berusaha mengadopsi arsitektur ini.

happy-kid
[GIF: gifbay.com]

Startup X

Alkisah, ada sebuah startup yang sedang berkembang, sebut saja namanya startup X.  Dalam hal engineering, startup ini memiliki talenta programmer yang dari sisi mobile, backend dan infrastruktur (server), cukup mumpuni.

Awalnya, startup ini dibangun dengan mengikuti konsep MVP (Minimum Viable Product) atau kalau dalam Bahasa Jawanya adalah “sek penting dadi”. Belakangan kemudian berkembang dan terus berkembang, lalu akhirnya bertemu dengan malaikat investor (baca: angel investor), mendapat pendanaan, dan melakukan promosi dengan gencar. Sayangnya, startup X ini lupa, status produk mereka saat ini masih berupa MVP, bukan produk aslinya.

Pada awalnya, sistem startup ini dibangun dengan mengadopsi arsitektur monolitk pada umumnya, yaitu menggunakan microframework dan mengikuti pattern MVC (Model View Controller). Semuanya standard.

Lama-kelamaan jumlah pelanggan semakin bertambah. Akhirnya sedikit demi sedikit, startup X ini mulai merasakan secara nyata, apa itu kenaikan trafik secara tiba-tiba (traffic spike), yeah..nice problem to have.

britney
[GIF: jamiebritneyfan.tumblr.com]
Apa yang terjadi pada keadaan ini?

  1. Bug-bug mulai bermunculan di mana-mana, yang artinya engineer perlu untuk segera melakukan perbaikan (fix/hot fix) secepat mungkin. Patching pun perlu segera dilakukan.
  2. Setelah frekuensi fix/hotfix/patching semakin sering, startup X perlu mekanisme rollback. Ini artinya standarisasi versioning pasti diperlukan, baik itu untuk mobile maupun sistem backend.
  3. Walaupun sibuk melakukan perbaikan, pengembangan fitur-fitur baru tetap tidak boleh berhenti. Dengan kondisi seperti ini, startup X tetap harus menambah value dari produk tersebut. Salah satu caranya adalah dengan terus berinovasi dalam hal pengembangan fitur.
  4. Berinovasi dalam hal pengembangan fitur ini dalam prakteknya adalah: sekarang butuh fitur A, besok fitur A+1, besoknya A+2, besoknya lagi bisa jadi malah fitur A diganti dengan fitur B, dan ini terus berulang.
  5. Dengan adanya bug, error dan fitur-fitur baru, untuk menjaga kualitas, startup X mulai membutuhkan QA (Quality Assurance) & QE (Quality Engineer). Prosedur testing yang dilakukan pun harus mulai agresif (unit test, integration test, end to end test dan smoke test).
  6. Dari semua faktor di atas, startup X mulai membutuhkan mekanisme otomatisasi sistem yang bisa melakukan testing dan deploy (thanks to mbah Jenkins).

Ini artinya di tahap ini para engineer/ programmer/ devops/ QA di startup X ini sedang dalam posisi yang “dikejar-kejar” (rush).  Dengan posisi ini biasanya akan memunculkan pertanyaan:

Bagaimana caranya agar tetap bisa menjaga speed development, tetapi tanpa mengorbankan kualitas?

Di sinilah peran arsitektur microservice. Seperti disebutkan di atas, arsitektur microservice ini memiliki beberapa keunggulan:

  1. Focus on doing small task
  2. Highly decoupled
  3. Small building blocks

I.  Focus on doing small task: Fokus mengerjakan hal yang spesifik

Engineer/ programmer itu juga manusia, dan kita (manusia) pada umumnya, jauh lebih bisa fokus di sesuatu yang kecil dan spesifik daripada sesuatu yang besar dan kompleks.  Dengan menggunakan arsitektur microservices, harapannya adalah, engineer / programmer bisa menyelesaikan tugas (task) dengan jauh lebih baik dari sisi kualitas karena mengerjakan sesuatu yang spesifik.

II.  Highly Decoupled: Sangat tidak tergantung satu sama lain

Melakukan perubahan di dalam sebuah sistem itu rasanya sangat mengerikan, karena kita tidak tahu apa efek dari perubahan yang kita lakukan, apakah mengakibatkan efek di bagian lain atau tidak.

Dengan adanya konsep highly decoupled, harapannya adalah engineer/ programmer bisa dengan nyaman dan pede melakukan perubahan dengan cepat, tanpa harus terlalu khawatir dengan efeknya di bagian lain sistem.

III.  Small Building Blocks: Pengembangan dalam blok-blok kecil

Dengan lingkup engineering yang kecil, engineer / programmer bisa dengan nyaman melakukan coding & testing. Hasilnya adalah kecepatan dalam development dan deployment.

 

Kembali ke cerita Startup X tadi, akhirnya startup X ini pun memutuskan untuk mulai memigrasikan sistemnya dari monolitik MVC ke microservices.

Singkat cerita, startup X ini memisahkan antar service berdasarkan domain context, misal :

  • Domain Users
  • Domain Products
  • dan seterusnya..

Lalu bagaimana akhirnya? Well, tidak terlalu happy ending bagi Startup X, tapi paling tidak tim engineering di startup X ini mendapatkan pengalaman/ pelajaran baru dari kejadian ini, yaitu:

  1. Memang benar, kalau menggunakan arsitektur microservices, engineer akan fokus di lingkup sistem dan pekerjaan yang lebih kecil, tapi harap diingat, kecil tapi buaanyakkk (sengaja saya tulis dengan agak hiperbola).
  2. Engineer di startup X, untuk saat ini gagal di tahap highly decoupled.  Karena pada kenyataannya, tingkat ketergantungan antar service masih sangat tinggi. Dan percaya deh, hal ini bisa sangat menganggu tidur engineer Anda. Trust me!
  3. Kita membutuhkan lebih banyak tools & mekanisme untuk otomatisasi & pemantauan (monitoring).  Engineer tentunya tidak mau jika setiap hari harus login server via ssh hanya untuk memastikan apakah service mereka masih menyala atau tidak.
  4. Scalability service.  Sekali lagi, service nya memang kecil, tapi banyak.  Ada dua pilihan di sini, satu host server satu service, atau satu host untuk multiple service ? Hati-hati dengan jawaban Anda, karena salah memilih, pertama startup Anda bisa sangat kehabisan uang, atau engineer Anda akan berdarah-darah dalam melakukan scaling service.
  5. Sifat (buruk) manusia ketika diberikan sesuatu yang simpel dan kecil, justru malah meremehkan.  Ini yang terjadi karena beranggapan service adalah sesuatu yang lingkupnya kecil, kadang muncul anggapan “Ah, sudahlah, tidak perlu test lagi.” dan akhirnya ketika dideploy, boom! COP (Crash On Production), dan karena point no.2 (masalah highly decoupled) juga belum selesai, alhasil satu sistem down saudara-saudar, atau paling bagus sistem tidak bekerja sebagaimana mestinya.
  6. Kompleksitas dalam hal communication protocol.  Di saat ini ada Apache Thrift, ada GRPC, selain itu juga masih ada warisan HTTP (REST), dari nenek moyang kita. Komunikasi antar service itu penting, pilihlah komunikasi protocol yang familiar. Satu catatan penting lainnya adalah, pilihkan protokol yang kira-kira bisa memudahkan engineer Anda untuk melakukan proses debugging dengan cepat.

Cerita selesai.

Analisa

Menurut saya pribadi, kesalahan engineer saat ini dalam mengadopsi arsitektur microservices adalah:

  • Selalu melihat hasil akhirnya. Percayalah proses untuk mengadopsi arsitektur ini bukan sesuatu yang simpel dan mudah.
  • Tidak sabar untuk segera mengadopsi arsitektur baru ini.
  • Langsung memulai dengan microservice.

Sebelum buru-buru menerapkan arsitektur microservices, pikirkan pertanyaan ini: Apa yang salah dengan monolitik?

Jika belum jelas, lebih baik mulailah dengan arsitektur monolitik (misal MVC). Apa manfaatnya? Manfaatnya adalah kita bisa mengetahui dengan pasti, domain/ context apa saja yang nantinya perlu kita ubah jadi service tersendiri.

Beberapa hal dalam engineering yang menurut saya penting saat mengadopsi arsitektur microservices adalah:

  1. Tooling
  2. Configuration
  3. Automation
  4. Monitoring
  5. Mentoring

Jangan pernah berpikir untuk mengadopsi microservices, kalau ternyata startup kita belum siap dengan kelima hal di atas ini, trust me!

Saya pribadi menyimpulkan :

Arsitektur microservices bukanlah sesuatu yang melulu hanya terkait dengan teknologi, engineering dan programming, tapi sebenarnya lebih kepada budaya dalam product development dalam sebuah startup (maupun yang sudah bukan startup lagi).

Catatan: untuk kiblat dalam mengadopsi microservice, saya merekomendasikan :

1. Video State of the Art in Microservices oleh Adrian Cockcroft (Battery Ventures)

Adrian Cockcroft pernah membantu Netflix dalam mengadopsi arsitektur microservices, dan penjelasan di video ini sangat membantu untuk memahami microservice sebagai sebuah budaya daripada hanya sebagai sebuah arsitektur teknologi saja.

2. Principles Of Microservices oleh Sam Newman 

Di video kedua ini, Sam Newman memaparkan kejadian-kejadian dan langkah-langkah yang bagi saya pribadi sesuai dengan kenyataan. Dan percayalah, apa yang terjadi di video ini, itulah kenyataannya.

Selamat “ber-microservices”.

amy-thanks
[Gif: HBO.com]
***

Tulisan ini sebelumnya saya publikasikan di akun Linkedin saya. Dipublikasikan ulang di sini dengan pengeditan dan penyesuaian oleh LABANA.id.

Jangan lupa ikuti kami di Twitter untuk mendapatkan update terbaru dari @LabanaID