Deployment Tradisional #

Sebelum Docker dan teknologi container menjadi standar de‑facto dalam dunia deployment aplikasi modern, proses deployment aplikasi dilakukan dengan pendekatan tradisional. Pendekatan ini sangat bergantung pada konfigurasi manual server, konsistensi environment, serta disiplin dokumentasi tim. Walaupun saat ini dianggap “ribet” dan “rawan error”, deployment tradisional adalah fondasi dari semua praktik DevOps yang kita kenal sekarang.

Artikel ini akan membahas secara mendalam:

• Apa itu deployment tradisional
• Bagaimana alur deployment sebelum Docker
• Pendekatan dan metode yang umum digunakan
• Masalah klasik yang sering muncul
• Kelebihan dan kekurangannya
• Mengapa Docker hadir sebagai solusi

Apa Itu Deployment Tradisional? #

Deployment tradisional adalah proses menjalankan aplikasi langsung di server (bare metal atau VM) tanpa isolasi container. Aplikasi berjalan di atas:

• Operating System server
• Dependency yang di‑install langsung ke OS
• Konfigurasi environment global

Setiap aplikasi “berbagi” sistem yang sama, baik library, runtime, maupun resource.

Arsitektur Umum Deployment Tradisional #

Secara sederhana, arsitekturnya seperti ini:

User
 │
 ▼
Load Balancer (Opsional)
 │
 ▼
Server / VM
 ├─ OS (Linux)
 ├─ Runtime (Java / PHP / Python / Node.js)
 ├─ System Library
 ├─ Application Code
 └─ Config (env, file, secret)

Setiap perubahan versi runtime atau dependency berisiko memengaruhi aplikasi lain di server yang sama.

Metode Deployment Tradisional yang Umum Digunakan #

Manual Deployment (SSH + Copy File) #

Metode paling awal dan paling sederhana.

Alur umum:

1. Developer build aplikasi di lokal
2. Login ke server via SSH
3. Upload file (SCP / SFTP)
4. Install dependency manual
5. Restart service

Ciri khas:

• Sangat bergantung pada manusia
• Sulit direproduksi
• Rawan human error

Deployment Berbasis Script (Shell Script) #

Untuk mengurangi kesalahan manual, mulai digunakan script bash.

Contoh:

• deploy.sh
• setup_server.sh

Script berisi:

• Install package
• Copy file
• Restart service

Masalah utama:

• Script sangat spesifik ke OS
• Sulit di-maintain
• Tidak idempotent

Deployment Menggunakan Configuration Management #

Muncul tools seperti:

• Ansible
• Chef
• Puppet
• SaltStack

Pendekatan ini mulai memperkenalkan konsep Infrastructure as Code.

Keunggulan:

• Konfigurasi terdokumentasi
• Lebih konsisten antar server

Namun:

• Tetap bergantung pada OS
• Dependency masih terinstall global
• Setup awal kompleks

Deployment Berbasis VM Image #

Beberapa tim menggunakan:

• Amazon AMI
• Vagrant Box
• Snapshot VM

Aplikasi dan dependency dibundel dalam satu image VM.

Kelemahan:

• Image sangat besar
• Build lambat
• Tidak fleksibel

Dependency Management di Era Tradisional #

Ini adalah sumber masalah terbesar.

Contoh kasus klasik:

• App A butuh Java 8
• App B butuh Java 11
• App C butuh library C versi lama

Solusi yang sering dipakai:

• Install manual dan ganti‑ganti versi
• Menggunakan virtualenv (Python)
• Menggunakan nvm (Node.js)

Namun solusi ini:

• Tidak konsisten
• Sulit diautomasi
• Tidak scalable

Konfigurasi Environment #

Biasanya dilakukan dengan:

• File .env
• Export environment variable
• File config di /etc

Masalah yang sering terjadi:

• Environment dev ≠ staging ≠ production
• Secret tersebar di banyak tempat
• Tidak ada standar

Inilah asal mula istilah legendaris:

“Works on my machine”

Scaling di Deployment Tradisional #

Scaling dilakukan dengan:

• Menambah server baru
• Clone konfigurasi manual
• Copy application & dependency

Problem:

• Provisioning lambat
• Tidak elastis
• Sulit autoscaling

Monitoring & Logging #

Biasanya menggunakan:

• Log file di /var/log
• tail -f
• Custom cron script

Belum ada:

• Standard log format
• Centralized logging
• Observability

Kelebihan Deployment Tradisional #

Walaupun banyak kekurangan, deployment tradisional punya kelebihan:

• ✅ Sangat sederhana secara konsep
• ✅ Tidak butuh tool tambahan
• ✅ Mudah dipahami pemula
• ✅ Full control ke OS

Untuk aplikasi kecil atau internal, pendekatan ini masih relevan.

Kekurangan Deployment Tradisional #

• ❌ Dependency conflict
• ❌ Tidak reproducible
• ❌ Sulit scaling
• ❌ High human error
• ❌ Setup lama
• ❌ Sulit CI/CD

Semua masalah ini terakumulasi seiring bertambahnya aplikasi dan tim.

Masalah Besar yang Melahirkan Docker #

Docker hadir sebagai jawaban atas problem klasik deployment tradisional:

Perbandingan Singkat #

Kapan Deployment Tradisional Masih Digunakan? #

Deployment tradisional masih relevan untuk:

• Legacy system
• Aplikasi monolith lama
• Sistem dengan regulasi ketat
• Environment air‑gapped

Namun, tren industri jelas bergerak ke container.

Penutup #

Deployment tradisional adalah pondasi sejarah dari praktik DevOps modern. Memahami keterbatasannya membantu kita:

• Menghargai evolusi Docker
• Mendesain arsitektur yang lebih baik
• Tidak salah kaprah dalam menggunakan container

Docker bukan sekadar tool, tapi jawaban dari problem nyata yang selama bertahun‑tahun dihadapi oleh engineer di era deployment tradisional.