- Sebagai disiplin organisasional yang membangun dan mengoperasikan produk internal dengan insinyur internal sebagai penggunanya, ini pada dasarnya merupakan ranah yang berbeda dari sekadar rebranding DevOps atau pengelolaan klaster Kubernetes
- Menurut laporan DORA 2025, 90% organisasi telah mengadopsi setidaknya satu platform internal, dan kualitas platform muncul sebagai indikator yang secara langsung memprediksi apakah alat AI dapat menciptakan nilai
- Saat cloud dan open source menyediakan primitive yang nyaris tak terbatas, alasan keberadaan utamanya adalah menyelesaikan masalah "rawa over-generalisasi (over-general swamp)" di mana tiap tim membangun pipeline masing-masing
- Memperlakukan platform sebagai produk sungguhan, serta memiliki abstraksi perangkat lunak, registry metadata, dan SLO operasional untuk developer median, adalah syarat struktural keberhasilan
- Platform yang baik bekerja begitu alami hingga developer lupa bahwa ia ada, sementara platform yang buruk membuat alat AI memperbesar kekacauan dan platform yang baik memperbesar throughput
Mengapa platform engineering ada
-
Rawa Over-Generalisasi (Over-General Swamp)
- Saat cloud dan OSS menyediakan primitive yang nyaris tak terbatas seperti queue, object store, database, CI runner, dan service mesh, tiap tim aplikasi akhirnya membuat pilihan yang berbeda-beda
- Setahun kemudian, semua layanan berubah menjadi rawa glue code di mana masing-masing punya pipeline deployment sendiri, logika retry sendiri, konvensi monitoring sendiri, dan binding IAM yang sedikit salah
- Ledakan jumlah pilihan dan ekspektasi operasional yang makin tinggi (uptime 24/7, keamanan, compliance, pengelolaan biaya) adalah dua penyebab yang menciptakan rawa ini
- Dalam proyek landing zone nyata, ada kasus 20 tim menemukan ulang modul Terraform yang hampir identik untuk VPC, IAM, dan alert anggaran, masing-masing dengan bug yang berbeda
-
Empat hal yang benar-benar dilakukan platform engineering
- Membatasi primitive yang dilihat developer agar mereka hanya menggunakannya melalui cara yang telah dikurasi
- Menyerap pekerjaan plumbing yang berulang ke dalam layanan bersama untuk mengurangi glue code per aplikasi
- Saat primitive dasar berubah, tim platform menanganinya sekali saja sehingga biaya migrasi dipusatkan
- Mendukung developer agar dapat mengoperasikan sendiri apa yang mereka bangun tanpa harus menjadi pakar kernel Linux
- DevOps adalah "developer harus memiliki ownership atas operasi", sedangkan platform engineering adalah "kami akan menyediakan alat yang baik untuk operasi itu sebagai produk sungguhan"
- Bahkan pada halaman kapabilitas DORA 2025, ini didefinisikan sebagai disiplin sosioteknis (sociotechnical), bukan kategori alat
Lima Pilar (Pillars)
-
Pendekatan Produk yang Dikurasi (Curated Product Approach)
- Secara sengaja memutuskan apa yang didukung platform dan apa yang tidak
- Saat tim menginginkan Kafka alih-alih Pub/Sub, responsnya bukan "tautan dokumentasinya di sini" melainkan penjelasan tentang "cakupan dukungan, alasannya, dan off-ramp jika tidak cocok"
- Menolak juga merupakan bagian dari pekerjaan
-
Abstraksi Berbasis Perangkat Lunak (Software-Based Abstractions)
- Platform adalah perangkat lunak, bukan wiki, dan antarmukanya adalah API, CLI, dan SDK
- Developer harus bisa memprovisikan layanan kelas produksi hanya dengan menulis file deklaratif kecil
- Proyek Score di bawah CNCF adalah contoh representatif, yang dengan satu spesifikasi workload dapat secara otomatis memprovisikan database, topic, service account, dan deployment
- Developer tidak perlu tahu apakah di balik layar yang digunakan adalah Cloud SQL, Pub/Sub, atau Cloud Run
-
Kustomisasi OSS dan Registry Metadata
- Tidak memakai Argo CD atau Backstage versi vanilla begitu saja, tetapi mengoperasikannya dengan plugin, kebijakan default, dan integrasi yang disesuaikan untuk organisasi
- Tanpa registry metadata (katalog layanan), mustahil mengetahui siapa memiliki apa, bagaimana relasi dependensinya, dan apa yang benar-benar sedang berjalan
- Backstage adalah framework OSS standar de facto untuk lapisan ini, dengan lebih dari 270 organisasi mengoperasikannya di production
- CNCF meluncurkan sertifikasi Certified Backstage Associate dan Certified Cloud Native Platform Engineering Associate
- Apa pun yang digunakan, baik Backstage, Port, maupun Cortex, diperlukan single source of truth tentang "layanan apa yang ada, siapa pemiliknya, dan apa relasi dependensinya"
-
Layanan untuk Basis Pengguna yang Luas
- Platform internal memang memiliki sedikit pelanggan yang sangat vokal, tetapi tujuannya adalah mendukung dengan baik pekerjaan median dari developer median
- Jika dibangun hanya untuk pengguna elite, tim-tim lain akan mengakali platform dan lahirlah platform bayangan (shadow platform)
-
Beroperasi sebagai Fondasi
- Jika platform down, perusahaan ikut down, sehingga dibutuhkan on-call 24/7, SLO nyata, change management nyata, dan beban dukungan
- Ini bukan sekadar "alat" melainkan "lantai (floor)", dan semua yang dibangun di atasnya mengasumsikan lantai itu akan menopang
Kapan dan bagaimana memulainya
-
Jangan membentuk tim platform terlalu dini
- Pada skala 10 insinyur, yang dibutuhkan bukan tim platform melainkan kolaborasi (cooperation)
- Cukup jika satu orang mengelola skrip deployment, orang lain mengelola Terraform, dan semua sepakat pada konvensi
- Jika tim dibentuk terlalu dini dengan 1–2 orang, mereka akan menjadi antrean tiket, dan organisasi lainnya menjadi pasif
- Biasanya setelah 50 insinyur, saat ada banyak target deployment dan tak seorang pun tahu jawaban benar untuk "bagaimana men-deploy layanan baru", pembentukan tim menjadi tepat
-
Transformasi organisasi infrastruktur yang sudah ada
- Saat mengubah tim infrastruktur/SRE menjadi organisasi platform, bagian tersulitnya bukan teknologi melainkan budaya
- Penanggung jawab infrastruktur terbiasa berperan sebagai gatekeeper yang berkata "tidak bisa", tetapi penanggung jawab platform harus menjadi "orang yang menyediakan ya yang mudah"
- Banyak berbicara dengan pelanggan
- Merekrut dan membina software engineer yang senang membangun alat, bukan hanya operator
- Memperbarui sistem penghargaan agar yang diapresiasi bukan "men-deploy klaster baru" melainkan "membuat 200 tim bekerja 5% lebih cepat"
- Mode kegagalan yang paling umum adalah menaburkan PM di atasnya lalu selesai, dan itu hanya menciptakan teater (theater), bukan platform
Membangun tim platform
-
Empat peran
- Software Engineer: membangun permukaan produk platform seperti API, SDK, dan portal
- Systems Engineer: sangat paham primitive dasar seperti Kubernetes, Linux, networking, dan control plane cloud
- Reliability Engineer: fokus pada kualitas operasional, on-call, SLO, dan observability
- Systems Specialist: ahli domain mendalam untuk database, keamanan, networking, dan sebagainya
- Jika terlalu berfokus pada software, portal yang indah akan runtuh di bawah beban nyata; jika terlalu berfokus pada sistem, hasilnya adalah klaster kokoh yang tak bisa dipakai siapa pun tanpa tiket
-
Perekrutan
- Perekrutan harus menempatkan empati terhadap pelanggan (customer empathy) sebagai prioritas tertinggi
- Insinyur yang setelah menelepon developer aplikasi yang frustrasi tetap tidak bisa keluar dengan pemahaman jelas atas masalahnya, tidak cocok untuk peran ini
- Keunggulan teknis tanpa empati akan menghasilkan platform yang benar tetapi tidak dipakai siapa pun
- Untuk peran software, gunakan matriks level yang sama, tetapi untuk system specialist, karena nilai pasar dan skill-nya tidak terpetakan rapi ke ladder software engineer, izinkan jabatan yang fleksibel
-
Manajer dan peran lainnya
- Tiga karakteristik umum manajer platform engineering yang hebat: pengalaman nyata mengoperasikan platform, pengalaman men-deploy proyek jangka panjang lintas banyak kuartal, dan obsesi terhadap detail
- Platform menghargai detail, dan kasus 1% yang tampak langka lalu dilewati justru menyumbang 80% waktu dukungan
- PM, technical writer, developer advocate, dan support engineer semuanya penting, tetapi rekrut mereka setelah tim engineering cukup matang
- PM yang dimasukkan terlalu awal ke tim platform beranggotakan 4 orang hanya akan menjadi kursi berbentuk roadmap
Platform sebagai produk
-
Pelanggan internal lebih sulit
- Pelanggan internal adalah pengguna captive yang sulit berpindah; mereka punya opini kuat tetapi kepekaan produk yang lemah
- Mereka mengatakan apa yang mereka inginkan (want), tetapi sering kali berbeda dari apa yang benar-benar mereka butuhkan (need)
- Mereka menuntut agar platform mengerjakan pekerjaan mereka, bukan menyediakan alat agar mereka bisa mengerjakannya dengan baik
- Backlog yang sesungguhnya adalah duduk di samping mereka dan mengamati berapa kali mereka harus melakukan context switching untuk menerapkan satu perubahan
-
Discovery, roadmap, dan mode kegagalan
- Discovery platform dilakukan dengan pilot, bukan A/B test, bersama tim yang kooperatif, lalu mengukur penurunan lead time setelah deployment nyata
- Empat horizon waktu dalam roadmap
- Vision (multi-tahun): arah platform
- Strategy (tahunan): taruhan tahun ini
- Goals and Metrics (triwulanan~tahunan): definisi kesuksesan
- Milestones (triwulanan): target deployment yang nyata
- Mode kegagalan yang sering menjatuhkan tim
- Meremehkan biaya migrasi (selalu 2~3 kali dari perkiraan)
- Melebih-lebihkan anggaran perubahan pengguna terhadap fitur baru
- Fokus pada penambahan fitur padahal masalah sebenarnya adalah stabilitas
- Terlalu banyak PM dibanding ukuran tim engineering (kalau ada 2 PM untuk 5 engineer, itu masalah)
Operasi platform
-
On-call bukan pilihan
- Karena platform dijalankan sebagai fondasi, cakupan 24/7 tidak bisa ditawar
- “You build it, you run it” juga berlaku di sini, dan ini bukan hukuman melainkan feedback loop
- Jika satu engineer menerima page lebih dari beberapa kali per minggu, yang harus diperbaiki adalah sistemnya, bukan jadwalnya
- Engineer platform yang burnout akan merilis platform yang buruk
-
Dukungan: separuh pekerjaan yang tersembunyi
- Ini hampir tidak pernah dibahas di konferensi, tetapi merupakan separuh inti dari platform engineering
- Framework empat tahap
- Tahap 1: formalkan level dukungan (P0 vs P3, waktu respons, dll.)
- Tahap 2: pisahkan dukungan non-kritis dari on-call agar pertanyaan seperti cara menambahkan CronJob tidak sampai membangunkan seseorang
- Tahap 3: bila volumenya membenarkan, rekrut spesialis dukungan khusus
- Tahap 4: bangun organisasi engineering support yang sesuai skala
- Jika tahap 1 dilewati, engineer akan menghabiskan separuh waktunya untuk membalas DM Slack dan separuh sisanya untuk mengeluh
-
Feedback operasional
- SLO dan SLA wajib ada, sedangkan error budget berguna tetapi opsional
- Synthetic monitoring menangkap mode kegagalan sebelum pengguna mengirim tiket
- Review operasional bukan sekadar melirik dashboard hijau, tetapi memaksa peninjauan data nyata
- Dalam data DORA 2025, kapabilitas platform yang menunjukkan korelasi tertinggi dengan pengalaman pengguna adalah feedback yang jelas terhadap hasil kerja — saat gagal, pengguna harus tahu persis apa yang gagal dan apa yang harus dilakukan
Perencanaan dan delivery
-
Proyek jangka panjang memerlukan dokumen proposal
- Proyek platform seperti migrasi, rearchitecture, atau control plane baru memerlukan waktu berbasis kuartal
- Elemen wajib proposal yang baik: masalah yang ingin diselesaikan, siapa yang diuntungkan, cakupan, apa yang secara eksplisit di luar cakupan, dan definisi kesuksesan
- Tulis dokumennya terlebih dahulu sebelum menulis kode, minta review, lalu ubah menjadi rencana eksekusi dengan milestone konkret
- Mode kegagalan “long slog” — proyek berjalan bertahun-tahun dan tak seorang pun lagi ingat alasannya — hampir selalu akibat melewati tahap ini
-
Perencanaan roadmap bottom-up
- Empat jenis pekerjaan dalam roadmap platform: KTLO (keep-the-lights-on), mandat dari pimpinan, perbaikan sistem yang diputuskan sendiri, dan permintaan pelanggan langsung
- Prioritas tidak bisa ditentukan hanya dari permintaan pelanggan; KTLO adalah prioritas pertama, mandat prioritas kedua, dan sisanya memerlukan diskusi jujur dengan para pemangku kepentingan
-
Pencapaian dan Tantangan Dua Mingguan (Biweekly Wins and Challenges)
- Setiap dua minggu, tulis dokumen singkat: apa yang dirilis (pencapaian), apa yang terhambat (tantangan), singkat, terbuka, dan tanpa berlebihan
- Tiga efek sekaligus: tim mengungkapkan kemajuan dengan jelas, pemangku kepentingan mendapat gambaran situasi sebenarnya, dan tantangan terekspos lebih awal sehingga mendorong dukungan pimpinan
- Dokumen yang hanya berisi pencapaian adalah dokumen yang tidak dipercaya siapa pun, jadi jangan hilangkan bagian tantangan
Rearchitecture dan migrasi
-
Rearchitecture, bukan v2
- Saat platform mulai usang, naluri untuk “membuat v2” hampir selalu jawaban yang salah
- Alasan proyek v2 gagal: investasi pada v1 dibekukan, waktu yang dibutuhkan lebih lama dari perkiraan, dan biaya migrasi ke v2 lebih tinggi daripada biaya rearchitecture yang coba dihindari
- Lakukan rearchitecture di dalam platform yang sudah ada, pertahankan kompatibilitas sebisa mungkin, serta manfaatkan lingkungan bawah, rollout lambat, dan migrasi berbasis tranche
- Empat tahap perencanaan
- Berpikir besar tentang target arsitektur akhir
- Masukkan biaya migrasi (selalu 2~3 kali perkiraan)
- Identifikasi hasil utama 12 bulan yang membenarkan investasi berkelanjutan
- Dapatkan persetujuan pimpinan, dan siap untuk menunggu
-
Keamanan bersifat arsitektural
- Tidak mungkin menambahkan keamanan setelah semuanya dibangun; arsitektur harus sejak awal memaksakan least privilege, isolasi, dan traceability
- Jika platform mengharuskan setiap tim mengingat IAM binding yang benar, maka bukan timnya yang bermasalah, melainkan platform-nya yang memiliki bug
-
Migrasi: masalah sulit yang diremehkan
- Anti-pattern yang paling umum
- Memberi semua tim clipboard dan deadline lalu menyuruh mereka migrasi sendiri
- Hanya memberi mandat tanpa on-ramp dan off-ramp yang jelas
- Meremehkan long tail dari use case yang unik
- Cara engineering untuk mempermudah migrasi
- Lacak metadata penggunaan agar bisa mengetahui dengan tepat siapa pengguna versi lama
- Jika 200 tim harus bermigrasi, maka tim platform yang menulis skripnya, bukan tim aplikasi
- Rancang arsitektur migrasi transparan di mana sistem baru menggunakan API lama
- Dokumentasikan on-ramp dengan jelas agar tim baru bisa self-service
- Mandat hanya efektif satu atau dua kali; setelah itu, ia menjadi kebisingan
- Dalam kebanyakan kasus, yang terbaik adalah membuat jalur baru cukup bagus sehingga jalur lama secara alami layu
-
Penghentian layanan (Sunsetting)
- Jangan takut menghapus produk
- Satu sistem deployment yang kokoh lebih unggul daripada tujuh sistem deployment yang setengah didukung, dan penghentian layanan adalah ciri tim yang matang
Hubungan dengan pemangku kepentingan
-
Power-Interest Grid
- Petakan pemangku kepentingan pada dua sumbu: power dan interest
- Power tinggi · interest tinggi: update rutin dan konsultasi
- Power rendah · interest rendah: halaman status sudah cukup
- Jangan membuang waktu tim dengan memberi informasi upgrade Kubernetes kepada VP yang minatnya rendah
-
Komunikasi tanpa oversharing
- Transparan, tetapi jangan berlebihan — pemimpin senior perlu tahu apakah milestone tercapai dan apa risikonya, bukan perdebatan tentang tiga strategi retry gRPC
- Gunakan meeting 1:1 dengan hati-hati, dan lacak ekspektasi serta komitmen di tempat yang terlihat
-
Menolak tanpa merusak hubungan
- Jelaskan dampak bisnisnya dengan jelas, misalnya “Jika fitur ini ditambahkan, migrasi akan mundur satu kuartal, dan itu menimbulkan biaya $X bagi perusahaan”
- “Ya dengan kompromi”, “menolak sambil memberi jalur”, dan kadang-kadang membiarkan shadow platform bisa lebih baik daripada biaya untuk bertarung
- Pada musim penyusunan anggaran, ajukan dalam bentuk tim dan kapabilitas, bukan per orang, dan miliki pendapat kuat tentang apa yang akan dikurangi dan dipertahankan — jika tidak, tim keuangan akan memutuskannya untuk Anda, dan mereka akan salah
Seperti Apa Wujud Kesuksesan
-
Platform yang selaras (Aligned)
- Diperlukan keselarasan tujuan (mengapa platform ini ada), keselarasan strategi (taruhan konsisten antar tim), dan keselarasan rencana (tanpa benturan milestone)
- Ketidakselarasan muncul ketika tim runtime semuanya menginginkan Kubernetes sementara tim observability berusaha mendukung semua framework
- Ini terlihat dalam bentuk panduan pelanggan yang saling bertentangan, pekerjaan duplikat, dan developer marah yang terjebak di tengah
- Solusinya bukan konsensus, melainkan kepemimpinan yang berprinsip
-
Platform yang dipercaya (Trusted)
- Kepercayaan dibangun perlahan dan bisa hilang karena satu migrasi buruk saja
- Kepercayaan dibentuk dari cara beroperasi (komunikasi saat insiden, menepati janji), cara berinvestasi (taruhan besar yang dijual benar-benar dirilis), dan prioritas delivery
- Contoh "overcoupled platform": terlalu banyak logika kustom dimasukkan ke platform sehingga setiap perubahan memakan waktu berbulan-bulan — solusinya bukan menambah engineering, melainkan menantang asumsi tentang cakupan
- Terkadang masalah kepercayaan muncul bukan karena melakukan terlalu sedikit, tetapi karena melakukan terlalu banyak
-
Platform yang mengelola kompleksitas
- Kompleksitas perangkat lunak tidak bisa dihindari, tetapi accidental complexity tidak
- Bedakan antara kompleksitas masalah yang tidak dapat direduksi dengan accidental complexity yang muncul dari buruknya koordinasi manusia, shadow platform yang memecahkan masalah yang sama dua kali, dan pertumbuhan tanpa batas
- Tiga tuas praktis
- Mengendalikan pertumbuhan: platform yang mendukung segalanya tidak akan mendukung apa pun dengan baik; jelaskan cakupannya
- Gunakan product discovery bukan hanya untuk menentukan apa yang akan ditambahkan, tetapi juga apa yang akan dihentikan
- Mengelola shadow platform: jika tim membangun solusi paralel, itu pertanda ada kekurangan nyata di platform atau seseorang sedang memperluas wilayahnya — keduanya perlu ditangani
-
Platform yang dicintai (Loved)
- Ada tiga bentuk
- Cinta "tinggal jalan": sebagian besar pengguna bahkan tidak sadar ada platform, deployment berjalan, CI lolos — membosankan adalah pujian terbaik
- Cinta "terasa seperti hack": kegembiraan kecil seperti perintah CLI yang tanpa penjelasan tambahan langsung melakukan hal yang jelas benar
- Cinta "yang terlihat jelas": skor survei, retensi, adopsi organik, dan merekomendasikan platform ke tim lain
- Saat platform dicintai, orang-orang akan ikut memperjuangkannya ketika ada permintaan anggaran, tetapi jika hanya sekadar ditoleransi, satu insiden buruk saja bisa membuatnya terancam digantikan
Prioritas praktik
- Urutan kasar saat memulai dari nol atau membangun ulang
- Prioritas 1: tentukan apa yang didukung lalu dokumentasikan dan pertahankan
- Prioritas 2: berinvestasi pada abstraksi perangkat lunak, bukan wiki (perangkat lunak dengan API nyata seperti Score, Crossplane, atau SDK internal)
- Prioritas 3: bangun registry metadata (dengan Backstage dan sejenisnya untuk mengetahui apa berjalan di mana dan siapa pemiliknya)
- Prioritas 4: bangun untuk tim median, bukan tim yang paling berisik
- Prioritas 5: perlakukan operasi sebagai fitur kelas satu seperti SLO, on-call, dan tier dukungan
- Prioritas 6: rekrut berdasarkan kemampuan berempati sama seriusnya dengan kemampuan sistem
- Prioritas 7: komunikasi tanpa ampun seperti pembaruan capaian dan tantangan dua mingguan, roadmap yang transparan, dan pengelolaan stakeholder yang jujur
- Prioritas 8: hentikan, gabungkan, tolak hal-hal yang tidak diperlukan
- Selaras dengan data DORA, kualitas platform adalah pengali bagi segalanya, termasuk adopsi AI — platform yang buruk membuat alat AI memperbesar kekacauan, platform yang baik memperbesar throughput
- Sebelum membuat roket, Anda harus membangun lantainya terlebih dahulu
1 komentar
Saya rasa komunikasi internal adalah hal yang paling penting.