Setelah 11 Minggu Migrasi ke Kubernetes, Perusahaan Lupa Alasan Mereka Ada (2020)

 (theolognion.com)
1 poin oleh GN⁺ 2024-03-02 | 1 komentar | Bagikan ke WhatsApp
  • Startup Silicon Valley Xenobroom Inc. memutuskan memigrasikan infrastruktur server lamanya ke Kubernetes ketika lonjakan penggunaan harian terjadi di tengah pandemi pada Mei 2020
  • Migrasi berkembang menjadi pekerjaan jangka panjang yang melampaui sekadar perbaikan deployment, karena perlu meninjau ulang dan merancang kembali skrip bash serta konfigurasi berbasis VPS
  • Upgrade dependensi dan library, peralihan sebagian PostgreSQL ke penyimpanan KV terdistribusi, serta pemanfaatan fleksibilitas AWS turut didorong bersama, sehingga cakupannya terus melebar
  • Server staging lama dan deployment harian berbasis branch develop digantikan oleh workflow production-only CI, routing dinamis, pengujian A/B, dan dukungan dependensi wilayah
  • Saat migrasi tampak selesai, tak seorang pun di perusahaan lagi mengingat tujuan produk, dan pengguna maupun investor juga mengakui tidak memahami produk aslinya, sehingga pemulihan praktis menjadi sulit

Cakupan pekerjaan yang membesar karena migrasi Kubernetes

  • Xenobroom Inc. memulai upgrade infrastruktur server pada Mei 2020
    • Menurut potongan jurnal CEO dan catatan engineering CTO, penggunaan harian meningkat tajam selama pandemi
    • Setelah itu diputuskan untuk memigrasikan infrastruktur lama ke Kubernetes
  • Pekerjaan berlangsung lebih lama dari perkiraan
    • Skrip bash sederhana dan mesin VPS harus dibuat ulang, ditinjau kembali, dan direkayasa ulang
    • Di dalam perusahaan, ini juga dianggap sebagai kesempatan untuk meng-upgrade dependensi software dan library
  • Perubahan infrastruktur berujung pada perombakan arsitektur yang lebih besar
    • Mereka menilai sebagian besar database PostgreSQL yang berjalan di satu mesin dapat diubah menjadi penyimpanan KV terdistribusi
    • Ini juga dibingkai sebagai upaya memanfaatkan fleksibilitas AWS
    • Server staging sederhana yang sebelumnya dideploy setiap hari dari branch develop pun dihapus
    • Sebagai gantinya, diperkenalkan workflow production-only CI dengan routing dinamis, serta konfigurasi yang mendukung pengujian A/B dan dependensi wilayah secara mulus

Hilangnya tujuan produk dan bantuan dari luar

  • Saat prosedur migrasi tampak telah selesai, tak seorang pun di dalam perusahaan mengingat tujuan produk
  • Pengguna dan investor juga tidak dapat menyelesaikan situasi ini
    • Kedua kelompok secara terbuka mengakui bahwa sejak awal mereka tidak pernah benar-benar memahami produk tersebut
    • Setelah beberapa minggu downtime, memulihkan makna produk menjadi praktis mustahil
  • CEO meminta bantuan Phutar Afrayughum, seorang spiritualis dan pakar persepsi ekstraindra
    • Ia diperkenalkan sebagai sosok yang membantu peningkatan pangsa pasar aplikasi perpesanan Google dan juga terlibat dalam pengembangan framework Material Design
    • Namun bantuan ini diberi label “allegedly”, sehingga tidak ditegaskan sebagai fakta

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-02
Komentar Hacker News

  • Tulisan ini lebih lucu lagi: tentang bagaimana memecat 20% manajer menengah secara tidak sengaja meningkatkan produktivitas pengembangan 3x lipat
    https://www.theolognion.com/p/company-accidentally-increased...

    • Ini bahkan sulit disebut sebagai satire

  • Di $dayjob kami juga sedang melakukan migrasi seperti ini, tetapi meski dimulai 2 tahun lalu, bahkan 30% pun belum selesai
    Orang-orang yang dulu paling lantang berteriak “kita harus pindah ke Kubernetes, monolit harus dibunuh” sekarang sudah melupakan Kubernetes karena sibuk main-main dengan LLM
    Sebagian orang memang sangat menyukai proof of concept dan hal-hal baru yang mengilap, dan peran seperti itu tampaknya ada gunanya juga

    • Ini adalah struktur yang memberi kepuasan kerja lewat teknologi baru yang mengilap
      Karena itu, orang-orang pintar tampak bisa bekerja dengan cukup puas bahkan di big tech yang tidak etis, perusahaan iklan, atau perusahaan pengawasan
      Alasan perusahaan itu ada dan apa yang benar-benar mereka lakukan di luar komputer mereka sendiri tidak terlalu penting; yang penting adalah kebebasan untuk mengejar teknologi dan hal-hal baru
      Perusahaan menyukai produktivitas dan antusiasme yang mereka hasilkan, serta membayar mereka dengan baik
      Biasanya para developer seperti ini juga punya hati nurani, tetapi hati nurani itu sering diserap dan dipamerkan dalam bentuk aktivisme sosial yang ramah korporasi
    • Ini lebih mirip pengembangan yang didorong resume yang disengaja daripada perluasan cakupan
      Seseorang sedang mencoret kotak centang satu per satu agar nanti bisa berkata “saya pernah mengerjakan X”
      Di tim kecil, cara seperti ini bisa sangat cepat menghentikan produktivitas, dan sering dibungkus sebagai keinginan untuk menyelesaikan semua masalah
      Namun hasilnya tidak ada satu pun masalah yang terselesaikan, malah lebih banyak masalah baru yang muncul
    • Di perusahaan dekat level FAANG, promosi sangat sulit, dan karena sistem level, sering kali satu-satunya cara menaikkan gaji adalah lewat promosi
      Promosi butuh promotion packet, dan promotion packet butuh proyek besar dan berat
      Akhirnya masalah inti yang ingin diselesaikan bukan lagi kebutuhan bisnis melainkan promosi, sehingga muncullah proyek-proyek raksasa yang sibuk mencari-cari masalah
    • Mungkin berguna untuk membakar uang perusahaan
      Yang dijelaskan tadi rasanya bahkan bukan proof of concept. Syarat dasar proof of concept adalah setidaknya harus bisa berjalan, sedangkan ini lebih mirip membuat susunan agar terlihat sibuk sambil ikut-ikutan tren
      Dari sudut pandang karyawan pun, sepertinya ini bukan lingkungan yang enak untuk bertahan lama
    • Orang-orang seperti itulah yang justru paling banyak dipromosikan. Sistemnya benar-benar kacau

  • Di blog itu ada lebih banyak tulisan yang lebih lucu. Saya terutama suka yang ini:
    https://www.theolognion.com/p/dev-builds-perfect-note-taking...
    Dan ada juga ini:
    https://www.theolognion.com/p/ai-solves-all-political-econom...

  • Saya tahu ini lelucon, tetapi kalau dilakukan postmortem, penyebab kegagalannya mungkin adalah “banyak orang di perusahaan berpikir ini sekalian kesempatan untuk melakukan upgrade dependensi software dan library juga. Mereka juga merasa sebagian besar database PostgreSQL yang tadinya berjalan di satu mesin bisa diubah menjadi distributed key-value store di AWS dengan memanfaatkan fleksibilitasnya yang luar biasa”
    Jaga scope

    • Itu memang hampir menjadi inti lelucon ini
      Di dunia ini banyak orang yang lebih fokus pada teknologi yang mereka gunakan daripada produk yang mereka buat
      Fokus pada produk berarti tahu scope dan tidak melakukan overengineering terlalu dini
      Lelucon ini berfokus pada Kubernetes, tetapi hal yang sama bisa dibuat dengan server-side rendering, AI, $modernFrontendLib, atau $modernLanguage
    • Scope perusahaan juga harus dijaga
      Jika bisnisnya bukan menjual infrastruktur cloud, ya gunakan saja penyedia cloud yang sudah jadi
      Apalagi jika Anda memang sudah membayar penyedia cloud, khususnya akan lebih baik jika tidak memakai Kubernetes

  • Di dunia nyata, migrasi Kubernetes 11 minggu akan dianggap sebagai sukses besar

    • Kenyataannya mungkin akan memakan 11 bulan, dan sekarang sudah menjadi sesuatu seperti “cloud-native”
      Tentu saja mengoperasikan database akan sedikit menyulitkan. Mereka lupa mengatur storage Kubernetes dengan benar, lalu setelah pod tiba-tiba berpindah, datanya pun hilang
    • Jika Anda sudah memakai Docker, hampir tidak ada alasan migrasi seperti itu harus memakan waktu selama itu
      Kalau sebelumnya bahkan belum memakai Docker, dalam migrasi serupa kemungkinan besar masalahnya bukan pada Kubernetes itu sendiri

  • Mengoperasikan sistem tidak pernah semudah dan semurah sekarang
    Tetapi para engineer justru cenderung lebih suka membentuk ekspedisi untuk mengantarkan satu pizza, mendaki Everest, memotret pizza itu di puncak, lalu membawanya pulang lagi dengan pesawat, menyewa Lamborghini untuk ikut Mongol Rally, dan baru 18 bulan kemudian mengantarkan pizza itu
    Padahal kalau selama itu mereka cukup naik skuter murah dan meluncur menuruni jalan, mereka sudah menang

    • Saya belum pernah bekerja di tempat di mana kompleksitas yang disuntikkan engineer bisa menandingi kompleksitas yang disuntikkan manajemen

  • Kalau teknologinya kompleks, harus dipelajari dulu. Coba dulu di layanan kecil yang tidak penting
    Lakukan satu per satu, dan mulai dari yang sederhana
    Saya memang berhasil memigrasikan layanan kami ke Kubernetes tanpa masalah, tetapi saya perlu 2 tahun belajar dan bereksperimen sambil memindahkan layanan-layanan kecil
    Setelah mencoba berbagai pendekatan, saya sampai pada cara yang paling cocok, dan itu bukan sesuatu yang bisa langsung ditemukan di internet
    Saya memakai GitOps, tetapi tidak mengotomatisasikannya; untuk hal yang diperlukan saya cukup menjalankan kubectl apply -k, karena saat itu saya menilai flux terlalu rumit untuk memulai
    Sekarang layanan kami sudah berjumlah puluhan dan pemahamannya juga sudah ada, jadi saya mulai mempertimbangkan untuk mengadopsi flux

  • Pada tahun 1977 saya bekerja sebagai pengacara litigasi muda di firma hukum yang menagih per jam
    Saya mencatat di kertas pekerjaan apa yang saya lakukan untuk tiap perkara, dan staf kantor memotong strip yang bisa dilepas dari lembar yang sudah selesai lalu menempelkannya di papan bagian dalam folder kertas tiap perkara
    Pada tahun 1979 saya membeli RadioShack Tandy I, dan tak lama kemudian mendalami Foxbase, program basis data berbasis DOS, di rumah. Belakangan menjadi FoxPro, dan diakuisisi Microsoft pada awal 1990-an
    Pada tahun 1981 saya membuka firma hukum saya sendiri, dan inovasi terbaru dalam produktivitas kantor saat itu adalah mesin tik elektrik dengan faks, layar satu baris, memori, dan disket kecil untuk menyimpan formulir. Perusahaan-perusahaan masih belum memakai komputer pribadi
    Firma saya segera berkembang menjadi sekitar 10 pengacara dan 12 staf pendukung, dan saya membelikan komputer Compaq untuk semua sekretaris
    Saya menghabiskan banyak waktu menulis program pencatatan waktu dan penagihan untuk menggantikan cara tempel-strip manual itu, dan saya juga belajar cara memasang jaringan lalu memasangnya sendiri
    Firma hukum lain yang saya kenal tidak punya komputer sama sekali, tetapi kami punya lebih dari 10 unit untuk staf pendukung dan 4–5 Compaq “portable” untuk para pengacara meninjau tagihan sebelum dikirim ke klien
    Pada saat yang sama, saya sedang menghancurkan bisnis saya. Kami punya teknologi kelas dunia pada masa ketika orang lain bahkan belum punya satu komputer pun, tetapi saya menutup pintu dan hanya memrogram, alih-alih fokus pada praktik hukum atau penjualan ke klien korporat
    Pada akhirnya saya menutup firma hukum itu pada tahun 1994
    Meski begitu, itu masa yang mendebarkan. Tak lama kemudian semua firma hukum punya komputer untuk pengolah kata, tetapi program penagihan komersial masih belum ada
    Selama sekitar 24 bulan, semua pengacara di firma hukum lain yang bekerja bersama saya menginginkan program penagihan saya
    Tetapi saya kewalahan dengan pekerjaan perkara sambil terus tenggelam dalam pemrograman yang menyenangkan, dan pekerjaan hukum saya menjadi laboratorium yang sempurna untuk program itu. Sayangnya, pemrograman itulah yang menghancurkan bisnis saya

    • Metode strip yang bisa dilepas itu benar-benar menarik. Saya penasaran apakah itu cara yang umum dipakai untuk pelacakan waktu saat itu
      Kalau masih ada fotonya, saya ingin melihatnya

  • Di bidang saya, kalau “Kubernetes” diganti dengan GraphQL/React/Next, itu tetap sangat tepat
    Tentu saja ini dilakukan untuk memindahkan aplikasi yang sudah berjalan sempurna, dan kebanyakan hanya aplikasi CRUD
    Padahal sama sekali tidak butuh trade-off yang dibawa GraphQL atau frontend interaktif, tetapi tetap saja dilakukan
    Semakin lama saya berada di industri ini, semakin sering saya melihat bahwa orang-orang di posisi yang bertanggung jawab sering kali tidak tahu apa yang mereka lakukan

    • Orang tidak dihargai karena menjaga agar sesuatu tetap berjalan baik
      Mereka dihargai karena perubahan, dan cukup kalau mereka bisa setidaknya berpura-pura bahwa perubahan itu menghasilkan dampak atau suatu saat nanti akan menghasilkan dampak

  • Saya sedang berjuang siang malam selama 4 bulan untuk memindahkan 500 ribu blob dari MinIO self-hosted ke blob storage terkelola, dan pekerjaan yang benar-benar produktif—bukan politik atau birokrasi—bahkan belum sampai 1 minggu
    Jadi migrasi Kubernetes 11 minggu terdengar seperti sukses besar