Platform Engineering: Cara Membina Internal Developer Platform

Apabila sistem perisian menjadi semakin kompleks - mikroservis, Kubernetes, multi-cloud, pipeline CI/CD, timbunan observabiliti - pembangun menghabiskan lebih banyak masa pada infrastruktur dan kurang masa membina produk. Platform Engineering menyelesaikan masalah ini dengan mencipta platform dalaman yang mengabstrakkan kerumitan dan menyediakan pembangun alat layan diri untuk penghantaran lebih pantas.

Gartner meramalkan menjelang 2027, 80% organisasi kejuruteraan perisian akan menubuhkan pasukan platform. Dalam panduan ini, kita akan meneroka apa itu Platform Engineering, mengapa ia penting, dan cara membina Internal Developer Platform dari awal.

Apa itu Platform Engineering?

Platform Engineering ialah disiplin mereka bentuk dan membina rantaian alat dan aliran kerja yang membolehkan keupayaan layan diri untuk organisasi kejuruteraan perisian. Hasilnya ialah Internal Developer Platform (IDP) - satu lapisan yang berada di antara pembangun dan infrastruktur.

Platform Engineering vs DevOps

Platform Engineering bukan pengganti DevOps - ia adalah evolusi seterusnya. DevOps berkata "anda bina, anda jalankan." Platform Engineering berkata "kami akan menjadikan pembinaan dan penjalanan mudah."

Mengapa Platform Engineering Penting

Masalah Beban Kognitif

Dalam organisasi moden biasa, seorang pembangun perlu memahami:

• Aliran kerja Git dan strategi pencabangan
• Konfigurasi pipeline CI/CD
• Pembinaan kontena dan pengurusan registri
• Manifest Kubernetes dan Helm Charts
• Perkhidmatan penyedia awan (AWS/GCP/Azure)
• Rangkaian, DNS, sijil TLS
• Persediaan pemantauan, pengelogan, amaran
• Peruntukan dan migrasi pangkalan data
• Dasar keselamatan dan pematuhan

Itu adalah beban kognitif yang sangat besar yang mengalihkan fokus daripada produk sebenar.

Golden Path

Platform Engineering memperkenalkan konsep golden path - laluan yang berpendirian, disokong dengan baik, dan didokumenkan untuk tugas-tugas biasa. Golden path bukan mandat; pembangun boleh menyimpang, tetapi platform menjadikan perkara yang betul sebagai perkara yang mudah.

Contoh golden path untuk mencipta mikroservis baharu:

1. Pembangun memilih "Perkhidmatan Backend Baharu" di portal
2. Memilih bahasa/rangka kerja (Node.js, Go, Python)
3. Platform mencipta secara automatik: repositori Git, pipeline CI/CD, namespace Kubernetes, papan pemuka pemantauan, dan peraturan amaran
4. Pembangun mengklon repositori dan mula mengekod serta-merta

Membina Internal Developer Platform

Lapisan 1: Developer Portal

Portal ialah titik masuk tunggal untuk pembangun. Pilihan sumber terbuka paling popular ialah Backstage (dicipta oleh Spotify, kini projek CNCF).

Ciri-ciri utama:

• Katalog perkhidmatan: Setiap perkhidmatan, pemiliknya, dokumentasi, dan kebergantungan
• Templat perisian: Perancah untuk perkhidmatan baharu dengan amalan terbaik terbina
• Dokumentasi teknikal: Dokumentasi sebagai kod, dipapar dan boleh dicari
• Ekosistem plugin: Boleh dikembangkan dengan fungsi tersuai

# backstage/catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: user-service
  description: Manages user accounts and authentication
  annotations:
    github.com/project-slug: myorg/user-service
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: team-auth
  system: identity-platform
  dependsOn:
    - resource:postgresql-main
  providesApis:
    - user-api

Lapisan 2: Abstraksi Infrastruktur

Pembangun tidak sepatutnya menulis Terraform atau Kubernetes YAML secara langsung. Platform sepatutnya menyediakan abstraksi.

Alat:

• Crossplane: Peruntukan infrastruktur asli Kubernetes
• Terraform dengan modul: Modul infrastruktur pra-bina dan diuji
• Pulumi: Infrastruktur sebagai kod sebenar (TypeScript, Python, Go)

# Example: Crossplane composition for a database
apiVersion: database.example.com/v1
kind: PostgreSQLInstance
metadata:
  name: user-db
spec:
  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
  version: "16"
  backup: daily
  team: auth-team

Daripada mengkonfigurasi parameter RDS, subnet VPC, kumpulan keselamatan, dan dasar sandaran, pembangun hanya menyatakan size: small dan backup: daily. Platform menguruskan yang selebihnya.

Lapisan 3: Penstandardan CI/CD

Standardkan CI/CD supaya pasukan tidak membina pipeline masing-masing.

# .github/workflows/platform-ci.yml
# Teams just include the shared workflow
name: Build and Deploy
on:
  push:
    branches: [main]

jobs:
  pipeline:
    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
    with:
      language: node
      deploy-target: production
    secrets: inherit

Amalan utama:

• Templat CI/CD kongsi yang disertakan oleh pasukan (bukan disalin)
• Pengimbasan keselamatan automatik (SAST, audit kebergantungan)
• Strategi penggunaan yang distandardkan (canary, blue/green)
• Rollback automatik apabila health check gagal

Lapisan 4: Observabiliti

Pemantauan pra-konfigurasi supaya pembangun mendapat papan pemuka dan amaran sedia untuk digunakan.

• Metrik: Prometheus + Grafana dengan papan pemuka standard setiap perkhidmatan
• Pengelogan: Pengelogan berstruktur dengan pengumpulan berpusat (Loki, ELK)
• Pengesanan: Pengesanan teragih dengan OpenTelemetry
• Amaran: Integrasi PagerDuty/Opsgenie dengan lalai yang munasabah

Mengukur Kejayaan

Bagaimana anda tahu platform anda berfungsi? Jejak metrik ini:

Metrik DORA

• Kekerapan penggunaan: Berapa kerap kod sampai ke pengeluaran
• Masa utama untuk perubahan: Masa dari commit ke pengeluaran
• Kadar kegagalan perubahan: Peratusan penggunaan yang menyebabkan kegagalan
• Masa purata pemulihan: Masa untuk memulihkan perkhidmatan selepas insiden

Metrik Khusus Platform

• Masa ke deploy pertama: Berapa lama dari "perkhidmatan baharu" ke deploy pengeluaran pertama
• Kepuasan pembangun (NPS): Tinjau pengguna anda dengan kerap
• Nisbah layan diri: % permintaan infrastruktur yang dikendalikan tanpa tiket
• Penggunaan golden path: % perkhidmatan yang mengikuti laluan yang disyorkan

Kesilapan Biasa

1. Membina Terlalu Banyak, Terlalu Awal

Mulakan dengan titik kesakitan terbesar, bukan visi besar. Jika penggunaan menyakitkan, mulakan di situ. Jika peruntukan mengambil masa berminggu-minggu, mulakan di situ.

2. Tidak Melayan Platform sebagai Produk

Pasukan platform memerlukan pengurus produk, penyelidikan pengguna, dan gelung maklum balas. Pembangun adalah pelanggan anda - fahami keperluan mereka.

3. Mewajibkan Berbanding Menarik

Platform terbaik diterima secara sukarela kerana menjadikan kehidupan pembangun lebih mudah. Jika anda perlu mewajibkan penggunaan, platform anda tidak cukup baik.

4. Mengabaikan Pengalaman Pembangun

Platform dengan UX yang teruk tidak akan digunakan. Laburkan dalam dokumentasi yang jelas, mesej ralat yang membantu, dan gelung maklum balas yang pantas.

Memulakan

Peta jalan praktikal untuk membina IDP pertama anda:

Platform Minimum Berdaya Maju

1. Katalog perkhidmatan (Backstage) - tahu apa yang wujud dan siapa pemiliknya
2. Satu templat perkhidmatan - golden path untuk jenis perkhidmatan paling biasa anda
3. CI/CD yang distandardkan - pipeline kongsi yang disertakan oleh pasukan
4. Dokumentasi asas - cara menggunakan platform, di mana mendapatkan bantuan

Anda boleh membina MVP ini dalam 2-3 bulan dengan pasukan 2-3 jurutera.

Kesimpulan

Platform Engineering bukan tentang membina platform sempurna dari hari pertama. Ia tentang mengurangkan beban kognitif pembangun secara berperingkat supaya mereka boleh fokus membina produk. Mulakan kecil, ukur impak, dan iterasi berdasarkan maklum balas pembangun.

Organisasi yang melabur dalam Platform Engineering akan mempunyai kelebihan daya saing yang signifikan: penghantaran lebih pantas, pembangun lebih gembira, dan sistem lebih boleh dipercayai.

Sumber:

• Team Topologies - buku yang mempopularkan pasukan platform
• Backstage - portal pembangun sumber terbuka Spotify
• CNCF Platforms White Paper - definisi komuniti dan amalan terbaik
• platformengineering.org - komuniti, acara, dan sumber