Belajar DevOps Engineer - Platform Engineering & IDP

#Pendahuluan

Sejak episode 0, gambaran DevOps adalah tim yang mengotomasi toolchain: CI/CD, container, observability. Semakin banyak tool yang dibuat, semakin besar beban yang diletakkan di pundak developer. Hasilnya paradoks: tool yang dirancang mempercepat justru memperlambat, karena developer harus menguasai Kubernetes, Terraform, dan puluhan tool lain sebelum bisa men-deploy aplikasi.

Platform Engineering adalah respons terhadap masalah ini — dan pada 2026 ia menjadi default operating model bagi tim engineering yang matang. Alih-alih menyerahkan seluruh toolchain, tim platform membangun Internal Developer Platform (IDP): satu lapisan yang menyembunyikan kompleksitas dan menyediakan golden path — jalur yang aman, terstandar, dan terukur untuk men-deploy aplikasi. Di episode ini kalian memahami konsepnya, mengenal Backstage, dan merancang IDP untuk tim kalian sendiri.

#Masalah yang Dibangun oleh DevOps "Klasik"

Ketika setiap tim harus memilih dan mengelola sendiri seluruh stack, muncul beban kognitif:

• Harus paham Kubernetes, Helm, Terraform, CI, observability — sebelum bisa menulis satu baris kode bisnis.
• Setiap aplikasi punya konfigurasi yang sedikit berbeda → operasional jadi sulit diprediksi.
• Tim platform sibuk menjawab pertanyaan yang sama berulang kali, bukan memperbaiki platform.

Developer Experience (DevEx) turun — dan DevEx adalah salah satu KPI paling penting tahun 2026, karena mengukur seberapa cepat ide menjadi kode yang berjalan di produksi. Platform engineering menaikkan DevEx dengan menghapus beban, bukan menambah tool.

#IDP: Lapisan di Atas Toolchain

IDP adalah abstraksi di atas toolchain yang sudah kalian bangun. Developer tidak lagi menyentuh Kubernetes, Terraform, dan pipeline secara langsung — mereka berinteraksi dengan satu antarmuka (portal web, CLI, atau API) yang memicu alur yang sudah disetujui tim platform:

Dari sisi developer, men-deploy aplikasi baru menjadi: pilih template → isi nama dan repo → jalan. Dari sisi platform, setiap aplikasi yang lahir sudah terstandar: pipeline yang sama, konfigurasi yang sama, observability yang aktif sejak hari pertama.

#Golden Path dan Tempat Menyimpang

Prinsip penting IDP bukan "memaksa semua orang satu jalur", melainkan menyediakan jalur emas yang lebih mudah daripada menyimpang. Analoginya jalan raya: jalur utama diaspal, ditandai, dan aman; jalur alternatif boleh dipakai, tetapi harus membayar biaya kognitif dan operasional yang lebih tinggi.

Conway's Law bekerja untuk kalian di sini: struktur IDP menentukan struktur produk. Jika golden path itu cepat, aman, dan terdokumentasi, developer akan memilihnya karena nyaman — bukan karena dipaksa.

#Backstage: Portal Developer Terbuka

Backstage, awalnya dikembangkan Spotify dan di-donate ke CNCF, adalah framework untuk membangun portal developer. Fitur intinya:

• Software Catalog — inventaris tunggal seluruh service, owner, dan dependency-nya.
• Software Templates (Scaffolder) — membuat repo, pipeline, dan environment baru dari template yang disetujui.
• TechDocs — dokumentasi yang hidup berdampingan dengan kode.
• Plugins — integrasi dengan GitHub, Argo CD, Datadog, dan lainnya.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: myapp
  description: Layanan inti billing
  annotations:
    backstage.io/techdocs-ref: dir:.
    github.com/project-slug: username/myapp
spec:
  type: service
  lifecycle: production
  owner: team-billing

Dengan catalog-info.yaml di setiap repository, seluruh sistem kalian terpetakan otomatis — siapa pemiliknya, apa dependensinya, dan dokumen apa yang tersedia.

#Praktik: Merancang Self-Service Platform

Kalian tidak perlu langsung membangun IDP penuh. Mulai dari satu template golden path dan ukur dampaknya:

1. Buat satu Software Template — "node-api": scaffolder membuat repo, Dockerfile, pipeline CI, Helm chart, dan dashboard Grafana dalam satu aksi.
2. Hubungkan dengan pipeline standar — CI build, test, scan (episode 18), lalu deploy via GitOps (episode 14).
3. Beri observability default — setiap service baru otomatis terdaftar di Prometheus dan muncul di catalog.
4. Dokumentasikan di TechDocs — template menghasilkan dokumentasi awal sehingga developer mulai dari konteks, bukan dari nol.
5. Ukur time-to-production — metrik dari request template sampai live di produksi. Itu KPI DevEx kalian.

# Developer menjalankan perintah di portal Backstage
backstage-cli new app myapp --template node-api
# Output: repo dibuat, CI aktif, env dev dideploy, catalog terdaftar

#Pitfall Umum

• Membangun IDP sebelum toolchain stabil — platform di atas fondasi yang sering berubah adalah lapisan yang harus terus dipelihara.
• Golden path yang lebih sulit daripada menyimpang — jika template jelek, developer tetap memilih cara manual; IDP kalian mati sia-sia.
• Mengukur kesuksesan dari jumlah tool, bukan hasil — ukur time-to-production dan frekuensi deployment, bukan jumlah plugin.
• Mengabaikan feedback developer — IDP adalah produk internal; jalankan user research seperti produk eksternal.
• Platform yang mengunci fleksibilitas — sediakan jalur penyimpangan yang terukur, bukan penjara.

#Penutup

Inti yang harus dibawa pulang:

• Platform engineering menyelesaikan masalah beban kognitif developer dengan membangun IDP.
• IDP menyediakan golden path: terstandar, aman, dan lebih mudah dipilih daripada jalur manual.
• Backstage menyediakan catalog, scaffolder, dan TechDocs untuk portal developer.
• DevEx / time-to-production adalah KPI yang harus diukur, bukan sekadar slogan.

Di episode 16 selanjutnya kita masuk ke Secrets Management & Security — Vault/OpenBao, cloud KMS, dan rotasi secret. Setiap praktik yang kalian bangun — CI, GitOps, Terraform, IDP — bergantung pada rahasia yang aman. Tanpa manajemen secret yang baik, seluruh fondasi itu rapuh.