Kenapa Docker Bisa Ada: Filosofi di Balik Container, Bukan Sekadar Teknologi

Gue inget pertama kali deploy aplikasi ke server bare metal. Localhost jalan mulus. Production? Error. "Works on my machine" - frasa yang jadi meme karena tiap developer pernah ngalamin. Versi Node beda, OS beda, library sistem beda. Debug 3 hari, akhirnya nemu versi libssl yang beda.

Terus temen recommand Docker. Gue skeptis awalnya - "lah, virtual machine aja udah ribet, pake container apalagi." Tapi setelah docker run pertama jalan di laptop dan server hasilnya identik, gue sadar: ini bukan teknologi baru. Ini filosofi baru tentang cara kita ship kode.

Kenapa Docker bisa ada, padahal teknologinya (namespaces, cgroups) udah ada 2007? Itu yang mau gue bahas. Bukan tutorial docker-compose, tapi filosofi kenapa container menang.

---

Analogi Kontainer Pengiriman (Kenapa Ini Penting)

Sebelum 1956, ngirim barang internasional itu kacau. Tiap pelabuhan punya cara sendiri. Barang dimuat manual - karung, peti kayu, drum - semuanya ukuran beda. Kapal nunggu berhari-hari di pelabuhan cuma buat di-load. Biaya mahal, pencurian tinggi, lambat.

Terus Malcolm McLean, seorang pengusaha trucking, punya ide gila: bikin kotak standar. Ukuran fixed, 8×8×20 kaki. Apapun isinya - sepatu, elektronik, buah - masuk ke kotak yang sama. Kapal, truk, crane - semuanya didesain buat angkut kotak itu, bukan isinya.

Efeknya: biaya pengiriman turun 90%. Pelabuhan jadi efisien. Globalisasi lahir. Satu standardisasi ngubah dunia.

Docker ngelakuin hal yang sama buat software. Sebelum Docker, ngirim aplikasi = ngirim "barang curian" - tiap app punya kebutuhan beda, tiap server harus di-setup manual. Docker bilang: "bungkus app lo dalam kotak standar. Apapun isinya - Node.js, Python, Go - kotaknya sama. Server mana pun yang bisa jalanin Docker, bisa jalanin app lo."

Itu inti filosofinya: standarisasi unit transport.

---

Sejarah Singkat Container (Docker Bukan yang Pertama)

Banyak yang kira Docker nemuin container. Enggak. Teknologinya udah ada puluhan tahun:

1. chroot (1979)

Unix bikin fitur chroot - bikin "jail" buat process, dia mikir dia ada di root filesystem sendiri. Bill Joy bikin ini 1979. Tapi cuma isolasi filesystem, gak ada resource limit.

2. FreeBSD Jails (2000)

FreeBSD bikin jail yang lebih serius - process gak cuma isolated di filesystem, tapi juga network. Tapi setup rumit, butuh kernel khusus FreeBSD.

3. Solaris Zones (2004)

Sun Microsystems bikin Solaris Zones - container native di kernel Solaris. Bagus, tapi Solarisnya sendiri mati.

4. LXC (2008)

Linux Containers - implementasi container di Linux kernel pake namespaces + cgroups. Inilah teknologi yang Docker pakai di awal. Tapi LXC ribet setup-nya. Dokumentasi dikit. Developer experience buruk.

5. Docker (2013)

Solomon Hykes + tim di dotCloud (PaaS startup yang berjuang) ngeluarin Docker. Bukan teknologi baru - mereka pakai LXC + namespaces + cgroups. Tapi mereka tambahin satu hal yang container sebelumnya gak punya: developer experience.

Docker bikin docker run - 1 command, jadi. Dockerfile - deklaratif, human-readable. Docker Hub - registry public, tinggal pull. Itu yang bikin container akhirnya masuk ke mainstream developer.

Intinya: Docker menang bukan karena teknologinya paling bagus. Docker menang karena bikin container accessible. Sama kayak iPhone bukan nemuin touchscreen, tapi bikin touchscreen enak dipake.

---

Filosofi Inti Docker

1. "Build once, run anywhere"

Ini slogan lama Sun Microsystems ("write once, run anywhere" buat Java). Tapi Java ngelakuin itu di level bytecode. Docker ngelakuin di level OS. Aplikasi lo + semua dependency-nya - library sistem, runtime, config - dibungkus jadi satu image. Image itu jalan sama di laptop dev, server staging, server production, cloud, on-prem.

2. Immutable infrastructure

Tradisionalnya, server itu "pet" - lo rawat, lo upgrade, lo tweak. Kalau rusak, lo perbaiki. Docker ubah: server jadi "cattle" - kalau rusak, buang, ganti baru. Image Docker itu immutable - sekali di-build, gak berubah. Ada bug? Build ulang image baru, deploy. Gak ada "upgrade in place" yang bisa bikin server drift.

3. Separation of concerns

Dockerfile = deklarasi "app butuh apa." Docker image = snapshot hasil build. Container = instance running dari image. Tiga konsep terpisah, masing-masing jelas. Developer fokus ke Dockerfile, operator fokus ke image + runtime. Beda sama SSH-ke-server-install-stuff yang nge-blur tanggung jawab.

4. Layered filesystem (kayak git, buat filesystem)

Tiap baris di Dockerfile bikin layer baru. Layer yang sama di-cache, gak di-rebuild. npm install yang berat? Cachenya bertahan walaupun lo ubah kode app-nya. Itu filosofi "diff" - cuma yang berubah yang di-rebuild. Mirip git, tapi di level filesystem.

---

Kenapa Docker Menang Lawan VM?

VM (VirtualBox, VMware) juga bisa isolate aplikasi. Kenapa container menang?

| | VM | Docker Container |
|---|---|---|
| Isolasi | Full OS guest (kernel sendiri) | Process-isolated (share kernel host) |
| Ukuran | GB (karena full OS) | MB (cuma app + deps) |
| Startup | 30-60 detik (boot OS) | < 1 detik (start process) |
| Density | Beberapa VM per server | Ratusan container per server |
| Use case | Beda OS total | Microservices, dev/prod parity |

VM itu kayak beli rumah baru buat tiap keluarga. Container itu kayak apartemen - share foundation (kernel), tapi tiap unit private. Kalau lo butuh isolasi kuat (beda kernel, security hard), VM. Kalau lo butuh density + speed, container.

Filosofi beda: VM isolasi total, container isolasi yang cukup. Container ngasih lo 80% benefit isolasi dengan 1% overhead VM.

---

Kenapa Docker Bisa Ada di 2013 (Bukan 2003)?

Pertanyaan bagus. Kenapa Docker baru lahir 2013 padahal LXC udah ada 2008?

1. Cloud udah matang. 2013 = AWS udah 7 tahun. Developer udah terbiasa deploy ke cloud. Tapi "works on my machine" makin parah karena environment makin beragam. Pain point baru dirasain skala besar.

2. Microservices lagi naik. 2013 = Netflix bikin microservices article, Martin Fowler nulis tentangnya. Tiap service butuh environment sendiri. VM terlalu berat buat microservices. Ada "bukti" kebutuhan pasar.

3. Developer experience jadi bahan pikiran. 2010-an = era "developer tools" sebagai produk (GitHub 2008, Vercel, Heroku). UX tooling jadi kompetitif. Docker lahir di era yang ngeh sama "tools should be delightful."

4. dotCloud harus pivot. dotCloud (PaaS startup) berjuang ngelawan Heroku. Mereka bikin Docker internal buat nge-manage container mereka. Pas pivot, mereka open-source Docker. Kadang produk lahir dari pressure bisnis, bukan riset lab.

Filosofi Docker menang karena timing: teknologi udah ada (LXC), pain point udah clear (dev/prod drift), tapi belum ada yang bungkus jadi UX bagus. Docker ngisi gap itu.

---

Yang Sering Disalahpahami

"Docker itu virtual machine." - Bukan. Container share kernel host. Beda konsep.

"Docker bikin app lo aman dari serangan." - Container isolasi process, tapi gak sekuat VM. Kalau ada container escape vulnerability, host kena. Buat security hard, pake gVisor / Kata Containers / VM.

"Pake Docker = otomatis microservices." - Salah. Lo bisa monolith di Docker. Lo bisa microservices tanpa Docker. Docker itu packaging, bukan arsitektur.

"Docker image itu ringan banget." - Tergantung base image. Alpine ~5MB. Ubuntu-based ~70MB. Node.js image bisa 900MB kalau gak dioptim. Lo tetep musti mikir ukuran.

---

Penutup yang Jujur

Docker bukan teknologi revolusioner. Namespace 2007, cgroups 2007, LXC 2008. Yang Docker lakukan: ngombinasikan yang udah ada jadi UX yang enak dipake. Filosofinya - standarisasi unit transport software, kayak kontainer pengiriman Malcolm McLean 1956.

Gue pake Docker tiap hari sekarang. Blog ini? Edge Functions Supabase jalan di Deno container. Vercel deploy React jalan di container. CI/CD GitHub Actions jalan di container. Tanpa Docker, dunia dev 2026 bakal jauh lebih ribet.

Tapi Docker bukan jawaban semua masalah. Buat script satu file, pake Docker overkill. Buat app yang butuh kernel khusus, VM. Buat tim yang baru belajar, Docker compose bisa membingungkan duluan.

Yang penting: lo paham kenapa Docker ada. Bukan "biar kekinian" atau "biar bisa docker-compose up." Tapi karena Docker solve masalah nyata - dev/prod parity - dengan filosofi yang simple: bungkus app lo jadi kotak standar, jalan di mana aja.

---

Sumber
• Docker Documentation
• Open Container Initiative Image Specification