Kematian oleh Seribu Mikroservis
(renegadeotter.com)- Kritik terhadap budaya yang mengadopsi mikroservis seolah sebagai pilihan default: biaya dan kompleksitas justru membesar untuk menyelesaikan masalah yang sebenarnya tidak ada, bukan masalah skala yang nyata
- Tertutupnya ekosistem JavaScript/Node.js, praktik ala FAANG, dan melimpahnya pendanaan ventura saling bertemu lalu menciptakan suasana di mana startup pun meniru arsitektur web-scale
- Meski ada Docker dan Kubernetes, kesulitan sistem terdistribusi seperti pengembangan, debugging, deployment, pengujian, dan memastikan resiliensi tidak hilang begitu saja
- Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow, WhatsApp, dan lainnya memulai dengan codebase monolitik atau sampai sekarang tetap menempatkan monolit di inti sistemnya
- Karena kebanyakan perusahaan tidak pernah mencapai skala yang benar-benar membutuhkan sistem terdistribusi, pendekatan yang lebih realistis adalah memisahkan layanan hanya ketika ada beban yang jelas perlu dipisah dan diskalakan
Budaya yang memuja kompleksitas
- Satire tentang kegagalan menjelaskan labirin mikroservis yang rumit hanya untuk mengambil satu tanggal lahir pengguna menyasar praktik over-engineering dalam budaya teknologi saat ini
- Masalahnya adalah tujuan berubah dari menyelesaikan tantangan nyata menjadi membakar uang demi menyelesaikan masalah yang tidak ada
- Kritik terhadap JavaScript dan Node.js bukan sekadar masalah teknologi tertentu, melainkan terkait dengan bahaya ekosistem perangkat lunak yang tertutup yang memaksa industri mempelajari kembali pelajaran yang sebenarnya sudah pernah dipelajari
- Industri juga pernah menabrak dinding kompleksitas seperti CORBA dan SOAP, lalu akhirnya berbalik arah
Kondisi yang melahirkan tren mikroservis
- Para pengembang yang sebelumnya memakai JavaScript untuk browser mulai menyebut diri “full-stack”, lalu masuk ke pengembangan server dan kode asinkron; Node awal lebih mirip proyek belajar pribadi, dan JavaScript awal merupakan pilihan yang bermasalah untuk pengembangan server
- Karena dunia di luar Node seolah dianggap nyaris tidak ada, muncul cara pikir dogmatis bahwa cara Node adalah satu-satunya cara yang benar
- Setelah itu, talenta eks-FAANG masuk ke startup dan menyebarkan “cara yang dipakai di Google” seolah itulah jawaban mutlak, tanpa memedulikan konteks dan skala
- Contoh khasnya adalah tekanan bahwa tanpa
User Preferences Serviceterpisah, sistem tidak akan bisa diskalakan
- Contoh khasnya adalah tekanan bahwa tanpa
- Pada masa pendanaan ventura melimpah, menunjukkan pertumbuhan eksplosif kepada investor menjadi lebih penting daripada pendapatan, dan perusahaan pun cepat-cepat merekrut software engineer mahal agar mereka melakukan “sesuatu”
Sistem terdistribusi tetap sulit
- Mikroservis dikemas seolah sebagai “cara baru memakai perangkat lunak yang skalabel”, padahal pada dasarnya ia berhubungan langsung dengan masalah sistem terdistribusi yang sudah lama ada
- Sistem terdistribusi pada masa lalu dipandang sebagai alat yang sulit dan berisiko, terutama sebagai pilihan terakhir untuk masalah yang benar-benar rumit
- Dalam sistem terdistribusi, semua pekerjaan berikut menjadi lebih sulit dan memakan waktu
- pengembangan
- debugging
- deployment
- pengujian
- memastikan resiliensi
- Pengembangan berbasis mikroservis tidak memiliki tool standar atau framework umum, dan bahkan pada 2020-an pun pekerjaan sistem terdistribusi hanya sedikit lebih mudah
- Docker dan Kubernetes tidak secara ajaib menghilangkan kompleksitas esensial dari konfigurasi terdistribusi
Kasus ketika kesederhanaan memberi hasil lebih baik
- Ringkasan audit kode startup selama 5 tahun menyimpulkan bahwa startup yang berjalan baik justru hampir dengan percaya diri memakai pendekatan Keep It Simple
- Peralihan terlalu dini ke mikroservis, arsitektur yang bergantung pada komputasi terdistribusi, dan desain yang berpusat pada messaging merupakan jebakan utama yang menyulitkan banyak perusahaan
- Banyak startup membangun sistem yang sederhana dan berkinerja baik, tetapi tetap merasa memiliki rasa rendah diri palsu karena “tidak memakai mikroservis sejak hari pertama”
- Untuk pertanyaan “apa yang salah kalau kami cuma punya monolit Django dan satu instance MySQL yang dipelihara beberapa engineer”, jawabannya hampir selalu “tidak ada yang salah”
- Bahkan engineer berpengalaman pun bisa merasa tidak memadai dalam budaya teknologi masa kini, padahal masalah sebenarnya mungkin adalah lingkungan yang dipenuhi rasa percaya diri berlebihan, pemborosan, dan campuran Dunning-Kruger
Perusahaan yang bertumbuh dengan monolit
- Gagasan bahwa perusahaan tidak bisa bertumbuh tanpa meninggalkan monolit hampir setara mitos
- Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow, dan lainnya memulai dengan codebase monolitik, dan sebagian masih mempertahankan monolit sebagai inti sistemnya
- StackOverflow bahkan menjadikan kemampuan menjalankan situs besar dengan hardware minim sebagai kebanggaan di halaman performanya
- Shopify masih memakai monolit Rails, dan dengan Resque yang sudah terbukti mampu memproses miliaran job
- WhatsApp tumbuh besar dengan monolit Erlang dan sekitar 50 engineer
- Organisasi engineering dijaga tetap kecil, sekitar 50 orang
- Tiap tim individual berukuran 1–3 orang dan memiliki otonomi tinggi
- Server dipilih dalam jumlah sedikit, dan tiap server diupayakan diskalakan secara vertikal semaksimal mungkin
- Instagram diakuisisi bernilai miliaran dolar dengan tim beranggotakan 12 orang, dan Threads juga mengikuti model Instagram
Jangan menyelesaikan masalah yang tidak ada
- Pertanyaan intinya adalah “masalah apa yang sedang diselesaikan?”
- Jika skala memang masalahnya, harus ada data yang menunjukkan apa yang perlu dipecah menjadi layanan terpisah dan mengapa
- Sistem terdistribusi dibangun untuk skala dan resiliensi, tetapi perlu juga mempertimbangkan situasi ketika satu layanan melambat atau mati lalu trafik berpindah ke layanan lain
- Faktor yang perlu dipertimbangkan berbeda-beda sesuai pola penggunaan dan karakteristik beban sistem
- backpressure
- circuit breaker
- queue
- jitter
- timeout yang masuk akal untuk semua endpoint
- pengaman agar perubahan kecil tidak memicu kegagalan menyeluruh
- Kebanyakan perusahaan tidak pernah mencapai skala raksasa yang benar-benar membutuhkan sistem terdistribusi
- Meniru cara Amazon atau Google tanpa memiliki skala, keahlian, dan sumber daya mereka mudah berujung pada pemborosan waktu dan uang
- Ada peringatan bahwa sistem terdistribusi yang buruk lebih sulit daripada sistem terdistribusi itu sendiri
Ideal dan realitas layanan per tim serta API
- Upaya menyelaraskan topologi terdistribusi dengan struktur perusahaan berangkat dari gagasan bahwa masalah akan lebih mudah jika dipecah menjadi bagian-bagian kecil
- Mikroservis ideal berbentuk layanan yang dijaga ketat oleh tim khusus, tersembunyi di balik API yang indah, berversi, dan kompatibel ke belakang, sehingga hampir tidak perlu komunikasi dengan tim lain
- Dalam kenyataannya, channel Slack dipenuhi rilis, bug, perubahan konfigurasi, breaking change, dan pengumuman
- Semua orang harus terus memahami keadaan seluruh sistem, dan tim yang sudah sibuk sering kali menangani banyak mikroservis secara setengah-setengah
- Seiring perpindahan orang, kepemilikan layanan pun ikut berubah, dan hasilnya bukan satu mobil balap yang bagus melainkan banyak golf cart buruk
Hal-hal yang hilang karena mikroservis
-
DRY yang melemah
- Mikroservis pada dasarnya tidak DRY, dan tiap layanan membawa boilerplate yang berulang
- Dalam mikroservis kecil, porsi kode plumbing menjadi besar sehingga rata-rata instance layanan bisa lebih mirip kode “service” daripada kode produk
- Bahkan ketika ingin mengekstrak kode bersama, semua pilihannya tetap menyakitkan
- Jika membuat common library, harus ditentukan strategi versi dan pembaruannya
- Bisa juga memaksa update dengan membuat pull request berkala ke semua repository
- Jika digabungkan ke monorepo, muncul masalah monorepo itu sendiri
- Atau membiarkan sebagian duplikasi kode, atau tiap tim terus-menerus menemukan kembali roda
-
Developer experience yang memburuk
- Developer experience adalah besarnya gesekan dan usaha yang dibutuhkan untuk mengembangkan fitur baru atau memperbaiki bug
- Dalam lingkungan mikroservis, orang memerlukan peta mental seluruh sistem untuk tahu layanan mana yang harus dijalankan untuk tugas tertentu, tim mana yang harus dihubungi, dan kepada siapa harus menanyakan apa
- Spotify membuat Backstage untuk membuat daftar begitu banyak sistem dan layanan, dan ini menjadi petunjuk bahwa biaya permainan ini sangat tinggi
- Perusahaan yang bukan Spotify akhirnya membuat solusi tambal-sulam sendiri, yang sulit diharapkan kuat dan portabel
- Untuk memulai layanan baru, ada banyak hal yang juga harus diotomatisasi
- izin developer GitHub/GitLab
- environment variable dan konfigurasi dasar
- CI/CD
- pemeriksaan kualitas kode
- pengaturan code review
- aturan dan perlindungan branch
- monitoring dan observability
- test harness
- infrastructure as code
- Jika memakai banyak bahasa pemrograman, daftar ini bertambah sebanyak jumlah bahasanya
- Menyempurnakan otomatisasi seperti ini bisa memakan waktu berbulan-bulan, dan tim akhirnya harus memilih apakah ingin membangun produk atau justru membangun tool
-
Sulitnya integration test
- Walaupun tes satu layanan dan unit test lulus, itu tetap tidak menjamin jalur inti sistem masih utuh setelah tiap commit
- Integration test untuk konfigurasi terdistribusi diperlakukan hampir seperti masalah yang nyaris mustahil, dan posisinya dianggap telah digantikan oleh observability
- Observability kini menjadi ranah industri tersendiri, menuntut bukan hanya biaya tetapi juga waktu developer
- Observability tidak langsung bekerja seperti plugin; tim juga harus memahami dan menerapkan canary release, feature flag, dan hal-hal serupa
- Memecah masalah bukan berarti penyelesaiannya menjadi mudah, melainkan sering kali hanya menghasilkan kumpulan masalah yang lebih sulit
Monolit tidak otomatis berarti kode yang baik
- Membela monolit bukan berarti “monolit adalah kode bagus dan mikroservis adalah kode buruk”
- Di dunia nyata ada banyak monolit biasa-biasa saja yang dibuat oleh tim tergesa-gesa atau tim yang medioker
- Namun sistem terdistribusi jauh lebih keras terhadap hal-hal yang asal lewat, keputusan buruk, dan mode kegagalan yang terlewat
- Jika tidak dijalankan terus-menerus pada standar tinggi, sistem terdistribusi akan menagih harganya
Bukan harus mikro, layanan biasa pun bisa cukup
- Layanan tidak harus “micro”; dalam beberapa kasus layanan biasa saja sudah cukup
- Beberapa startup bahkan sampai membuat layanan untuk tiap fungsi, menunjukkan seberapa jauh cargo cult yang belum teruji bisa berjalan
- Mulai dengan monolit adalah pilihan yang jelas masuk akal
- Pola “trunk & branches” juga bisa cocok dalam banyak kasus
- Fungsi inti ditangani oleh monolit utama yang menjadi “daging dan kentang”
- Beban yang bisa diidentifikasi dengan jelas dan perlu diskalakan terpisah ditangani oleh layanan branch
Image-Resizing Serviceyang boros CPU lebih masuk akal dijadikan layanan terpisah daripadaUser Registration Service- Pertanyaan apakah jumlah pendaftaran per detik benar-benar cukup tinggi hingga memerlukan penskalaan horizontal independen menjadi tolok ukur pemisahan layanan
Surutnya tren dan pilihan yang realistis
- Kegilaan mikroservis tampaknya mulai mereda, dan ketika aliran pendanaan ventura mengetat, pasar mendorong perusahaan mengambil keputusan yang lebih masuk akal
- Menghabiskan uang untuk arsitektur web-scale padahal tidak punya masalah web-scale bukanlah pendekatan yang berkelanjutan
- Jika yang dibutuhkan adalah pergi dari New York ke Philadelphia, solusi yang sesuai masalah adalah membeli tiket kereta Amtrak 90 menit, bukan membuat pesawat ruang angkasa yang rumit
1 komentar
Opini Hacker News
Saya termasuk orang yang selama ini sangat mendukung microservices, membantu membangun platform Netflix, dan berkeliling dunia untuk menjelaskan keunggulannya. Namun saat memberi saran kepada startup, saya hampir selalu mengatakan agar mulai dengan monolith
Menyatukan codebase dan database jauh lebih mudah, dan masih bisa diskalakan cukup lama. Jika memakai penyimpanan key/value seperti DynamoDB, memang ada sebagian fitur relasional yang hilang, tetapi bisa bertahan lebih lama
Monolith juga bisa di-deploy ke Lambda, dan Anda bisa mendapatkan manfaat Lambda tanpa harus memecah layanan
Baru setelah tumbuh, bagian yang perlu diskalakan secara independen atau perlu deployment terpisah bisa dipisahkan menjadi microservice dengan penyimpanan datanya sendiri
Microservices memakan setidaknya 25% waktu engineering hanya untuk menjaga platform tetap berjalan, jadi kalau tidak bisa mengembalikan efisiensi sebesar itu, nilainya tidak ada
Saat sedang bertumbuh, atau bahkan dalam kebanyakan kasus, lebih baik tidak memakai microservices sama sekali
Dan tolong jangan memecah data. Data jauh lebih rumit dikelola daripada kode
Membuat sesuatu lebih rumit dari sekarang selalu bisa dilakukan. Anda bisa memisahkan sebagian dari monolith menjadi layanan; tentu itu sulit, tetapi tidak sebanding dengan mengeluarkan kompleksitas yang sudah terlanjur masuk ke sistem
Siapa pun yang pernah mengubah banyak microservices kembali menjadi monolith tahu bahwa biasanya jumlah pekerjaannya mirip dengan membangun ulang dari awal
Produk seperti ini, jika mau, benar-benar bisa menjalankan lingkungan produksi dari laptop
Di tempat kerja sebelumnya, kami mengadakan pesta microservices untuk 300 pelanggan. Padahal itu bisnis yang sudah sukses jika mencapai ribuan pelanggan, dan sukses besar jika mencapai puluhan ribu
Biasanya orang tidak menghabiskan 25% waktu engineering untuk menjaga platform, sehingga akhirnya bahkan tidak bisa dijalankan secara lokal dan lingkungan produksinya hanya tertempel seadanya dengan duct tape
Dalam wawancara baru-baru ini, saya ditanya untuk merancang sistem bagi “500 juta pengguna serentak”, padahal perusahaan itu umumnya bertipe pelanggan sedikit dan pendapatan per pelanggan tinggi
Saya masih tidak tahu apakah itu tes untuk melihat apakah saya menyadari bahwa 500 juta adalah angka tidak masuk akal, sekitar 10% dari populasi dunia yang terhubung ke internet, atau apakah mereka benar-benar percaya startup bisa sampai ke sana
Saya menjawab bahwa saya akan fokus membuat hal paling sederhana, yaitu monolith, lalu memastikan apakah fiturnya dan produknya memang diinginkan orang, dan saya tidak diterima
Saya bekerja di monolith raksasa dengan sekitar 800 kontributor, dan menambahkan field sederhana seperti tanggal lahir pengguna pun sama rumitnya. Namun kompleksitasnya tidak semuanya teknis; karena menyentuh kode semua orang, dibutuhkan “penyelarasan organisasi”
Desain dan review berulang tanpa henti, perlu persetujuan minimal 2 arsitek, dan masuk ke beberapa siklus perencanaan. Kode sebenarnya tidak sampai setengah hari
Dalam code review harus memenuhi 90% test coverage, tetapi test-nya terlalu banyak sehingga satu PR terlalu besar, harus dipecah menjadi beberapa PR dan masuk lewat beberapa rilis mingguan
Karena itu fiturnya disembunyikan di balik feature flag, dan saat ini ada 13.000 feature flag
Setelah masuk produksi dan dipasangi dashboard serta monitoring, flag dinyalakan dan dimatikan berulang kali. Tidak jelas mengapa fitur ulang tahun merusak layanan billing, tetapi tampaknya itu penyebabnya, jadi perlu dianalisis selama beberapa minggu
Akhirnya, setahun kemudian engineer yang mengerjakan hal itu bisa mendapat penilaian baik dan menjadi kandidat promosi. Lalu ia segera ditugaskan ke proyek rusak lain yang sudah memasuki tahun ketiga pengembangan: memungkinkan pengguna mengatur zona waktu
Baik microservices maupun monolith bukan palu serbaguna atau peluru perak, dan sebaliknya juga bukan kejahatan itu sendiri. Keduanya adalah alat dengan trade-off, dan berpadu dengan trade-off dalam konteks yang berbeda di tiap organisasi
Masalahnya adalah engineer terpikat oleh kompleksitas dan mencampuradukkan “kesederhanaan” dengan “solusi sementara”, sementara organisasi meniru alat dan pola arsitektur secara membabi buta
Percaya bahwa manfaat akan muncul hanya dengan memakai arsitektur atau design pattern, lalu menerapkannya secara naif, tidak akan membuat hal itu terjadi
Saya berusaha menanamkan dalam pikiran bahwa software engineering adalah perjuangan tanpa henti melawan kompleksitas, dan kadang saya berhasil, kadang gagal
Pertarungan ini harus selalu dilakukan dan harus menjadi nilai utama. Jika tidak, hal seperti ini terjadi
Tidak ada arsitektur atau ideologi yang mengakhiri perang ini; ini memang hakikat pekerjaan ini
Di lingkungan produksi, flag rilis seperti ini tidak bisa dinyalakan, dan developer harus menghapus kode flag sebelum pengujian akhir dan rilis
Ada sedikit pekerjaan tambahan untuk setiap fitur yang membutuhkan flag, tetapi setelah beberapa bulan saja, dampaknya berupa berkurangnya kompleksitas codebase terasa sangat besar
Microservices bukan solusi untuk masalah teknis, melainkan untuk masalah sosial
Tim dengan N engineer membutuhkan koordinasi sebesar N². Tim besar terjebak dalam rapat, email, dan review desain tanpa akhir; tim kecil lebih efektif, tetapi kesulitan memelihara sistem besar
Dengan membagi sistem menjadi subsistem, tiap tim bisa fokus pada potongan puzzle mereka sendiri sambil mengurangi koordinasi antarmanusia
Memang benar microservices menambah kompleksitas dan overhead, tetapi pendekatan ini memungkinkan organisasi besar membangun sistem besar dengan cepat dan melakukan perbaikan iteratif
Sekarang, alih-alih koneksi langsung, dibutuhkan rapat “lintas fungsi” antartim dan lapisan komunikasi yang rumit
Jika Anda menemukan dekomposisi yang hampir tidak membutuhkan koneksi antar-subsistem, maka koneksi itu juga tidak akan ada dalam sistem semula, dan masalah N² pun tidak akan muncul
Yang berulang kali saya lihat adalah satu tim raksasa di mana “semua orang bertanggung jawab atas semua microservices”, dan pada akhirnya tidak ada yang bertanggung jawab atas apa pun
Demi menyelesaikan “masalah manusia”, mereka mengubah masalah teknis sepele menjadi masalah sistem terdistribusi yang rumit
Sekarang muncullah masalah yang sesungguhnya
Proyek itu mendukung dua jenis database dan juga memiliki eksekutor pekerjaan yang bisa diskalakan secara horizontal
Dulu timnya pernah berisi 35 orang, tetapi setelah PHK menyusut menjadi 7 orang, dan saat itu justru kami mulai menyelesaikan jauh lebih banyak pekerjaan. Karena waktu yang dipakai untuk menyelaraskan semua orang berkurang drastis
Rapat, persetujuan, review, perencanaan, retrospektif, dan rapat manajemen jauh berkurang; ruang gerak developer membesar, jadi pekerjaan tinggal diselesaikan
Fitur dengan mudah ditangani dalam separuh waktu, dan 50% sisanya dipakai untuk membayar utang teknis. Karena kami memangkas kompleksitas tanpa ampun, kecepatan menambahkan fitur baru juga meningkat
Beberapa proyek mungkin memang membutuhkan lebih banyak orang, tetapi menurut saya ada batas atas kompleksitas yang bisa ditambahkan ke sistem dalam jangka waktu tertentu
Jika melewati ambang itu lalu menambah developer, jumlah fitur per minggu tetap sama, sementara semua orang bekerja sedikit lebih sedikit dan menghabiskan lebih banyak waktu untuk berkomunikasi
Ulangi proses ini sampai ribuan orang, maka menambahkan satu field saja bisa memakan waktu berbulan-bulan
Saya penasaran apakah pernah terpikir untuk memindahkannya ke folder yang berbeda
Tidak perlu memodulkannya dengan repository baru dan konfigurasi Docker baru. Pakai folder saja
Pola yang sering saya lihat seperti ini. CTO atau VP saat ini dulunya membuat monolith tersebut, atau ikut terlibat dalam pembuatannya
Tidak ada yang ingin mengatakan kepada CTO bahwa kode itu buruk. Atau mungkin zamannya sudah berubah sehingga kodenya memang perlu dirombak total, dan itu tidak ada hubungannya dengan fakta bahwa ia berupa monolith
CTO sibuk dengan marketing atau fundraising sehingga tidak bisa memutuskan microservices atau monolith, lalu arsitek yang baru direkrut mengambil keputusan
Semua orang bersorak untuk microservices. Itu cocok dengan narasi sebagai perusahaan teknologi serius yang tumbuh cepat, dan tidak ada yang ingin sendirian menentang atau mengkritik CTO
Jarang sekali ada orang yang merekomendasikannya karena sungguh-sungguh menganggap microservices sebagai trade-off terbaik. Mereka menyukainya karena mereka suka pekerjaannya, suka merekrut lebih banyak orang, dan itu sangat cocok dengan narasi perusahaan
Dalam perombakan besar-besaran, banyak kode bisa ditulis ulang dan diperbaiki; cukup sebut saja itu sebagai migrasi ke microservices
Pada akhirnya, itu menjadi cara untuk menulis ulang banyak kode lama yang buruk dengan alasan yang didukung hampir semua orang, sambil tidak melukai perasaan CTO dan mengikuti arus
Baik lead engineer individu maupun CTO/pendiri, pada akhirnya saat menoleh ke belakang mereka akan menyimpulkan bahwa mereka bisa melakukannya lebih baik, dan melihat dengan gembira sekaligus ngeri manfaat serta kekurangan dari pola dan proses yang diikuti tim dengan sungguh-sungguh
Saya lebih suka tulisan ini karena mengonfirmasi bias saya
Sudah bertahun-tahun saya mengatakan ini, tetapi menurut saya demam microservices lebih mirip alasan bagi engineer biasa-biasa saja untuk mempertahankan permintaan terhadap mereka. Mediokritas mendorong hal ini, dan pada saat yang sama membuat banyak perusahaan teknologi terus berjalan
Tidak ada cukup engineer kompeten yang bisa menangani UNIX dengan benar dan membangun sistem minimalis yang indah seperti StackOverflow
Jadi microservices sebagai tabir asap untuk menutupi mediokritas akan terus bertahan. Apalagi karena penyedia cloud seperti AWS mempromosikan diri lewat semua kanal yang memungkinkan dan membuat para pengambil keputusan memilih jalan itu
Kalau tidak bicara soal cloud, microservices, dan framework terbaru yang belum teruji, kita dianggap orang tua yang ketinggalan zaman
Padahal sistem seperti itu jarang sekali merupakan yang paling efisien, kuat, atau aman
Perusahaan saya sekarang membuat software untuk dipakai di dalam perusahaan lain; pengguna bersamaan paling banyak 200 orang dan tidak ada lonjakan penggunaan
Itu lingkungan yang sempurna untuk web server biasa, dan mestinya tidak akan ada masalah scaling tak terduga, tetapi semua orang ingin pindah ke cloud
Menurut saya alasannya karena manajemen, programmer, bahkan pelanggan pun sudah diyakinkan oleh marketing cloud dan percaya bahwa cloud itu keren
Perusahaan tidak hanya mengirimkan bagan organisasi ke dalam produk, tetapi juga semua disfungsi dan beban historisnya
Lima tahun lalu, mungkin itu adalah platform indah dengan model data dan API yang efisien serta dirancang baik, juga kode yang ditulis dan diuji dengan baik. Namun setelah lima tahun, akibat CEO yang terus mengubah arah, permintaan pelanggan di menit-menit terakhir yang didorong tim sales, product manager yang menambahkan fitur yang tidak dibutuhkan maupun diminta, serta kurangnya staf dan waktu, semuanya bisa berubah menjadi kekacauan total
Suatu hari kita berhadapan dengan tumpukan besar technical debt, ketika perbaikan bug dan penambahan fitur memakan waktu jauh lebih lama dari semestinya, dan microservices terdengar seperti nyanyian siren yang berbisik bahwa kita tidak perlu membakar semuanya dan memulai lagi dari nol
Ini mungkin terdengar seperti mencari-cari kesalahan, tetapi ada poin yang lebih besar. Pilihan teknologi jarang menjadi bottleneck
Sebaliknya, microservices jauh lebih kompleks karena memiliki lebih banyak komponen bergerak dan mode kegagalan, sehingga engineer biasa-biasa saja—bahkan banyak engineer yang tidak biasa-biasa saja—jauh lebih mungkin menciptakan masalah
Rasanya kita gagal mengajarkan dengan benar kepada generasi sekarang apa yang penting dalam pekerjaan ini
Saya relate karena sedang pindah ke microservices di tim kecil. Masalah terbesarnya adalah observability
Saat terjadi masalah di operasi, mencari tahu persis apa yang salah menjadi pekerjaan remeh yang luar biasa banyak
Mengikuti log dari satu aplikasi terdistribusi saja tidak cukup; kita harus melihat log dari beberapa aplikasi terdistribusi yang pesannya saling bercampur secara bersamaan
Kalau ada tool untuk memvisualisasikan tracing mungkin akan baik-baik saja, tetapi karena tim kecil, bandwidth manusia terbatas dan kami belum punya tool seperti itu
Sebaliknya, monolit sudah terintegrasi dengan NewRelic sejak beberapa tahun lalu. Ada masalah performa, tetapi sebagian besar terselesaikan dengan indeks dan beberapa materialized view
Mudah untuk memahami apa yang salah, dan meskipun kodenya tua serta penuh race condition, pemecahan masalahnya sendiri tidak sulit
Saya takut ketika nanti setiap microservice punya instance database terpisah dan harus di-upgrade. Saya berharap kami menaruh beberapa database dalam satu instance database, tetapi arsitektur itu bukan opsi
Logging terpusat serta tracing panggilan service/eksekusi kode bukan hal baru. Hanya saja sering ditunda untuk nanti, lalu akhirnya masuk ke situasi tidak menyenangkan seperti ini
Karena tool yang tepat tidak dipasang sejak awal, tim menjadi lebih kecil dan lebih terbatas. Sebab mereka hampir tidak tahu, atau sama sekali tidak tahu, apa yang dilakukan service-service itu
Instance database bisa di-upgrade satu per satu. Kalau tidak ada bug serius seperti masalah keamanan, tidak perlu terburu-buru hanya karena upgrade itu memungkinkan
Membaca tulisan seperti ini terasa anehnya terapeutik. Karena 10 tahun lalu saya juga meneriakkan hal yang sama, tetapi diperlakukan seperti orang tidak percaya dan disuruh diam
Maaf kalau paradigma “microservices” meninggalkan rasa pahit bagi saya. Saya sudah mengalami langsung apa yang terjadi ketika teknologi tren terbaru diadopsi sepenuhnya tanpa benar-benar memahami trade-off-nya
Dulu saat saya direkrut di StumbleUpon, ada seorang doktor ilmu komputer terkemuka yang sedang mencoba mengganti monolit PHP yang berjalan baik dan menghasilkan uang menjadi arsitektur microservices Scala/Java
Proses onboarding karyawan baru juga mencakup sesi 1:1 aneh dengan ilmuwan komputer gila itu; ia menjelaskan panjang lebar keunggulan microservices, dan pertanyaan seperti “kenapa kita membuat service terdistribusi hanya untuk menjumlahkan daftar angka?” dengan cekatan ia hindari lewat gestur seolah berkata “kamu tidak akan mengerti kenapa ini jauh lebih baik”
Setelah lebih dari 30 rekrutan baru dan lebih dari 4 tahun pengembangan intens, perusahaan yang tidak lagi menghasilkan laba hanya tersisa dengan neraka terdistribusi yang lebih lambat, lebih banyak bug, dan tidak bisa di-debug
Perancang sekaligus arsitek keseluruhan menilai saat itu adalah waktu yang tepat untuk mengambil “sabbatical”, dan tak lama kemudian putaran pendanaan yang entah keberapa pun habis, sehingga semua orang harus mencari pekerjaan
Tulisan ini, kalau meminjam analogi Amtrak, benar-benar keluar jalur
Penulis berasumsi bahwa kalau mereka membuat microservice yang buruk, semuanya akan secara ajaib baik-baik saja seandainya mereka cukup membuat monolith
Seolah-olah meski dengan tingkat desain dan engineering yang sama mereka membuat microservice sampah, kalau tujuannya monolith hasilnya akan menjadi emas
Di beberapa bagian tulisannya juga terasa sangat merasa benar sendiri; komentarnya tentang developer JS full-stack adalah salah satu contohnya
Namun hampir tidak ada isi dari sudut pandang engineering yang nyata. Kalau berharap metrik atau data, yang didapat hanya uraian panjang lebar
Mengelola kompleksitas agar biaya perubahan sistem tetap rendah adalah tujuan yang baik, tetapi bukan itu yang diusulkan tulisan ini
Tulisan ini akan lebih baik jika mengakui poin tersebut, atau menyajikan data, atau setidaknya satu anekdot
Kalau di tim saya, saya akan memilih developer front-end yang cerdas dan antusias, yang ingin memperluas wawasan dan berkembang menjadi developer full-stack, daripada orang yang merasa sudah tahu semuanya dan tidak punya ruang untuk tumbuh lagi
Di tempat kerja saat ini saya sedang melawan arus ini, dan di beberapa tim cukup berhasil, tetapi di tim lain jauh kurang berhasil. Tim-tim itu sekarang sedang bergulat dengan monolith terdistribusi yang mereka buat sendiri
Ironisnya, semua mantan orang FAANMG justru berada di kubu pendukung monolith
Banyak orang tampaknya melewatkan fakta bahwa microservice adalah hasil dari proses iteratif. Pada akhirnya, yang Anda lakukan adalah memisahkan bagian dari monolith yang memang perlu diskalakan
Microservice membutuhkan banyak infrastruktur dasar yang tidak ingin Anda pelihara kecuali memang diperlukan
Sebagian besar perusahaan juga tidak memiliki platform yang tepat untuk mendukung pola tersebut
Saya setuju. Di perusahaan kami, alat-alatnya tidak berfungsi dengan benar sampai-sampai kami sudah menyerah pada debugging itu sendiri
Untuk menjalankan satu service di mesin lokal, kami harus menyesuaikan 9 service lainnya agar terhubung ke service ini
Kalau membuat “fitur” untuk pelanggan, tentu saja harus menyentuh setidaknya 2 service sekaligus dan memindahkan lebih banyak data
Jika memasang breakpoint di satu sisi, sisi lainnya timeout
Jadi semua developer men-deploy build rilis ke VM lokal, lalu tanpa hot reload mereka menanamkan console.log, System.PrintLines(), _logger, dan membaca file log yang tersebar
Tentu saja saya berencana lompat dari kapal
Akan lebih baik lagi jika semuanya dipindahkan ke distributed tracing, tetapi agar request bisa dilacak dengan benar, metadata tracing harus diseragamkan secara menyeluruh, sehingga investasinya lebih besar
Kemungkinan lebih membantu untuk operasi daripada pengembangan, tetapi tetap akan membantu. Informasi span yang layak saja sudah memberi banyak insight untuk memahami kekacauan itu
Jika breakpoint di satu sisi membuat sisi lain timeout, saya penasaran apakah tidak ada cara untuk memperpanjang atau mematikan timeout dalam mode pengembangan