‹ Daftar slide
Pertemuan 2: Model Layanan Cloud (IaaS, PaaS, SaaS, FaaS, Shared Responsibility)
PEBD6027 · RPS minggu 2 · 2x50 menit
Model Layanan Cloud
IaaS · PaaS · SaaS · FaaS — Cloud System Bisdig
Peta Pembelajaran Hari Ini
Sub-CPMK 2: membedakan model layanan cloud dan memilih untuk skenario. Empat indikator capaian.
Jam ke-1 (50 menit)
- 4 model: IaaS, PaaS, SaaS, FaaS + analogi pizza
- Komparasi tanggung jawab & stack
- Hitung dari nol: EC2 vs Lambda
Jam ke-2 (50 menit)
- Shared responsibility model + Capital One breach
- Matriks skenario → model
- Kapan serverless menang & kalah
Posisi alur 14P: setelah fondasi P1, hari ini kita pilih "menu makanan" cloud. P3 akan bahas model deployment public/private/hybrid.
Pizza-as-a-Service: Analogi Klasik
Albert Barron (IBM, 2014) membuat analogi yang masih jadi rujukan terbaik untuk memahami model cloud.
On-premise
Masak Sendiri
Beli tepung, oven, gas — pegang kontrol penuh
IaaS
Pizza Beku
Beli pizza beku, masak di oven sendiri (DiGiorno)
PaaS
Delivery
Pesan pizza delivery, tinggal makan (Pizza Hut)
SaaS
Makan di Restoran
Semua ditangani, Anda konsumsi saja
Naik abstraksi = kurang kontrol, lebih banyak yang ditangani provider. Trade-off utama cloud.
Bagian 1 · 1/4
4 Model Layanan Cloud
Diskusi kelas: aplikasi Gojek (driver, food, ride) pake model apa? Bisakah beda per fitur?
IaaS: Infrastructure as a Service
Provider beri VM, storage, network; Anda install OS, app, database sendiri. Kontrol tinggi, beban operasional tinggi.
| Aspek | Detail |
|---|---|
| Contoh provider | AWS EC2, Azure VM, GCP Compute Engine, DigitalOcean Droplet, Lintasarta Cloudeka VM |
| Anda kelola | OS, runtime, data, aplikasi, security patch, backup |
| Provider kelola | Virtualization, server fisik, storage, network, data center |
| Cocok untuk | Migrasi lift-and-shift, legacy app, kontrol penuh, database sensitif |
| Kerugian | Tim DevOps wajib, beban patching & monitoring |
PaaS: Platform as a Service
Provider beri runtime (Java, Node, Python), DB managed. Anda tinggal push kode. Fokus produktivitas developer.
Contoh Provider
- Heroku (pionir, git push heroku main)
- Google App Engine
- AWS Elastic Beanstalk
- Azure App Service
- Render, Railway (modern)
Trade-off
- + Deploy cepat, fokus kode bisnis
- + Auto-scaling built-in
- − Runtime terbatas yang didukung
- − Vendor lock-in buildpack
SaaS: Software as a Service
Aplikasi jadi, akses via browser/API, bayar subscription. Yang Anda pakai sehari-hari.
Contoh SaaS Sehari-hari
- Gmail, Google Workspace, Office 365
- Slack, Notion, Miro, Canva
- Salesforce, HubSpot (CRM)
- Shopify, Tokopedia Seller (e-commerce)
- Zoom, Google Meet, Discord
Karakteristik
- Zero maintenance bagi pelanggan
- Multi-tenant (1 instance, banyak pelanggan)
- Subscription per user/bulan
- Update otomatis provider
FaaS / Serverless: Function as a Service
Deploy function (potongan kode), provider jalanin saat dipanggil. Skala 0 ke jutaan, bayar per eksekusi (ms).
Contoh Provider
- AWS Lambda (pionir 2014)
- Google Cloud Functions
- Azure Functions
- Cloudflare Workers (edge)
- Vercel Functions (frontend)
Cocok untuk
- Webhook payment gateway
- Chatbot trigger event
- Cron job ringan & scheduler
- Image/thumbnail processing
- API ringan event-driven
Kerugian: cold start latency 100–500ms, debugging kompleks, vendor lock-in event format. Bukan silver bullet — pelajari trade-off di Slide 19. Sejarah: Salesforce 1999 (SaaS), AWS 2006 (IaaS), Google App Engine 2008 (PaaS), AWS Lambda 2014 (FaaS), Cloudflare Workers 2018 (Edge). Pola 5–6 tahunan: model baru lebih abstrak.
Komparasi 4 Model: Stack Tanggung Jawab
Naik abstraksi = banyak lapisan yang ditangani provider. Grafik tanggung jawab per model.
Hitung dari Nol: EC2 Always-on vs Lambda
Webhook 100 request/hari, durasi 200ms tiap. Memory Lambda 128MB. EC2 t3.micro. Kurs Rp 16.000/USD (dihedge).
| Langkah | Komponen | Perhitungan | Nilai |
|---|---|---|---|
| 1 | EC2 t3.micro on-demand | $0,0104/jam × 730 jam | $7,59/bln = Rp 121.440 |
| 2 | Lambda compute (100×30×0,2×0,125 GB) | 750 GBs × $0,00000001667 | $0,0000125 ≈ Rp 0,2 |
| 3 | Lambda request (3.000 req < 1jt free) | gratis (free tier) | Rp 0 |
| 4 | Selisih traffic rendah | 121.440 − 0,2 | Rp 121.440/bln |
| 5 | Pada 1jt req/hari: Lambda compute 750rb GBs | = $12,50 + $6 req | $18,50 ≈ Rp 296.000 |
| 6 | Di sini EC2 ($7,59) lebih murah dari Lambda ($18,50) | break-even ~500rb req/hari | EC2 menang steady |
Aturan praktis: spiky traffic → Lambda, steady high load → EC2. Harga AWS public pricing (verify via Pricing Calculator).
Bagian 2 · 2/4
Shared Responsibility Model
Diskusi kelas: bila data nasabah bocor dari S3 yang salah konfigurasi public, siapa salahnya — AWS atau pelanggan?
Shared Responsibility Model (AWS)
AWS bertanggung jawab atas security OF the cloud. Pelanggan bertanggung jawab atas security IN the cloud.
| AWS (Security OF Cloud) | Pelanggan (Security IN Cloud) |
|---|---|
| Hardware fisik server & storage | Data (enkripsi at-rest/in-transit) |
| Software virtualisasi (hypervisor) | Identity & Access Management (IAM) |
| Jaringan fisik data center | OS & patching (untuk IaaS) |
| Region & Availability Zone | Platform & aplikasi (untuk IaaS/PaaS) |
| Keamanan fisik (guard, CCTV, AC) | Firewall, security group, WAF config |
| Redundansi infrastruktur | Backup & disaster recovery data |
Garis pembagian bergeser per model: pada SaaS, sebagian besar OS & runtime jadi tanggungan provider. Pada IaaS, OS jadi tanggungan Anda.
Studi Kasus: Capital One Breach 2019
Pelajaran klasik shared responsibility di industri keuangan AS — kasus yang wajib Anda kenal sebelum kerja di bank digital.
Fakta kasus:
- Hacker eksfiltrasi data 106 juta nasabah Capital One (bank AS)
- Vektor: WAF misconfigured + permission IAM longgar di S3
- AWS TIDAK salah — infrastruktur fisik & hypervisor aman
- Capital One salah konfigurasi permission S3 & WAF
- Denda class action: $190 juta (settlement 2022)
Pelajaran untuk Bank Jago / Bank Neo / Bank Neo Commerce: pilih provider hanya setengah pekerjaan. Konfigurasi IAM & tim security adalah separuh lainnya. BPOJK & POJK cloud perbankan mewajibkan audit konfigurasi berkala.
Bagian 3 · 3/4
Pemilihan Model untuk Skenario
Diskusi: startup Bisdig tim 3 orang mau bikin marketplace, pilih model apa? Bagaimana jika tim 20 orang?
Matriks Keputusan: Skenario vs Model
Lima skenario realistis di industri Indonesia. Aturan emas: pilih abstraksi tertinggi yang masih memenuhi kebutuhan.
| Skenario | Model | Justifikasi |
|---|---|---|
| Migrasi ERP legacy lift-and-shift | IaaS | Kontrol OS, kompatibilitas aplikasi lama |
| Web app baru tim 3 orang | PaaS | Heroku/Beanstalk, hemat waktu DevOps |
| Email korporat 100 karyawan | SaaS | Google Workspace, zero maintenance |
| Webhook payment gateway | FaaS | Lambda, bayar per event, scale otomatis |
| Marketplace kompleks (Tokopedia) | Mix | IaaS DB + PaaS app + FaaS trigger + SaaS CRM |
Untuk Bisdig founder: mulai dari abstraksi tertinggi (SaaS/PaaS), turun ke IaaS hanya bila ada kebutuhan spesifik (kontrol, regulasi, cost).
Vendor Lock-in & Portabilitas
Naik abstraksi = naik lock-in. Mitigasi: container Docker + Kubernetes = portabilitas tinggi.
Lock-in Tinggi
- SaaS proprietary (Salesforce)
- FaaS event format (Lambda)
- Migrasi rewrite kode 80%+
Lock-in Sedang
- PaaS runtime (Heroku Buildpack)
- Managed DB dengan API spesifik
- Migrasi butuh refactor moderate
Lock-in Rendah
- IaaS dengan Docker container
- DB open-source (PostgreSQL)
- Migrasi lift-and-shift antar provider
Strategi multi-cloud (Docker + K8s) = portabilitas tinggi, tapi naikkan kompleksitas operasional. Tidak ada makan siang gratis di cloud.
Latihan: Pilih Model untuk 4 Startup
Diskusi kelompok (10 menit): Pilih model + justifikasi untuk 4 startup:
- A. Fintech P2P lending tim 5 orang — kepatuhan POJK OJK ketat
- B. E-commerce UMKM batik tim 2 orang — bootstrap, modal minim
- C. News portal traffic spike saat breaking news
- D. Chatbot customer service bank — idle lama, spike saat promo
Pertimbangkan: ukuran tim, anggaran, kebutuhan kontrol, vendor lock-in, regulasi sektor.
Bagian 4 · 4/4
Serverless: Kapan Menang & Kalah
Diskusi: bila Lambda cold start 200ms, bisakah dipakai untuk high-frequency trading sub-milidetk?
Kapan Serverless Kalah
Lima situasi serverless bukan pilihan optimal. Bukan silver bullet — kenali batasnya.
| Situasi | Masalah | Alternatif |
|---|---|---|
| 1. Cold start 100–500ms | Tidak cocok real-time gaming / trading | EC2 dengan koneksi persisten |
| 2. Execution cap 15 menit | Tidak cocok batch job ETL panjang | Fargate / EC2 spot |
| 3. Debugging kompleks | Local emulation tidak sempurna | Serverless Framework + SAM |
| 4. Vendor lock-in event format | Migrasi ke provider lain sulit | Abstraction layer (Knative) |
| 5. Cost meledak steady high load | 1jt+ req/detik lebih mahal dari EC2 | EC2 reserved/spot |
Serverless optimal: spiky, event-driven, light compute. EC2 optimal: steady, long-running, latency-critical.
Widget: Komparator 5 Service Model
Klik tab On-Prem, IaaS, PaaS, SaaS, FaaS. Perhatikan tumpukan layer yang bergeser dari "Anda kelola" (aksen merah) ke "AWS kelola" (vendor). Geser dari On-Prem ke SaaS untuk melihat trade-off kontrol vs kecepatan.
Ringkasan Kunci Pertemuan 2
4 Model
IaaS · PaaS · SaaS · FaaS — trade-off kontrol vs kenyamanan
Shared Responsibility
Security OF cloud (provider) vs IN cloud (pelanggan) — Capital One pelajaran
Spiky vs Steady
Spiky → Lambda, steady → EC2. Aturan praktis arsitektur.
Tiga lensa P2: 4 model layanan · shared responsibility · spiky vs steady.
Persiapan P3: baca Wittig bab 2; pelajari perbedaan public/private/hybrid cloud. Kuis 5 menit di awal P3 soal 4 model layanan + Capital One case.