Platform as a Service — DevOps

PaaS: Deploy Tanpa Kelola Server PaaS (Platform as a Service) memungkinkan kamu fokus pada kode tanpa mengurus server, OS, atau infrastructure. Push kode…

PaaS (Platform as a Service) adalah tempat kamu cukup menyerahkan kode, lalu platform yang mem-build, menjalankan, me-restart, dan menambah salinannya saat kamu minta. Gak ada SSH, apt upgrade, atau systemd. Bayangin tinggal di apartemen servis. Kamu cuma membawa barang (kode). Listrik, air, kebersihan, dan perbaikan diurus pengelola. Mau tambah kamar, tinggal bilang. Tapi dinding gak boleh dibongkar (kontrol terbatas), barang yang kamu taruh di lantai dibuang petugas setiap kamar dibersihkan, dan tarif per malamnya lebih mahal dari kontrakan. Di pelajaran ini catatan-api yang sama dipindah dari web-1 ke Heroku, PaaS yang mempopulerkan cara kerja ini. Railway, Render, dan Fly.io mirip.

🧪 Tebakan cepat: catatan-api sudah jalan di Heroku. Kamu upload satu lampiran (disimpan ke folder storage/lampiran, sama seperti di web-1), lalu git push perubahan kecil. Apakah lampiran tadi masih bisa dibuka? Tebak dulu, jawabannya ada di bagian "Disk yang selalu dikosongkan".

Deploy dengan git push

Di repo catatan-api cukup tambah satu file bernama Procfile (tanpa ekstensi):

web: node app.js

Artinya: proses bernama web dijalankan dengan node app.js, dan proses web itulah yang menerima request HTTP. Lalu:

$ heroku create catatan-api
$ git push heroku main
remote: -----> Building on the Heroku-24 stack
remote: -----> Determining which buildpack to use for this app
remote: -----> Node.js app detected
...
remote: -----> Build succeeded!
remote: -----> Discovering process types
remote:        Procfile declares types -> web
...
remote:        Released v3
remote:        https://catatan-api-3f9a1c2b4d5e.herokuapp.com/ deployed to Heroku

PORT dan config vars

Di web-1, catatan-api mendengar port 3000 dan nginx meneruskan ke sana. Di PaaS, platform yang menentukan port lewat environment variable PORT:

const port = process.env.PORT || 3000;
app.listen(port);

Kalau app tetap memakai app.listen(3000), router gak pernah bisa menyambung, dan setelah 60 detik log-nya berisi Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch.

Secret dan alamat database jadi config vars (cara mengelolanya ada di pelajaran Environment Variables & Secrets):

$ heroku addons:create heroku-postgresql:essential-0
$ heroku config:set JWT_SECRET=...

Add-on Postgres otomatis mengisi DATABASE_URL. Tanpa itu, catatan-api crash saat start, dan tiap request dijawab router dengan code=H10 desc="App crashed" status 503.

Disk yang selalu dikosongkan

Tiap instance di Heroku disebut dyno, dan disk-nya ephemeral: semua file yang ditulis app hilang setiap dyno di-restart. Dyno di-restart setiap deploy, setiap perubahan config, dan kira-kira sekali sehari. Jadi lampiran yang disimpan ke storage/lampiran hilang begitu kamu git push, dan GET ke lampiran itu dijawab 404. Itu jawaban tebakannya.

Ada masalah kedua: tiap dyno punya disk sendiri. Dengan 2 dyno, router membagi request secara acak, jadi lampiran yang tersimpan di web.1 kadang 404 karena request-nya mendarat di web.2. Jalan keluarnya sama untuk keduanya: simpan file di object storage seperti S3 atau R2 (pelajaran Object Storage), dan biarkan disk dyno cuma untuk file sementara.

Scale: tambah dyno

$ heroku ps:scale web=2
Scaling dynos... done, now running web at 2:Standard-1X

Satu perintah, dan dua salinan catatan-api jalan di belakang router. Ini cuma aman kalau app-nya stateless: gak menyimpan apa pun di memori atau disk dyno yang dibutuhkan request berikutnya. Session dan cache disimpan di Postgres atau Redis.

Kapan PaaS gak murah lagi

Harga di tabel ini contoh untuk berhitung, bukan harga terkini:

Kebutuhan PaaS (contoh) VPS (contoh)
Mulai: 1 instance kecil + Postgres $7 + $5 = $12 per bulan VPS 1 GB $6, plus jam kerjamu mengurus server
Ramai: 4 dyno 512 MB + Postgres 4 × $25 + $20 = $120 per bulan 2 VPS 4 GB = $48 per bulan

Per GB RAM, PaaS bisa beberapa kali lipat lebih mahal dari VPS. Sebagai gantinya kamu gak mengurus OS, patch, TLS, restart, atau pipeline deploy. Selain biaya, kontrolnya terbatas: gak ada akses root, gak bisa memasang software sistem sesukamu, disk ephemeral, dan Heroku memutus request yang lebih dari 30 detik.

PaaS paling pas untuk tim kecil tanpa DevOps engineer yang mau fokus ke produk, untuk MVP, dan side project. VPS (atau IaaS lain) mulai lebih masuk akal saat tagihan PaaS lebih besar dari waktu yang kamu hemat, atau saat butuh kontrol penuh.

Di latihan: memilih platform

recommendPlatform({ type, framework, needsDatabase, budget }) memakai aturan latihan berikut, dicek berurutan dan berhenti di aturan pertama yang cocok:

  1. type adalah "static": "Netlify" (hosting situs statis)
  2. framework adalah "nextjs": "Vercel" (pembuat Next.js)
  3. needsDatabase true dan budget "low": "Railway"
  4. needsDatabase true dan budget "high": "AWS Elastic Beanstalk", PaaS-nya AWS
  5. selain itu: "Render"

Urutan penting: { type: "ssr", framework: "nextjs", needsDatabase: true, budget: "low" } cocok dengan aturan 2 dan 3, tapi aturan 2 dicek lebih dulu, jadi hasilnya "Vercel".

⚠️ Jebakan yang sering ketemu

TL;DR: PaaS (Heroku, Railway, Render) menjalankan kode dari git push: platform mengenali bahasanya dari file seperti package.json, membaca Procfile (web: node app.js), lalu merilis versi bernomor. App harus mendengar process.env.PORT, dan secret serta DATABASE_URL jadi config vars. Disk dyno ephemeral: file hilang tiap deploy dan restart, dan tiap dyno punya disk sendiri, jadi upload disimpan di object storage. heroku ps:scale web=2 menambah instance, asal app-nya stateless. Kekurangan utamanya biaya lebih tinggi dan kontrol terbatas, jadi PaaS paling cocok untuk tim kecil tanpa DevOps engineer yang mau fokus ke produk.

Yang akan kamu pelajari