Belajar Platform Engineer - Golden Paths & PaaS

#Pendahuluan

Setelah di episode 2 kita membangun mindset produk, saatnya mengubahnya menjadi abstraksi yang nyata. Konsep pertama yang akan kita bangun adalah golden paths — jalur utama yang direkomendasikan (dan di-enforce) bagi developer untuk men-deploy aplikasi. Golden path adalah tempat di mana mindset produk bertemu dengan konfigurasi: ia adalah "produk" terkecil yang bisa dipakai developer tanpa memahami seluruh kompleksitas di belakangnya.

Mengapa golden path adalah fondasi platform? Karena hampir semua komponen lain — portal, CI/CD platform, service mesh, observability — bekerja untuk mendukung satu atau beberapa golden path. Tanpa golden path, kalian hanya punya koleksi tool yang saling terpisah. Dengan golden path, tool-tool itu menjadi satu pengalaman terpadu.

#Apa Itu Golden Path?

Golden path adalah pola yang paling direkomendasikan, terstandarisasi, dan terdukung penuh untuk membangun dan men-deploy aplikasi di atas platform. Ia menjawab satu pertanyaan developer: "Apa cara paling aman, paling cepat, dan paling sesuai standar untuk deploy aplikasi saya?"

Golden path bukan larangan. Ia adalah rekomendasi yang diinvestasikan: tim platform merawat tooling, template, dan dokumentasinya sehingga mengikuti jalur ini selalu lebih mudah daripada menyimpang. Kunci adopsi ada di kalimat terakhir — jika jalur alternatif lebih mudah, developer akan memilihnya.

#Karakteristik Golden Path yang Baik

#Dari Template ke Golden Path: Tingkatan Abstraksi

Golden path bisa diimplementasikan pada berbagai tingkat kedalaman. Ini adalah spektrum — tim yang berbeda akan memilih posisi yang berbeda:

• Level 1 — Dokumentasi: dokumen "cara deploy" yang manusiawi. Paling murah, tapi paling mudah diabaikan.
• Level 2 — Template scaffolding: struktur project dan konfigurasi lahir otomatis (Backstage scaffolder). Developer mulai dari kode, bukan konfigurasi.
• Level 3 — Pipeline template: pipeline CI/CD yang sudah jadi, terhubung ke golden path deploy. Developer tinggal push.
• Level 4 — PaaS / app runner: abstraksi hingga developer tidak melihat Kubernetes sama sekali. Ini adalah tingkat yang sedang tren di 2026 (dibahas detail di episode 13).

Golden path kalian bisa berhenti di level mana pun. Yang penting: pilih tingkat yang sesuai dengan kematangan dan kapabilitas tim kalian — bukan tingkat tercanggih yang pernah dibaca.

#Komponen Golden Path dalam Praktik

Satu golden path yang baik biasanya mengemas beberapa komponen sekaligus:

#1. Template Project (Scaffolder)

Template menentukan struktur project. Di Backstage, template didefinisikan sebagai YAML yang bisa men-scaffold repository GitHub lengkap dengan konfigurasi:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: springboot-service
  title: Spring Boot Service
  description: Golden path untuk service Spring Boot
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Informasi Service
      properties:
        component_id:
          type: string
          description: Nama komponen
        owner:
          type: string
          description: Tim pemilik
  steps:
    - id: fetch-template
      action: fetch:template
      input:
        url: ./skeletons/springboot
        values:
          name: ${{ parameters.component_id }}
    - id: publish
      action: publish:github
      input:
        repoUrl: ${{ parameters.repoUrl }}
    - id: register
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps['publish'].output.repoContentsUrl }}

#2. Infrastructure Scaffolding

Bersamaan dengan kode, golden path menyediakan infrastruktur yang dibutuhkan — namespace, database, secrets. Di episode 5 kita akan melakukan ini dengan Terraform + Crossplane, tapi konsepnya sama: infrastruktur lahir dari template, bukan dari tiket.

#3. Pipeline yang Terhubung

Template berakhir pada pipeline CI/CD yang otomatis terhubung ke deployment:

name: Deploy via Golden Path
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy ke golden path
        run: score-k8s run -f score.yaml -o manifests/

Kita akan membangun pipeline seperti ini secara utuh di episode 7.

#Praktik: Golden Path Pertama

Mari rancang golden path pertama dengan pola yang bisa direplikasi ke tim mana pun. Kita tidak perlu tools lengkap dulu — cukup struktur keputusannya:

1. Pilih workload pertama yang paling sering dideploy (misalnya service HTTP sederhana).
2. Tentukan stack default (bahasa, framework, base image) — hanya satu pilihan untuk memulai.
3. Tentukan mekanisme deploy (misalnya: push ke branch main → pipeline build → deploy ke namespace otomatis).
4. Tentukan observability bawaan (metrics endpoint + logging terstruktur, aktif tanpa konfigurasi).
5. Tentukan escape hatch (cara menyimpang, terdokumentasi dan di-review).

Contoh ringkas dalam satu halaman "kontrak":

Golden Path: Service HTTP (Node.js/TypeScript)
- Repo : github.com/org/{service} dari template backstage
- Deploy : push ke main -> CI build -> deploy otomatis ke prod (namespace {service})
- DNS  : https://{service}.apps.example.com (TLS otomatis)
- DB   : provisioning otomatis via Cloud SQL (episode 14)
- O11y : Prometheus metrics di /metrics + logs JSON (episode 9)
- Sekuriti : secrets via Vault (episode 10), image signed (episode 19)
- SLO  : 99.9% availability, deploy success 95%

Setelah kontrak ini jelas, semua episode berikutnya tinggal mengisi kotak-kotak di atas dengan implementasi nyata.

#Common Pitfalls

1. Golden path yang terlalu fleksibel — setiap tim minta satu opsi tambahan, dan akhirnya "satu jalur" berubah jadi 10 cabang yang tak terawat.
2. Template tanpa dokumentasi — developer yang bertanya "kok template-nya seperti ini?" tidak menemukan jawaban, lalu menganggap platform rusak.
3. Golden path yang tidak lebih mudah — jika langkah manual (staging kubectl apply dari laptop) masih lebih cepat, developer akan memilihnya.
4. Membangun semua sekaligus — mencoba golden path lengkap (template + pipeline + DB + mesh) sebelum yang sederhana terbukti dipakai.

#Penutup

Inti yang harus dibawa pulang:

• Golden path = jalur utama yang direkomendasikan dan di-enforce, lebih mudah diikuti daripada disimpangi.
• Tingkat abstraksi: dokumentasi → scaffolding → pipeline → PaaS. Pilih sesuai kematangan tim.
• Golden path mengemas template, infrastruktur, pipeline, dan observability menjadi satu pengalaman.
• Tulis kontrak golden path satu halaman sebelum menulis kode.

Di episode 4 selanjutnya kita akan membangun fondasi teknis di bawah golden path: Kubernetes platform dasar — cluster provisioning, namespaces, quotas, dan RBAC yang aman untuk multi-team. Inilah fondasi yang akan menopang semua abstraksi yang kita rancang!