Container vs Virtual Machine: Apa Sebenarnya yang Beda

Kumpulkan dua engineer di satu ruangan, lalu tanya “kita pakai container atau VM?” — biasanya pendapat keras sudah keluar duluan sebelum ada yang sempat mendefinisikan istilahnya. Sayang sekali, karena beda antara container dan virtual machine itu bukan soal selera. Bedanya konkret dan teknis, dan begitu kamu lihat persis di mana garis pemisahnya, pertanyaan “mending pakai yang mana” hampir terjawab dengan sendirinya.

Kedua teknologi ini lahir untuk menyelesaikan masalah yang sama: kamu punya satu server fisik, dan kamu ingin menjalankan beberapa beban kerja terpisah di atasnya tanpa saling mengganggu. Yang membedakan keduanya adalah seberapa banyak yang mereka bangun ulang untuk mewujudkan keterpisahan itu. VM membangun ulang satu komputer utuh. Container malah berbagi komputer yang sudah ada. Semua selisih lainnya — soal kecepatan, ukuran, dan kompromi — mengalir dari satu keputusan tunggal ini.

Masalah yang sama-sama mereka pecahkan

Bayangkan ACY Partner Indonesia punya satu server yang lumayan kuat. Di atasnya mereka ingin menampung sebuah website, sebuah tool internal terpisah, dan satu database, masing-masing dengan library dan pengaturannya sendiri, idealnya tanpa yang satu menjatuhkan yang lain atau bisa mengintip berkas yang lain.

Sebenarnya kamu bisa saja menginstal ketiganya berdampingan di sistem operasi yang sama. Itu jalan sampai akhirnya bermasalah: dependensinya bentrok, update untuk satu hal merusak yang lain, dan satu celah keamanan di salah satunya memberi penyerang kuasa atas ketiganya sekaligus. Yang sebenarnya kamu mau adalah isolasi — beri tiap beban kerja dunia kecilnya sendiri yang merasa dia sendirian di mesin itu.

Container dan VM adalah dua jawaban untuk keinginan tadi. Keduanya menyediakan lingkungan terisolasi di atas perangkat keras yang dibagi bersama. Bedanya, mereka menarik garis batas di lapisan yang berbeda.

Virtual machine itu apa

Virtual machine adalah komputer tiruan yang utuh, berjalan di dalam komputer aslimu. Sebuah software bernama hypervisor duduk di atas perangkat keras fisik dan membagi-bagikan perangkat keras virtual — CPU virtual, memori virtual, disk virtual, kartu jaringan virtual — ke tiap VM. Di dalam perangkat keras virtual itu, kamu menginstal sistem operasi penuh, lengkap dengan kernel-nya, persis seperti memasangnya di mesin fisik telanjang.

Ini bagian yang harus kamu pegang erat: tiap VM menjalankan sistem operasinya sendiri yang utuh. Kalau ada satu server fisik menampung empat VM, berarti ada lima sistem operasi yang aktif — milik host (atau hypervisor) ditambah satu di dalam tiap VM.

        VIRTUAL MACHINE
 ┌────────┐ ┌────────┐ ┌────────┐
 │  App   │ │  App   │ │  App   │
 ├────────┤ ├────────┤ ├────────┤
 │ Libs   │ │ Libs   │ │ Libs   │
 ├────────┤ ├────────┤ ├────────┤
 │ Guest  │ │ Guest  │ │ Guest  │   ← OS penuh (kernel
 │  OS    │ │  OS    │ │  OS    │      ikut) di tiap VM
 └────────┘ └────────┘ └────────┘
 ┌──────────────────────────────┐
 │         Hypervisor           │   ← membagi perangkat keras virtual
 ├──────────────────────────────┤
 │     Perangkat keras fisik    │
 └──────────────────────────────┘

Karena tiap VM membawa OS-nya sendiri secara penuh, dia betul-betul terpisah dari tetangganya. Satu VM bisa menjalankan Windows sementara VM di sebelahnya menjalankan Linux. Satu VM bisa crash, di-restart, atau dibobol, dan yang lain hampir tidak terpengaruh. Temboknya tebal — sedekat mungkin dengan “mesin fisik terpisah” yang bisa kamu dapatkan sambil tetap berbagi perangkat keras nyata.

Kekuatan itu juga jadi ongkosnya. Sistem operasi yang utuh itu berat: memakan ruang disk bergiga-giga, butuh memorinya sendiri, dan perlu waktu nyata untuk booting — biasanya puluhan detik sampai beberapa menit. Jalankan selusin VM, dan kamu menjalankan selusin salinan OS yang mengerjakan urusan rumah tangga yang sama berulang-ulang.

Container itu apa

Container mengambil taruhan yang berbeda. Alih-alih meniru perangkat keras dan booting OS baru, container berbagi kernel sistem operasi milik host dan hanya mengisolasi apa yang ada di atasnya — aplikasinya, library-nya, dan berkas-berkasnya.

Kernel adalah inti dari sebuah sistem operasi: bagian yang berbicara dengan perangkat keras serta mengatur proses dan memori. (Kalau gambaran ini masih kabur, ada baiknya kamu mampir dulu ke apa yang dikerjakan sistem operasi di sebuah server.) Container tidak membawa kernel-nya sendiri. Dia memakai kernel milik host, dan mengandalkan fitur yang sudah tertanam di kernel itu untuk membuatkan ruang privat — pandangan filesystem-nya sendiri, daftar proses-nya sendiri, jaringan-nya sendiri — supaya dari dalam, dia kelihatan seperti mesin tersendiri.

            CONTAINER
 ┌────────┐ ┌────────┐ ┌────────┐
 │  App   │ │  App   │ │  App   │
 ├────────┤ ├────────┤ ├────────┤
 │ Libs   │ │ Libs   │ │ Libs   │   ← cuma app + library-nya
 └────────┘ └────────┘ └────────┘
 ┌──────────────────────────────┐
 │     Container runtime        │   ← mengisolasi tiap container
 ├──────────────────────────────┤
 │  OS host  (SATU kernel dibagi)│   ← semua container pakai INI
 ├──────────────────────────────┤
 │     Perangkat keras fisik    │
 └──────────────────────────────┘

Perhatikan apa yang hilang dibanding diagram VM tadi: tidak ada lapisan guest OS di dalam tiap kotak. Cuma ada satu kernel di paling bawah, dan tiap container meminjamnya. Satu perubahan itulah seluruh ceritanya.

Karena container hanya membungkus aplikasi beserta dependensinya — bukan satu sistem operasi — ukurannya mungil dibandingkan VM: sering kali puluhan megabita, bukan gigabita. Dan karena tidak ada OS yang perlu di-booting, dia menyala dalam pecahan detik. Menjalankan container lebih mirip meluncurkan sebuah program ketimbang menyalakan komputer, karena pada dasarnya memang itulah dia: sebuah proses biasa di host, yang dibungkus isolasi.

Container itu proses yang dipagari, bukan komputer mungil

Gampang sekali membayangkan container sebagai VM versi kecil. Padahal bukan. Tidak ada perangkat keras virtual dan tidak ada sistem operasi kedua di dalamnya. Container hanyalah proses biasa yang berjalan di atas kernel milik host, dengan kernel diminta memberinya pandangan sistem yang terbatas dan privat. Rasa “ini sebuah mesin” itu adalah ilusi yang dijaga oleh kernel — ilusi yang sangat berguna, tapi tetap saja ilusi.

Garis pemisahnya, dalam satu kalimat

Kalau tidak ada hal lain yang kamu ingat, ingat ini: VM memvirtualisasi perangkat kerasnya; container memvirtualisasi sistem operasinya.

VM berkata “ini komputer palsu — instal OS utuh di atasnya.” Container berkata “kamu boleh ikut memakai OS-ku — aku cuma kasih kamu sudutmu sendiri di dalamnya.” Batas di tingkat perangkat keras versus batas di tingkat OS. Satu perbedaan tunggal itulah akar dari semua selisih praktis yang menyusul berikutnya.

Perbandingan dalam praktik

Arsitekturnya kedengaran abstrak, jadi ini artinya kalau kamu benar-benar memakainya.

Ukuran. Image VM itu besar karena memuat OS penuh — umumnya beberapa gigabita. Image container hanya berisi aplikasi dan library-nya, sering kali cuma beberapa puluh megabita. Kamu bisa menampung jauh lebih banyak container ketimbang VM di disk yang sama.
Waktu nyala. VM booting sebuah sistem operasi, jadi siapkan puluhan detik sampai beberapa menit. Container cuma proses yang menyala — biasanya di bawah satu detik. Inilah kenapa container unggul untuk hal-hal yang naik-turun jumlahnya terus-menerus.
Kepadatan. Karena ringan, kamu bisa menjejalkan jauh lebih banyak container ke satu server dibanding VM. Ratusan container di satu host itu wajar; ratusan VM tidak.
Beban tambahan. VM menjalankan kernel dan layanan OS-nya sendiri, yang menghabiskan CPU dan memori cuma untuk eksis. Container nyaris tidak menambah beban — dia berjalan hampir secepat proses biasa di host.
Kekuatan isolasi. Di sini VM menang. Tiap VM punya kernel-nya sendiri, jadi tembok antar-mereka sangat kokoh; eksploitasi tingkat kernel di satu VM tetap terkurung. Container berbagi kernel, jadi cacat pada kernel bersama itu adalah cacat bagi semua yang ada di atasnya. Isolasi container itu bagus dan terus membaik, tapi memang temboknya lebih tipis secara desain.
Keleluasaan OS. VM bisa menjalankan sistem operasi apa pun terlepas dari host-nya — misalnya VM Windows di atas host Linux. Container harus cocok dengan kernel host: container Linux butuh kernel Linux di bawahnya. Kamu tidak bisa menjalankan OS dari keluarga yang benar-benar berbeda di container seperti yang bisa kamu lakukan di VM.

Ini perbandingan yang sama dalam sekilas pandang:

                    Virtual Machine        Container
 Memvirtualisasi    perangkat keras        sistem operasi
 Tiap instance      OS penuh sendiri       berbagi kernel host
 Ukuran umum        gigabita               megabita
 Waktu nyala        detik sampai menit     jauh di bawah sedetik
 Isolasi            sangat kuat            kuat, tembok lebih tipis
 OS berbeda         bisa                   tidak (keluarga kernel sama)
 Kepadatan/host     sedang                 tinggi

Jadi, sebaiknya pakai yang mana?

Tidak ada yang “lebih baik” secara mutlak — keduanya disetel untuk prioritas yang berbeda, dan banyak sistem nyata justru memakai keduanya sekaligus.

Pilih virtual machine kalau isolasi adalah perhatian utamamu: menjalankan kode yang tidak tepercaya, menjaga tiap penyewa benar-benar terpisah, memenuhi aturan kepatuhan yang menuntut pemisahan keras, atau ketika kamu memang butuh sistem operasi yang berbeda dari yang dijalankan host. Tembok tebal dan keleluasaan OS penuh itu persis yang dibutuhkan situasi semacam itu.

Pilih container kalau yang paling penting adalah kecepatan, kepadatan, dan portabilitas: membungkus aplikasi dengan dependensi yang persis sama supaya jalan sama di mana pun, menambah dan mengurangi instance dengan cepat seiring beban yang berubah, atau menjejalkan banyak layanan kecil ke perangkat keras yang sederhana. Keringanan yang membuat container kurang terisolasi adalah keringanan yang sama yang membuatnya begitu praktis untuk mengirim dan menskalakan software.

Dan menggabungkan keduanya itu benar-benar lazim: jalankan beberapa VM untuk pemisahan keras, lalu jejalkan container di dalam tiap VM untuk pembungkusan dan kepadatan. Kamu dapat tembok luar VM yang kokoh sekaligus kelincahan container di dalamnya. Susunan berlapis ini begitu umum sampai nyaris jadi standar di sistem yang lebih besar.

Cocokkan alat dengan batas yang benar-benar kamu butuhkan

Sebelum memilih, tanya satu hal: apa sih yang sebenarnya ingin aku pisahkan? Kalau itu sistem-sistem utuh yang mungkin saling memusuhi dan tidak boleh bersentuhan — VM. Kalau itu versi aplikasi beserta library-nya yang ingin kamu kirim dan jalankan dengan andal — container. Sebagian besar perdebatan “container atau VM” langsung bubar begitu ada yang menyebut batas yang sebenarnya dibutuhkan proyek itu.

Kenapa perbedaan ini layak dipahami

Container mengubah wajah cara software dibangun dan dikirim selama satu dekade terakhir, dan alasannya bisa ditarik lurus ke arsitektur di atas tadi. Dengan membuang guest OS dan berbagi kernel, container membuatnya jadi murah untuk membungkus sebuah aplikasi beserta lingkungannya, lalu memindahkan paket itu antara laptop developer, server pengujian, dan produksi tanpa berubah. “Di mesinku jalan kok” berhenti jadi alasan, karena mesin — bagian yang relevan darinya — sekarang ikut bepergian bersama aplikasinya.

Tapi VM tidak hilang, dan tidak akan hilang. Mereka tetap memegang pekerjaan yang butuh batas keras berbasis OS penuh, dan sering kali justru jadi fondasi tempat container berjalan di atasnya. Memahami keduanya, beserta satu garis yang memisahkan mereka, berarti kamu bisa membaca hampir semua diagram infrastruktur modern dan langsung menangkap jenis isolasi apa yang sedang dibeli dan apa yang dibayar demi isolasi itu.

Penutup

Seluruh topik ini dalam satu tempat:

Baik container maupun virtual machine sama-sama mengisolasi beban kerja di atas perangkat keras yang dibagi — bedanya cuma di lapisan mana garis batasnya ditarik.
VM memvirtualisasi perangkat keras: hypervisor membagikan perangkat keras virtual, dan tiap VM menjalankan sistem operasinya sendiri yang utuh, kernel ikut.
Container memvirtualisasi OS: dia berbagi kernel milik host dan cuma mengisolasi aplikasi, library, serta berkasnya — dia proses yang dipagari, bukan komputer mungil.
VM itu lebih besar, lebih lambat menyala, dan isolasinya lebih kuat; container itu mungil, nyaris instan, dan jauh lebih padat, tapi berbagi kernel sehingga temboknya lebih tipis.
Pilih berdasarkan batas yang kamu butuhkan: VM untuk pemisahan keras atau OS berbeda; container untuk kecepatan, portabilitas, dan kepadatan — dan sering kali keduanya bersama, container di dalam VM.

Berikutnya, setelah bedanya jelas, ada baiknya kita lihat sisi keuntungan yang mendorong container jadi arus utama sejak awal — alasan konkret kenapa tim memilihnya dan masalah apa saja yang dibuatnya lenyap.