Belajar Backstage - Sejarah, Latar Belakang & Mengapa Membutuhkan Backstage

#Pendahuluan

Di episode 0, kalian menyiapkan skill dasar dan perangkat yang dibutuhkan: Node.js 20+, Yarn 4, Docker, Git, dan lainnya. Episode 1 ini berhenti sejenak dari tooling untuk memahami mengapa Backstage ada. Sebuah teknologi tidak muncul dari ruang hampa — ia lahir dari evolusi cara organisasi membangun dan menjalankan software. Memahami konteks sejarah ini akan membuat keputusan arsitektur Backstage di episode-episode berikutnya terasa masuk akal.

#Evolusi Platform Engineering

#Era DevOps (1990s - 2010s)

Pada era DevOps, tim engineering mulai memadukan pengembangan dan operasi. Proses release yang dulu menunggu jadwal bulanan perlahan berubah menjadi pipeline otomatis dengan commit, build, dan deploy yang lebih sering. Alat bantu seperti CI/CD muncul dan culture kolaborasi antara developer dan operator menjadi nilai utama. Namun pada masa ini, software masih didominasi monolith — satu aplikasi besar yang di-deploy utuh.

#Microservices Explosion

Masalah mulai terasa ketika monolith dipecah menjadi banyak service kecil. Setiap service bisa dideploy, di-scaling, dan dikembangkan secara independen. Jumlah service pun meroket: dari puluhan menjadi ratusan bahkan ribuan. Kondisi ini disebut microservices explosion. Tiap tim punya repositori, pipeline, dan cara kerja sendiri. Pada titik ini, persoalan teknis bergeser dari "bagaimana menulis kode" menjadi "bagaimana menemukan kode yang sudah ada".

Efek samping lain dari ledakan ini adalah kebutuhan tooling baru: service discovery, observability, dan manajemen versi API menjadi beban yang tidak pernah ada sebelumnya. Tim mulai menyadari bahwa membangun service hanyalah awal — mengelolanya di skala besar adalah tantangan sesungguhnya.

#Masalah Discoverability dan Cognitive Overload

Ketika service berjumlah ribuan, para engineer mulai mengalami dua masalah besar:

• Discoverability — engineer tidak tahu service apa yang sudah ada, siapa pemiliknya, di mana dokumentasinya, dan bagaimana cara mengintegrasikannya.
• Cognitive overload — informasi tersebar di banyak repositori, wiki, chat, dan dokumen yang tidak sinkron. Menyambungkan satu service baru berarti menjelajahi lautan informasi yang saling bertabrakan.

Dampaknya: waktu yang seharusnya untuk menulis fitur habis untuk mencari informasi dan menunggu jawaban dari tim platform. Pada titik tertentu, bottleneck bukan lagi kecepatan menulis kode, tetapi kecepatan menemukan dan memahami apa yang sudah ada.

#Lahirnya Platform Engineering dan IDP

Dari masalah itu lahirlah disiplin Platform Engineering — praktik membangun lapisan alat bantu dan layanan internal yang membuat engineer bisa self-service. Konsep utamanya adalah golden path: jalur yang sudah teruji untuk hal-hal umum seperti membuat service baru, men-deploy, dan mengelola infrastruktur. Lapisan ini dikenal sebagai Internal Developer Platform (IDP), dan Backstage adalah salah satu implementasi IDP yang paling terkenal.

Ringkasan evolusinya:

#Asal Usul Backstage

Perjalanan Backstage dari alat internal menjadi standar industri tidak lepas dari tiga tonggak utama: kelahiran di Spotify, keterbukaan kodenya, dan penerimaan luas komunitas. Ketiganya dijelaskan di bawah.

#Dibuat oleh Spotify (2016/2017)

Backstage lahir dari kebutuhan internal Spotify. Perusahaan musik itu menjalankan ribuan service internal yang dikelola ratusan tim engineer. Masalahnya persis seperti yang sudah dijelaskan: engineer tidak bisa menemukan service yang relevan, dokumentasi tersebar, dan onboarding service baru terasa seperti pekerjaan besar. Spotify mulai membangun Backstage sekitar 2016/2017 sebagai katalog dan control plane internal untuk semua service tersebut.

#Open Source dan Donasi ke CNCF (2020)

Tahun 2020, Spotify mengambil keputusan penting: membuka kode Backstage secara open-source dan kemudian mendonasikannya ke Cloud Native Computing Foundation (CNCF) dengan status incubating. Sejak saat itu Backstage dikembangkan bersama komunitas, bukan hanya oleh satu perusahaan. Model pengelolaan semacam ini memastikan Backstage tetap netral dan tidak terikat kepentingan vendor tertentu. Status incubating juga berarti proyek dianggap sehat dan layak digunakan, dengan tata kelola yang jelas di bawah naungan CNCF.

#Standar De Facto Developer Portal

Kombinasi fitur, ekosistem plugin, dan dukungan komunitas membuat Backstage tumbuh pesat. Banyak perusahaan besar mengadopsinya dan menjadikannya standar de facto untuk developer portal. Kini Backstage menjadi titik awal yang wajar ketika sebuah organisasi ingin membangun IDP-nya sendiri tanpa memulai dari nol.

#Masalah yang Diselesaikan Backstage

Backstage dibangun untuk menjawab langsung masalah-masalah yang muncul sepanjang evolusi di atas:

Bayangkan sebuah catalog-info.yaml yang mendeskripsikan setiap service — satu file yang menjadi sumber kebenaran tentang nama, tipe, dan pemilik service tersebut:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: order-service
spec:
  type: service
  owner: team-checkout

File semacam ini akan kalian buat dan kelola lebih dalam di episode 4. Untuk sekarang, catalog-info.yaml adalah contoh konkret dari "katalog software tunggal" yang menjadi jawaban Backstage atas masalah discoverability.

#Backstage vs Pendekatan Tradisional

Sebelum Backstage, banyak organisasi mencoba menyelesaikan masalah discoverability dengan cara konvensional — dan hasilnya selalu kurang:

Backstage menutup celah ini dengan menjadikan kode sebagai sumbernya: catalog-info.yaml hidup di repositori yang sama dengan kode, sehingga catalog selalu sinkron dengan kenyataan. Tidak ada proses manual untuk memperbarui entri — perubahan di repositori langsung tercermin di portal. Inilah yang membuat Backstage berbeda dari sekadar dokumen atau spreadsheet: kebenarannya dijaga oleh alur kerja Git yang sudah dipakai tim engineering sehari-hari.

#Penutup

Pada episode 1 ini, kalian memahami konteks kelahiran Backstage: evolusi dari era DevOps, ledakan microservices, masalah discoverability dan cognitive overload, hingga lahirnya platform engineering dan IDP. Kalian juga tahu asal usul Backstage dari Spotify, perjalanannya menjadi proyek CNCF incubating, dan mengapa ia menjadi standar de facto developer portal.

Inti yang harus dibawa pulang:

• Backstage lahir dari masalah nyata — ribuan service yang sulit ditemukan dan dipahami.
• IDP adalah jawaban atas toil — self-service menggantikan antrean ticket.
• Backstage bersifat netral — dikelola CNCF, bukan terikat vendor tertentu.
• Katalog tunggal adalah jantung solusinya — semua informasi tersentralisasi di satu tempat.

Di episode 2 berikutnya, kita masuk ke hal yang lebih teknis: konsep dasar dan arsitektur utama Backstage — struktur monorepo, primitif inti seperti Software Catalog dan Scaffolder, serta frontend dan backend system yang modern.