Belajar Platform Engineer - Cost Platform & FinOps

#Pendahuluan

Setelah di episode 10 kita mengamankan secrets, tibalah masalah yang paling sering membuat tim platform tidak bisa tidur: biaya cloud. Semua abstraksi yang kita bangun — golden paths, self-service, K8s platform — pada akhirnya menghasilkan tagihan. Di 2026, pertanyaan "berapa biaya untuk menjalankan service ini?" harus punya jawaban yang jelas, atau platform kalian akan dipandang sebagai pemboros bukan pemungkin.

Mengapa FinOps harus jadi bagian platform? Karena biaya cloud hanya bisa dikendalikan di tempat ia muncul: infrastruktur bersama yang dikelola platform. Jika setiap tim memegang cluster sendiri dan tagihan sendiri, tidak ada yang bisa melihat gambaran besar. Platform yang baik menyediakan visibilitas biaya per tim dan mekanisme optimasi terpusat — itulah inti FinOps.

#Apa Itu FinOps?

FinOps adalah praktik operasional yang menyatukan tim finansial, engineering, dan produk untuk mengelola biaya cloud. Siklusnya terus berulang:

Peran platform engineer dalam FinOps: membangun infrastruktur data biaya — memastikan setiap cent rupiah bisa diatribusikan ke tim/service, dan menyediakan alat optimasi yang bisa dipakai tanpa mengganggu development.

#Data Foundation: Label adalah Segalanya

FinOps gagal jika data biaya tidak bisa diatribusikan. Di episode 4 kita menetapkan label team dan environment di namespace. Sekarang label itu menghasilkan nilai: cost allocation.

Aturan emas: setiap resource yang berbiaya harus punya label:

# Setiap resource di platform wajib punya:
labels:
  team: payments
  service: payments-api
  environment: prod
  cost-center: eng-payments

Di Kubernetes, biaya juga bisa di-attach ke label Pod dan namespace. Platform engineer menetapkan standard label ini dan menegakkannya dengan policy (Kyverno, episode 5) — resource tanpa label ditolak atau masuk bucket "unallocated" yang mencurigakan.

#Cost Dashboards: OpenCost dan KubeCost

Alat open-source utama untuk cost visibility Kubernetes:

Keduanya menghitung biaya per workload berdasarkan resource yang diminta (requests) dan yang dipakai. Instalasi via Helm:

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost \
  --namespace opencost \
  --create-namespace \
  --set opencost.exporters.prometheus.enabled=true \
  --set opencost.ui.enabled=true

Outputnya: dashboard yang menjawab pertanyaan klasik — "service mana yang paling mahal bulan ini?"

# Biaya per namespace (bulanan)
sum(kubecost_namespace_cpu_cost{}) + sum(kubecost_namespace_gpu_cost{})
# Biaya per deployment
sum(kubecost_deployment_cpu_cost{})

#Showback vs Chargeback

Dua model bagaimana biaya "dipulangkan" ke pemiliknya:

Pendekatan yang paling banyak dipakai di 2026: mulai dengan showback. Tampilkan dashboard "cost per team" kepada setiap tim, biarkan mereka melihat dampak keputusan mereka sendiri. Setelah budaya data biaya terbentuk, baru pertimbangkan chargeback parsial (misal hanya di atas baseline tertentu).

#Mekanisme Optimasi

Optimasi biaya bukan berarti menyuruh semua tim memakai resource kecil. Tiga strategi yang layak menjadi produk platform:

#1. Rightsizing dengan Data

Ubah request/limit berdasarkan data pemakaian nyata, bukan tebakan:

curl -s "http://opencost:9003/model/recommendation/cluster"

Hasil rekomendasi (request yang disarankan) bisa di-terapkan lewat Vertical Pod Autoscaler (VPA) dalam mode recommender untuk sementara, lalu pindah ke auto setelah terbukti.

#2. Autoscaling yang Benar

Autoscaling adalah optimasi biaya terbaik karena otomatis:

Karpenter (eksis di AWS) memberi Node Autoscaling berdasarkan workload — node disediakan saat Pod butuh, dihapus saat kosong. Ini sering menghemat 30-50% dibanding node statis.

#3. Menangani "Idle" dan "Waste"

Sumber pemborosan terbesar biasanya bukan resource besar, tapi resource yang menganggur:

• Pod tanpa traffic — service internal yang tidak dipanggil siapa pun.
• Node dengan utilization rendah — node standby yang jarang dipakai.
• Dev/staging selalu aktif — environment non-prod yang hidup 24/7 padahal hanya dipakai 8 jam.

Kebijakan platform yang efektif: scale-to-zero atau schedule untuk dev/staging (misal mati otomatis malam hari), dan deteksi Pod idle via metrik.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payments-api
  namespace: team-payments-prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payments-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

#Kebijakan Biaya sebagai Produk

Platform engineer mengemas FinOps sebagai produk dengan:

1. Cost dashboard per tim (self-service, bukan minta ke finance).
2. Budget alert — peringatan otomatis saat biaya tim melewati threshold.
3. Rekomendasi optimasi — daftar rightsizing yang bisa di-apply satu klik.
4. Standar label dan tagging — di-enforce dengan policy.
5. Review bulanan — sesi showback bersama tim, bukan hanya email.

Contoh budget alert dengan Prometheus:

groups:
  - name: cost
    rules:
      - alert: MonthlyBudgetWarning
        expr: |
          sum(kubecost_namespace_total_monthly_cost) by (namespace) > 1000
        for: 2h
        labels:
          severity: ticket
        annotations:
          summary: "Biaya namespace {{ $labels.namespace }} bulan ini di atas $1000"

#Common Pitfalls

1. Tanpa label, tanpa data — cost allocation kosong karena resource tidak bertag.
2. Mengoptimasi sebelum mengukur — keputusan hemat berdasarkan dugaan, bukan data.
3. Autoscaling yang salah konfigurasi — HPA tanpa metrik yang tepat justru membuat biaya naik.
4. Chargeback prematur — perang data dan politik sebelum data solid.
5. Mengabaikan hidden cost — egress network, snapshot, dan observability stack sendiri sering mendominasi tagihan.

#Penutup

Inti yang harus dibawa pulang:

• FinOps = Inform → Optimize → Operate; platform membangun fondasi datanya.
• Label adalah segalanya untuk cost allocation; enforce dengan policy.
• OpenCost/KubeCost memberikan visibilitas per tim/service secara self-service.
• Showback dulu, chargeback belakangan; optimasi berbasis data + autoscaling.

Di episode 12 selanjutnya kita membuat developer tidak lagi bergantung pada tiket: self-service developer experience — portal self-service, request workflows, dan approval flow yang mengubah "minta ke platform team" menjadi "klik sendiri". Inilah puncak dari semua abstraksi yang kita bangun!