Kemaren gue nyaranin buat mecah jadwal lu yang tadinya Monolith jadi Microservices. Idenya adalah bikin hidup lu lebih modular, jadi kalo satu rencana lu berantakan, rencana yang lain ga bakal ikutan crash kayak efek domino.

Tapi jujur aja, setiap arsitektur baru itu selalu bawa masalah baru. Ini hukum alam. Dan di kasus microservices, masalah paling gedenya adalah overhead management alias keribetan ngatur komponen-komponen kecil itu.

Temen gue yang kemaren nge-refactor jadwalnya pake pendekatan ini, sekarang ngalamin apa yang di dunia cloud computing disebut sebagai dependency hell dan orchestration failure.

Gini ceritanya. Dia mecah idupnya jadi puluhan service kecil. Ada baca-buku-service, ngegym-service, nongkrong-service, ngerjain-tugas-service, sampe nelpon-nyokap-service. Teorinya bagus, dia kasih buffer 15 menit antar tiap service. Tapi dia lupa kalo otak manusia itu bukan Kubernetes yang bisa nge-manage 50 container sekaligus tanpa delay.

Otak manusia itu single-threaded. Cuma bisa jalanin satu proses gede di satu waktu.

Pas dia nyoba jalanin 10 service berbeda dalam satu hari, otaknya kehabisan RAM buat ngelakuin context switching (pindah fokus). Dia baru aja selesai ngerjain kalkulus yang butuh otak kiri, terus 15 menit kemudian dia langsung maksa jalanin ngegym-service yang butuh adrenalin. Belom kelar napas dari gym, dia udah harus jalanin nongkrong-service yang butuh skill sosial tingkat tinggi.

Akhirnya apa? Semua service-nya jalan, tapi performanya jelek semua (high latency). Dia ngerjain kalkulus ga fokus, dia ngegym ngangkat beban yang ringan doang karena buru-buru, dan pas nongkrong dia malah ngelamun karena kecapean.

Ini adalah kesalahan klasik developer yang baru belajar microservices: terlalu kecil mecahnya (over-engineering). Kalo lu mecah service lu jadi mikroskopis banget, energi lu bakal abis cuma buat ngatur komunikasi antar service itu, bukan buat ngejalanin service-nya sendiri.

Terus gimana solusinya biar kubernetes mental lu ga nge-crash?

Pertama, pake konsep Domain-Driven Design (DDD). Gabungin service-service kecil yang konteksnya mirip ke dalam satu modul yang agak gedean. Daripada lu mecah baca-buku-service dan ngerjain-tugas-service, mending gabungin aja jadi Deep-Work-Service yang di-run di satu blok waktu gede, misal 3 jam tanpa henti. Di 3 jam itu, lu ga boleh di-interupt.

Kedua, batasin jumlah service yang lu deploy tiap harinya. Jangan maruk. Lu ga bisa jadi anak rajin, atlet, pacar yang baik, dan anak nongkrong asik secara bersamaan dalam periode 24 jam. Pilih 3 service utama per hari. Sisanya, biarin idle atau taroh di backlog buat hari besoknya.

Ketiga, belajar soal graceful degradation. Kalo energi lu hari ini cuma tinggal 20 persen gara-gara kehujanan di jalan, lu harus siap nge-shutdown beberapa service yang ga critical. Nonaktifin ngegym-service dan nongkrong-service. Alokasiin sisa baterai lu cuma buat makan malem-service dan tidur-service.

Jangan ngerasa gagal kalo lu harus nge-drop beberapa jadwal. Server Google aja berani nge-kill request yang kepanjangan demi nyelamatin keseluruhan sistem. Masa lu kalah logis sama mesin pencari?

Khay