19.4 Platform Engineering: Jalan Aspal untuk Banyak Tim
Ketika satu tim sudah bisa menjalankan siklus ini dengan baik, tantangan berikutnya adalah membuat pola yang sama bisa diadopsi oleh banyak tim. Di sinilah platform engineering masuk.
Saya pernah melihat situasi di sebuah perusahaan e-commerce yang memiliki dua belas tim produk. Setiap tim membangun microservice sendiri. Dan hampir setiap tim membangun infrastrukturnya dengan cara yang berbeda. Tim A memakai Kubernetes dengan cara A. Tim B memakai cara B yang sama sekali berbeda. Tim C malah memakai serverless. Masing-masing punya alasan kuat. Tapi ketika arsitek ingin menerapkan standar observability, ia harus menjelaskan caranya dua belas kali. Ketika tim keamanan ingin memastikan semua service punya mekanisme authentication yang konsisten, mereka harus audit satu per satu. Perusahaan bergerak, tapi ada gesekan di mana-mana.
Masalahnya bukan pada tim yang kreatif. Masalahnya adalah tidak ada jalur kerja yang sudah teruji dan siap pakai. Setiap tim harus memikirkan semuanya dari nol: bagaimana melakukan deployment, bagaimana mengelola secret, bagaimana mengatur logging, bagaimana melakukan health check. Beban pikiran ini menguras energi yang seharusnya bisa dipakai untuk membangun fitur bisnis.
Platform engineering menjawab kebutuhan ini dengan cara yang sederhana: menyediakan jalan aspal. Bukan jalan setapak, bukan jalan yang harus dibuka sendiri dengan parang. Jalan aspal yang sudah diaspal, sudah diukur, sudah ada rambu-rambunya. Dalam istilah teknis, ini sering disebut golden path atau paved road.
Berikut adalah diagram yang membandingkan dua situasi tersebut.
Konsepnya begini. Tim platform — yang bisa terdiri dari beberapa engineer senior, arsitek, dan operation engineer — membangun satu set tooling, jalur pemrosesan, dan infrastruktur yang sudah teruji. Mereka menyediakan self-service portal atau command-line tool yang memungkinkan tim aplikasi membuat service baru dalam hitungan menit, bukan minggu. Service baru itu langsung datang dengan: CI/CD jalur pemrosesan yang sudah jadi, template monitoring dan alerting, mekanisme secret management, konfigurasi logging standar, dan dokumentasi yang selalu sinkron.
Berikut contoh potongan konfigurasi Terraform yang bisa disediakan tim platform sebagai template golden path.
# modules/golden-path/main.tf
# Template infrastruktur standar untuk tim aplikasi
resource "aws_vpc" "this" {
cidr_block = "10.0.0.0/16"
tags = { Name = "${var.service_name}-vpc" }
}
resource "aws_eks_cluster" "this" {
name = "${var.service_name}-cluster"
role_arn = var.cluster_role_arn
vpc_config {
subnet_ids = aws_subnet.private[*].id
}
}
resource "aws_cloudwatch_log_group" "this" {
name = "/aws/eks/${var.service_name}/cluster"
retention_in_days = 30
}
output "cluster_endpoint" {
value = aws_eks_cluster.this.endpoint
}
Tim aplikasi tinggal fokus pada kode bisnis mereka. Mereka tidak perlu bertanya-tanya apakah infrastrukturnya sudah aman atau belum. Mereka tidak perlu menghabiskan waktu debugging jalur pemrosesan yang rusak. Jalurnya sudah aspal.
Yang penting, platform ini bukan proyek sekali jadi. Platform adalah produk internal. Sama seperti produk eksternal, platform harus punya pengguna (tim aplikasi), harus punya product owner, harus punya roadmap, dan harus terus diperbaiki berdasarkan feedback. Tim platform tidak boleh bekerja dalam isolasi. Mereka perlu berbicara dengan tim aplikasi secara rutin, mendengar apa yang membuat mereka lambat, dan memperbaiki platform berdasarkan kebutuhan nyata.
Di perusahaan yang menjalankan platform engineering dengan baik, dampaknya terasa langsung. Waktu yang dibutuhkan untuk meluncurkan service baru turun drastis. Konsistensi antar service naik. Insiden akibat misconfiguration berkurang. Dan tim aplikasi merasa dipermudah, bukan dibatasi.
Ini bukan soal mengontrol tim. Ini soal memberi mereka jalan yang sudah terbukti aman dan cepat. Kalau ada tim yang butuh keluar dari jalur aspal karena kebutuhan khusus, mereka boleh. Tapi mereka harus tahu bahwa mereka sedang meninggalkan jalur yang terawat, dan konsekuensinya ada pada mereka.
Platform engineering adalah jembatan antara arsitektur yang digambar dan arsitektur yang dijalankan oleh banyak tim sekaligus. Tapi menyediakan platform saja tidak cukup. Tim aplikasi juga perlu merasa bahwa beban pikiran mereka benar-benar berkurang.