GitPod memutuskan untuk meninggalkan Kubernetes + mengumumkan GitPod Flex

xguru · 2024-11-05T10:11:01+09:00

GitPod telah menggunakan Kubernetes selama 6 tahun untuk membangun "platform lingkungan pengembangan jarak jauh", mendukung 1,5 juta pengguna dan menyediakan ribuan lingkungan pengembangan setiap hari Namun, mereka menyadari bahwa Kubernetes tidak cocok untuk membangun lingkungan pengembangan Ini bukan pembahasan tentang apakah Kubernetes sebaiknya dipakai untuk workload produksi, juga bukan tentang cara membangun pengalaman developer untuk menerapkan aplikasi ke K8s → Ini adalah cerita tentang bagaimana membangun lingkungan pengembangan di cloud (atau bagaimana sebaiknya tidak melakukannya) [Mengapa lingkungan pengembangan itu istimewa] Sangat stateful dan sangat interaktif Tidak bisa dipindahkan begitu saja antar node Banyak source code, build cache, container Docker, data pengujian, dan sebagainya yang sering berubah, dengan biaya migrasi yang tinggi Berbeda dari layanan produksi, interaksi 1:1 terjadi antara developer dan lingkungannya Developer sangat terikat dengan source code dan perubahannya Mereka tidak suka kehilangan perubahan source code atau diblokir oleh sistem Lingkungan pengembangan sangat sensitif terhadap kegagalan Memiliki pola penggunaan resource yang tidak dapat diprediksi Sebagian besar waktu tidak membutuhkan banyak bandwidth CPU, tetapi dalam hitungan ratusan ms bisa saja membutuhkan beberapa core Jika lebih lambat dari itu, hasilnya terasa sebagai latensi yang tidak bisa diterima dan sistem yang tidak responsif Membutuhkan hak akses dan kemampuan yang luas Tidak seperti workload produksi, lingkungan ini memerlukan akses root serta kemampuan mengunduh/memasang paket Hal-hal yang menjadi masalah keamanan di workload produksi justru merupakan perilaku yang diharapkan di lingkungan pengembangan (akses root, kemampuan jaringan yang diperluas, mount filesystem tambahan, dll.) Karakteristik ini membuatnya berbeda dari workload aplikasi biasa, dan sangat memengaruhi keputusan infrastruktur [Sistem saat ini: Kubernetes] Pada masa awal Gitpod, Kubernetes tampak seperti pilihan infrastruktur yang ideal Skalabilitas, orkestrasi container, dan ekosistem yang kaya sangat cocok dengan visi mereka untuk lingkungan pengembangan cloud Namun, seiring skala dan basis pengguna bertambah, mereka menghadapi kesulitan dalam keamanan dan pengelolaan state Kubernetes dirancang untuk menjalankan workload aplikasi yang terkontrol dengan baik, bukan untuk lingkungan pengembangan yang sulit ditangani Mengelola Kubernetes dalam skala besar itu rumit Layanan terkelola seperti GKE dan EKS memang meredakan sebagian masalah, tetapi punya batasan dan kendalanya sendiri Banyak tim yang ingin menjalankan CDE cenderung meremehkan kompleksitas Kubernetes Ini menyebabkan beban support yang besar pada produk Gitpod self-managed sebelumnya Sulitnya manajemen resource Alokasi CPU dan memori adalah tantangan terbesar Berbagi lingkungan di satu node memang terlihat menarik, tetapi dalam praktiknya efek noisy neighbor sangat besar Masalah CPU Lingkungan pengembangan kadang tidak membutuhkan banyak CPU, tetapi sesekali membutuhkannya dalam jumlah besar secara mendadak Mereka bereksperimen dengan solusi berbasis CFS, controller kustom, dan lainnya, tetapi tetap sulit diprediksi Bahkan dengan batas CPU statis pun, tetap muncul masalah ketika beberapa proses saling berebut resource Manajemen memori Mengalokasikan memori tetap itu sederhana tetapi membatasi Overbooking dapat menyebabkan proses dihentikan Dengan diperkenalkannya swap space, kebutuhan untuk overbooking sedikit berkurang Optimasi performa storage IOPS dan latensi memengaruhi pengalaman lingkungan pengembangan Mereka bereksperimen dengan berbagai konfigurasi untuk mencari keseimbangan antara kecepatan, stabilitas, biaya, dan performa SSD RAID 0 Block storage seperti EBS dan persistent disk PVC Backup/restore adalah operasi yang mahal Autoscaling dan optimasi waktu startup Meminimalkan waktu startup adalah tujuan utama Mereka mengira menjalankan beberapa workspace di satu node akan memperbaiki waktu startup berkat cache bersama, tetapi ternyata tidak demikian Kubernetes menetapkan batas bawah pada waktu startup Evolusi cara scale-out Mereka bereksperimen dengan ghost workspace, ballast pod, dan lainnya untuk scale-out Pengenalan plugin autoscaler sangat meningkatkan strategi scaling Autoscaling proporsional untuk menangani beban puncak Menyalakan pod kosong agar bisa merespons lonjakan permintaan dengan cepat Berbagai upaya untuk mengoptimalkan image pull Pre-pull DaemonSet, memaksimalkan reuse layer, pre-baked image, Stargazer dan lazy pulling, Registry-facade + IPFS Kompleksitas jaringan Kontrol akses lingkungan pengembangan Lingkungan harus benar-benar terisolasi satu sama lain Network policy membantu, tetapi saat jumlah layanan bertambah muncul masalah keandalan Berbagi bandwidth jaringan CNI kadang mendukung network shaping, tetapi itu berarti ada hal lain lagi yang harus dikendalikan Keamanan dan isolasi: menyeimbangkan fleksibilitas dan perlindungan Tantangan terbesar adalah menyediakan lingkungan yang aman sambil tetap memberi fleksibilitas kepada pengguna Memberikan hak root kepada pengguna memiliki banyak kelemahan User namespace adalah solusi yang lebih granular Konversi UID filesystem, masked proc mount, dukungan FUSE, penyediaan kemampuan jaringan, mengaktifkan Docker Sulitnya implementasi user namespace Dampak performa, masalah kompatibilitas, kompleksitas, dan kebutuhan mengikuti versi Kubernetes [Eksperimen Micro VM] Saat menyadari keterbatasan Kubernetes, mereka mulai menjajaki teknologi micro VM (uVM) seperti Firecracker, Cloud Hypervisor, dan QEMU sebagai titik tengah Mereka berharap bisa meningkatkan isolasi resource, kompatibilitas dengan workload lain (termasuk Kubernetes), dan keamanan, sambil tetap mempertahankan kelebihan containerization Kelebihan micro VM Menawarkan sejumlah keuntungan menarik yang sangat selaras dengan tujuan untuk lingkungan pengembangan cloud Isolasi resource yang lebih baik: kemampuan overbooking menurun, tetapi isolasi resource lebih baik dibanding container. Perebutan resource kernel bersama hilang sehingga performa per lingkungan pengembangan menjadi lebih dapat diprediksi Memory snapshot dan resume cepat: fitur userfaultfd di Firecracker mendukung memory snapshot. Ini memungkinkan seluruh mesin, termasuk proses yang sedang berjalan, dilanjutkan hampir seketika. Dari sudut pandang developer, startup lingkungan menjadi jauh lebih cepat, dan pekerjaan bisa dilanjutkan tepat dari titik terakhir Batas keamanan yang lebih baik: uVM dapat berfungsi sebagai batas keamanan yang kuat, sehingga mekanisme user namespace kompleks yang mereka bangun di Kubernetes tidak lagi diperlukan. Ini juga bisa sepenuhnya kompatibel dengan workload yang lebih luas, termasuk containerization bertingkat (menjalankan Docker atau Kubernetes di dalam lingkungan pengembangan) Tantangan micro VM Namun, hasil eksperimen micro VM mengungkap beberapa tantangan besar Overhead: bahkan VM ringan pun menyebabkan overhead lebih besar daripada container. Ini memengaruhi performa maupun pemanfaatan resource, yang merupakan pertimbangan penting bagi platform lingkungan pengembangan cloud Konversi image: untuk mengubah image OCI menjadi filesystem yang bisa digunakan di uVM dibutuhkan solusi kustom. Ini membuat pipeline manajemen image lebih rumit dan berpotensi memengaruhi waktu startup Keterbatasan per teknologi Firecracker: tidak ada dukungan GPU (yang makin penting bagi sebagian workflow pengembangan), tidak ada dukungan virtiofs (membatasi opsi berbagi filesystem yang efisien) Cloud Hypervisor: tidak ada dukungan userfaultfd, sehingga proses snapshot dan restore menjadi lebih lambat (mengurangi salah satu keunggulan utama uVM) Masalah perpindahan data: uVM membuat mereka harus menangani memory snapshot berukuran besar, sehingga perpindahan data menjadi lebih sulit. Ini memengaruhi scheduling maupun waktu startup, yang merupakan elemen kunci pengalaman pengguna lingkungan pengembangan cloud Pertimbangan storage: eksperimen menghubungkan volume EBS ke micro VM membuka kemungkinan baru, tetapi juga memunculkan pertanyaan baru Storage persisten: menyimpan konten workspace di volume terpasang menghilangkan kebutuhan mengambil data berulang kali dari S3, sehingga diharapkan bisa memperbaiki waktu startup dan mengurangi penggunaan jaringan Pertimbangan performa: berbagi volume throughput tinggi antar workspace diharapkan meningkatkan performa I/O, tetapi juga menimbulkan kekhawatiran tentang implementasi kuota yang efektif, pengelolaan latensi, dan jaminan skalabilitas Pelajaran dari eksperimen micro VM Walaupun micro VM pada akhirnya tidak menjadi solusi infrastruktur utama, eksperimen ini menghasilkan wawasan berharga Mereka menyukai backup penuh workspace untuk lingkungan pengembangan serta pengalaman suspend/resume state runtime Untuk pertama kalinya mereka mulai mempertimbangkan untuk keluar dari Kubernetes. Setelah berupaya mengintegrasikan KVM dan uVM ke pod, mereka mulai mengeksplorasi opsi di luar Kubernetes Mereka kembali menyadari bahwa storage adalah elemen kunci untuk menghadirkan tiga hal sekaligus: performa startup yang stabil, workspace yang stabil (mencegah kehilangan data), dan pemanfaatan mesin yang optimal Kubernetes sangat menantang sebagai platform lingkungan pengembangan Seperti disebutkan sebelumnya, lingkungan pengembangan membutuhkan sistem yang menghormati sifat stateful uniknya Sistem juga harus memberikan hak akses yang diperlukan agar developer bisa produktif, sambil tetap menjamin batas keamanan yang aman Semua itu harus dicapai sambil menjaga overhead operasional tetap rendah dan tanpa mengorbankan keamanan Saat ini semua itu memang bisa dicapai dengan Kubernetes, tetapi biayanya sangat besar Mereka belajar dengan cara yang sulit bahwa workload aplikasi dan workload sistem itu berbeda Kubernetes adalah teknologi yang luar biasa Ia membangun ekosistem yang benar-benar kaya dengan dukungan komunitas yang penuh semangat Jika Anda menjalankan workload aplikasi, Kubernetes tetap merupakan pilihan yang baik Namun untuk workload sistem seperti lingkungan pengembangan, Kubernetes menghadirkan tantangan besar dari sisi keamanan dan overhead operasional Micro VM dan anggaran resource yang jelas memang membantu, tetapi biaya menjadi faktor yang lebih dominan Karena itu, setelah bertahun-tahun secara efektif merekayasa balik dan memaksakan lingkungan pengembangan ke atas platform Kubernetes, mereka memutuskan untuk mundur selangkah dan memikirkan seperti apa arsitektur pengembangan masa depan seharusnya Pada Januari 2024, mereka mulai membangunnya, dan pada Oktober meluncurkan Gitpod Flex Fondasi arsitekturnya dibangun di atas lebih dari 6 tahun wawasan yang sangat sulit diperoleh tentang cara menjalankan lingkungan pengembangan secara aman pada skala internet Masa depan lingkungan pengembangan Dengan Gitpod Flex, mereka mempertahankan aspek mendasar Kubernetes, yaitu penerapan teori kontrol yang bebas dan API deklaratif, sambil menyederhanakan arsitektur dan memperkuat fondasi keamanan Mereka mengorkestrasi lingkungan pengembangan menggunakan control plane yang sangat terinspirasi oleh Kubernetes Mereka memperkenalkan lapisan abstraksi yang dibutuhkan dan khusus untuk lingkungan pengembangan, sambil menghilangkan sebagian besar kompleksitas infrastruktur yang tidak perlu Semua ini dilakukan dengan keamanan zero-trust sebagai prioritas utama Berkat arsitektur baru ini, mereka dapat mengintegrasikan dev container dengan mulus Ini juga membuka kemampuan untuk menjalankan lingkungan pengembangan di desktop Karena tidak lagi harus memikul beban berat platform Kubernetes, Gitpod Flex kini bisa di-deploy secara self-hosted dalam waktu kurang dari 3 menit, dan dapat diterapkan ke sebanyak apa pun region yang diinginkan Ini memberikan kontrol yang lebih rinci untuk kepatuhan serta fleksibilitas yang lebih besar dalam memodelkan batas dan domain organisasi (Aslinya tulisan terpisah, tetapi rasanya lebih baik jika dipindahkan bersama.) Gitpod Flex Platform otomasi pertama untuk lingkungan pengembangan zero-trust Dirancang untuk berjalan di laptop, cloud, dan on-premise, sambil menjaga source code, data, dan kekayaan intelektual tetap berada di dalam jaringan privat Menyediakan building block untuk otomasi siklus hidup pengembangan perangkat lunak, dimulai dari lingkungan pengembangan Automations Tugas dan layanan yang dapat diprogram, didefinisikan melalui repositori atau API Membantu developer menyelesaikan masalah sendiri, sekaligus memungkinkan tim produktivitas developer memusatkan peningkatan lingkungan pengembangan Menawarkan kemampuan lebih dari sekadar menjalankan skrip sederhana Dapat digunakan untuk provisioning dan seeding database, menyesuaikan workflow developer, menjalankan cluster sementara, menyiapkan workflow agen berbasis LLM, menerapkan keamanan dan kepatuhan global/lokal secara terpusat, dan lain-lain Zero-trust environments Memperlakukan semua aktor dan layanan dengan prinsip 'jangan pernah percaya, selalu verifikasi' Memblokir aktor jahat sepenuhnya, sangat mengurangi permukaan serangan, dan menurunkan risiko malware atau kebocoran kode Mencakup evaluasi berkelanjutan dan verifikasi eksplisit, enkripsi tingkat enterprise yang tervalidasi, kontrol akses granular, kendali penuh atas jaringan, serta audit log lengkap Yang paling penting adalah menjaga source code, data, dan hak kekayaan intelektual tetap berada di dalam jaringan privat Gitpod Desktop Memungkinkan standardisasi dan otomasi lingkungan pengembangan lokal Dukungan dimulai dari Apple Silicon Menawarkan latensi mendekati nol, alternatif yang lebih cepat, ringan, dan sederhana dibanding Docker Desktop untuk pengembangan, optimasi biaya dengan memanfaatkan komputasi lokal, serta dukungan pemulihan bencana terhadap gangguan cloud atau endpoint Dukungan Development Container Mengintegrasikan spesifikasi Dev Container secara penuh Dapat menggunakan konfigurasi Dev Container yang ada tanpa perubahan Menyediakan kompatibilitas dengan VS Code dan alat lain yang didukung Memungkinkan bekerja secara konsisten baik secara lokal maupun di cloud Adopsi standar Dev Container membuat definisi, berbagi, dan pengelolaan lingkungan pengembangan menjadi lebih mudah Akan menjadi pijakan otomasi pengembangan perangkat lunak untuk 10 tahun ke depan Selama ini kita memandang lingkungan pengembangan terlalu sempit Lingkungan pengembangan adalah ruang mendasar tempat perangkat lunak dibuat, lebih dari sekadar IDE, dependensi, dan alat Di sanalah prototyping kode, pembentukan oleh manusia dan mesin, pengujian, refactoring, kompilasi, packaging, penandatanganan, dan deployment berlangsung Lingkungan ini memberi akses yang tak tertandingi ke konteks pengembangan, workflow, dan insight, sehingga memungkinkan kemampuan yang membedakannya dari platform pengembangan lain Visi produk Continuous Integration (CI) menyatu dengan lingkungan pengembangan Berperan sebagai system of record untuk pengembangan perangkat lunak Menjadi platform untuk alat developer generasi berikutnya Lebih dari sekadar memperbaiki praktik coding, tujuannya adalah membangun cara tercepat dan teraman agar perusahaan, dari startup hingga Fortune 50, bisa berkembang dan sukses dalam 10 tahun ke depan

(gitpod.io)

11 poin oleh xguru 2024-11-05 | 3 komentar | Bagikan ke WhatsApp

GitPod telah menggunakan Kubernetes selama 6 tahun untuk membangun "platform lingkungan pengembangan jarak jauh", mendukung 1,5 juta pengguna dan menyediakan ribuan lingkungan pengembangan setiap hari
Namun, mereka menyadari bahwa Kubernetes tidak cocok untuk membangun lingkungan pengembangan
Ini bukan pembahasan tentang apakah Kubernetes sebaiknya dipakai untuk workload produksi, juga bukan tentang cara membangun pengalaman developer untuk menerapkan aplikasi ke K8s
→ Ini adalah cerita tentang bagaimana membangun lingkungan pengembangan di cloud (atau bagaimana sebaiknya tidak melakukannya)

[Mengapa lingkungan pengembangan itu istimewa]

Sangat stateful dan sangat interaktif
- Tidak bisa dipindahkan begitu saja antar node
- Banyak source code, build cache, container Docker, data pengujian, dan sebagainya yang sering berubah, dengan biaya migrasi yang tinggi
- Berbeda dari layanan produksi, interaksi 1:1 terjadi antara developer dan lingkungannya
Developer sangat terikat dengan source code dan perubahannya
- Mereka tidak suka kehilangan perubahan source code atau diblokir oleh sistem
- Lingkungan pengembangan sangat sensitif terhadap kegagalan
Memiliki pola penggunaan resource yang tidak dapat diprediksi
- Sebagian besar waktu tidak membutuhkan banyak bandwidth CPU, tetapi dalam hitungan ratusan ms bisa saja membutuhkan beberapa core
- Jika lebih lambat dari itu, hasilnya terasa sebagai latensi yang tidak bisa diterima dan sistem yang tidak responsif
Membutuhkan hak akses dan kemampuan yang luas
- Tidak seperti workload produksi, lingkungan ini memerlukan akses root serta kemampuan mengunduh/memasang paket
- Hal-hal yang menjadi masalah keamanan di workload produksi justru merupakan perilaku yang diharapkan di lingkungan pengembangan (akses root, kemampuan jaringan yang diperluas, mount filesystem tambahan, dll.)
Karakteristik ini membuatnya berbeda dari workload aplikasi biasa, dan sangat memengaruhi keputusan infrastruktur

[Sistem saat ini: Kubernetes]

Pada masa awal Gitpod, Kubernetes tampak seperti pilihan infrastruktur yang ideal
- Skalabilitas, orkestrasi container, dan ekosistem yang kaya sangat cocok dengan visi mereka untuk lingkungan pengembangan cloud
Namun, seiring skala dan basis pengguna bertambah, mereka menghadapi kesulitan dalam keamanan dan pengelolaan state
- Kubernetes dirancang untuk menjalankan workload aplikasi yang terkontrol dengan baik, bukan untuk lingkungan pengembangan yang sulit ditangani
Mengelola Kubernetes dalam skala besar itu rumit
- Layanan terkelola seperti GKE dan EKS memang meredakan sebagian masalah, tetapi punya batasan dan kendalanya sendiri
Banyak tim yang ingin menjalankan CDE cenderung meremehkan kompleksitas Kubernetes
- Ini menyebabkan beban support yang besar pada produk Gitpod self-managed sebelumnya

Sulitnya manajemen resource

Alokasi CPU dan memori adalah tantangan terbesar
Berbagi lingkungan di satu node memang terlihat menarik, tetapi dalam praktiknya efek noisy neighbor sangat besar
Masalah CPU
- Lingkungan pengembangan kadang tidak membutuhkan banyak CPU, tetapi sesekali membutuhkannya dalam jumlah besar secara mendadak
- Mereka bereksperimen dengan solusi berbasis CFS, controller kustom, dan lainnya, tetapi tetap sulit diprediksi
- Bahkan dengan batas CPU statis pun, tetap muncul masalah ketika beberapa proses saling berebut resource
Manajemen memori
- Mengalokasikan memori tetap itu sederhana tetapi membatasi
- Overbooking dapat menyebabkan proses dihentikan
- Dengan diperkenalkannya swap space, kebutuhan untuk overbooking sedikit berkurang

Optimasi performa storage

IOPS dan latensi memengaruhi pengalaman lingkungan pengembangan
Mereka bereksperimen dengan berbagai konfigurasi untuk mencari keseimbangan antara kecepatan, stabilitas, biaya, dan performa
- SSD RAID 0
- Block storage seperti EBS dan persistent disk
- PVC
Backup/restore adalah operasi yang mahal

Autoscaling dan optimasi waktu startup

Meminimalkan waktu startup adalah tujuan utama
Mereka mengira menjalankan beberapa workspace di satu node akan memperbaiki waktu startup berkat cache bersama, tetapi ternyata tidak demikian
Kubernetes menetapkan batas bawah pada waktu startup
Evolusi cara scale-out
- Mereka bereksperimen dengan ghost workspace, ballast pod, dan lainnya untuk scale-out
- Pengenalan plugin autoscaler sangat meningkatkan strategi scaling
Autoscaling proporsional untuk menangani beban puncak
- Menyalakan pod kosong agar bisa merespons lonjakan permintaan dengan cepat
Berbagai upaya untuk mengoptimalkan image pull
- Pre-pull DaemonSet, memaksimalkan reuse layer, pre-baked image, Stargazer dan lazy pulling, Registry-facade + IPFS

Kompleksitas jaringan

Kontrol akses lingkungan pengembangan
- Lingkungan harus benar-benar terisolasi satu sama lain
- Network policy membantu, tetapi saat jumlah layanan bertambah muncul masalah keandalan
Berbagi bandwidth jaringan
- CNI kadang mendukung network shaping, tetapi itu berarti ada hal lain lagi yang harus dikendalikan

Keamanan dan isolasi: menyeimbangkan fleksibilitas dan perlindungan

Tantangan terbesar adalah menyediakan lingkungan yang aman sambil tetap memberi fleksibilitas kepada pengguna
Memberikan hak root kepada pengguna memiliki banyak kelemahan
User namespace adalah solusi yang lebih granular
- Konversi UID filesystem, masked proc mount, dukungan FUSE, penyediaan kemampuan jaringan, mengaktifkan Docker
Sulitnya implementasi user namespace
- Dampak performa, masalah kompatibilitas, kompleksitas, dan kebutuhan mengikuti versi Kubernetes

[Eksperimen Micro VM]

Saat menyadari keterbatasan Kubernetes, mereka mulai menjajaki teknologi micro VM (uVM) seperti Firecracker, Cloud Hypervisor, dan QEMU sebagai titik tengah
Mereka berharap bisa meningkatkan isolasi resource, kompatibilitas dengan workload lain (termasuk Kubernetes), dan keamanan, sambil tetap mempertahankan kelebihan containerization
Kelebihan micro VM
- Menawarkan sejumlah keuntungan menarik yang sangat selaras dengan tujuan untuk lingkungan pengembangan cloud
- Isolasi resource yang lebih baik: kemampuan overbooking menurun, tetapi isolasi resource lebih baik dibanding container. Perebutan resource kernel bersama hilang sehingga performa per lingkungan pengembangan menjadi lebih dapat diprediksi
- Memory snapshot dan resume cepat: fitur userfaultfd di Firecracker mendukung memory snapshot. Ini memungkinkan seluruh mesin, termasuk proses yang sedang berjalan, dilanjutkan hampir seketika. Dari sudut pandang developer, startup lingkungan menjadi jauh lebih cepat, dan pekerjaan bisa dilanjutkan tepat dari titik terakhir
- Batas keamanan yang lebih baik: uVM dapat berfungsi sebagai batas keamanan yang kuat, sehingga mekanisme user namespace kompleks yang mereka bangun di Kubernetes tidak lagi diperlukan. Ini juga bisa sepenuhnya kompatibel dengan workload yang lebih luas, termasuk containerization bertingkat (menjalankan Docker atau Kubernetes di dalam lingkungan pengembangan)
Tantangan micro VM
- Namun, hasil eksperimen micro VM mengungkap beberapa tantangan besar
- Overhead: bahkan VM ringan pun menyebabkan overhead lebih besar daripada container. Ini memengaruhi performa maupun pemanfaatan resource, yang merupakan pertimbangan penting bagi platform lingkungan pengembangan cloud
- Konversi image: untuk mengubah image OCI menjadi filesystem yang bisa digunakan di uVM dibutuhkan solusi kustom. Ini membuat pipeline manajemen image lebih rumit dan berpotensi memengaruhi waktu startup
- Keterbatasan per teknologi
  - Firecracker: tidak ada dukungan GPU (yang makin penting bagi sebagian workflow pengembangan), tidak ada dukungan virtiofs (membatasi opsi berbagi filesystem yang efisien)
  - Cloud Hypervisor: tidak ada dukungan userfaultfd, sehingga proses snapshot dan restore menjadi lebih lambat (mengurangi salah satu keunggulan utama uVM)
- Masalah perpindahan data: uVM membuat mereka harus menangani memory snapshot berukuran besar, sehingga perpindahan data menjadi lebih sulit. Ini memengaruhi scheduling maupun waktu startup, yang merupakan elemen kunci pengalaman pengguna lingkungan pengembangan cloud
- Pertimbangan storage: eksperimen menghubungkan volume EBS ke micro VM membuka kemungkinan baru, tetapi juga memunculkan pertanyaan baru
  - Storage persisten: menyimpan konten workspace di volume terpasang menghilangkan kebutuhan mengambil data berulang kali dari S3, sehingga diharapkan bisa memperbaiki waktu startup dan mengurangi penggunaan jaringan
  - Pertimbangan performa: berbagi volume throughput tinggi antar workspace diharapkan meningkatkan performa I/O, tetapi juga menimbulkan kekhawatiran tentang implementasi kuota yang efektif, pengelolaan latensi, dan jaminan skalabilitas
Pelajaran dari eksperimen micro VM
- Walaupun micro VM pada akhirnya tidak menjadi solusi infrastruktur utama, eksperimen ini menghasilkan wawasan berharga
- Mereka menyukai backup penuh workspace untuk lingkungan pengembangan serta pengalaman suspend/resume state runtime
- Untuk pertama kalinya mereka mulai mempertimbangkan untuk keluar dari Kubernetes. Setelah berupaya mengintegrasikan KVM dan uVM ke pod, mereka mulai mengeksplorasi opsi di luar Kubernetes
- Mereka kembali menyadari bahwa storage adalah elemen kunci untuk menghadirkan tiga hal sekaligus: performa startup yang stabil, workspace yang stabil (mencegah kehilangan data), dan pemanfaatan mesin yang optimal

Kubernetes sangat menantang sebagai platform lingkungan pengembangan

Seperti disebutkan sebelumnya, lingkungan pengembangan membutuhkan sistem yang menghormati sifat stateful uniknya
Sistem juga harus memberikan hak akses yang diperlukan agar developer bisa produktif, sambil tetap menjamin batas keamanan yang aman
Semua itu harus dicapai sambil menjaga overhead operasional tetap rendah dan tanpa mengorbankan keamanan
Saat ini semua itu memang bisa dicapai dengan Kubernetes, tetapi biayanya sangat besar
Mereka belajar dengan cara yang sulit bahwa workload aplikasi dan workload sistem itu berbeda
Kubernetes adalah teknologi yang luar biasa
Ia membangun ekosistem yang benar-benar kaya dengan dukungan komunitas yang penuh semangat
Jika Anda menjalankan workload aplikasi, Kubernetes tetap merupakan pilihan yang baik
Namun untuk workload sistem seperti lingkungan pengembangan, Kubernetes menghadirkan tantangan besar dari sisi keamanan dan overhead operasional
Micro VM dan anggaran resource yang jelas memang membantu, tetapi biaya menjadi faktor yang lebih dominan
Karena itu, setelah bertahun-tahun secara efektif merekayasa balik dan memaksakan lingkungan pengembangan ke atas platform Kubernetes, mereka memutuskan untuk mundur selangkah dan memikirkan seperti apa arsitektur pengembangan masa depan seharusnya
Pada Januari 2024, mereka mulai membangunnya, dan pada Oktober meluncurkan Gitpod Flex
Fondasi arsitekturnya dibangun di atas lebih dari 6 tahun wawasan yang sangat sulit diperoleh tentang cara menjalankan lingkungan pengembangan secara aman pada skala internet

Masa depan lingkungan pengembangan

Dengan Gitpod Flex, mereka mempertahankan aspek mendasar Kubernetes, yaitu penerapan teori kontrol yang bebas dan API deklaratif, sambil menyederhanakan arsitektur dan memperkuat fondasi keamanan
Mereka mengorkestrasi lingkungan pengembangan menggunakan control plane yang sangat terinspirasi oleh Kubernetes
Mereka memperkenalkan lapisan abstraksi yang dibutuhkan dan khusus untuk lingkungan pengembangan, sambil menghilangkan sebagian besar kompleksitas infrastruktur yang tidak perlu
Semua ini dilakukan dengan keamanan zero-trust sebagai prioritas utama
Berkat arsitektur baru ini, mereka dapat mengintegrasikan dev container dengan mulus
Ini juga membuka kemampuan untuk menjalankan lingkungan pengembangan di desktop
Karena tidak lagi harus memikul beban berat platform Kubernetes, Gitpod Flex kini bisa di-deploy secara self-hosted dalam waktu kurang dari 3 menit, dan dapat diterapkan ke sebanyak apa pun region yang diinginkan
Ini memberikan kontrol yang lebih rinci untuk kepatuhan serta fleksibilitas yang lebih besar dalam memodelkan batas dan domain organisasi

(Aslinya tulisan terpisah, tetapi rasanya lebih baik jika dipindahkan bersama.)

Gitpod Flex

Platform otomasi pertama untuk lingkungan pengembangan zero-trust
Dirancang untuk berjalan di laptop, cloud, dan on-premise, sambil menjaga source code, data, dan kekayaan intelektual tetap berada di dalam jaringan privat
Menyediakan building block untuk otomasi siklus hidup pengembangan perangkat lunak, dimulai dari lingkungan pengembangan
Automations
- Tugas dan layanan yang dapat diprogram, didefinisikan melalui repositori atau API
- Membantu developer menyelesaikan masalah sendiri, sekaligus memungkinkan tim produktivitas developer memusatkan peningkatan lingkungan pengembangan
- Menawarkan kemampuan lebih dari sekadar menjalankan skrip sederhana
- Dapat digunakan untuk provisioning dan seeding database, menyesuaikan workflow developer, menjalankan cluster sementara, menyiapkan workflow agen berbasis LLM, menerapkan keamanan dan kepatuhan global/lokal secara terpusat, dan lain-lain
Zero-trust environments
- Memperlakukan semua aktor dan layanan dengan prinsip 'jangan pernah percaya, selalu verifikasi'
- Memblokir aktor jahat sepenuhnya, sangat mengurangi permukaan serangan, dan menurunkan risiko malware atau kebocoran kode
- Mencakup evaluasi berkelanjutan dan verifikasi eksplisit, enkripsi tingkat enterprise yang tervalidasi, kontrol akses granular, kendali penuh atas jaringan, serta audit log lengkap
- Yang paling penting adalah menjaga source code, data, dan hak kekayaan intelektual tetap berada di dalam jaringan privat
Gitpod Desktop
- Memungkinkan standardisasi dan otomasi lingkungan pengembangan lokal
- Dukungan dimulai dari Apple Silicon
- Menawarkan latensi mendekati nol, alternatif yang lebih cepat, ringan, dan sederhana dibanding Docker Desktop untuk pengembangan, optimasi biaya dengan memanfaatkan komputasi lokal, serta dukungan pemulihan bencana terhadap gangguan cloud atau endpoint
Dukungan Development Container
- Mengintegrasikan spesifikasi Dev Container secara penuh
- Dapat menggunakan konfigurasi Dev Container yang ada tanpa perubahan
- Menyediakan kompatibilitas dengan VS Code dan alat lain yang didukung
- Memungkinkan bekerja secara konsisten baik secara lokal maupun di cloud
- Adopsi standar Dev Container membuat definisi, berbagi, dan pengelolaan lingkungan pengembangan menjadi lebih mudah

Akan menjadi pijakan otomasi pengembangan perangkat lunak untuk 10 tahun ke depan

Selama ini kita memandang lingkungan pengembangan terlalu sempit
Lingkungan pengembangan adalah ruang mendasar tempat perangkat lunak dibuat, lebih dari sekadar IDE, dependensi, dan alat
Di sanalah prototyping kode, pembentukan oleh manusia dan mesin, pengujian, refactoring, kompilasi, packaging, penandatanganan, dan deployment berlangsung
Lingkungan ini memberi akses yang tak tertandingi ke konteks pengembangan, workflow, dan insight, sehingga memungkinkan kemampuan yang membedakannya dari platform pengembangan lain
Visi produk
- Continuous Integration (CI) menyatu dengan lingkungan pengembangan
- Berperan sebagai system of record untuk pengembangan perangkat lunak
- Menjadi platform untuk alat developer generasi berikutnya
Lebih dari sekadar memperbaiki praktik coding, tujuannya adalah membangun cara tercepat dan teraman agar perusahaan, dari startup hingga Fortune 50, bisa berkembang dan sukses dalam 10 tahun ke depan

3 komentar

ahwjdekf 2024-11-06

Perusahaan-perusahaan dalam negeri yang memaksa penggunaan spesifikasi virtual desktop dengan memori 8 GB dengan dalih keamanan. Rasanya pahit.

bus710 2024-11-05

Mencari orang yang benar-benar menguasai Kubernetes saja sudah sulit, jadi saya merasa akan lebih sulit lagi mencari orang yang mau memahami dan mencoba hal-hal yang diajukan di sini sebagai alternatif.

xguru 2024-11-05

Komentar Hacker News

Pengembang harus memiliki perangkat pengembangan yang mereka gunakan. Jika lingkungan yang konsisten dibutuhkan, pengembang harus memiliki perangkatnya sendiri dan menerima image VM yang stabil. Upaya memindahkan lingkungan pengembangan ke host jarak jauh sebagian besar gagal. Memberikan perangkat keras yang layak kepada pengembang lebih hemat biaya daripada sumber daya jarak jauh. Menjalankan stack secara lokal harus didukung, dan container membantu menjaga konsistensi. Diperlukan alat untuk menghasilkan data di lingkungan lokal, dan ini bisa diotomatisasi. Ada kekurangan dalam pengelolaan data, tetapi bagi kebanyakan perusahaan, kemampuan eksekusi tim lebih penting daripada kode sumber.
Menggunakan Kubernetes untuk workload produksi adalah persoalan yang berbeda; ini adalah pembahasan tentang cara membangun lingkungan pengembangan di cloud. Artikel yang menarik tentang trade-off rekayasa yang kompleks dalam Kubernetes.
Artikel ini menjelaskan masalah Kubernetes dan solusi yang telah dicoba, tetapi kurang menjelaskan alternatif yang akhirnya dipilih. Gitpod Flex disebut sebagai solusi baru, tetapi informasinya sangat minim.
Kubernetes cocok untuk workload stateless, tetapi untuk yang stateful, LXC lebih cocok. LXC dapat di-cluster seperti K8S dan mengekspos alat ke data plane. LXC menyediakan instance sistem seperti VM, dengan performa mirip container Docker. LXC menggunakan sintaks deklaratif dan dapat dipakai sebagai lapisan dasar klaster Kubernetes.
Memilih Kubernetes saat membangun solusi CI berarti masalahnya belum benar-benar dipahami. Untuk tujuan keamanan, seharusnya menggunakan alat seperti Firecracker.
Kubernetes tidak cocok untuk lingkungan pengembangan. Lingkungan pengembangan selalu berada dalam kondisi yang berubah-ubah. Saya tidak memahami kebutuhan akan lingkungan pengembangan cloud. Tujuan aplikasi yang dikontainerisasi adalah untuk menghindari sinkronisasi lingkungan pengembangan antar tim.
Makalah Kubernetes hanya menyebut kombinasi workflow latensi rendah dan latensi tinggi sebagai satu-satunya kasus penggunaan. Sulit membenarkan mempertimbangkan Kubernetes untuk masalah Gitpod.
Saya pernah mengerjakan proyek yang mirip dengan Gitpod, dan saya tidak paham mengapa microVM digunakan untuk menggantikan Kubernetes. Kubernetes dapat mengorkestrasi container eksternal dan bisa digunakan untuk menjalankan microVM. Masalah terbesar adalah yang berkaitan dengan storage.
Membangun lingkungan pengembangan di atas Kubernetes itu boros. Jika produk di-self-host di infrastruktur pelanggan, debugging dan support menjadi sulit. Mengekspos masalah jaringan, memori, komputasi, dan storage kepada engineer adalah hal yang efektif. Kubernetes merupakan peningkatan bagi tim yang besar.