Belajar Platform Engineer - Self-Service Developer Experience

#Pendahuluan

Setelah sebelas episode membangun fondasi teknis (K8s, GitOps, IDP, CI/CD, observability, secrets, cost), ada satu pertanyaan yang menentukan apakah semua itu benar-benar dipakai: bagaimana developer mendapatkan sesuatu dari platform? Jika jawabannya "buat tiket ke tim platform", maka kita baru memindahkan masalah, bukan menyelesaikannya. Episode ini membahas self-service — puncak pengalaman platform engineering.

Mengapa self-service adalah tujuan akhir? Ingat mindset produk di episode 2: pengguna (developer) memilih berdasarkan kemudahan. Platform yang butuh tiket selalu lebih lambat daripada cara lama yang sudah biasa. Self-service bukan kemewahan — ia adalah mekanisme adopsi. Semakin bisa dikerjakan sendiri, semakin besar platform dipakai, dan semakin terkendali cara kerja semua orang.

#Prinsip Self-Service yang Benar

Self-service bukan berarti "kasih semua orang akses ke semua". Justru sebaliknya. Empat prinsip:

1. Self-service untuk jalan yang disetujui — developer bebas di golden path; jalan menyimpang butuh review.
2. Default harus aman — apa pun yang bisa dibuat sendiri, dibuat dengan konfigurasi yang benar secara default.
3. Tanpa approval untuk hal berulang — bootstrap service baru tidak perlu ditandatangani manusia.
4. Approval hanya untuk dampak besar — production access, kenaikan resource besar, ekspos ke publik.

Dengan prinsip ini, self-service mengurangi beban tim platform dan menambah kecepatan developer — bukan salah satu saja.

#Request Workflows: Dari "Tiket" ke "Alur"

Kata kuncinya adalah mengubah tiket (ad-hoc, menunggu manusia) menjadi alur (deterministik, terotomasi). Perbedaan mendasar:

Semua alur ini kita sudah punya bahannya: template scaffolder (episode 6), modul Terraform (episode 5), RBAC berbasis group (episode 4), dan policy-as-code (episode 5/10). Self-service adalah cara menyatukan semuanya menjadi alur yang bisa diklik developer.

#Membedah Satu Flow: Bootstrap Service Baru

Mari kita rancang flow paling penting: developer membuat service baru dari nol.

#Langkah 1: Scaffold di Portal

Developer membuka Backstage → klik "Create Service" → mengisi form (nama, owner, bahasa). Template (episode 6) menghasilkan:

• Repository GitHub dengan struktur project.
• catalog-info.yaml yang mendaftarkan service di catalog.
• Pipeline CI/CD yang terhubung.

#Langkah 2: Infrastruktur Lahir Otomatis

Pipeline (episode 7) memanggil modul Terraform yang membuat:

module "service_bootstrap" {
  source = "./modules/service-bootstrap"
  service = "payments-api"
  team    = "payments"
  environment = "dev"
  # namespace, quota, RBAC, database, secrets path
  # semuanya lahir dari satu panggilan
}

#Langkah 3: Policy Menjaga

Policy-as-code (episode 16) memverifikasi bahwa yang lahir sesuai standar — namespace ber-label, quota ada, secrets path sesuai convention. Jika melanggar, deployment ditolak dengan pesan jelas.

#Hasil: Semua otomatis, tanpa manusia

Satu klik, nol manusia di tengah. Inilah self-service yang sebenarnya.

#Approval Flow: Kapan dan Bagaimana

Approval tetap diperlukan untuk keputusan berdampak besar. Kuncinya: bukan jangan ada approval, tapi approval yang tepat sasaran.

#Matriks Approval

Perhatikan polanya: keputusan berulang tidak butuh approval; keputusan langka dan berisiko butuh. Approval di-backend oleh policy bukan manusia jika memungkinkan.

#Implementasi Approval yang Menyatu

Approval paling baik disatukan ke alur yang sudah ada — misalnya PR ke repo GitOps. "Request production akses" = membuat PR ke repo config → reviewer dari security → merge → otomatis berlaku:

# PR ini, setelah di-review, menjadi:
apiVersion: v1
kind: ServiceAccount
metadata:
  name: payments-release
  namespace: team-payments-prod
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: payments-release
  namespace: team-payments-prod
subjects:
  - kind: ServiceAccount
    name: payments-release
    namespace: team-payments-prod
roleRef:
  kind: Role
  name: team-operator
  apiGroup: rbac.authorization.k8s.io

Keuntungannya: semua request dan approval terekam di git, auditable, bisa di-revert, dan mengikuti alur yang sama dengan kode. Tidak ada lagi "saya approve di chat".

#Memberi Dukungan: Error yang Membantu

Self-service tanpa dukungan yang baik adalah resep frustrasi. Ketika flow gagal, developer butuh tahu apa yang salah dan bagaimana memperbaikinya. Tiga lapisan dukungan:

1. Error message yang jelas di portal — "Quota team kalian hampir habis: 85/100 CPU requests. Minta kenaikan lewat PR ke repo platform".
2. Runbook yang tertaut — setiap error punya link ke panduan penyelesaian.
3. Feedback channel yang nyata — tempat developer melaporkan "platform membuatku gagal" dan tim platform merespons.

#Mengukur Self-Service

Self-service harus diukur — adopsi adalah KPI platform (episode 22):

#Common Pitfalls

1. Self-service tanpa guardrails — semua orang bisa buat semua tanpa batas; biaya dan risiko meledak.
2. Approval di setiap langkah — developer lebih memilih cara lama daripada self-service yang macet.
3. Flow yang tidak pernah diuji — platform team membangun flow tapi tidak pernah menjalankannya dari sudut pandang developer.
4. Dokumentasi yang tidak sinkron — flow berubah, dokumen tidak, developer tersesat.
5. Self-service sebagai pengganti komunikasi — tetap butuh forum, office hours, dan changelog; self-service bukan pengganti hubungan manusia.

#Penutup

Inti yang harus dibawa pulang:

• Self-service adalah mekanisme adopsi, bukan sekadar kemudahan.
• Ubah tiket menjadi alur deterministik yang lahir dari template + modul + policy.
• Approval tetap ada, tapi hanya untuk dampak besar — dan lewat git, bukan lisan.
• Error message, runbook, dan feedback channel adalah bagian dari produk.
• Ukur dan uji golden path secara berkala agar tidak membusuk.

Di episode 13 selanjutnya kita menaikkan abstraksi satu tingkat lebih tinggi: app delivery platform (PaaS) — membangun aplikasi tanpa menyentuh infra sama sekali, dengan buildpacks dan app runners yang menyembunyikan Kubernetes sepenuhnya. Self-service jadi lebih dari sekadar alur — menjadi pengalaman tanpa memahami infra!