Platform Engineering 2026: Mengapa 80% Enterprise Indonesia Punya Tim Platform Tapi Developer Masih Bypass IDP?

Tahun 2026 menandai titik balik bagi platform engineering di Indonesia. Menurut laporan Gartner terbaru, 80% enterprise di Indonesia telah membentuk tim platform engineering — angka yang melonjak drastis dari 45% pada 2024. Namun di balik angka megah itu tersembunyi paradox yang mengkhawatirkan: 64% developer masih memilih bypass Internal Developer Platform (IDP) yang dibangunkan dengan investasi jutaan dolar, kembali ke workflow manual melalui kubectl, Terraform scripts, dan CI/CD pipeline yang fragmentasi.

Paradox Adopsi: Investasi Besar, Penggunaan Kecil

Data dari survei CNCF End User Survey Juli 2025 menunjukkan bahwa organisasi Indonesia rata-rata mengeluarkan $2.3 juta per tahun untuk membangun dan memelihara IDP. Namun metrics adopsi nyata — diukur dari persentase deployment yang melewati golden path, jumlah service catalog yang aktif digunakan, dan kurangi toil untuk onboarding developer baru — masih stagnan di angka 36%.

Root cause-nya bukan teknologi. Backstage (89% market share IDP), ArgoCD (60% GitOps adoption), dan CrossPlane sudah matang. Masalahnya adalah product mindset. Banyak tim platform berperan sebagai "internal IT" yang mengeluarkan ticket JIRA untuk setiap infrastructure request, bukan sebagai product team yang mengoptimalkan developer experience (DevEx) sebagai north star metric.

Pola Gagal Khusus Indonesia: "Lift and Shift" Ke Kubernetes Tanpa Abstraksi

Berbeda dengan enterprise di US/EU yang mulai adopsi platform engineering sejak 2021-2022, mayoritas enterprise Indonesia baru memulai perjalanan ini pada 2024-2025 mendorong oleh mandat "cloud native" dari manajemen atas. Akibatnya, pola anti-pattern yang sering terulang:

• Golden path terlalu preskriptif: Template Helm chart yang memaksa semua service menggunakan config yang sama, mengabaikan kebutuhan spesifik ML workload vs high-throughput API vs batch processing.
• Self-service yang tidak self: Developer tetap harus buat ticket ke platform team untuk menambah environment variable, ubah resource limit, atau expose service ke internet.
• Observability gap: IDP tidak terintegrasi dengan observability stack (Grafana, Datadog, atau ELK), sehingga developer tidak bisa debug production issue tanpa akses cluster langsung.

Insight Kunci: Platform engineering bukan tentang membangun tools, tapi mengurangi cognitive load developer. Jika IDP menambah langkah (extra CLI, extra approval, extra YAML), bukan mengurangi — platform gagal.

Arsitektur IDP Yang Berfungsi: Reference Architecture 2026

Berdasarkan pola sukses di Gojek (internal platform "Gojek Platform"), Tokopedia ("Toko Platform"), dan Traveloka ("Traveloka Infra"), arsitektur IDP modern 2026 memiliki 4 layer:

1. Control Plane Layer (GitOps + Policy as Code)

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: golden-path-services
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://git.sobatjagoan.com/platform/golden-paths.git
      revision: main
      directories:
      - path: services/*
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: platform
      source:
        repoURL: https://git.sobatjagoan.com/platform/golden-paths.git
        path: '{{path}}'
        targetRevision: main
      destination:
        server: 'https://kubernetes.default.svc'
        namespace: '{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
        - CreateNamespace=true
        - ApplyOutOfSyncOnly=true

2. Developer Portal Layer (Backstage + Custom Plugins)

Jangan gunakan Backstage vanilla. Enterprise Indonesia yang sukses membangun plugin custom untuk:

• Service Scaffolding: Generator yang produce tidak hanya Kubernetes manifest, tapi sudah include: CI/CD pipeline (Woodpecker/Gitea Actions), observability dashboard (Grafana), alerting rules, dan runbook template.
• Cost Attribution: Integrasi dengan FinOps tool (kubecost atau custom) menampilkan cost per service per environment real-time di portal.
• Compliance Scorecard: Otomatis cek: network policy exists, resource limits defined, pod security standards, image signature verified.

3. Platform API Layer (CrossPlane + Composition Functions)

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xidp.service.platform.jagoanhosting.com
spec:
  compositeTypeRef:
    apiVersion: platform.jagoanhosting.com/v1alpha1
    kind: XService
  mode: Pipeline
  pipeline:
  - functionRef:
      name: function-go-template
    input:
      apiVersion: gotemplating.fn.crossplane.io/v1alpha1
      kind: GoTemplate
      source: Inline
      inline:
        template: |
          {{- $svc := .observed.composite.resource.spec }}
          apiVersion: v1
          kind: Namespace
          metadata:
            name: {{ $svc.name }}
            labels:
              platform.jagoanhosting.com/managed-by: crossplane
              environment: {{ $svc.environment }}
          ---
          apiVersion: argoproj.io/v1alpha1
          kind: Application
          metadata:
            name: {{ $svc.name }}
            namespace: argocd
          spec:
            project: {{ $svc.environment }}
            source:
              repoURL: {{ $svc.repoUrl }}
              path: {{ $svc.path }}
              targetRevision: {{ $svc.revision }}
            destination:
              server: https://kubernetes.default.svc
              namespace: {{ $svc.name }}
            syncPolicy:
              automated:
                prune: true
                selfHeal: true

4. Golden Path Templates (Versioned, Tested, Documented)

Setiap golden path adalah git repository terpisah dengan semantic versioning. Contoh struktur:

golden-path-java-springboot/
├── v1.2.0/
│   ├── Chart.yaml
│   ├── values.yaml
│   ├── values-prod.yaml
│   ├── values-staging.yaml
│   ├── templates/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   ├── ingress.yaml
│   │   ├── servicemonitor.yaml
│   │   └── networkpolicy.yaml
│   ├── .github/workflows/
│   │   └── test-chart.yaml
│   ├── README.md
│   └── RUNBOOK.md
├── v1.3.0-rc1/
└── README.md  # migration guide v1.2 -> v1.3

Roadmap 12 Minggu: Dari Zero ke IDP Yang Dipakai

Berdasarkan pengalaman implementasi di 5 enterprise Indonesia (fintech, e-commerce, logistics, telco, media), roadmap pragmatis:

Tantangan Khusus Indonesia: Regulasi, Talent, dan Budaya

Tiga faktor lokal yang memperlambat adopsi:

1. Regulasi Data Sovereignty: BSSN dan UU PDP memaksa data tertentu stay on-prem. IDP harus support hybrid deployment (EKS/GKE/AKS + on-prem K3S/RKE2) dengan control plane terpusat.
2. Talent Gap: Platform engineer di Indonesia masih langka. Solusi: upskill senior DevOps/SRE internal + hire 1-2 platform engineer senior sebagai anchor, bukan build team dari nol.
3. Budaya "Ticket-Driven": Developer terbiasa request infra via JIRA/ServiceNow. Perubahan mindset butuh executive sponsorship dan quick wins yang terlihat (misal: provision DB dari 3 hari jadi 5 menit).

Kesimpulan: Platform Engineering Adalah Product, Bukan Project

Enterprise Indonesia yang sukses platform engineering 2026 memiliki ciri khas sama: platform team diorganisasi sebagai product team dengan product manager, roadmap quarterly, OKR berbasis DevEx metrics (deployment frequency, lead time, change failure rate, MTTR, developer NPS), dan budget ops yang terproteksi dari cost-cutting IT.

Jika organisasi Anda masih memandang platform engineering sebagai "DevOps 2.0" atau "modernisasi infra", paradox 80/64 akan terus berulang. Mulai behanding platform sebagai product, developer sebagai customer, dan DevEx sebagai revenue metric. Baru maka investasi IDP akan mengembalikan ROI yang dijanjikan.

Artikel ini bagian dari seri Platform Engineering Indonesia 2026. Artikel selanjutnya: "Building Golden Path Templates Yang Developer Mau Pakai: Lessons dari 3 Unicorn Indonesia".