Beberapa tahun terakhir, dunia software engineering pelan-pelan bergeser. Dulu, DevOps jadi kata sakti semua orang pengin “jadi DevOps”, bikin squad DevOps, pasang tool DevOps. Sekarang, kita mulai ketemu batasnya:
- Infrastruktur makin kompleks (Multi-cloud, Hybrid).
- Time-to-market makin gila cepatnya.
- Developer makin pengin “tinggal fokus ke kode, jangan bikin hidup susah dengan konfigurasi rumit”.
Dari kombinasi ini lahir satu disiplin baru: Platform Engineering. Tapi seperti biasa, begitu jadi buzzword, muncul masalah baru: banyak inisiatif platform engineering yang berhenti di tengah jalan.
Kenapa bisa begitu? dan gimana caranya bikin platform yang beneran dipakai dan bukan cuma jadi repo cantik di internal wiki?
Saya ingin mengajak melihatnya dari 3 sisi utama + 1 pandangan ke masa depan,,,,, cekidottt
Bagian Pertamax : Kenapa Banyak Inisiatif Platform Engineering Gagal?
Banyak tim platform punya cerita mirip: “Kita sudah bikin platform rapi banget, tapi kok developer tetap pakai cara lama?”
Di atas kertas, platformnya keren. Di lapangan, adopsinya minim.
Di sinilah muncul yang sering saya sebut :
1. The Adoption Paradox
Tim platform merasa:
“Ini solusi ideal. Sudah standar, automated, pakai tool modern. Harusnya semua orang senang.”
Tapi kenyataannya:
- Developer tetap pakai skrip lama
- Deploy manual masih hidup
- Tiket ke tim Ops tidak berkurang signifikan
Kenapa?
Biasanya karena tidak nyambung dengan alur kerja developer atau terlalu preskriptif. Platform memaksa cara kerja baru yang kaku tanpa fleksibilitas. Developer merasa kehilangan freedom. Mereka tidak melihat value: "Gue harus belajar hal baru, tapi manfaat nyatanya mana?"
👉 Ingat, Developer bukan menolak perubahan. Developer menolak friksi. Kalau platform bikin hidup mereka lebih ribet, mereka akan balik ke cara lama. Sesimpel itu.
2. Platform Harus Dipikirkan sebagai Produk, Bukan Proyek
Kesalahan umum: menganggap platform sebagai proyek sekali jadi. Padahal, platform itu produk internal. Artinya:
- Butuh adanya product manager
- Punya roadmap yang jelas
- Ada riset pengguna (developer)
- Ada feedback loop yang aktif
- Punya metrik adopsi & kepuasan
Kalau pakai analogi:
- Platform engineering = buka warung makan di dalam kantor.
- Developer = pelanggan.
- Tim platform = koki + manajer resto.
Hal yang sama berlaku buat platform. Bukan soal “Pakai Kubernetes dan Service Mesh paling canggih”, tapi “Developer sekarang deploy dan debugging lebih cepat nggak? Lebih percaya diri nggak?”
3. Membangun Trust Architecture
- Transparan: Kalau ada issue, komunikasikan.
- Reliable: Kalau platform sering error, developer akan bikin "jalan tikus" di luar platform.
- Empatik: Error message yang manusiawi, bukan log mesin yang bikin pusing.
🧠 Bayangkan platform itu seperti jembatan baru.Kalau sejak awal kelihatan ringkih dan pernah hampir roboh, orang akan ogah lewat lagi.Sekali trust hilang, butuh waktu lama untuk pulihkan.
Bagian Keduax : Apa Itu Platform Engineering?
Sekarang kita masuk ke definisi dasarnya.
Platform engineering adalah disiplin yang mendesain, membangun, dan merawat Internal Developer Platform (IDP) supaya developer bisa kerja lebih produktif, dengan kompleksitas teknis yang lebih sedikit.
Fokusnya:
Developer Experience (DevEx). Bukan cuma “bikin infra jalan”, tapi “bikin infra jadi enak dipakai”.
1. Komponen Utama Platform Engineering
- Abstraksi Infrastruktur Developer nggak harus paham detail Kubernetes atau konfigurasi BGP networking yang rumit. Mereka cukup bilang: “Saya butuh web service dengan database kecil untuk QA.” Platform yang menerjemahkan kebutuhan itu jadi resource nyata.
- Golden Paths Ini adalah alur kerja standar yang aman dan terbukti. Contoh :
- Template microservice yang sudah pre-configured.
- Network Automation: Developer tidak perlu kirim tiket "Buka Port Firewall". Golden path otomatis mengatur Security Group atau Network Policy yang aman sesuai standar kantor.
- Setup monitoring default. Jalur emas ini seperti jalan tol: Cepat, Aman, dan ada Rambu-rambu.
- The Missing UI: Internal Developer Portal Seringkali kita punya API canggih, tapi developer malas pakai CLI. Di sinilah peran Portal (seperti Backstage atau Port). Ini adalah "etalase" warung makan kita. Tempat developer melihat katalog service, dokumentasi, dan status sistem dalam satu layar.
- Self-Service Developer bisa provision environment, deploy, restart service, hingga rollback sendiri tanpa harus buka tiket ke tim Ops/Network.
2. Dampak Nyata Platform Engineering
Kalau platform engineering dilakukan dengan benar, kamu akan melihat:
- ⏱ Time-to-market lebih cepat : Setup environment dan deploy tidak lagi makan waktu berhari-hari.
- 👨💻 Developer fokus ke coding, bukan infra : Mengurangi cognitive load developer soal infrastruktur.
- 💰 Efisiensi Biaya (FinOps): Dengan Golden Path, kita bisa membatasi resource (misal: dev env maksimal 2 vCPU). Developer tidak sembarangan spin-up instance raksasa yang bikin tagihan cloud jebol.
- 🧯 Beban tim Ops/SRE berkurang : Kurangi tiket manual ("tolong restart server"), perbanyak kerjaan strategis.
Intinya: platform engineering bukan tentang teknologi paling baru, tapi tentang menghilangkan friction yang bikin developer lelah.
Bagian Ketigax : GitOps & Masa Depan Platform Engineering
Kalau bicara platform modern, nama GitOps (ArgoCD/Flux) hampir pasti nongol. GitOps membawa kita ke era di mana infrastruktur dikelola secara deklaratif via Git, dengan Git sebagai single source of truth, audit trail otomatis, dan deployment yang terprediksi.
Tapi semakin besar skala organisasi, semakin kelihatan batas GitOps tradisional. Mari pecah jadi tiga bagian.
1. Hal yang Sudah Diselesaikan GitOps
GitOps membawa banyak manfaat:
- ✅ Environment promotion yang lebih aman
Perpindahan dari dev → staging → prod lewat pull request, bukan klik manual.
- ✅ Single source of truth
Semua konfigurasi ada di Git: jelas, versioned, bisa di-review.
- ✅ Audit trail otomatis
“Siapa deploy apa, kapan, dan bagaimana?” Jawabannya ada di history Git.
- ✅ Separation of concerns yang lebih rapi
Bisa pisah repo/folder untuk: app, infra, policy, dsb.
- ✅ Deployment lebih terprediksi dan bisa di-observe
Tools seperti ArgoCD/Flux bikin status sinkronisasi Git ↔ cluster jadi transparan.
2. Tantangan GitOps Ketika Skala Membesar
Namun, saat organisasi masuk ke level multi-cloud dan multi-cluster, GitOps murni mulai kewalahan:
- 😵💫 Multi-repo & multi-cluster complexity
Satu aplikasi, banyak environment, banyak cluster, banyak repo. Tiba-tiba orang lebih sering mengurus struktur repo daripada value bisnis.
- 🔐 Secret management yang tricky
Menyimpan secret di Git = bahayaEnkripsi = perlu urus kunciIntegrasi dengan vault eksternal = nambah komponen & kompleksitas
- 🧰 Banyak tool tambahan
Helm, Kustomize, ArgoCD/Flux, OPA, Secrets manager, dsb.Semua bagus, tapi bikin learning curve naik dan operasi makin berat.
- 🧵 GitOps tidak cukup untuk orkestrasi proses kompleks
Kalau alurnya simpel: “Apply YAML → jalan”, oke.Tapi kalau:“Provision infra → register ke CMDB → pasang monitoring → kirim notifikasi ke Slack → update tiket”….. butuh sesuatu yang lebih dari sekadar sync Git ↔ cluster.
3. Solusi Declarative Control Planes
Di titik ini, muncul pendekatan baru seperti Crossplane atau Kubernetes Resource Orchestrator (KRO). Konsep besarnya: “Segala sesuatu adalah resource deklaratif yang di-manage oleh control plane.”
Bayangkan Developer cukup bikin satu objek Application. Di balik layar, Control Plane yang akan:
- Provision Infratruktur (On-prem/Cloud).
- Setup Networking (DNS/Load Balancer).
- Deploy App
- Inject Secrets ke Vault.
- Pasang Monitoring.
- Set Policy
- Integrasi ke sistem lain
Apa yang bikin control plane menarik?
- 🔌 API abstrak untuk developer
Developer berinteraksi lewat API/CRD yang sesuai bahasa domain mereka, bukan bahasa tool.
- 🌩 Lintas cloud & environment
Satu control plane bisa atur resource di AWS, GCP, on-prem, dsb.
- 🧠 Workflow kompleks bisa dideklarasikan
“Kalau ini siap → jalankan itu → kalau error → rollback + kirim alert.”
- 🧭 Governance lebih mudah
Policy bisa dipasang di level API (mis. semua
Databaseharus punya label owner, environment, dsb).
GitOps akan tetap relevan — terutama sebagai cara menyimpan deklarasi & audit trail. Tapi perannya akan jadi bagian dari orkestrasi yang lebih besar, bukan satu-satunya bintang utama.
Bagian Keempat : Platform Engineer Lifecycle
Biar lebih kebayang secara end-to-end, kita nggak lagi lihat platform engineering sebagai bukan proyek sekali jalan, tapi sebagai siklus hidup (lifecycle) yang terus berputar.
Kurang lebih, lifecycle-nya bisa kamu bayangkan seperti ini:
Discover → Design → Build & Pilot → Launch & Enable → Operate & Observe → Evolve & Iterate
Mari kita bedah satu per satu.
- Discover – Mulai dari Masalah Developer
Ini fase yang sering dilompati, padahal paling krusial. Ngobrol sama tim developer & tech lead. Apa yang bikin mereka lambat? Tahapan mana yang paling sering bikin stres? Pekerjaan apa yang selalu diulang dan bisa diotomasi? Jangan berasumsi!!!
Di fase Discover, platform engineer lebih mirip product researcher daripada infra engineer.
- Design – Rancang Platform & Golden Paths
Tentukan abstraksi yang pas (jangan terlalu kaku, jangan terlalu longgar). Setelah tahu masalahnya, baru masuk ke fase desain.
Di sini, platform engineer berperan sebagai arsitek + product designer: merancang “jalan tol” yang nanti akan dilalui developer.
- Build & Pilot – Bangun MVP dan Cari Quick Wins
Ini fase “eksekusi teknis”, tapi tetap diikat oleh tujuan yang jelas. Selesaikan 1 masalah besar dulu dengan tim pilot. Tujuan fase ini bukan bikin platform sempurna, tapi menunjukkan bahwa:
“Platform ini bisa bikin hidup developer lebih mudah dalam waktu dekat.”
- Launch & Enable – Rilis dan Edukasi
Marketing internal! Bikin dokumentasi, demo di townhall, dan support channel. Tanpa edukasi, platform secanggih apapun akan mangkrak. Begitu MVP cukup matang, masuk ke fase launch.
Tanpa enablement, developer akan merasa platform “dipaksa masuk”, bukan “ditawarkan untuk membantu”.
- Operate & Observe – Menjalankan dan Mengamati
Pantau adopsi. Fitur mana yang sering dipakai? Mana yang bikin error? Gunakan data untuk perbaikan.
Di fase ini, platform engineer berperan sebagai SRE (menjaga reliabilitas) dan Analis produk (membaca data penggunaan), tujuannya: bukan cuma “platform-nya uptime”, tapi juga “platform-nya benar-benar dipakai”.
- Evolve & Iterate – Belajar, Putar Lagi Siklusnya
Lifecycle tidak berhenti setelah platform “jadi”. Terus berinovasi. Teknologi berubah, kebutuhan developer juga berubah. Justru di sini siklusnya kembali lagi ke Discover, tapi dengan konteks baru. Yang dilakukan di fase ini:
- Mengumpulkan feedback rutin dari developer
- Memprioritaskan backlog : fitur baru, perbaikan UX, dan Merapikan hal yang dulu “sementara tapi ternyata kepakai terus”
- Mengevaluasi apakah saatnya: menambah abstraksi baru, mengadopsi control plane yang lebih canggih, mengubah golden path karena ada cara yang lebih baik
Platform yang sehat bukan yang sekali jadi terus dibiarkan, tapi yang terus berevolusi bersama kebutuhan developer dan bisnis.
Bagian Kelimax : Penutup
Kita tidak bisa bicara masa depan tanpa menyinggung AI. Masa depan Platform Engineering akan sangat terbantu oleh Generative AI.
Bayangkan "Conversational Infrastructure": Interaksi developer dengan platform mungkin tidak lagi melulu lewat GUI atau YAML, tapi lewat Natural Language.
Developer: "Buatkan environment staging untuk service Payment, tapi pakai database yang di-anonymize datanya." Platform (AI Agent): "Siap. Environment staging sedang dibuat menggunakan Golden Path v2. Data akan diambil dari snapshot minggu lalu dengan masking PII. Estimasi selesai: 5 menit."
Ini akan menurunkan barrier to entry secara drastis. Platform Engineer akan bertugas melatih model dan menjaga guardrails agar AI tidak melakukan hal berbahaya, sementara AI membantu developer melakukan tugas repetitif.
Kita berada di fase menarik dalam dunia software engineering. Bisnis butuh cepat, infrastruktur makin rumit, dan developer butuh ketenangan untuk coding.
Platform engineering hadir sebagai jembatan. Bukan jembatan biasa, tapi jembatan yang dibangun dengan empati, dirawat layaknya produk, dan didukung teknologi modern (GitOps, Control Planes, AI).
Kalau kita berhasil membangun platform yang: ✅ Developer suka ✅ Developer percaya ✅ Developer merasa terbantu setiap hari
… maka platform engineering bukan sekadar tren, tapi akan jadi fondasi utama cara kita membangun software di masa depan. 🚀