Belajar Cloud Engineer - Compute (EC2/VM/Serverless)

#Pendahuluan

Setelah memahami peta fisik cloud (region/AZ) di episode 2, sekarang saatnya masuk ke praktik pertama yang sesungguhnya: compute — otak dari setiap sistem cloud. Compute adalah layanan yang kalian pakai untuk menjalankan kode, dan di episode ini kita akan membedah spektrumnya: dari VM yang paling fleksibel (EC2, Compute Engine, Azure VM), container services di tengah, hingga serverless function yang paling otomatis (Lambda, Cloud Functions, Azure Functions).

Mengapa penting? Karena hampir semua keputusan arsitektur dimulai dari pertanyaan: "di mana kode saya berjalan?" Jawabannya menentukan biaya, cara scaling, cara security, dan seberapa banyak operasional yang harus kalian tanggung. Cloud engineer yang memahami spektrum ini tahu kapan memilih VM untuk workload yang butuh kontrol penuh, dan kapan memilih serverless untuk workload event-driven yang intermittent.

#Spektrum Compute Cloud

VM (IaaS)  ──>  Container Services  ──>  Serverless
  kontrol        kontrol medium          kontrol minimum
  ++++++         ++ +++                  +
  ops tinggi     ops medium              ops ~0

Di ujung kiri, kalian mengelola semuanya (OS, patch, scaling sendiri). Di ujung kanan, provider mengelola semuanya dan kalian cukup mengirim kode. Pilihan kalian bergantung pada workload, tim, dan kebutuhan scaling.

#Virtual Machine (EC2 / Compute Engine / Azure VM)

#Instance Family dan Type

VM disusun dari instance type — kombinasi vCPU, RAM, dan kadang GPU/storage lokal. AWS menyebutnya seperti t3.micro, GCP machine type seperti e2-standard-2, Azure seperti Standard_B2s. Kategorinya:

Kesalahan umum pemula: memilih tipe terbesar karena "biar aman". Sebenarnya mulailah dari yang paling kecil yang memenuhi kebutuhan, lalu naikkan (right-sizing) berdasarkan metrik penggunaan — topik yang akan kita bahas tuntas di episode 16 (FinOps).

#Membuat VM Pertama

Buat VM dari CLI. AWS:

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-keypair \
  --security-group-ids sg-0123456789 \
  --subnet-id subnet-0123456789 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=lab-web}]'

GCP:

gcloud compute instances create lab-web \
  --zone=asia-southeast2-a \
  --machine-type=e2-micro \
  --image-family=ubuntu-2404-lts-amd64 \
  --tags=http-server

Azure:

az vm create \
  --resource-group rg-lab \
  --name lab-web \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --admin-username azureuser \
  --generate-ssh-keys

Ketiga perintah di atas melakukan hal yang sama: provision sebuah VM dari CLI, lengkap dengan jaringan, key SSH, dan tag. Ini langkah pertama dari pola pikir IaC — dari sini kita akan ke Terraform di episode 7.

#Lifecycle VM

Setiap VM punya status: running, stopped, terminated/deleted. Di semua provider, instance yang stopped tidak membebani biaya compute (hanya storage disk), sedangkan yang running dihitung per detik (AWS/GCP) atau per menit (Azure). Biasakan menghentikan VM yang tidak dipakai — ini kebiasaan FinOps paling murah yang bisa kalian mulai hari ini.

#Container Services

Di antara VM dan serverless ada container services — kalian tetap mengontrol runtime, tapi provider membantu mengelola orkestrasi. Spektrumnya:

Kalian bisa menjalankan container Docker langsung tanpa VM: AWS Fargate menghilangkan kebutuhan mengelola node, Cloud Run bahkan auto-scale ke nol. Kita akan membahas managed Kubernetes secara penuh di episode 10. Untuk sekarang, cukup pahami bahwa container adalah unit deployment modern — dan Docker yang kalian install di episode 0 akan dipakai terus.

#Serverless Function (Lambda / Cloud Functions / Functions)

#Konsep

Function as a Service (FaaS): kalian mengirim kode fungsi, provider mengelola runtime, scaling, dan ketersediaan. Biaya dihitung dari jumlah eksekusi × durasi, dan fungsi bisa scale ke nol — tidak ada biaya saat tidak dipanggil. Ini menjadikannya ideal untuk workload event-driven: upload file, webhook, API ringan, job terjadwal.

#Deploy Function Pertama

AWS Lambda dengan runtime Python:

mkdir -p ~/lambda-lab && cd ~/lambda-lab
cat > lambda_function.py <<'EOF'
def handler(event, context):
    name = event.get("name", "cloud")
    return {"statusCode": 200, "body": f"hello {name}"}
EOF
zip -r function.zip lambda_function.py
aws lambda create-function \
  --function-name hello-cloud \
  --runtime python3.12 \
  --handler lambda_function.handler \
  --role arn:aws:iam::123456789012:role/lambda-basic \
  --zip-file fileb://function.zip
aws lambda invoke --function-name hello-cloud \
  --payload '{"name":"engineer"}' out.json && cat out.json

GCP Cloud Functions:

gcloud functions deploy hello-cloud \
  --runtime python312 \
  --trigger-http \
  --allow-unauthenticated \
  --entry-point handler

Azure Functions:

az functionapp create \
  --resource-group rg-lab \
  --consumption-plan-location southeastasia \
  --runtime python \
  --name func-lab-unique

#Trade-off Serverless

Kelebihan:

• Zero management: tidak ada OS untuk di-patch, tidak ada node untuk di-scale.
• Pay-per-invocation: murah untuk traffic tidak stabil.
• Scale otomatis: dari 0 ke ribuan konkurrensi tanpa konfigurasi.

Kekurangan (common pitfalls):

• Cold start: fungsi idle pertama kali dipanggil akan lambat (ratusan ms) karena runtime di-boot ulang — masalah besar untuk API yang sensitif latensi. Kita bedah detail di episode 11.
• Timeout: Lambda maksimal 15 menit, Cloud Functions 60 menit — tidak cocok untuk job panjang.
• Vendor lock-in: kode terikat pada runtime dan event model provider.
• Biaya tersembunyi: traffic tinggi dengan durasi panjang bisa lebih mahal dari VM tetap.

#Latihan: Deploy VM + Serverless Function

Sebagai penutup, rangkai apa yang baru kalian pelajari:

1. Buat VM lab-web di region terdekat (pakai salah satu command di atas).
2. Deploy function serverless hello-cloud di provider yang sama.
3. Panggil function tersebut dengan payload nama kalian.
4. Catat berapa lama waktu provisioning masing-masing — VM butuh menit, function butuh detik.

Setelah selesai, matikan atau hapus resource yang tidak dipakai untuk menghindari biaya tak terduga.

#Penutup

Inti yang harus dibawa pulang:

• Compute punya tiga level: VM (kontrol penuh, ops tinggi), container services (tengah), serverless (ops minimum, pay-per-invocation).
• Instance type menentukan rasio CPU/RAM; mulailah dari kecil lalu right-size.
• Lifecycle VM: stop ≠ hapus; yang stopped tidak dibebani biaya compute.
• Serverless cocok untuk workload event-driven, tapi waspadai cold start, timeout, dan vendor lock-in.

Di episode 4 selanjutnya kita akan membahas storage dan database services — object storage (S3/Cloud Storage/Blob), block & file storage, lifecycle policy, serta managed database (RDS/Cloud SQL) dan NoSQL (DynamoDB/Firestore/Cosmos DB). Sampai jumpa di episode 4!