Belajar Cloud Engineer - Peran, Model & Sejarah Cloud
Menelusuri perjalanan cloud dari era mainframe dan bare-metal hingga hyperscaler modern, memahami apa yang sebenarnya dikelola seorang Cloud Engineer (provisioning, security, networking, cost, automation), membedah model IaaS/PaaS/SaaS dan public/private/hybrid, serta mengapa industry ini berevolusi menuju cloud-native.
#Pendahuluan
Setelah di episode 0 kita menyiapkan environment — akun free tier, CLI tools, Terraform, dan Docker — pada episode ini kita menarik napas sejenak dan memahami mengapa cloud ada dan apa sebenarnya pekerjaan seorang Cloud Engineer. Sejarah dan model bisnis mungkin terasa seperti teori, padahal justru di sanalah letak semua keputusan desain yang akan kalian temui di episode-episode berikutnya.
Mengapa harus paham sejarah? Karena setiap istilah yang akan kalian pakai sehari-hari — region, availability zone, managed service, serverless, cloud-native — lahir dari evolusi panjang menghilangkan beban operasional. Memahami alurnya akan menjelaskan mengapa provider menyediakan service A tetapi menyerahkan tanggung jawab service B kepada kalian (model shared responsibility), dan itu menentukan seluruh strategi arsitektur kalian ke depan.
#Apa yang Dikelola Seorang Cloud Engineer
Peran Cloud Engineer adalah mengelola seluruh siklus hidup infrastruktur cloud — bukan hanya membuat VM lalu lupa. Empat domain utama:
| Domain | Contoh Aktivitas |
|---|---|
| Provisioning | Membuat VM, database, jaringan, dan service lain — idealnya dari kode |
| Security & Networking | Mengatur IAM, firewall, enkripsi, dan segmen jaringan |
| Cost | Memantau dan mengoptimalkan biaya agar tidak membengkak |
| Automation | Menulis script dan pipeline agar seluruh proses berulang terotomasi |
Cloud engineer juga menjadi jembatan antara tim development (yang ingin merilis fitur cepat) dan kebutuhan operasional (kestabilan, keamanan, biaya). Kalian bukan sekadar "operator dashboard", melainkan orang yang membangun sistem sehingga seluruh tim bisa self-service dengan aman.
Note
Peran ini beririsan dengan DevOps, SRE, dan Platform Engineer. Di episode 26 dan 27 kita akan memetakan perbedaan dan jalur transisinya. Untuk sekarang, ingat kata kuncinya: kalian bertanggung jawab atas seluruh lifecycle infrastruktur, bukan hanya satu titik di dalamnya.
#Sejarah Cloud: Dari Mainframe ke Hyperscaler
#Era Bare-Metal (1980-2000an)
Awalnya perusahaan membeli server fisik, menaruhnya di datacenter sendiri, dan menyewa admin untuk merawatnya. Masalahnya jelas: server menganggur sebagian besar waktu, butuh berminggu-minggu untuk menambah kapasitas, dan biaya listrik + pendinginan besar. Ini era di mana provisioning server bisa memakan 6-8 minggu.
#Era Virtualisasi (Awal 2000an)
VMware dan Xen mempopulerkan hypervisor — satu mesin fisik dibagi menjadi banyak VM yang terisolasi. Ini memangkas waktu provisioning dari minggu ke jam. Namun kalian masih harus membeli, memasang, dan merawat hardware sendiri. Konsep "sewa server per jam" mulai lahir, dan AWS EC2 (2006) memanfaatkan momen ini: Amazon menjual komputasi sebagai utilitas.
#Era Cloud Publik (2006-2015)
AWS meluncurkan S3 (2006) dan EC2 (2006); Azure menyusul (2010) dan GCP (2011). Provider membangun datacenter raksasa dan menjual kapasitasnya dalam hitungan menit, dengan model pay-as-you-go. Kalian tidak perlu membeli hardware lagi — hanya perlu tahu cara menggunakan API-nya. Inilah momen Cloud Engineer lahir: bukan lagi "beli server", tapi "provision via API, otomasi, dan optimasi".
#Era Cloud-Native (2015-sekarang)
Kubernetes open-source (2015) dan konsep serverless (Lambda rilis 2014) menggeser fokus dari "mengelola mesin" ke "mengelola aplikasi". Container, mikroservis, dan fungsi event-driven menjadi default. Pada 2026, cloud-native dan IaC adalah standar, bukan kemewahan — kita akan membahas ini di episode 10, 11, dan 26.
#Model Layanan: IaaS, PaaS, SaaS
Cara paling praktis memahami cloud adalah lewat tanggung jawab bersama (shared responsibility) — siapa yang mengelola apa dari hardware sampai aplikasi:
┌─────────────────────────────────────────────────────┐
│ ON-PREM IaaS PaaS SaaS MANAGED │
├─────────────────────────────────────────────────────┤
│ Data Data Data Data Data │
│ App App App [SaaS] App │
│ OS OS [PaaS] [Service]│
│ VM [IaaS] │
│ Storage │
│ Network │
└─────────────────────────────────────────────────────┘
Semakin ke kanan, semakin banyak yang dikelola provider- IaaS (EC2, Compute Engine, Azure VM) — kalian mengelola OS sampai aplikasi; provider mengelola hypervisor dan hardware. Paling fleksibel, paling banyak yang harus diurus.
- PaaS (Elastic Beanstalk, App Engine, App Service) — provider mengelola OS dan runtime; kalian cukup men-deploy kode. Cepat naik, tapi kurang kontrol.
- SaaS (Gmail, Salesforce, Confluence) — kalian hanya memakai aplikasi jadi; tidak ada yang perlu diurus.
Poin penting: ini bukan soal mana yang "terbaik", tapi mana yang cocok untuk kebutuhan. IaaS memberi kontrol penuh untuk workload kustom; PaaS mempercepat delivery; SaaS menghilangkan operasional. Cloud engineer yang baik tahu kapan memilih masing-masing.
#Model Deployment: Public, Private, Hybrid
| Model | Lokasi Infrastruktur | Kapan Dipakai |
|---|---|---|
| Public cloud | Datacenter provider (AWS/GCP/Azure) | Default: skalabilitas & biaya variabel |
| Private cloud | Datacenter sendiri (OpenStack, VMware) | Regulasi ketat, data sensitif, latensi |
| Hybrid cloud | Campuran private + public | Sudah punya datacenter + butuh burst capacity |
| Multi-cloud | Lebih dari satu provider public | Hindari vendor lock-in, redundansi |
Pada 2026, hampir semua perusahaan besar memakai hybrid atau multi-cloud — bukan lagi pertanyaan "pilih AWS atau GCP", melainkan "bagaimana mengelola semuanya secara konsisten". Strategi ini akan kita bahas detail di episode 22.
#Mengapa Ini Penting untuk Kalian
Memahami model dan sejarah bukan sekadar teori:
- Shared responsibility menentukan apa yang wajib kalian konfigurasi. Misalnya di IaaS, patching OS adalah tugas kalian; di PaaS, tugas provider. Salah mengira ini = lubang keamanan.
- Istilah region/AZ (episode 2) lahir dari cara hyperscaler membangun datacenter — memahami arsitektur fisik memudahkan memahami arsitektur logisnya.
- Evolusi cloud-native menjelaskan mengapa provider menawarkan 200+ service: setiap service adalah jawaban atas beban operasional tertentu. Kalian tinggal memilih yang menghilangkan beban paling banyak tanpa kehilangan kontrol yang kalian butuhkan.
#Penutup
Pada episode 1 ini, kalian telah memahami fondasi konseptual cloud:
- Cloud Engineer mengelola seluruh lifecycle infrastruktur: provisioning, security, networking, cost, dan automation.
- Cloud berevolusi dari bare-metal → virtualisasi → cloud publik → cloud-native; AWS EC2 (2006) menjadi tonggak komputasi-as-a-utilitas.
- IaaS/PaaS/SaaS dibedakan oleh batas shared responsibility — semakin ke kanan, semakin banyak yang dikelola provider.
- Deployment model: public, private, hybrid, dan multi-cloud — masing-masing punya trade-off.
Di episode 2 selanjutnya kita akan membahas arsitektur cloud dan provider — apa itu region, availability zone, edge location, dan global infrastructure, lalu membandingkan AWS vs GCP vs Azure serta cara memetakan service antar-provider. Sampai jumpa di episode 2!