Memilih Platform Orchestration

Perjalanan section ini meninggalkan kita di posisi yang nyaman sekaligus sulit: Budi kini memegang tiga pilihan yang semuanya sudah pernah disentuh tangannya. Compose menjalankan toko di srv-toko selama berbulan-bulan dengan disiplin backup dan rilis yang teruji; cluster Swarm tiga VPS baru saja membuktikan rolling update satu perintah; Kubernetes menunggu dengan seluruh ekosistemnya di balik pintu. Tidak ada jawaban tunggal yang benar untuk semua tim, dan jawaban yang benar untuk toko hari ini belum tentu benar tahun depan. Chapter terakhir ini tidak akan memilih untuk kita — ia merakit kerangka keputusan yang jujur: tabel perbandingan tujuh dimensi, tujuh pertanyaan penentu, jawaban terus terang untuk kasus toko, dan jalur migrasi bertahap yang bisa ditempuh tanpa menulis ulang aplikasi.

Tiga Kandidat dan Satu Fakta yang Menyatukan #

Sebelum membandingkan, satu fakta perlu ditegaskan karena fakta inilah yang membuat seluruh perbandingan menjadi damai: image kita tidak pernah berpindah kubu. registry.example.com/toko/backend:1.6.0 yang dibangun dari satu Dockerfile adalah image OCI — standar yang dibedah Chapter Container Runtime — dan ketiga platform meminumnya tanpa modifikasi. Compose menjalankannya di satu mesin, Swarm mendistribusikannya ke tiga node, Kubernetes menjadwalkannya sebagai pod; image yang sama, Dockerfile yang sama, registry yang sama. Bahkan compose.yaml-nya pun ikut portabel sebagian: docker stack deploy membacanya langsung di cluster Swarm, dan alat penerjemah kompose sanggup mengubahnya menjadi draf manifest Kubernetes. Biaya perpindahan platform, dengan kata lain, bukan pada artefak aplikasi — melainkan pada model operasional di sekitarnya.

Tabel Keputusan #

Dimensi	Compose	Swarm	Kubernetes
Cakupan host	satu mesin	banyak node dalam satu cluster Docker	banyak node hingga ribuan, lintas cluster dan zona
Kompleksitas operasional	rendah — satu daemon yang diurus	sedang — cluster, quorum, upgrade node	tinggi — control plane plus ekosistem add-on
Fitur andalan	dependency, healthcheck, profiles	service, routing mesh, secret, rolling update	pod sidecar, autoscaling, RBAC, operator
Ukuran tim ideal	satu sampai tiga orang	dua sampai lima orang	tiga orang ke atas dengan peran platform khusus
Biaya implisit	satu mesin adalah satu titik kegagalan	upgrade cluster dikerjakan manual, ekosistem kecil	biaya belajar, upgrade, dan pemeliharaan cluster itu sendiri
Kurva belajar	landai — sudah kita tempuh	sedang — dua-tiga hari dari Compose	curam — minggu sampai bulan untuk fasih
Momen tepat	development, staging, produksi kecil	cluster Docker kecil sampai menengah	organisasi multi-tim dan tuntutan enterprise

Cara membaca tabel ini sama pentingnya dengan isinya. Tidak ada kolom yang menang di semua baris — Compose menang di kurva belajar dan kalah di cakupan host, Kubernetes sebaliknya — sehingga membaca “mana yang terbaik” adalah cara membaca yang salah. Baca baris per baris dengan bobot keadaan kita: tim dua orang memberi bobot besar pada baris ukuran tim dan kurva belajar; SLA ketersediaan 99,9% memberi bobot besar pada baris cakupan host. Dan baca baris biaya implisit paling pelan-pelan — baris itulah yang paling sering tidak masuk hitungan saat keputusan diambil.

Tujuh Pertanyaan Penentu #

#	Pertanyaan penentu	Mengena ke mana
1	Berapa host riil yang harus dilayani?	satu mesin sungguhan cukup membuat Compose sah; lebih dari itu memasuki ranah cluster
2	Berapa toleransi downtime?	budget gangguan menentukan apakah satu titik kegagalan masih bisa diterima
3	Siapa yang memegang pager jam 3 pagi?	cluster membutuhkan manusia yang mengerti cara kerjanya pada jam terburuk
4	Bagaimana pola beban?	beban stabil puas dengan replika tetap; lonjakan sporadis menuntut autoscaling
5	Talenta apa yang sudah dimiliki tim?	kurva belajar dibayar dengan waktu nyata orang-orang nyata
6	Apa tuntutan organisasi?	compliance, klien, atau standar internal bisa memaksa satu arah
7	Berapa anggaran, waktu dan uang?	platform besar mengonsumsi keduanya sebelum memberi balasan

Tujuh jawaban itu hampir selalu mengarah ke keputusan yang sama ketika dijawab jujur — dan itulah fungsinya: bukan menakut-nakuti, melainkan memastikan keputusan lahir dari keadaan, bukan dari keramaian.

Kejujuran tentang Kubernetes #

Jawaban jujur untuk kasus toko kita sendiri, setelah seluruh section ini dijalankan: Compose di satu VPS dengan backup yang disiplin dan pipeline yang teruji tetap rasional untuk beban toko hari ini — itu bukan langkah yang memalukan melainkan keputusan yang dihitung. Cluster Swarm tiga VPS yang kita bangun menempati posisi kedua yang justru lebih sering diabaikan orang: staging yang meniru sifat multi-node sekaligus cadangan ketersediaan bila srv-toko tumbang — tim kecil, dua perintah, tanpa ekosistem baru yang harus dipelajari. Kubernetes masuk hitungan ketika tim bertumbuh melewati satu platform, ketika ada tim kedua yang ingin berbagi cluster, atau ketika tuntutan organisasi menutup pilihan lain — dan ketika saat itu tiba, seluruh kosakata yang kita bangun di section ini siap dipakai ulang.

Jalur Migrasi Lima Anak Tangga #

Keputusan pindah tidak harus berarti lompatan. Lima anak tangga berikut bisa dinaiki satu per satu, dan berhenti di tengah tangga pun merupakan keputusan yang sah:

Berangkat dari Compose yang sehat — pastikan healthcheck, resource limit, restart policy, dan backup sudah hidup di compose.yaml, karena keempatnya adalah bahasa yang sama yang akan dibaca platform berikutnya; aplikasi yang sehat di satu mesin adalah syarat aplikasi yang sehat di banyak mesin.
Naik ke Swarm dengan stack deploy — compose.yaml yang sama dideploy ke cluster dengan docker stack deploy; blok deploy: yang selama ini diabaikan Compose mulai dibaca, dan di anak tangga ini pula kompose menjalankan kompose convert -f compose.yaml untuk menghasilkan draf manifest Kubernetes — draf, bukan hasil akhir.
Rapikan hasil konversi secara manual — terjemahan mesin tidak memahami niat: deploy.resources perlu dibedah ulang menjadi requests dan limits, healthcheck menjadi liveness dan readiness probe, network alias menjadi Service dengan selector label; inilah pekerjaan yang menentukan mutu manifest akhir.
Uji di cluster sekali pakai — kind dan minikube membangun Kubernetes kecil di mesin lokal: manifest yang sudah dirapikan diterapkan, digulir, dan dihancurkan tanpa menyentuh produksi; galat konversi paling murah ditemukan di sini.
Migrasikan satu service dulu — pilih service stateless yang paling tidak kritis — biasanya backend atau frontend — pindahkan ke cluster baru sementara proxy dan db tetap di platform lama, amati trafik dan log selama beberapa hari, lalu perluas satu per satu; kegagalan pada satu service yang bisa mundur dalam menit adalah harga belajar yang wajar.

Perhatikan bahwa kelima anak tangga memakai artefak yang sama — Dockerfile, image OCI, compose.yaml — yang kita bawa sejak Section Dockerfile; hanya lapisan operasionalnya yang berganti satu tingkat demi satu tingkat. Ekosistem Docker memang dibangun untuk kontinuitas seperti ini: Dockerfile yang ditulis di laptop Budi pada chapter-chapter awal menjadi image OCI yang diminum Compose di staging, Swarm di cluster tiga VPS, dan Kubernetes di pusat data orang lain — satu rantai artefak dari pengembangan sampai produksi, dan Course ini kini telah menempuhinya utuh dari docker run hello-world sampai proses yang di-clone runc. Pengetahuan yang tersisa adalah otot yang hanya tumbuh pada praktik: Section Proyek menanti dengan lima proyek utuh — situs web statis, API Go dengan PostgreSQL, API Rust dengan PostgreSQL, WordPress dengan MySQL, dan reverse proxy multi-service — yang masing-masing mempraktikkan seluruh keahlian ini dalam bentuk yang bisa dijalankan, diuji, dan dibanggakan.

Referensi #

Docker Compose — titik berangkat model aplikasi satu berkas.
Docker Swarm mode — anak tangga kedua: cluster dari compose.yaml yang sama.
Kubernetes Overview — kosakata dan konsep dasar platform standar industri.
Open Container Initiative — standar image yang menyatukan ketiga platform pada satu artefak.