Belajar Platform Engineer - App Delivery Platform (PaaS)

#Pendahuluan

Setelah di episode 12 developer bisa meng-create service sendiri lewat portal, muncul pertanyaan lebih dalam: haruskah developer tahu apa itu Dockerfile, Deployment, atau HorizontalPodAutoscaler? Jika jawabannya "tidak", maka kita butuh lapisan abstraksi paling tinggi di platform: app delivery platform (PaaS) — di mana developer hanya membawa kode, dan platform mengurus sisanya.

Mengapa PaaS relevan di 2026? Karena platform engineering belajar dari kegagalan abstraksi sebelumnya: Kubernetes langsung untuk semua orang membuat banyak developer tenggelam dalam detail infrastruktur. PaaS di atas Kubernetes memberikan kembali kebebasan tanpa beban — gaya Heroku yang sudah terbukti, tetapi dengan kontrol dan portabilitas platform internal.

#Dari "Tahu Kubernetes" ke "Tidak Perlu Tahu"

Gradasi abstraksi yang kita lihat sejak episode 3 kini mencapai puncaknya:

PaaS bukan menghilangkan Kubernetes — ia menempatkan Kubernetes di belakang antarmuka yang jauh lebih kecil. Platform team tetap memegang kendali; developer mendapat kebebasan.

#Buildpacks: Build Tanpa Dockerfile

Tahap build PaaS menggunakan buildpacks — mekanisme deteksi otomatis bahasa dan framework, lalu menghasilkan container image yang optimal tanpa developer menulis Dockerfile.

#Cloud Native Buildpacks

Cloud Native Buildpacks (CNB) adalah standar modern (memakai OCI image). Contoh kerja dengan pack:

pack build registry.example.com/payments-api:latest \
  --builder paketobuildpacks/builder-jammy-base \
  --env BP_NODE_RUN_SCRIPTS=build

Yang terjadi di balik layar: buildpack mendeteksi package.json (atau pom.xml, go.mod, dst), memilih runtime, meng-compile, dan menghasilkan image yang otomatis aman (user non-root, image teroptimasi, cache layer yang efisien). Developer tidak perlu tahu base image mana yang benar.

Keuntungan platform: image dihasilkan dengan proses yang sama untuk semua bahasa — platform team bisa menjamin konsistensi, keamanan, dan update base image di satu tempat.

#App Runner: Deploy Tanpa Manifest

Di atas buildpacks ada app runner — lapisan yang menerima "specifikasi sederhana aplikasi" dan mengubahnya menjadi Kubernetes resource yang benar. Alat paling relevan di ekosistem CNCF: Kratos (dari Grafana Labs, di-akuisisi dan jadi bagian CNCF) dan standar Score.

#Score: Manifest Portabel

Score adalah standar open-source untuk mendeskripsikan workload tanpa vendor lock-in. Developer menulis spec abstrak:

apiVersion: score.dev/v1b1
metadata:
  name: payments-api
containers:
  payments-api:
    image: registry.example.com/payments-api:sha
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 256Mi
service:
  ports:
    www:
      port: 8080
  type: LoadBalancer
resources:
  db:
    type: postgres

Satu score.yaml bisa di-render ke berbagai target — Kubernetes, cloud PaaS, bahkan Docker Compose untuk lokal. Developer mendeskripsikan kebutuhan, bukan implementasi.

#Kratos: App Runner untuk K8s

Kratos adalah app runner yang menerima ops (deklarasi) dan mengelola lifecycle lengkapnya di Kubernetes — termasuk:

• Rolling update dengan health check.
• Auto-scaling otomatis.
• Service discovery dan traffic.
• Integrasi secrets dan config.

kratos run -f score.yaml -o manifests/

Perbedaan dengan manifest Kubernetes manual: developer tidak pernah menyentuh kind: Deployment, HPA, atau Service — semuanya di-generate dan dikelola runner. Ini yang membuat PaaS internal terasa seperti "Heroku di atas cluster kita sendiri".

#Membangun App Delivery Platform di Platform Kalian

#Komponen Utama

1. Build service — buildpacks + registri image + signing (episode 7/19).
2. App runner — Kratos (atau sejenisnya) yang mengelola workload.
3. App spec standard — score.yaml sebagai bahasa bersama.
4. Routing — gateway yang mempublish service dengan DNS standar.
5. Observability bawaan — telemetry aktif tanpa konfigurasi (episode 9).
6. Policy — abstraksi tetap harus mematuhi kebijakan platform (episode 16).

#Alur Developer di PaaS

#PaaS dan Platform-as-a-Product

App delivery platform adalah contoh paling jelas platform-as-a-product (episode 2): ia punya pengguna jelas (developer), SLO jelas (deploy time, success rate), dan roadmap jelas (fitur runner apa berikutnya). Pengukurannya langsung:

Jika angka-angka ini tidak membaik setelah PaaS hadir, evaluasi desainnya — bukan hanya "sosialisasi lebih gencar".

#Common Pitfalls

1. PaaS tanpa escape hatch — workload yang butuh kontrol khusus jadi terpaksa "di luar platform" sepenuhnya.
2. Menutup kompleksitas tapi membuka yang lain — app spec yang menuntut developer memahami abstraksi berlapis (konsep baru yang sama rumitnya).
3. Buildpack yang tidak dirawat — base image/buildpack usang → image baru sekaligus membawa kerentanan.
4. Debug yang sulit — developer tidak bisa melihat manifest; pastikan ada cara inspeksi read-only saat troubleshooting.
5. Menjual PaaS sebagai "tanpa YAML" — developer senior tetap butuh melihat apa yang terjadi; beri visibilitas, jangan hanya abstraksi.

#Penutup

Inti yang harus dibawa pulang:

• App delivery platform = buildpacks (build) + app runner (deploy) + spec portabel (Score).
• Developer mendeskripsikan kebutuhan, platform menangani implementasi.
• PaaS bukan menghapus Kubernetes — ia menyembunyikannya di balik antarmuka kecil.
• Ukur time-to-prod, success rate, dan adopsi; K8s langsung tetap jadi escape hatch.

Di episode 14 selanjutnya kita melengkapi PaaS dengan salah satu kebutuhan paling sering diminta developer: data platform — managed databases, data services, dan self-service data yang membuat developer bisa dapat database tanpa tiket dan tanpa menjadi DBA!