1~
2Seiring sistem perangkat lunak menjadi semakin kompleks  -  microservice, Kubernetes, multi-cloud, pipeline CI/CD, stack observability  -  developer menghabiskan lebih banyak waktu untuk infrastruktur dan lebih sedikit waktu untuk membangun produk. **Platform Engineering** menyelesaikan ini dengan membuat platform internal yang mengabstraksi kompleksitas dan menyediakan developer alat layanan mandiri untuk pengiriman lebih cepat.
3~
4Gartner memprediksi bahwa pada 2027, **80% organisasi rekayasa perangkat lunak** akan membentuk tim platform. Dalam panduan ini, kita akan mengeksplorasi apa itu Platform Engineering, mengapa penting, dan cara membangun Internal Developer Platform dari awal.
5~
6## Apa itu Platform Engineering?
7~
8Platform Engineering adalah disiplin merancang dan membangun toolchain dan workflow yang memungkinkan kemampuan layanan mandiri untuk organisasi rekayasa perangkat lunak. Hasilnya adalah **Internal Developer Platform (IDP)**  -  sebuah lapisan yang berada di antara developer dan infrastruktur.
9~
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17~
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24~
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31~
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43~
44### Platform Engineering vs DevOps
45~
46Platform Engineering bukan pengganti DevOps  -  ini adalah evolusi berikutnya. DevOps berkata "kamu membangun, kamu menjalankan." Platform Engineering berkata "kami akan membuat membangun dan menjalankan menjadi mudah."
47~
48| Aspek | DevOps | Platform Engineering |
49|-------|--------|---------------------|
50| **Fokus** | Budaya dan praktik | Produk dan layanan mandiri |
51| **Pendekatan** | Setiap tim mengelola infra | Tim platform mengabstraksi infra |
52| **Beban Kognitif** | Tinggi (setiap tim mempelajari semuanya) | Rendah (golden path disediakan) |
53| **Output** | Pipeline CI/CD, skrip IaC | Internal Developer Platform |
54| **Pengguna** | Seluruh engineering | Tim platform melayani engineering |
55~
56## Mengapa Platform Engineering Penting
57~
58### Masalah Beban Kognitif
59~
60Dalam organisasi modern yang umum, seorang developer perlu memahami:
61~
62- Workflow Git dan strategi branching
63- Konfigurasi pipeline CI/CD
64- Pembuatan container dan manajemen registry
65- Manifest Kubernetes dan Helm Charts
66- Layanan penyedia cloud (AWS/GCP/Azure)
67- Networking, DNS, sertifikat TLS
68- Pengaturan monitoring, logging, alerting
69- Provisioning dan migrasi database
70- Kebijakan keamanan dan kepatuhan
71~
72Itu adalah beban kognitif yang sangat besar yang mengalihkan fokus dari produk yang sebenarnya.
73~
74### Golden Path
75~
76Platform Engineering memperkenalkan konsep **golden path**  -  jalur yang berpendirian, didukung dengan baik, dan terdokumentasi untuk tugas-tugas umum. Golden path bukan mandat; developer *bisa* menyimpang, tetapi platform membuat hal yang benar menjadi hal yang mudah.
77~
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88~
89**Contoh golden path untuk membuat microservice baru:**
901. Developer memilih "Layanan Backend Baru" di portal
912. Memilih bahasa/framework (Node.js, Go, Python)
923. Platform otomatis membuat: repositori Git, pipeline CI/CD, namespace Kubernetes, dashboard monitoring, dan aturan alerting
934. Developer mengkloning repositori dan langsung mulai coding
94~
95## Membangun Internal Developer Platform
96~
97### Lapisan 1: Developer Portal
98~
99Portal adalah titik masuk tunggal untuk developer. Opsi open-source paling populer adalah **Backstage** (dibuat oleh Spotify, sekarang proyek CNCF).
100~
101Fitur utama:
102- **Katalog layanan**: Setiap layanan, pemiliknya, dokumentasi, dan dependensi
103- **Template perangkat lunak**: Scaffolding untuk layanan baru dengan praktik terbaik bawaan
104- **Dokumentasi teknis**: Dokumentasi sebagai kode, dirender dan dapat dicari
105- **Ekosistem plugin**: Dapat diperluas dengan fungsionalitas kustom
106~
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127~
128### Lapisan 2: Abstraksi Infrastruktur
129~
130Developer tidak seharusnya menulis Terraform atau YAML Kubernetes secara langsung. Platform harus menyediakan abstraksi.
131~
132**Alat:**
133- **Crossplane**: Provisioning infrastruktur native Kubernetes
134- **Terraform dengan modul**: Modul infrastruktur siap pakai dan teruji
135- **Pulumi**: Infrastruktur sebagai kode nyata (TypeScript, Python, Go)
136~
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149~
150Alih-alih mengonfigurasi parameter RDS, subnet VPC, security group, dan kebijakan backup, developer cukup menentukan `size: small` dan `backup: daily`. Platform menangani sisanya.
151~
152### Lapisan 3: Standardisasi CI/CD
153~
154Standardisasi CI/CD agar tim tidak membangun pipeline masing-masing.
155~
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163~
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172~
173**Praktik utama:**
174- Template CI/CD bersama yang disertakan tim (bukan disalin)
175- Pemindaian keamanan otomatis (SAST, audit dependensi)
176- Strategi deployment terstandarisasi (canary, blue/green)
177- Rollback otomatis saat health check gagal
178~
179### Lapisan 4: Observability
180~
181Monitoring pra-konfigurasi sehingga developer mendapatkan dashboard dan alert siap pakai.
182~
183- **Metrik**: Prometheus + Grafana dengan dashboard standar per layanan
184- **Logging**: Logging terstruktur dengan pengumpulan terpusat (Loki, ELK)
185- **Tracing**: Distributed tracing dengan OpenTelemetry
186- **Alerting**: Integrasi PagerDuty/Opsgenie dengan default yang masuk akal
187~
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199~
200## Mengukur Keberhasilan
201~
202Bagaimana Anda tahu platform Anda berfungsi? Lacak metrik ini:
203~
204### Metrik DORA
205- **Frekuensi deployment**: Seberapa sering kode mencapai produksi
206- **Lead time untuk perubahan**: Waktu dari commit hingga produksi
207- **Tingkat kegagalan perubahan**: Persentase deployment yang menyebabkan kegagalan
208- **Rata-rata waktu pemulihan**: Waktu untuk memulihkan layanan setelah insiden
209~
210### Metrik Spesifik Platform
211- **Waktu hingga deploy pertama**: Berapa lama dari "layanan baru" hingga deploy produksi pertama
212- **Kepuasan developer (NPS)**: Survei pengguna Anda secara berkala
213- **Rasio layanan mandiri**: % permintaan infrastruktur yang ditangani tanpa tiket
214- **Adopsi golden path**: % layanan yang mengikuti jalur yang direkomendasikan
215~
216## Kesalahan Umum
217~
218### 1. Membangun Terlalu Banyak, Terlalu Cepat
219Mulai dari titik masalah terbesar, bukan visi besar. Jika deployment menyakitkan, mulai dari situ. Jika provisioning memakan waktu berminggu-minggu, mulai dari situ.
220~
221### 2. Tidak Memperlakukan Platform sebagai Produk
222Tim platform membutuhkan product manager, riset pengguna, dan loop umpan balik. Developer adalah pelanggan Anda  -  pahami kebutuhan mereka.
223~
224### 3. Mewajibkan Alih-alih Menarik
225Platform terbaik diadopsi secara sukarela karena membuat hidup developer lebih mudah. Jika Anda harus mewajibkan penggunaan, platform Anda belum cukup baik.
226~
227### 4. Mengabaikan Pengalaman Developer
228Platform dengan UX yang buruk tidak akan digunakan. Investasikan dalam dokumentasi yang jelas, pesan error yang membantu, dan loop umpan balik yang cepat.
229~
230## Memulai
231~
232Peta jalan praktis untuk membangun IDP pertama Anda:
233~
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239~
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243~
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247~
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251~
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256~
257### Platform Minimum yang Layak
258~
2591. **Katalog layanan** (Backstage)  -  ketahui apa yang ada dan siapa pemiliknya
2602. **Satu template layanan**  -  golden path untuk jenis layanan paling umum Anda
2613. **CI/CD terstandarisasi**  -  pipeline bersama yang disertakan tim
2624. **Dokumentasi dasar**  -  cara menggunakan platform, di mana mendapatkan bantuan
263~
264Anda bisa membangun MVP ini dalam 2-3 bulan dengan tim 2-3 engineer.
265~
266## Kesimpulan
267~
268Platform Engineering bukan tentang membangun platform sempurna dari hari pertama. Ini tentang secara bertahap mengurangi beban kognitif developer agar mereka bisa fokus membangun produk. Mulai kecil, ukur dampaknya, dan iterasi berdasarkan umpan balik developer.
269~
270Organisasi yang berinvestasi dalam Platform Engineering akan memiliki keunggulan kompetitif yang signifikan: pengiriman lebih cepat, developer lebih bahagia, dan sistem lebih andal.
271~
272**Sumber Daya:**
273- [Team Topologies](https://teamtopologies.com/)  -  buku yang mempopulerkan tim platform
274- [Backstage](https://backstage.io/)  -  portal developer open-source dari Spotify
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  definisi komunitas dan praktik terbaik
276- [platformengineering.org](https://platformengineering.org/)  -  komunitas, acara, dan sumber daya
277~