Tentang Sesi Ini
Ringkasan & metadata
Sesi ini membahas satu masalah yang diam-diam menggerus produktivitas banyak tim: siklus umpan balik pengembang yang lambat di Kubernetes. Setiap kali seorang pengembang mengubah satu baris kode dan ingin melihat hasilnya di Amazon EKS (Elastic Kubernetes Service), ia sering harus menunggu proses build image, push ke registry, lalu redeploy — total bisa memakan menit demi menit. Kalikan dengan puluhan kali per hari, dan waktu tunggu itu menumpuk menjadi jam yang hilang plus konsentrasi yang buyar.
Target sesi jelas dan berani: memangkas "inner loop" — siklus edit → build → deploy → lihat hasil — dari hitungan menit menjadi sekitar 5 detik. Ketika umpan balik secepat itu, pengembang tetap berada dalam kondisi flow: mereka mengetik, melihat perubahan seketika, memperbaiki, dan mengulang tanpa jeda yang mematahkan alur pikir. Inilah inti dari Developer Experience (DX) yang baik.
Kenapa penting untuk Anda? Jika tim Anda memindahkan pengembangan ke Kubernetes dan merasa "kok jadi lebih lambat dari sebelumnya", sesi ini membongkar penyebabnya dan menawarkan peta jalan konkret — lengkap dengan pengalaman nyata tim SG-EDTS.
SG-EDTS (Enterprise Digital Technology Services) adalah perusahaan penyedia layanan teknologi digital yang berperan sebagai Digital Center of Excellence Salim Group — didirikan sejak 2019 dan berbasis di Jakarta (bukan bagian dari Sinar Mas, sebagaimana kadang keliru dikaitkan). Timnya melayani perusahaan yang bertumbuh cepat di sektor ritel, keuangan, dan FMCG dengan layanan Data & Analytics, Applied AI, Cloud Services, Digital Marketing, dan Digital Product Creation. Pada praktik Cloud Services-nya, SG-EDTS menyebut penggunaan AWS Well-Architected Framework, Infrastructure as Code (IaC), migrasi cloud, serta optimasi biaya cloud — konteks yang selaras dengan sesi ini tentang pengembangan modern di atas AWS. Latar belakang inilah yang membuat pengalaman mereka relevan untuk topik mempercepat inner loop pengembang di Amazon EKS.
Sumber: situs resmi SG-EDTS (sg-edts.com — halaman About dan Cloud Services). Catatan: hingga rangkuman ini disusun, kami tidak menemukan publikasi terbuka SG-EDTS yang merinci arsitektur EKS atau angka inner loop "~5 detik"; detail teknik dan arsitektur spesifik dalam buku ini bersifat ilustratif kecuali disebutkan lain.
Apa Itu & Bagaimana Bekerjanya
Inner loop vs outer loop
Bayangkan pekerjaan pengembang sebagai dua lingkaran yang berputar dengan kecepatan berbeda. Inner loop adalah lingkaran cepat yang dijalani sepanjang hari di laptop: tulis kode → jalankan → lihat hasil → perbaiki. Idealnya ini berlangsung dalam hitungan detik. Outer loop adalah lingkaran lambat yang berjalan lebih jarang: commit → pull request → pipeline CI/CD → uji otomatis → rilis ke produksi. Outer loop memang seharusnya lebih berat dan penuh gerbang mutu.
Masalah muncul ketika langkah-langkah outer loop (build image, push registry, redeploy) menyusup ke dalam inner loop. Setiap perubahan kecil jadi terasa seperti "rilis mini". Tujuan sesi ini: mengembalikan inner loop ke kecepatan detik tanpa mengorbankan kenyataan bahwa aplikasi tetap berjalan di lingkungan mirip-produksi, yaitu Kubernetes.
Mengapa lambat di Kubernetes
Di laptop biasa, mengubah kode lalu me-restart proses cukup instan. Begitu aplikasi hidup di dalam kontainer di atas EKS, ada rantai panjang yang harus dilalui setiap kali:
- Build image. Kode dikemas menjadi container image — sering butuh puluhan detik hingga menit, apalagi jika layer besar ikut dibangun ulang.
- Push ke registry. Image diunggah ke Amazon ECR; makin besar image, makin lama unggahannya.
- Redeploy. Kubernetes menarik image baru, menjadwalkan pod, menunggu readiness probe, lalu memutar trafik. Tiap langkah menambah detik.
Tiga langkah itu bagus untuk rilis, tetapi menyakitkan bila diulang setiap kali seorang pengembang mengubah satu baris. Di sinilah sekumpulan teknik "inner loop" hadir untuk memangkasnya.
Teknik & tools
Ada beberapa keluarga teknik yang dibahas, masing-masing menyerang titik lambat yang berbeda:
Intinya berbeda-beda: Skaffold mengotomatiskan dan mempercepat siklus build-deploy sekaligus memantau perubahan file. File sync / hot reload melewati rebuild image sepenuhnya dengan menyalin file langsung ke kontainer yang sedang berjalan. mirrord dan Telepresence mengambil pendekatan remote-to-local: proses berjalan di laptop tetapi "seolah-olah" hidup di dalam kluster, memakai konfigurasi, variabel lingkungan, dan trafik nyata dari EKS. Semua ini bisa dikombinasikan sesuai kebutuhan tim.
Analogi yang Mudah Dicerna
Adonan yang matang vs pratinjau instan
Ibaratnya, membuat aplikasi di Kubernetes tanpa teknik inner loop seperti seorang koki yang harus memanggang seluruh kue dari awal hanya untuk mencicipi apakah tambahan sejumput garam sudah pas. Uleni adonan, tunggu oven panas, panggang 40 menit, dinginkan — baru bisa mencicipi. Kalau kurang garam, ulangi semuanya. Itulah "build image → push → redeploy" setiap kali kode berubah.
Teknik inner loop mengubahnya menjadi koki yang mencicipi langsung dari panci: cukup sesendok, rasakan seketika, sesuaikan bumbu, cicipi lagi. Pratinjau instan. Sang koki tetap "in flow" — konsentrasinya tak putus menunggu oven. Itulah yang dilakukan file sync, hot reload, dan pendekatan remote-to-local: memberi pengembang cara mencicipi hasil perubahan dalam hitungan detik, bukan menunggu "kue matang" tiap kali.
High-Level Architecture & Alur
High-Level Architecture (HLA)
Secara garis besar, alur inner loop yang cepat menghubungkan laptop pengembang langsung dengan kluster Amazon EKS. Alih-alih melewati jalur penuh build → ECR → redeploy setiap kali, sebuah agen sinkronisasi (dari Skaffold, mirrord, atau Telepresence) menyalin perubahan atau mengarahkan trafik langsung ke pod yang sudah berjalan. Jalur outer loop (build image → ECR → deploy) tetap ada, tetapi hanya dipakai sesekali untuk rilis, bukan tiap ketikan.
Alur satu perubahan kode
Ketika pengembang menekan simpan setelah mengubah satu baris kode, inilah yang terjadi dengan inner loop cepat:
- Deteksi perubahan. Agen (mis. Skaffold) mengawasi berkas dan langsung menangkap file yang berubah.
- Sinkronisasi. Alih-alih rebuild image, file disalin langsung ke kontainer yang berjalan (file sync), atau proses lokal disambungkan ke kluster (mirrord/Telepresence).
- Muat ulang. Aplikasi melakukan hot reload — memuat kode baru tanpa membangun ulang image atau menjadwalkan pod baru.
- Lihat hasil. Pengembang langsung melihat perubahan memakai konfigurasi & trafik nyata dari EKS — dalam hitungan detik.
- Ulangi. Karena umpan balik sekejap, pengembang tetap "in flow" dan bisa beriterasi berkali-kali tanpa jeda.
Dari Konsep ke Praktik Nyata
Contoh nyata (konteks Indonesia)
Agar tidak berhenti di teori, berikut tiga skenario penerapan yang khas di tim rekayasa Indonesia.
Iterasi cepat di kluster EKS bersama
Sebuah tim yang mengelola belasan microservice di EKS sering kesulitan: mengubah satu servis butuh servis-servis lain yang saling terhubung. Dengan mirrord/Telepresence, seorang pengembang menjalankan hanya servis yang sedang ia kerjakan di laptop, sementara sisanya tetap di kluster. Perubahan kode langsung terlihat memakai trafik & konfigurasi nyata, tanpa perlu men-deploy ulang seluruh sistem. Inner loop kembali ke hitungan detik.
Pengembang baru produktif di hari pertama
Startup yang cepat tumbuh butuh anggota baru langsung berkontribusi. Dengan Dev Container dan Skaffold, lingkungan pengembangan tertata otomatis: satu perintah menyiapkan semuanya, dan setiap penyimpanan file langsung tersinkron ke kluster. Alih-alih menghabiskan hari pertama menyiapkan mesin, pengembang baru sudah bisa mengubah kode dan melihat hasilnya di sore hari. DX yang baik mempercepat onboarding.
Perbaikan fitur & bug sepanjang hari
Tim produk fintech mengerjakan puluhan penyesuaian kecil tiap hari — teks tombol, aturan validasi, tampilan. Dengan file sync + hot reload, tiap perubahan tampil dalam ~5 detik, sehingga produk & QA bisa meninjau bersama secara langsung. Waktu tunggu yang dulu terbuang untuk build berulang kini dipakai untuk lebih banyak iterasi — kualitas naik tanpa menambah jam kerja.
Ringkasan Visual (Geser)
Ringkasan visual
Enam kartu berikut merangkum inti sesi. Gunakan tombol atau tombol panah keyboard (← →) untuk berpindah.
Poin yang Bisa Dibawa Pulang
Poin yang bisa dibawa pulang
- Inner loop cepat = produktivitas & DX. Umpan balik dalam detik menjaga pengembang tetap dalam flow.
- Pisahkan inner dari outer loop. Build image, push, dan redeploy adalah pekerjaan rilis — jangan biarkan menyusup ke tiap ketikan.
- Pilih teknik sesuai titik lambat. File sync/hot reload melewati rebuild; Skaffold mengotomatiskan; mirrord/Telepresence menyambungkan lokal ke kluster nyata.
- Sadari trade-off. Setiap pendekatan punya kompromi (kesetiaan ke produksi, keamanan, kompleksitas). Mulai kecil, ukur, lalu perluas.