Apa Itu Platform Engineering? Panduan Praktis untuk Tim

Apa itu platform engineering? Platform engineering adalah praktik membangun dan menjalankan platform internal yang memberi developer akses mandiri ke hal-hal yang mereka butuhkan untuk merilis perangkat lunak: environment, pipeline, service, dokumentasi, dan guardrail. Tim kecil memperlakukan jalur dari "saya punya ide" sampai "sudah berjalan di produksi" sebagai sebuah produk, dan developer adalah pelanggannya. Tujuannya sederhana: lebih sedikit menunggu, lebih sedikit tiket, dan lebih sedikit tool yang harus dipelajari.

Mungkin Anda sudah pernah mengalami masalahnya. Sebuah service baru butuh repo, pipeline, database, secret, dashboard, dan jadwal on-call, dan masing-masing ada di halaman wiki yang berbeda atau di tangan orang yang berbeda di Slack.

Mengapa platform engineering muncul?

Prinsip "you build it, you run it" berjalan baik ketika satu tim memiliki satu service dan beberapa tool saja. Prinsip itu berhenti berskala ketika toolchain bertambah menjadi Kubernetes, Terraform, tiga sistem CI, secret manager, service mesh, dan tumpukan observability. Setiap developer produk kemudian diharapkan menjadi insinyur infrastruktur paruh waktu.

Biayanya muncul sebagai beban kognitif, bukan sebagai baris di anggaran. Developer yang butuh 90 menit untuk mengetahui Helm chart mana yang "benar" tidak melambat karena kurang skill. Mereka melambat karena kurangnya default.

Platform engineering adalah koreksinya. Alih-alih meminta setiap tim merakit tumpukan yang sama dari nol, satu tim khusus merakitnya sekali, menjadikannya pilihan yang paling mudah, dan menjaganya tetap sehat. Analis melihat dorongan yang sama: Gartner memperkirakan bahwa pada 2026, 80% organisasi engineering perangkat lunak besar akan memiliki tim platform engineering, naik dari 45% pada 2022.

Apa yang sebenarnya dibangun tim platform?

Abaikan dulu diagram vendor. Di sebagian besar perusahaan, tim platform mengirimkan empat hal.

• Internal developer platform (IDP). Kumpulan tool dan alur kerja self-service di atas cloud dan CI Anda. Bisa berupa portal Backstage, produk vendor, atau repo template yang terawat plus sebuah CLI.

• Golden path. Rute yang opinionated dan didukung untuk tugas umum, misalnya "buat service API baru" atau "tambahkan queue".

• Guardrail. Kebijakan, pemindaian, dan batas biaya yang aktif secara default, sehingga pilihan yang aman juga menjadi pilihan yang paling malas.

• Dokumentasi dan penemuan. Katalog yang menjawab "siapa pemilik service ini, di mana runbook-nya, dan apa saja dependensinya?"

Tidak ada yang memerlukan kategori produk baru. Banyak platform yang baik dimulai dari template cookiecutter dan README yang terus dijaga tetap mutakhir oleh seseorang.

Apa itu golden path, dan mengapa tim mengabaikannya?

CNCF mendefinisikan golden path sebagai "templated composition of well-integrated code and capabilities for rapid project development", yaitu komposisi kode dan kemampuan yang terintegrasi dengan baik dalam bentuk template untuk pengembangan proyek yang cepat. Definisi ini dijelaskan Google Cloud lewat contoh Spring Boot. Secara sederhana, golden path adalah template yang memberi service baru repo, pipeline, logging, dan konfigurasi deploy sejak hari pertama.

Mode kegagalannya sama sederhananya. Jalur yang tidak pernah diminta siapa pun, dibangun tanpa berbicara dengan tim yang akan memakainya, akan berhenti di adopsi satu digit, sementara tim platform bertanya-tanya mengapa developer terus membuka tiket. Jalur itu harus lebih pendek daripada cara alternatifnya, atau orang akan memilih cara alternatif itu.

Dua aturan menjaga golden path tetap hidup:

1. Beraspal, bukan berpagar. Developer boleh keluar dari jalur, tetapi mereka menanggung beban dukungan atas apa pun yang mereka bangun di luar jalur itu.

2. Dikelola seperti produk. Ada yang membaca masukan, memantau adopsi, dan menghapus jalur yang tidak dipakai siapa pun.

Apakah platform engineering hanya DevOps dengan nama baru?

Sebagian, dan jawaban jujur lebih berguna daripada jawaban pemasaran. DevOps adalah budaya: kepemilikan bersama antara development dan operasi, dengan umpan balik yang singkat. Platform engineering adalah salah satu cara membuat budaya itu berkelanjutan dalam skala besar, dengan mengubah pekerjaan operasional yang berulang menjadi sebuah produk.

SRE adalah disiplin yang berbeda lagi. SRE menetapkan target keandalan, mengukurnya, dan memutuskan kapan harus berhenti merilis untuk melindunginya. Tim platform menyediakan jalan beraspalnya. Tim SRE memberi tahu Anda seberapa besar risiko yang bisa Anda tanggung di jalan itu.

• DevOps adalah budaya dan kumpulan praktik. Hasilnya adalah kepemilikan bersama dan otomatisasi, dan biasanya gagal ketika berubah menjadi jabatan dan antrean tiket.

• SRE adalah disiplin keandalan. Hasilnya adalah SLO, error budget, dan proses insiden, dan biasanya gagal ketika berubah menjadi rota pager tanpa wewenang.

• Platform engineering adalah tim produk internal. Hasilnya adalah platform self-service dan golden path, dan biasanya gagal ketika berubah menjadi platform yang tidak dipakai siapa pun.

Bagian tentang mode kegagalan ini layak dibaca dua kali. Tim platform yang menerima tiket dan membangun apa pun yang diminta adalah tim ops yang berganti nama, dan ia mewarisi semua masalah antrean yang lama.

Kapan tim platform layak dibiayai dengan headcount?

Lewati dulu jika Anda punya kurang dari sekitar 30 engineer dan satu atau dua service. Di ukuran itu, satu repo template yang baik dan satu modul Terraform bersama sudah cukup, dan tim platform penuh waktu hanya menjadi overhead. Beberapa orang di tim berisi sepuluh orang akan diam-diam menjadi platform itu sendiri, dan itu tidak apa-apa.

Investasi mulai terbayar ketika sinyal berikut terus berulang:

• Service baru butuh berminggu-minggu untuk sampai ke produksi, sebagian besar karena menunggu orang lain.

• Tiga tim sudah memecahkan masalah deploy yang sama dengan tiga cara berbeda.

• Onboarding engineer baru berarti tumpukan pengetahuan tidak tertulis dan banyak kalimat "tanya Priya, dia yang tahu".

• Review keamanan dan kepatuhan terjadi di akhir, per tim, secara manual.

Versi paling kecil yang berguna adalah yang oleh Team Topologies disebut thinnest viable platform: cukup untuk menghilangkan rasa sakit berulang yang paling besar, terdokumentasi dengan baik, dan tidak lebih. Mulailah dari satu alur kerja yang paling banyak memakan jam lintas tim, biasanya "buat service baru" atau "dapatkan preview environment".

Manajemen feature flag adalah contoh kemampuan yang lebih murah sebagai layanan bersama daripada sebagai sepuluh layanan privat.

Layanan flag yang bisa dipanggil semua tim, dengan jejak audit dan aturan pembersihan yang sama, menyelamatkan setiap tim dari membuat sistem toggle setengah jadi sendiri. Entah Anda membelinya atau membangunnya, layanan itu sebaiknya berada di platform, bukan di setiap repo.

Apa hubungan platform dengan membaca kode?

Lebih banyak dari yang diakui diagram-diagram itu. Platform hanya seberguna pengetahuan di sekitarnya. Ketika developer bertanya "bagaimana service A melakukan autentikasi ke service B?", jawabannya ada di kode, konfigurasi, dan runbook yang mungkin sudah enam bulan tidak diperbarui.

Di sinilah tim platform diam-diam kehabisan waktu. Merekalah yang menerima pertanyaan Slack yang dimulai dengan "di mana X dikonfigurasi?", lalu menjawabnya dari ingatan, untuk kelima kalinya minggu ini. Efeknya terlihat ketika sebuah repo tumbuh melewati 80K baris dan tim platform berubah menjadi indeks pencarian manusia.

Beberapa tool membantu di sini, dan masing-masing menyelesaikan separuh masalah yang berbeda. Tool docs-as-code menjaga bagian tertulis tetap dekat dengan sumbernya.

Asisten yang memahami kode menjawab pertanyaan tentang kode itu sendiri. Asisten Sourcegraph ditujukan untuk organisasi besar dengan banyak repo, dan dijual ke perusahaan berdasarkan penawaran harga, jadi lebih cocok untuk tim platform di estat yang besar daripada tim beranggotakan lima belas orang.

Untuk pekerjaan sehari-hari di dalam editor, asisten umum mencakup banyak hal, dengan catatan bahwa ia hanya tahu konteks yang Anda berikan.

Pola yang layak ditiru: letakkan template golden path, katalog kepemilikan, dan indeks kode yang bisa dicari di satu tempat, lalu biarkan engineer baru bertanya di sana sebelum bertanya ke orang. Hasilnya juga bisa diukur dalam jam. Jika tim platform Anda menjawab kurang dari sepuluh pertanyaan "ini dikonfigurasi di mana" per minggu setelah Anda melakukannya, berarti cara ini berhasil.

Bagaimana memulai tanpa membangun katedral?

Sebagian besar upaya platform yang gagal dimulai dari tool. Urutan yang lebih baik adalah orang, lalu jalur, lalu tooling.

1. Wawancarai sepuluh developer. Tanyakan di mana mereka kehilangan waktu antara PR yang sudah di-merge dan fitur yang berjalan. Anda akan mendengar tiga jawaban yang sama.

2. Pilih satu jalur dan rilis dalam sebulan. Satu template "service baru" yang bekerja dari ujung ke ujung lebih baik daripada portal dengan 40 kotak kosong.

3. Ukur sebelum dan sesudah. Lacak waktu sampai deploy pertama untuk service baru dan waktu sampai PR pertama karyawan baru di-merge. Dua angka itu akan memberi tahu Anda lebih banyak daripada survei kepuasan mana pun.

4. Terbitkan roadmap dan changelog. Pekerjaan platform tidak terlihat kecuali Anda membuatnya terlihat.

5. Hapus hal-hal. Pensiunkan jalur dan tool yang tidak dipakai siapa pun. Platform yang lebih kecil tetapi dipercaya lebih baik daripada platform yang lebih besar yang terus dihindari orang.

Tahan dorongan untuk membeli portal dulu. Portal di atas alur kerja yang berantakan hanya menghasilkan kekacauan yang tampak lebih rapi, dan katalog dengan 247 entri, separuhnya usang, lebih buruk daripada tanpa katalog sama sekali.

Apa yang bisa salah, dan bagaimana mengenalinya sejak dini?

Tiga pola kegagalan muncul berulang kali.

Platform helpdesk. Permintaan datang lewat tiket, tim memenuhinya secara manual, dan semua itu disebut self-service. Tesnya: bisakah developer menyelesaikan tugas umum tanpa berbicara dengan siapa pun?

Platform yang dipaksakan. Pimpinan memerintahkan setiap tim pindah ke platform sebelum platform itu bagus. Angka adopsi terlihat hebat dan sentimen runtuh. Biarkan pemakaian diraih dengan kerja, setidaknya selama enam bulan pertama.

Platform serba-bisa. Setiap permintaan menjadi fitur, area permukaannya membengkak, dan kualitas menurun. Katakan tidak, secara tertulis, dengan alasannya.

Peringatan dini yang berguna adalah rasio pertanyaan Slack terhadap jawaban yang terdokumentasi. Jika pertanyaan yang sama muncul tiga kali dalam sebulan dan belum ada dokumen, template, atau otomatisasi untuknya, itulah item backlog Anda berikutnya.

Jadi, apa yang bisa Anda lakukan hari Senin? Pilih satu hal yang paling banyak membuang waktu lintas tim dan jadikan itu membosankan. Bagi sebagian besar perusahaan, itu adalah membuat service baru atau mendapatkan environment uji. Tulis jalurnya, letakkan di tempat orang akan menemukannya, hitung jam yang dihemat, dan baru setelah itu putuskan apakah Anda memerlukan tim yang lebih besar. Platform engineering bukan toolchain yang tinggal dipasang. Ia adalah keputusan untuk memperlakukan developer internal sebagai pelanggan, dan buktinya adalah jarak yang makin pendek antara hari pertama karyawan baru dan perubahan pertama yang mereka merge.