kertenkerem_
· DevOps · 5 dk okuma

Platform Mühendisliğinde Internal Developer Portal (IDP) Kurulumu: Backstage mi, Port mu?

Modern Platform Engineering pratiklerinin merkezinde tek bir hedef var: Kognitif yükü azaltıp Developer Experience (DevX) çıtasını yukarı çekmek. Ancak bir sabah uyanıp “Hadi şirkete bir IDP kuralım” dediğinizde DevOps dünyasının iki büyük kutbu önünüze dikiliyor: Açık kaynak kodlu, Spotify kökenli Backstage ve SaaS/API-first yaklaşımıyla son dönemin parlayan yıldızı Port. Bu iki aracın broşür vaatlerini bir kenara bırakıp üretim ortamındaki gerçek maliyetlerine, mimari esnekliklerine ve Day-2 operasyonlarına bakalım.

SlackOps’tan self-service’e: Neden bir IDP’ye ihtiyacımız var?

Kabul edelim, şirket içinde yazdığınız bash script’leri, Terraform modülleri ve “production-hazır” Helm chart’ları güzel çalışıyor olabilir. Fakat yazılımcı yeni bir microservice açmak için hâlâ Slack kanalından “#devops-help bana yeni bir Redis açar mısınız?” yazıyorsa, ortada bir platform yok, yalnızca insan gücüyle çalışan bir bilet kuyruğu var. IDP; Golden Path (Altın Yol) felsefesini somutlaştıran, altyapı yetkilendirmesini ve servis kataloğunu tek bir panelde toplayan arayüzdür.

1. Spotify Backstage: Kodun gücü ve bakımın laneti

Backstage bir ürün değil, bir framework’tür. TypeScript ve React ile yazılmış bir monorepo iskeletidir. Kurulumu yaptığınız an elinizde bitmiş bir portal olmaz, sizin geliştirmeniz gereken bir yazılım projesi olur.

Backstage mimarisi ve plugin ekosistemi

Backstage’in en büyük artısı limitsiz özelleştirilebilmesidir. Şirket içi legacy bir LDAP sisteminiz ya da kurum içi custom bir deployment engine’iniz varsa, Backstage’e plugin yazarak entegre edemeyeceğiniz hiçbir şey yoktur. Servislerinizi catalog-info.yaml dosyalarıyla declarative olarak tanımlarsınız:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-gateway-service
  description: Core payment processing engine
  annotations:
    github.com/project-slug: acme-corp/payment-gateway
    backstage.io/techdocs-ref: dir:.
    argocd/app-name: payment-gateway-prod
    prometheus.io/rule: alert_payment_latency
spec:
  type: service
  lifecycle: production
  owner: payments-team
  system: core-banking
  providesApis:
    - payment-api
  dependsOn:
    - resource:default/payment-postgres-db

Yazılım şablonları (Software Templates) ile self-service

Backstage Scaffolder, geliştiricinin parametreleri girdiği ve arka planda bir Git repo’su oluşturup ilk commit’i attığı şablon mekanizmasıdır:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: go-service-template
  title: Go Microservice (Golden Path)
spec:
  owner: platform-core
  type: service
  parameters:
    - title: Servis Konfigürasyonu
      required: [name, owner]
      properties:
        name:
          type: string
          description: Servis adı (kebab-case)
        owner:
          type: string
          ui:field: OwnerPicker
  steps:
    - id: template
      name: Dosyaları Hazırla
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: GitHub Reposu Aç
      action: publish:github
      input:
        allowedHosts: ['github.com']
        description: Service created via Backstage
        repoUrl: github.com?owner=acme-corp&repo=${{ parameters.name }}
        defaultBranch: main

Neden can sıkar?

  • Node.js dependency cehennemi: Her yarn upgrade çalıştırdığınızda core plugin’lerin kırılma ihtimali çok yüksektir.
  • Frontend eforu: Platform ekibinde React ve modern frontend toolchain’lerine hâkim mühendis yoksa arayüz geliştirmeleri kabusa dönüşür.
  • State ve DB yönetimi: Catalog senkronizasyonu için PostgreSQL tutmanız, cache stratejilerini (Redis) yönetmeniz ve auth mekanizmalarını tek tek implemente etmeniz gerekir.

2. Port (getport.io): Data-model first ve low-code IDP

Port, Backstage’in tam zıddı bir felsefeyle gelir: “Siz platform mühendisisiniz, frontend geliştiricisi değilsiniz.” Port bir SaaS ya da Control-Plane-Only çözümüdür. UI tarafında tek satır kod yazmazsınız; her şey Blueprints (Veri Modelleri) ve Actions (Eylemler) üzerinden kurgulanır.

Entity ve Blueprint mantığı

Port’ta altyapınızı bir Graph Database gibi modellersiniz. Bir Kubernetes Cluster’ı bir Microservice’e, o Microservice de bir RDS instance’ına ve bir PagerDuty On-Call rotasyonuna bağlanabilir.

Bu modeli Terraform ile Infrastructure as Code (IaC) prensibine uygun şekilde yönetebilirsiniz:

# Port Terraform Provider ile Blueprint tanımı
resource "port_blueprint" "microservice" {
  title      = "Microservice"
  icon       = "Microservice"
  identifier = "microservice"
  properties = {
    string_props = {
      "language" = {
        title = "Language"
        enum  = ["Go", "NodeJS", "Python"]
      }
      "slack_channel" = {
        title = "Slack Channel"
      }
    }
  }
}

resource "port_action" "scaffold_service" {
  title       = "Scaffold New Microservice"
  icon        = "Github"
  identifier  = "create_microservice"
  blueprint   = port_blueprint.microservice.identifier
  trigger_type = "self-service"

  user_inputs = {
    string_props = {
      "service_name" = {
        title = "Service Name"
      }
    }
  }

  backend_invocation = {
    type = "github"
    org  = "acme-corp"
    repo = "platform-scaffolder-workflows"
    workflow = "scaffold.yaml"
  }
}

Kubernetes ve CI/CD entegrasyonu: Port Exporter

Backstage katalog için repo taraması (polling) yaparken Port event-driven çalışır. Cluster’ınıza kurduğunuz bir exporter agent, kaynakları dinamik olarak Port paneline push eder:

helm repo add port-labs https://port-labs.github.io/helm-charts
helm repo update

helm install port-k8s-exporter port-labs/port-k8s-exporter \
  --set port.clientId="YOUR_CLIENT_ID" \
  --set port.clientSecret="YOUR_CLIENT_SECRET" \
  --values values.yaml

Burada values.yaml içinde basit JQ mapping’leri tanımlayarak Kubernetes CRD’lerinizi doğrudan UI component’lerine dönüştürebilirsiniz. Sıfır React, sıfır TypeScript.

Derin kıyaslama: Hangi senaryoda hangisi?

1. Bakım maliyeti (Total Cost of Ownership)

Backstage açık kaynak ve “bedava” gibi görünse de en az 1-2 platform mühendisinin tam zamanlı mesaisini tüketir. Güvenlik yamaları, TypeScript bağımlılıkları ve plugin güncellemeleri ciddi bir yüktür. Port ise SaaS lisans maliyeti getirir, ama kurulumu günler içinde tamamlanır ve minimum eforla ayakta tutulur.

2. Esneklik ve kurumsal uyum

Kurum içi compliance politikalarınız multi-tenant SaaS kullanımına izin vermiyorsa, air-gapped ortamlarda çalışıyorsanız ya da tamamen şirketinizin UI design system’ına (örneğin kurumsal Material UI teması) gömülmüş bir portal istiyorsanız Backstage tek seçenektir. Port hibrit çalışabilir (self-hosted exporter ve runner modelleriyle verinizi içeride tutabilir) ancak UI kontrolü her zaman onlardadır.

3. Self-service workflow tetikleme

Backstage kendi Scaffolder motoruna güvenir: Node.js backend’i üzerinde repo klonlar, commit atar ve PR açar. Port ise orkestrasyonu var olan araçlarınıza devreder: GitHub Actions, GitLab CI, Argo Workflows ya da doğrudan bir Webhook. DevOps mühendisi için Port’un bu yaklaşımı çok daha doğaldır, çünkü CI pipeline’ı yazmak Scaffolder Action yazmaktan katbekat hızlıdır.

Karar ağacı

Mimarinize karar verirken şu kontrol listesini uygulayabilirsiniz:

  • Ekip büyüklüğü: 150+ yazılımcınız ve sadece portal geliştirmeye adanmış 3+ kişilik bir Platform Engineering ekibiniz varsa: Backstage.
  • Hızlı değer üretimi (Time-to-Value): 20-100 kişilik yazılımcı grubuna hizmet veren yalın bir DevOps ekibiyseniz ve iki hafta içinde bir katalog + self-service portal istiyorsanız: Port.
  • Arayüz ihtiyacı: “Bize standart bir dashboard yetmez, production tracing ve billing verilerini custom canvas grafikleriyle basacağız” diyorsanız: Backstage.
  • IaC ve GitOps entegrasyonu: Portalı da Terraform ile yönetip altyapı state’i gibi kontrol etmek istiyorsanız: Port.

Özet

Platform mühendisliğinin amacı yeni bir monorepo yazılım bakım yükü yaratmak değil, yazılım ekiplerinin önündeki altyapı bariyerlerini kaldırmaktır. Bir yazılım evi değilseniz ve temel yetkinliğiniz portal geliştirmek değilse, operasyonel yükü en aza indirmek için Port gibi modern platformlar daha rasyoneldir. Ancak regülasyonların boğduğu, UI üzerinde tam egemenlik isteyen devasa bir kurumsal yapıdaysanız, Backstage’in getirdiği bakım yükünü göze alıp kendi iç ürününüzü inşa etmek doğru yoldur.