Bagaimana Figma bermigrasi ke K8s dalam waktu 12 bulan

 (figma.com)
1 poin oleh GN⁺ 2024-08-10 | 1 komentar | Bagikan ke WhatsApp
  • Figma menargetkan migrasi layanan inti yang sudah dikontainerisasi dari ECS ke Kubernetes berbasis EKS untuk mengurangi keterbatasan platform jangka panjang tanpa downtime
  • Di ECS, ketiadaan StatefulSets, sulitnya menjalankan OSS berbasis Helm chart, dan keterbatasan isolasi node menjadi hambatan besar, sementara Kubernetes membuka opsi dalam ekosistem CNCF seperti Keda, Karpenter, dan Istio
  • Migrasi dipersempit cakupannya dengan mempertahankan abstraksi untuk menjalankan layanan, deployment, dan tooling, lalu hanya mengganti orkestrasi; definisi layanan berbasis Bazel dan konfigurasi 3 klaster EKS termasuk dalam cakupan awal
  • Selama transisi, mereka memastikan kemungkinan rollback lewat load testing, pemindahan trafik bertahap berbasis Weighted DNS, migrasi dini layanan nyata, penyembunyian YAML mentah, dan kolaborasi dengan pemilik layanan
  • Hingga Januari 2024, sebagian besar layanan prioritas tertinggi telah dipindahkan ke EKS, menghasilkan pengurangan biaya overprovisioning, peningkatan keandalan, dan pengalaman developer yang lebih baik, lalu dilanjutkan dengan logging, autoscaling, dan migrasi ke Graviton

Alasan berpindah dari ECS ke Kubernetes

  • Pada awal 2023, Figma sudah menjalankan semua layanannya di dalam container, dan menggunakan AWS Elastic Container Service (ECS) sebagai platform orkestrasi
  • Saat meninjau platform komputasi generasi berikutnya, mereka menilai pendekatan terus menumpuk di atas ECS akan menyulitkan pembuatan kapabilitas yang diinginkan dalam jangka panjang
  • Figma bukan perusahaan yang mengoperasikan ribuan microservice, sehingga cakupan migrasi ke Kubernetes masih bisa dikelola secara realistis
    • Memang ada kasus di mana layanan baru dibutuhkan demi isolasi atau performa, tetapi layanan inti sudah menyediakan modularisasi dasar dan isolasi trafik
    • Produk baru juga sering didukung dengan menambahkan logika ke layanan inti yang ada, alih-alih membuat layanan baru

Fitur yang kurang di ECS

  • ECS tidak mendukung StatefulSets milik Kubernetes, sehingga pengoperasian penyimpanan data konsensus dengan konsistensi kuat seperti etcd menjadi rumit
    • Figma menyiasatinya dengan kode kustom yang memperbarui membership klaster secara dinamis saat container etcd dimulai
    • Pendekatan ini rapuh dan sulit dipelihara, sedangkan di Kubernetes lazim menggunakan alokasi jaringan stateful dari StatefulSets
  • Di ECS, sulit menjalankan kumpulan layanan yang didefinisikan dengan Helm charts
    • Beberapa tim ingin menjalankan perangkat lunak OSS seperti Temporal, tetapi di ECS tiap layanan harus dipindahkan secara manual ke definisi Terraform
  • Di ECS on EC2, penghentian satu mesin EC2 yang bermasalah secara elegan juga merepotkan
    • Di EKS, node yang buruk bisa di-cordon sehingga API server menghormati proses terminasi dan memindahkan Pod ke mesin lain

Ekosistem CNCF dan pilihan platform

  • Jika tetap memakai ECS, akan sulit memanfaatkan teknologi open source dari ekosistem Cloud Native Computing Foundation(CNCF)
  • Autoscaling adalah area penting untuk platform komputasi generasi berikutnya
    • Saat itu Figma belum menerapkan autoscaling pada layanan yang dikontainerisasi
    • Layanan diprovisi agar mampu menangani beban puncak bahkan pada jam trafik rendah seperti malam hari dan akhir pekan, sehingga menimbulkan biaya yang tidak perlu
    • Keda di ekosistem Kubernetes mendukung scaling bukan hanya berdasarkan penggunaan CPU, tetapi juga panjang antrean AWS SQS dan metrik kustom Datadog
  • Service mesh juga dinilai berpotensi dibutuhkan dalam jangka panjang
    • Trafik antar layanan yang ada dirutekan melalui AWS Application Load Balancers(ALB) dan Network Load Balancers(NLB)
    • NLB memerlukan waktu beberapa menit untuk mendaftarkan target baru dan menghapus target lama, sehingga memperlambat deployment darurat dan meningkatkan mean time to recovery saat insiden
    • Envoy menawarkan kustomisasi yang lebih tinggi dan kemampuan menjalankan filter kustom
    • Figma sebelumnya sudah menempatkan klaster mesin Envoy independen sebagai proxy di depan layanan-layanan penting, dan pernah memakai filter kustom untuk mengurangi beban saat insiden
    • Di EKS tersedia banyak opsi open source seperti Istio, sedangkan di ECS kemampuan serupa harus dibangun ulang sendiri

Keuntungan operasional dari platform yang populer

  • Figma tidak ingin menjadi pengguna terbesar dari suatu layanan atau perangkat lunak
    • Pengguna terbesar cenderung paling cepat menabrak sisi kasar dan batas skalabilitas
    • Kubernetes dipakai banyak perusahaan besar untuk platform komputasi berskala sangat besar, sehingga Figma termasuk pengguna yang jauh lebih kecil
  • Kubernetes membantu mengurangi vendor lock-in
    • EKS memberi keuntungan control plane yang didukung vendor
    • Karena layanan ditulis agar dapat berjalan di Kubernetes umum, beban untuk pindah ke platform Kubernetes lain yang didukung vendor atau platform self-hosted tidak terlalu besar
  • Merekrut engineer yang sudah berpengalaman dengan Kubernetes juga lebih mudah
    • Engineer dengan pengalaman sebelumnya bisa cepat beradaptasi dan memberi konteks pada area yang bisa menjadi keputusan baru di Figma

Prinsip penetapan cakupan migrasi

  • Dalam migrasi besar, lebih aman mengganti hanya sistem inti yang ingin diubah dan mempertahankan abstraksi yang terlihat oleh pengguna platform semaksimal mungkin
  • Figma mempersempit cakupan pada pemindahan dari ECS ke EKS tanpa mengubah cara menjalankan layanan, cara deployment, maupun tooling interaksi antarlayanan
  • Pekerjaan yang terlihat bukan seperti perubahan fitur pun bisa menimbulkan efek sekunder, sehingga jadwal migrasi skala besar mudah membesar
  • Ada dua pengecualian
    • Jika membuat sistem baru berperilaku sama seperti sistem lama memerlukan pekerjaan tambahan yang berlebihan, mereka bisa menerima efek sekunder dan memilih pendekatan baru
    • Untuk keputusan one-way door yang nantinya sulit atau mahal diubah, pendekatan baru bisa diterapkan sejak awal

Perbaikan yang dimasukkan ke dalam cakupan

  • Pengalaman developer

    • Definisi layanan ECS yang ada sebelumnya terutama dibuat dan diubah dengan Terraform
    • Melalui apply Terraform, mereka membuat template ECS task set dengan 0 instance, lalu pada proses deployment template itu digandakan, hash image diganti, dan task set dengan jumlah instance non-0 dideploy ke ECS
    • Bahkan untuk menambah satu environment variable pun perlu menulis dan meng-apply Terraform lalu menjalankan deployment; jika urutannya salah, environment variable tidak bisa dipakai dengan aman di kode dan bisa memicu bug
    • Di EKS, definisi layanan dipusatkan di satu tempat dan perubahan dideploy dalam satu langkah
    • Figma membuat pendekatan internal sederhana untuk mendefinisikan layanan lewat file konfigurasi Bazel, lalu menghasilkan otomatis YAML definisi layanan dan YAML konfigurasi seperti Ingress
    • YAML dihasilkan oleh tool CI saat kode di-commit, lalu diterapkan melalui sistem deployment internal

  • Keandalan

    • Untuk tiap layanan, mereka mengatur 3 klaster EKS agar menjalankan Pod dan menerima trafik
    • Jika seluruh operasi dilakukan pada level klaster, gangguan total bisa dibatasi menjadi dampak pada sepertiga layanan
    • Pada layanan yang bisa melakukan retry request atau pemrosesan asinkron, gangguan ke pengguna sering kali bisa diminimalkan
    • Konfigurasi ini memang sangat menambah kompleksitas operasional seperti pipeline deployment, tetapi dinilai layak diterapkan langsung saat migrasi daripada ditambahkan belakangan

  • Efisiensi biaya

    • Mereka tidak memasukkan banyak pekerjaan optimasi biaya yang kompleks ke dalam cakupan migrasi, tetapi sejak awal tetap mendukung autoscaling node
    • Pada layanan ECS on EC2, mesin di-overprovision untuk menangani lonjakan saat deployment
    • Di EKS, mereka memakai Karpenter untuk menaikkan dan menurunkan jumlah node secara dinamis sesuai permintaan

Pekerjaan yang dikeluarkan dari cakupan

  • Pipeline logging yang ada cukup kompleks
    • Semua log lebih dulu ditulis ke CloudWatch
    • Lambda membaca log tersebut dan melakukan transformasi seperti menghapus pola tertentu dan menambahkan tag
    • Setelah itu log ditulis ke Datadog dan Snowflake
    • Biaya CloudWatch sebagai penyimpanan perantara terus membesar
  • Figma berencana mengadopsi proyek CNCF Vector yang bisa memproses dan meneruskan log sebagai sidecar di stack EKS
  • Namun mereka menilai efek sekunder dari memindahkan logika log forwarder ke konfigurasi Vector tidak sepadan untuk dimasukkan ke cakupan migrasi
  • Autoscaling level Pod juga tidak dimasukkan ke dalam migrasi
    • Kompleksitasnya dinilai terlalu tinggi
    • Mereka menganggap ini pekerjaan yang mudah ditambahkan nanti
  • Pekerjaan yang dikeluarkan itu kemudian menjadi tindak lanjut, dan perbaikannya bisa dilakukan sambil melanjutkan migrasi layanan lain ke EKS

Cara eksekusi yang aman

  • Karena stack ECS yang ada relatif stabil, stack EKS baru dan proses migrasinya juga harus setidaknya sama andalnya

  • Load testing

    • Figma membuat layanan “Hello, World” dan menskalakannya hingga menjalankan jumlah Pod yang sama dengan layanan terbesar di Figma
    • Dari pengujian ini mereka menemukan bahwa ukuran dan skala layanan komputasi inti yang menopang seluruh platform perlu disesuaikan
    • Kyverno adalah tool validasi keamanan klaster, dan jika tidak dikonfigurasi cukup besar, dapat memperlambat startup Pod baru

  • Rollout bertahap

    • Mereka menggunakan entri Weighted DNS untuk memindahkan trafik sedikit demi sedikit dari layanan ECS lama ke padanannya di EKS
    • Kontrol pemindahan trafik yang rinci dan kemampuan rollback adalah inti migrasi yang aman
    • Dampak tak terduga bisa muncul di titik belok yang belum diketahui, sehingga cakupan dampak harus diperkecil dan rollback harus bisa dilakukan cepat

  • Menjalankan layanan nyata lebih awal

    • Menaruh workload nyata ke dalam sistem memungkinkan banyak pembelajaran yang tidak bisa didapat hanya dari staging
    • Figma memigrasikan satu layanan lebih dulu bahkan sebelum pembangunan environment staging selesai
    • Migrasi awal ini membantu memverifikasi kemampuan menjalankan workload secara end-to-end serta menemukan bottleneck dan bug

  • Abstraksi YAML

    • Membiarkan pengguna mendefinisikan layanan langsung dengan Kubernetes YAML mentah bisa membingungkan
    • Figma menyediakan golden path bagi pengguna, dengan kemampuan kustomisasi hanya untuk kasus khusus
    • Dengan memperjelas apa yang boleh dan perlu dikustomisasi pengguna sambil memaksakan konsistensi default, pemeliharaan dan perubahan di masa depan jadi lebih sederhana

  • Kolaborasi dengan pemilik layanan dan penempatan SDM

    • Konfigurasi layanan baru ditangani tim platform, sementara pembaruan monitoring dan alert dilakukan lewat kolaborasi erat dengan pemilik layanan yang paling paham kondisi layanan
    • Bahkan sebelum migrasi dimulai, mereka sudah cukup berdiskusi dengan pemilik layanan mengenai opsi dan trade-off
    • Migrasi berskala besar bisa menimbulkan masalah tak terduga, interaksi kompleks, dan bug umum, sehingga dibutuhkan tim dengan keahlian teknis mendalam dan kemampuan debugging yang kuat

Jadwal migrasi nyata dan hasilnya

  • Pada kuartal 1 2023, mereka menyusun rencana dan mendapatkan persetujuan untuk menjalankan migrasi
  • Pada kuartal 2 2023, mereka membangun environment staging dan memigrasikan satu layanan
  • Pada kuartal 3 2023, fokusnya adalah productionization, load testing, dan persiapan migrasi layanan tambahan
  • Dari kuartal 4 2023 hingga minggu pertama Januari 2024, trafik layanan dipindahkan secara perlahan
  • Hingga Januari 2024, sebagian besar layanan prioritas tertinggi telah dipindahkan ke klaster EKS baru
    • Monolith yang berisi logika bisnis inti
    • Layanan kompleks yang menangani aspek multiplayer dalam pengeditan file Figma
    • Layanan-layanan penyusun Livegraph 100x yang mendorong update real-time ke semua klien
  • Hasilnya, biaya overprovisioning untuk deployment berkurang, keandalan meningkat berkat operasi pada 3 klaster, dan usability untuk developer membaik
  • Keseluruhan pekerjaan berlangsung dengan insiden kecil dan dampak pelanggan yang rendah
  • Pernah ada insiden ketika seorang operator tanpa sengaja menghancurkan dan membuat ulang CoreDNS di salah satu klaster production
    • Pada konfigurasi sebelumnya, situasi seperti ini akan menjadi outage total
    • Dalam konfigurasi 3 klaster, dampaknya terbatas pada sepertiga request
    • Sebagian besar layanan downstream melakukan retry request dan akhirnya berhasil

Perbaikan tooling setelah rilis

  • Figma membangun tool agar pemilik layanan bisa melakukan debugging terhadap apa yang terjadi di klaster
    • Mengecek jumlah instance yang sedang berjalan
    • Mengakses shell container
    • Menjalankan tugas operasional seperti scaling darurat
  • Segera setelah rilis, mereka menerima masukan bahwa tool akses ini belum cukup ramah pengguna
  • Ada dua sumber kompleksitas utama
    • Dengan adanya 3 klaster, pengguna harus menjalankan perintah lintas beberapa klaster dan menambahkan nama klaster pada setiap perintah
    • Karena memanfaatkan role Kubernetes RBAC untuk memberi izin yang lebih terperinci, pengguna harus memahami role apa yang mereka miliki dan role apa yang dibutuhkan untuk tugas tertentu
  • Figma langsung menghentikan pekerjaan lain dan mengubah tool tersebut agar otomatis menyimpulkan klaster dan role yang tepat
  • Dengan begitu, pengguna tidak perlu membuang waktu mencari role, terutama saat situasi darurat tengah malam

Langkah berikutnya

  • Sambil melanjutkan migrasi layanan yang tersisa, mereka juga paralel meningkatkan platform komputasi baru
  • Area fokus saat ini adalah sebagai berikut
    • Menyederhanakan desain pipeline logging
    • Mendukung horizontal Pod autoscaling melalui Keda
    • Memindahkan layanan paling mahal di Figma ke prosesor Graviton untuk menekan biaya, sekaligus membuka jalur agar layanan lain juga bisa berjalan di Graviton ke depannya
  • Mereka juga berencana mengeksplorasi area yang belum banyak diinvestasikan
    • Meninjau penawaran service mesh untuk meningkatkan keandalan dan observability stack jaringan
    • Mengelola lebih banyak resource dengan AWS Controllers for Kubernetes(ACKs) untuk mengurangi ketergantungan pada Terraform serta menyederhanakan dan menyatukan stack
    • Bekerja sama dengan tim pengalaman developer untuk menyatukan cara layanan dijalankan di environment pengembangan dan di environment lain

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-10
Pendapat Hacker News

  • Secara pribadi saya menyukai Kubernetes. Saya mengelola beberapa toko e-commerce kustom yang kecil tetapi kompleks, sambil juga menangani pemasaran, keuangan, dan dukungan pelanggan
    Dulu semuanya berjalan di server khusus, tetapi stack-nya cukup kompleks sehingga deployment menjadi mimpi buruk, dan pada akhirnya beban deployment itu memperlambat laju perusahaan kecil kami
    Butuh satu bulan untuk mempelajari Kubernetes dan bermigrasi, dan sekarang kami menjalankan sekitar 25 layanan seperti frontend, pengelola produk, dashboard logistik, optimasi rute pengiriman, OSRM, ERP, mesin rekomendasi, pencarian, dan lainnya
    Dengan mengumpulkan konfigurasi cluster di satu tempat, kami bisa menatanya menjadi struktur yang dapat diulang, dan dapat mengetahui dengan tepat status setiap layanan serta versi yang sedang berjalan. Rolling deployment tanpa downtime juga menjadi mungkin, dan meski memang rumit, programmer memang pada dasarnya menangani hal-hal rumit. File konfigurasi Nginx juga rumit
    Semakin mendalaminya, semakin saya memahami mengapa arsitektur Kubernetes masuk akal, dan ia memaksa kita benar-benar mengikuti 12-factor. Jika pendapatan terhubung langsung dengan ketersediaan dan stabilitas stack, high availability bukan sekadar sesuatu yang “bagus kalau ada”. Biaya hosting juga sekitar 400 dolar per bulan, jadi tidak terlalu mahal

    • Figma sebelumnya juga sudah berjalan di ECS, jadi bukan sekadar memakai server khusus saja
      Saya cenderung percaya pada Kubernetes, tetapi memang benar-benar kompleks. Ini adalah alat yang memecahkan masalah sulit. Kalau multi-cloud, tidak perlu banyak diperdebatkan, dan kalau menginginkan infrastruktur kompleks yang sepadan 1:1 dengan lokal, ini cocok
      Namun jika jumlah developer kurang dari 100 dan Anda hanya men-deploy container ke AWS, menurut saya memakai EKS alih-alih ECS + Fargate pada 2024 itu tidak waras
    • Jika menjalankan beberapa toko e-commerce kustom yang kecil dan kompleks, saya penasaran bagaimana Anda menangani kurangnya multitenancy di Kubernetes

  • Migrasi untuk memperbaiki fondasi infrastruktur itu sendiri bagus. Namun cukup mengejutkan bahwa salah satu motivasinya adalah agar tim memakai Helm chart alih-alih mengonversinya ke Terraform
    Dalam praktiknya, saya jarang melihat Helm chart sembarang bisa dipakai secara stabil tanpa modifikasi, dan jika penggunaannya didorong, pada akhirnya tim akan mem-fork dan memodifikasi chart tersebut. Helm adalah alat yang begitu buruk sehingga saya tidak ingin memelihara Helm chart kustom sendiri
    Menurut saya, menulis ulang dengan Terraform justru lebih mudah untuk memelihara versi lokal. Saya ingin mendengar jika ada contoh yang membantahnya. Mungkin sekarang kegilaan indent 4 di Helm dan masalah template string bertingkat sudah hilang

    • Menurut saya Helm chart dan Terraform adalah hal yang berbeda. Terraform lebih cocok untuk men-deploy resource cloud seperti bucket S3, cluster EKS, worker EKS, dan RDS
      Kubernetes workload memang bisa dikelola dengan Terraform, tetapi saya tidak merekomendasikannya. Kubernetes sendiri sudah punya state, dan jika Terraform juga punya state, kombinasi Terraform + Kubernetes menjadi menyakitkan. Helm dibuat untuk Kubernetes, sedangkan Terraform tidak
      Meski begitu, bukan berarti saya menyukai Helm. YAML yang ditemplatkan itu tidak menyenangkan, dan kegilaan indent 4 juga masih ada. Kustomize bagus saat masih sederhana, tetapi ketika aplikasi menjadi kompleks, menurut saya ia lebih buruk daripada Helm. Misalnya, jika ingin men-deploy aplikasi dengan Ingress, sertifikat TLS, dan external-dns untuk beberapa environment, sesuatu yang cukup memakai satu variabel di tiga tempat malah mengharuskan Anda mem-patch resource tiga kali
      Helm maupun Terraform sama-sama populer sehingga sering disebut, tetapi pada akhirnya saya rasa akan muncul alat pengganti keduanya yang belum menjadi mainstream
    • Di BigCo tempat saya bekerja saat ini, kami mengelola infrastruktur dan deployment dengan Terraform dalam skala yang tidak masuk akal, dan itu mimpi buruk
      Masalah Terraform adalah workspace harus dirancang agar tidak melampaui jumlah resource yang direkomendasikan per workspace, sekitar 100–200. Jika tidak, plan menjadi jauh lebih lambat karena ikut memeriksa database atau jaringan yang tidak disentuh dan tidak ingin disentuh, sehingga waktu deployment bertambah
      Dalam praktiknya, Anda akan membuat kisi-kisi workspace Terraform yang saling memicu, dan saat ini tidak ada alat open source yang bagus yang benar-benar mendukung ini
      Menurut saya opsi terbaik saat ini adalah Terraform memasang alat continuous deployment seperti ArgoCD sebagai bagian dari infrastruktur, lalu deployment sehari-hari ditangani oleh alat CD. Dan sebagian besar alat CD meminta deployment dipaketkan dengan sesuatu seperti Helm
    • Kalau bicara soal Helm, secara pribadi sekarang saya sudah sangat membencinya. Saat pertama muncul, ia hebat dan mengisi kekosongan yang memang dibutuhkan
      Namun ada terlalu banyak jebakan, sehingga saya menghabiskan waktu mengulang dan men-debug pekerjaan yang dibuat engineer lain
      Saya berharap alat baru bernama timoni mendapatkan momentum. Ia menyelesaikan hampir semua keluhan saya terhadap Helm. Jika sedang mencari solusi yang lebih baik, timoni layak dilihat
    • Tim kami juga mengalami masalah yang disebutkan pada Helm chart publik. Agar berjalan dengan benar di environment sendiri, selalu ada sesuatu yang harus dikustomisasi
      Kami memilih pendekatan memakai Helm chart publik apa adanya, lalu menangani kustomisasi dengan kustomize —enable-helm
    • Saya setuju bahwa menulis Helm chart bukan sesuatu yang terlalu menyenangkan, tetapi dari sisi penggunaannya bisa cukup baik
      Dalam kasus kami, ada Helm chart berbasis satu aplikasi/layanan yang menyediakan default yang masuk akal, dan semua deployment memperluasnya. Konfigurasi Helm values yang dibutuhkan di sisi pengguna minimal, dan hampir tidak pernah perlu memasukkan template sendiri. Itu karena chart dasar mengekspos titik pengaturan yang cukup
      Banyak chart pihak ketiga bisa kami deploy apa adanya, dan sesekali kami menambahkan fitur yang dibutuhkan ke upstream lewat PR. Kadang memang harus membungkus atau mem-fork, tetapi jauh lebih banyak chart pihak ketiga yang kami deploy apa adanya
      Saat memelihara chart kustom, helm unittest (https://github.com/helm-unittest/helm-unittest) sangat membantu menghindari regresi
      Kami memang mengelola beberapa resource Kubernetes termasuk ArgoCD dengan Terraform, tetapi secara umum deployment Helm chart melalui ArgoCD jauh lebih mudah dikelola dan lebih produktif

  • Saya agak heran kenapa di HN ada begitu banyak sentimen anti-Kubernetes seperti ini. Saya penasaran apakah sebagian besar komentator adalah developer yang terbiasa dengan layanan seperti Heroku, fly.io, render.com, atau memang menjalankan aplikasi di VM

    • Banyak orang sudah muak, dan wajar saja, dengan ledakan kompleksitas yang tidak perlu dalam software selama kira-kira 10 tahun terakhir
      Ini bukan masalah yang terbatas pada kasus tertentu, melainkan masalah yang muncul dari insentif industri yang sangat melenceng secara umum, serta sampai batas tertentu demam emas era suku bunga rendah
      Terus terang, kalau dilihat seperti sekarang, di bidang lain kita mungkin tampak seperti perajin yang cukup tidak berguna. Kita terobsesi secara tidak sehat pada alat dan pekerjaan meta, sementara terus membuang penggunaan sumber daya yang masuk akal demi memakai alat tertentu. Semacam situasi “insinyur FAANG yang untuk sementara sedang berada dalam kesulitan”
    • Secara pribadi saya agak kesal dengan argumen memakai Kubernetes karena kebutuhan bisnis teoretis yang dibayangkan, misalnya suatu hari nanti mungkin perlu multi-cloud atau deployment on-premises
      Sulit menjelaskan betapa jauh lebih lama, betapa lebih banyak keahlian yang dibutuhkan, betapa lebih rapuh, dan betapa lebih mahalnya membangun di atas Kubernetes dibandingkan model deployment yang bisa dipilih di AWS, misalnya image VM di EC2, Elastic Beanstalk, ECS/Fargate, atau Lambda
      Saya tidak ingin memasang dan memelihara sendiri stack ELK atau Prometheus. Saya juga tidak ingin bergulat dengan plugin CNI, Kafka, Postgres high-availability, Argo, Helm, dan upgrade control plane. Dengan layanan padanan dari AWS, kita bisa mulai hampir seketika, maintenance-nya hampir tidak ada, dan biayanya biasanya mulai secara linear dari titik yang mendekati 0
      Masalah bisnis bisa diselesaikan jauh lebih cepat dan efisien. Ini bedanya antara kondisi di mana kita bisa melampaui ekspektasi secara signifikan dan kondisi di mana seluruh tim tertinggal beberapa kuartal
      Namun jika memang benar-benar ada kebutuhan multi-cloud atau on-premises, saya tidak ingin memakai apa pun selain Kubernetes. Kalau perusahaan besar punya banyak engineer berpengalaman yang memahami Kubernetes, mungkin tidak terlalu buruk. Setidaknya tempat-tempat saya bekerja tidak seperti itu
    • Dalam satu sisi, fakta bahwa banyak orang membencinya juga merupakan tanda keberhasilan
      Menyenangkan melihat perusahaan-perusahaan terutama berpindah ke infrastruktur open source. Banyak di antaranya berasal dari CNCF (https://landscape.cncf.io), ASF, dan berbagai proyek di GitHub
    • Dalam situasi tertentu teknologi ini layak dipakai, tetapi terlalu sering diadopsi seperti cargo cult
    • Bagi saya, masalah di sisi VM cukup besar. Saya tidak nyaman membayangkan jika ada kerentanan kernel, kode berbahaya bisa keluar dari container dan mengobrak-abrik host Kubernetes
      kata-containers mungkin bisa mengatasi kekhawatiran itu dan membuat saya menikmati Kubernetes
      Secara keseluruhan, bagi saya pribadi tidak ada hal di Kubernetes yang terasa keren. Container, load balancer, YAML berukuran megabyte—semua itu sudah pernah saya lihat, dan tidak terasa cukup menarik untuk dicoba

  • Untuk perusahaan sebesar ini mungkin normal, tetapi saya sulit mengikuti pengambilan keputusan dalam migrasi raksasa atau proyek teknologi seperti ini. Sebab keputusan itu tidak tampak berasal dari kebutuhan pengguna atau perusahaan
    Saya merasakan hal yang sama dari tulisan serupa yang dulu diposting Figma tentang database
    Misalnya, jika alasan ingin pindah ke Kubernetes adalah karena di ECS tidak bisa memakai etcd/Helm, maka pertanyaan pertama seharusnya adalah mengapa ingin memakai etcd/Helm. Apakah itu benar-benar sepenting itu? Apakah cara mencapai tujuan perusahaan benar-benar harus persis seperti itu?
    Jika keputusan didasarkan pada kebutuhan pengguna, mudah untuk memverifikasi apakah keputusan-keputusan turunannya masuk akal. Tetapi jika didasarkan pada kebutuhan teknis, keputusan turunan bisa tampak masuk akal dalam konteks kebutuhan teknis tersebut, tetapi tetap belum jelas apakah valid dalam konteks pengguna
    Rasanya salah satu dari dua hal ini benar: saya yang tidak memahami organisasi sebesar ini, atau memang secara fundamental sulit bagi organisasi sebesar ini untuk mengidentifikasi dan menalar pekerjaan yang bernilai

    • Saya penulisnya, dan menurut saya ini pertanyaan yang bagus dengan framing yang bagus juga. Setidaknya untuk beberapa keputusan besar, termasuk keputusan ini, saya setuju dengan pernyataan bahwa “secara fundamental sulit bagi organisasi sebesar ini untuk mengidentifikasi dan menalar pekerjaan yang bernilai”
      Pada dasarnya kami adalah tim platform, dan kami sering membuat alat untuk tim platform lain yang membuat alat guna mendukung developer Figma yang membangun pengalaman produk nyata. Semakin jauh dari pengguna akhir, semakin sulit menalar keputusan yang benar, tetapi pada saat yang sama leverage-nya juga besar
      Jika platform dibuat dengan benar, dampaknya memengaruhi kemampuan semua engineer lain untuk bekerja secara efisien dan efektif. Banyak dari dampak itu bersifat tidak langsung
      Opsi untuk mengatakan bahwa kami tidak bisa mendukung etcd dan Helm lalu meminta mereka mencari jalan memutar lain jelas ada. Namun keduanya adalah titik data tambahan yang mendorong kami pada kesimpulan bahwa kami mengoperasikan platform Compute di atas komponen dasar yang keliru
      Meski penalarannya sulit, upaya melakukannya dengan baik sangat layak. Sebab sebagai tim platform, itulah cara kami memastikan apakah kami melakukan hal yang benar untuk mencapai platform terbaik. Karena itu kami menghabiskan banyak waktu untuk mengambil keputusan ini, dan saya pikir ini topik yang menarik untuk ditulis
    • Alasan orang berpindah dari ECS ke Kubernetes adalah untuk memakai alat dan produk yang tidak terikat pada penyedia cloud
      Kemungkinan besar banyak migrasi Kubernetes di perusahaan besar didorong oleh keinginan untuk multi-cloud atau hybrid on-premises, serta mitigasi biaya, ketersediaan, dan risiko lock-in
    • Mengelola lebih dari 500 VM itu banyak pekerjaannya
      Upgrade VM, autentikasi, backup, rotasi log, dan sebagainya semuanya harus diselaraskan
      Di Kubernetes, kita bisa memberikan namespace, policy, dan volume kepada masing-masing pihak, dan berkat DaemonSet serta stack Kubernetes/cloud-native, agregasi log otomatis juga memungkinkan
      Ada juga self-healing dan lain-lain; sulit menjelaskan seberapa besar peningkatannya
    • Saya tidak suka Helm, tetapi alternatif yang baik untuk etcd ternyata sangat sedikit
      Misalnya, tidak banyak data store yang high-availability sekaligus konsisten untuk dipakai sebagai padanan file .pid di lingkungan terdistribusi. Yang terpikir hanya Zookeeper, tetapi dari sisi operasional benar-benar menyakitkan, membutuhkan versi JVM lama, dan meski begitu secara keseluruhan tetap tidak stabil
    • Teori tentang mengapa hal seperti ini terjadi ada di sini: https://lethain.com/grand-migration/

  • Setelah kode Terraform diterapkan, dibuat ECS task set dengan 0 instans untuk menjalankan templat layanan. Lalu, saat developer men-deploy layanan, mereka harus menduplikasi task set templat ini dan melakukan beberapa pekerjaan manual. Bagian ini terdengar bukan sebagai masalah ECS, melainkan seperti cara pengelolaan deployment Terraform + ECS yang dibuat terlalu rumit
    Saya paham bagian membuat templat untuk divalidasi sebelum deployment sebenarnya. Namun ini agak ambigu

    • Saya penulisnya, dan saya sepenuhnya setuju bahwa ini bukan keterbatasan mendasar ECS. Kami juga bisa terus memperbaiki konfigurasi ini menjadi sesuatu yang lebih baik
      Karena itu saya sengaja mengklasifikasikan item ini sebagai pekerjaan yang kami putuskan untuk dimasukkan dalam proses migrasi, dan tidak memasukkannya sebagai alasan mendasar kami memulai migrasi
    • Setuju. Deployment ECS cukup tidak menyakitkan dan sederhana
      Namun saya bisa membayangkan beberapa skenario yang membuat pendekatan ini diperlukan. Misalnya ketika ada banyak layanan yang di-deploy ke ECS sehingga ukuran state Terraform membesar. Maka plan dan apply menjadi jauh lebih lambat, dan mereplikasi konfigurasi apa adanya berbasis templat untuk melakukan sharding state Terraform bisa menjadi jauh lebih aman
    • Sangat setuju. Saya pernah membangun infrastruktur ECS dengan Terraform di dua perusahaan, dan tidak ada langkah manual sama sekali untuk pekerjaan seperti ini
      Yang dilakukan hanya menambahkan variabel lingkungan ke file Terraform, merge, lalu CI yang melakukan deployment. Sebagian besar perubahan konfigurasi yang kami lakukan ditangani lewat proses itu

  • “Migrasi ke Kubernetes bisa memakan waktu bertahun-tahun”—saya tidak tahu ini sedang membaca apa
    Untuk siapa itu berlaku? Saya juga tidak begitu paham mengapa perusahaan sengaja melakukan migrasi seperti ini. Di mana nilai bisnisnya, dan di mana manfaatnya bagi pelanggan? Apakah ini semacam proyek “seni demi seni” yang dilakukan karena Figma bisa melakukannya?

    • Saya juga cukup terkejut dengan kalimat itu, dan juga terkejut dengan bagian yang seolah membanggakan bahwa mereka pindah ke Kubernetes dalam waktu kurang dari 1 tahun
      Bahkan di perusahaan yang sangat mapan, berusia sekitar 30 tahun, dengan beban warisan yang menyertainya, kami pindah ke Kubernetes dalam waktu yang jauh lebih singkat. Namun kami tidak mencoba memindahkan semuanya ke Kubernetes; kami hanya memindahkan hal-hal yang bisa mendapatkan manfaat
      Usulan kami kira-kira begini. Jika pindah ke Kubernetes, saat perpindahan data center yang direncanakan akhir tahun nanti, Anda tidak perlu melakukan apa pun selain pengecekan. Atau, Anda harus men-deploy ulang aplikasi ke mesin atau VM baru dan menangani segala macam masalah yang menyertainya. Jika belum dikontainerisasi, lakukan kontainerisasi sekarang dan sisanya akan kami tangani
      Sebagian besar berpindah dan sangat puas dengan hasilnya. Sebaliknya, layanan yang sensitif terhadap latensi atau berada di ranah komputasi berkinerja tinggi tidak punya alasan untuk dipaksa pindah, dan kami juga tidak mencoba memaksakannya
    • Ini menyelesaikan masalah “baru saja diakuisisi, dan ada banyak resource yang harus digunakan”

  • Berapa lama waktu yang dibutuhkan untuk keluar dari ini?

    • Tergantung berapa banyak kode Kubernetes-native yang ada. Ada juga aplikasi yang banyak menggunakan Kubernetes API dan dirancang untuk berjalan di Kubernetes
      Jika aplikasinya sudah menjadi microservices, kembali mundur juga tidak sederhana

  • Saat membaca posting blog yang dengan santai menyebut 6 proyek CNCF bernama keren yang baru pertama kali saya dengar, hanya untuk mendapatkan fitur yang sekilas terlihat sederhana, saya merasa tertinggal zaman
    Saya jadi serius bertanya-tanya apakah sudah saatnya saya menua dan keluar dari pengembangan perangkat lunak profesional

    • Tidak juga. Masih banyak pekerjaan untuk individual contributor
      Itu hanya berarti Anda belum terbiasa dengan salah satu pendekatan untuk scaling organisasi, yaitu cara tim platform mengabstraksikan hardware, logging, retry, dan sebagainya
      Itu bukan satu-satunya pendekatan, jadi mungkin Anda terbiasa dengan cara lain

  • Saya suka artikel ini karena menjelaskan manfaat dan alasan menggunakan Kubernetes dengan jelas dan runtut
    Banyak tim terjun tanpa tahu apa yang akan mereka dapatkan, atau apakah mereka memang membutuhkannya sejak awal, tetapi alasan yang diberikan di sini terlihat masuk akal

  • Sekadar penasaran, sistem atau layanan modern lain apa yang, bagi orang waras, layak dibanggakan karena berhasil dimigrasikan dalam 1 tahun?

    • Ini pertanyaan yang sulit dijawab. Tidak semua sistem sama dalam hal skala, cakupan, dan dampak
      Sistem seperti Kubernetes biasanya merupakan inti infrastruktur, sehingga memengaruhi semua hal yang sedang berjalan. Jika ditambah batasan tim yang disebutkan dalam artikel, 1 tahun tidak terdengar terlalu buruk
      Contoh yang langsung terpikir adalah dulu Amazon pernah berpindah sepenuhnya dari Oracle ke database relasional Amazon/open-source. Namun seingat saya itu memakan waktu beberapa tahun. Kalau selesai dalam 1 tahun, mereka pasti akan membanggakannya
    • Saya sudah sering melihat migrasi yang memakan waktu lebih dari 1 tahun
      Biasanya masalahnya lebih pada technical debt, kompleksitas integrasi, dan jumlah orang yang dialokasikan, bukan pada teknologinya sendiri