Belajar Platform Engineer - Data Platform

#Pendahuluan

Setelah di episode 13 developer bisa deploy aplikasi tanpa menyentuh Kubernetes, pertanyaan berikutnya selalu datang cepat: kalau aplikasinya sudah jalan, datanya disimpan di mana? Data adalah kebutuhan yang paling sering diminta developer dan paling mahal dilayani secara manual. Episode ini membangun data platform — managed databases, data services, dan self-service data — supaya developer mendapatkan database dalam hitungan menit, bukan menunggu tiket berhari-hari.

Mengapa ini penting? Provisioning database dan pemberian akses data termasuk toil terbesar tim infrastruktur di hampir semua organisasi. Tanpa data platform, satu request database mempertemukan DBA, tim network, dan security dalam satu antrian. Dan ketika developer kabur ke cloud console membuat DB sendiri, platform kehilangan kontrol biaya, backup, dan keamanan. Data platform adalah cara mengembalikan kendali itu tanpa memperlambat developer.

#Level Perawatan Data

Sebelum membangun, pahami pilihan tingkat abstraksi yang tersedia:

Data platform bukan berarti "semua database harus di dalam cluster kita". Ia berarti semua permintaan database melewati satu jalur yang terstandardisasi — entah itu DB in-cluster lewat operator, atau managed DB dari cloud yang di-provisioning lewat modul yang sama. Konsistensi antarmuka itulah produknya.

#Komponen Data Platform

#1. Provisioning

Titik masuknya bisa dua: operator in-cluster (contoh CloudNativePG, KubeDB) yang mengelola PostgreSQL di Kubernetes, atau modul IaC (Terraform/Crossplane) untuk managed DB dari cloud. Pilihan keduanya diseragamkan lewat satu template — developer tidak perlu tahu bedanya.

data/
├── modules/
│   ├── postgres/        # satu antarmuka: managed cloud ATAU in-cluster
│   ├── mysql/
│   └── object-storage/
├── compositions/
│   ├── db-small.yaml    # 1 vCPU, 4Gi, backup harian
│   ├── db-medium.yaml
│   └── db-large.yaml
└── policies/
    ├── require-backup.yaml
    └── require-encryption.yaml

#2. Connection Management

Aplikasi tidak boleh menerima connection string mentah yang berubah-ubah. Platform menyediakan pooler (PgBouncer) dan proksi yang memberi DNS stabil, dan connection string disuntikkan sebagai secret (episode 10) — bukan di-hardcode di config.

#3. Migration Service

Migrasi skema adalah bagian paling menakutkan dari data. Platform menyediakan tooling migrasi terstandardisasi (pola upgrade task di app runner, atau job khusus) sehingga migrasi bisa di-review, diuji di staging, dan dijalankan dengan rollback plan — bukan psql manual ke produksi.

#4. Backup & Restore

Backup tanpa restore yang teruji adalah ilusi. Data platform wajib punya SLO backup (RPO/RTO) dan verifikasi restore berkala otomatis — restore ke lingkungan staging setiap minggu dan biarkan test suite berjalan di atasnya.

#5. Self-Service Data untuk Analitik

Lapisan terakhir: data untuk analitik (warehouse, lakehouse) dengan katalog data dan akses via query engine, bukan lagi "minta dump dari DBA". Ini mencegah tiap tim membangun pipeline data sendiri-sendiri.

#Praktik: Database Self-Service

Mari rancang flow yang sama seperti bootstrap service di episode 12, sekarang untuk data. Developer membuka portal dan memilih "Create Database":

# Diisi developer lewat form portal
name: payments-api
engine: postgres
version: "16"
size: small          # -> db-small: 1 vCPU, 4Gi, backup harian
environment: dev
enable_read_replica: false

Hasilnya: developer mendapat database yang aman secara default (encryption, backup aktif, quota sesuai size) tanpa membuka cloud console. Akses lewat secret yang disuntikkan ke aplikasi — misalnya resource type: postgres di score.yaml (episode 13) yang di-resolve otomatis ke connection string.

#Common Pitfalls

1. Setiap tim membuat DB sendiri di cloud — vendor lock-in, biaya tak terkendali, dan tidak ada standar backup.
2. Backup ada tapi restore tidak pernah diuji — saat bencana datang, baru ketahuan dump-nya korup.
3. Connection string tersebar di config — sekuriti bocor; semua koneksi harus lewat secret + proxy.
4. Self-service tanpa quota — puluhan database lahir dalam semalam dan membebani cluster maupun anggaran.
5. Menyerahkan migrasi tanpa tooling — developer takut menyentuh skema produksi; pilih migration-as-a-service atau escape hatch yang terdokumentasi.

#Penutup

Inti yang harus dibawa pulang:

• Data platform = provisioning terstandardisasi + connection management + backup teruji + self-service data.
• Satu antarmuka untuk semua database — in-cluster maupun managed cloud — lewat template dan modul.
• Connection string lewat secret dan proxy, bukan config mentah.
• Backup harus diverifikasi restore-nya, bukan sekadar dijadwalkan.
• Data analitik pun butuh jalur self-service agar tim tidak membuat pipeline sendiri-sendiri.

Di episode 15 selanjutnya kita menaikkan skala platform dari satu cluster menjadi banyak: multi-cluster & multi-tenancy — bagaimana mengelola fleet cluster tanpa kehilangan kendali, dan bagaimana menetapkan model tenancy yang benar sebelum jumlah cluster meledak!