Platform Engineering: Geliştiricilerin Gerçekten Kullanmak İsteyeceği Internal Developer Platformları Oluşturmak

Bir Internal Developer Platform, mühendis ticket açmadan servisini production’a çıkarabildiği gün değerini kanıtlar. Oraya götüren varsayılan, çoğu platform yol haritasının varsaydığından dar: tek bir golden path, tek bir pilot ekiple kurulur, portal arayüzünden önce API veya CLI ile açılır ve zorunlu olduğu için değil en hızlı yol olduğu için benimsenir.

Catalog, self-servis aksiyonlar, IaC orchestration, metrikler ve araç seçimi bu varsayılanın etrafına asılır. Backstage, Port ve AWS bileşenleri, ilk golden path gönüllü benimseme kazandıktan sonra verilecek kararlardır.

Ticket Kuyruğundan Self-Servise#

Platform Engineering, software engineering organizasyonlarına self-servis yetenek kazandıran toolchain’leri ve workflow’ları tasarlama işi. Belirleyici değişim, internal developer’ları istediği an vazgeçebilecek birer müşteri olarak görmek.

Platform Engineering’i geleneksel DevOps’tan ayıran nedir?

Temel fark platform-as-a-product zihniyeti. DevOps ekiplerinin ticket’lara yanıt veren servis sağlayıcılar olarak hareket etmesi yerine, platform ekipleri geliştiricilerin gönüllü olarak seçtiği araçlar oluşturan product owner’lar haline geliyor.

Değişim, bir geliştirici deployment’a ihtiyaç duyduğunda duyduğu cümlede görünüyor:

• DevOps: “Bunu senin için deploy ederiz (ticket gerekli)”
• Platform Engineering: “İşte 5 dakikada kendin nasıl deploy edeceksin”

Platform Engineering neden ivme kazanmaya devam ediyor?

İki baskı aynı yöne itiyor. Cloud-native yığın sürekli yeni parça ekliyor; ticket’lara yanıt veren tek bir ortak ekip ise ilk birkaç düzine servisten sonra ölçeklenmeyi bırakıyor. Platform ekibi bu karmaşıklığı bir kez soğuruyor ki her ürün ekibi ayrı ayrı soğurmak zorunda kalmasın.

Temel Felsefe:

Pratikte en belirleyici prensipler şunlardır:

• Self-servis aracılığıyla developer güçlendirme (yerine geçilen şey ticket kuyruğu)
• Esnekliği azaltmadan standardizasyon (golden path’ler çıkış rampasıyla gelir)
• Bilişsel yükü azaltma (iyi çalışan tek yol on seçeneği yener)
• Hız ve güvenliği aynı anda sağlama (korkuluklar yolun içinde durur)
• Product thinking’i internal araçlara uygulama (önce araştırma, sonra inşa)

Internal Developer Platform’un Temel Bileşenleri#

İşte pratikte çalışan etkili bir IDP’yi oluşturan unsurlar:

Software Catalog / Service Catalog#

Tüm servislerin, API’lerin, kaynakların ve ekiplerin merkezi kaydı. Değerini ancak iki soruyu anında yanıtladığı sürece koruyor: buna kim sahip, ne neye bağlı?

Backstage, YAML tabanlı catalog entity’leri kullanıyor (Component, System, API, Resource, User, Group, Domain). Anahtar, catalog-as-code için GitHub veya GitLab ile version control entegrasyonu:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: user-service
  description: User management microservice
  annotations:
    github.com/project-slug: org/user-service
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: team-platform
  system: user-management
  providesApis:
    - user-api
  consumesApis:
    - auth-api
  dependsOn:
    - resource:user-database

Golden Paths / Paved Roads#

“Golden Paths” terimi Spotify’dan geliyor (Netflix aynı konsepte “Paved Roads” diyor). Pratikte en iyi oturan tanım: yazılım geliştirmenin ve deploy etmenin, belirli bir yaklaşımı benimseyen, iyi dokümante edilmiş ve desteklenen yolu.

Etkili golden path özellikleri:

• Tamamen self-servis (ticket açmak gerekmiyor)
• Minimal bilişsel yük (mantıklı default’lar, açık dokümantasyon)
• Keşfedilebilir organizasyondaki herkes tarafından
• İsteğe bağlı ama en pratik (benimseme, en kolay yol olmaktan doğar)
• Doğal olarak standardizasyon sağlar (insanlar daha iyi olduğu için seçiyor)

Golden path’lerin teknik örnekleri:

• Standardize servis template’leri (30 dakikada yeni microservice)
• Önceden yapılandırılmış CI/CD pipeline’ları (test + deployment hazır)
• Infrastructure-as-Code modülleri (yaygın pattern’ler kullanıma hazır)
• Containerization blueprint’leri (security baseline dahil)
• Monitoring ve observability önceden bağlı (sonradan instrumentation yok)

Self-Service Actions / Developer Portal#

Platform yetenekleri için UI katmanı. Geliştiricilerin beklemeden servis oluşturmak, environment deploy etmek, database provision etmek için platformla etkileşime geçtiği yer.

Yaygın implementasyonlar web portal’ları, CLI araçları, IDE plugin’leri ve Slack/ChatOps entegrasyonlarını içeriyor. En iyi platformlar bunların hepsini destekleyerek geliştiricilerin tercih ettikleri şekilde çalışmasına izin veriyor.

Infrastructure as Code (IaC) Orchestration#

Merkezi IaC template’leri ve modülleri tutarlı infrastructure provisioning’i sağlıyor. Version-controlled infrastructure tanımları tekrarlanabilirliği garanti ediyor.

Örnekler AWS CDK construct’ları, Terraform modülleri ve Pulumi component’lerini içeriyor. AWS Proton’un Ekim 2026’da kullanımdan kaldırılacağını unutma; ekipler şimdiden alternatif planlamalı.

CI/CD Entegrasyonu#

Otomatik test, quality gate’ler ve progressive deployment stratejileriyle (canary, blue-green) standardize pipeline template’leri. GitHub Actions, GitLab CI, Jenkins veya CircleCI ile entegrasyon.

Observability ve Monitoring#

Önceden yapılandırılmış monitoring dashboard’ları, standardize logging ve tracing, alerting template’leri ve maliyet takibi. Prometheus, Datadog, New Relic veya CloudWatch gibi araçlar burada entegre oluyor.

Security ve Compliance#

Policy-as-code enforcement, security scanning otomasyonu (SAST, DAST, dependency scanning), golden path’lere gömülü compliance korkulukları ve secret management entegrasyonu.

Snyk, Dependabot, AWS Security Hub ve OPA (Open Policy Agent) gibi araçlar security’yi platform seviyesinde otomatize ediyor.

Platform as a Product Zihniyeti#

Platform başarısı gönüllü benimseme ile ölçülüyor. Kullanımı zorunlu hale getirdiğin anda elindeki en önemli geri bildirim sinyalini kaybediyorsun: geliştiricilerin platformu değerli bulup bulmadığını.

İşe yarayan kritik pratikler:

• Oluşturmadan önce developer sıkıntı noktalarını araştır
• Sürekli geri bildirim döngüleri topla (anketler, office hour’lar, Slack kanalları)
• Developer memnuniyetini üç ayda bir ölç (NPS veya özel metrikler)
• Platform benimsemeyi zorunlu hale getirme (geri bildirim döngülerini kapatır)
• Bir product roadmap’i tut ve değişiklikleri şeffafça duyur

Product thinking kontrol listesi:

• Tanımlanmış kullanıcı personaları (farklı dev ekip tipleri)
• Kullanıcı araştırması yapıldı (anketler, görüşmeler)
• Developer’lar için net değer önermesi
• Onboarding deneyimi tasarlandı
• İnsanlar için yazılmış dokümantasyon
• Destek kanalları kuruldu
• Başarı metrikleri tanımlandı ve takip ediliyor
• Roadmap şeffaf olarak paylaşıldı
• Geri bildirim mekanizmaları mevcut

Build vs. Buy ve Ekip Kurulumu#

Build vs. Buy Değerlendirmeleri#

Özel oluştur (ne zaman):

• Son derece spesifik organizasyonel gereksinimler
• Legacy sistemlerle derin entegrasyon gerekli
• Dedicated platform engineering ekibi var (3+ mühendis)
• Uzun vadeli yatırım taahhüdü
• React/TypeScript uzmanlığı mevcut (Backstage için)

Satın al/mevcut olanı benimse (ne zaman):

• Standart gereksinimler mevcut araçlarla karşılanıyor
• Sınırlı platform engineering kaynakları
• Hızlı time-to-value gerekli (aylar değil haftalar)
• Self-hosting yerine managed çözümler tercih ediliyor
• Aktif topluluk ve ekosistem isteniyor

Ekip Yapısı Önerileri#

Platform Engineering Ekip Kompozisyonu:

• Eski infrastructure mühendisleri (uzmanlık zaten var)
• Product odaklı mühendisler (kullanıcı empati)
• Developer experience (DevEx) uzmanları
• Technical writer’lar (dokümantasyon önemli)

Kaçın: Tüm senior mühendisleri platform ekibine taşımak (dev ekiplerinde bilgi boşlukları yaratır)

Organizasyona göre ekip boyutu:

• Küçük (< 50 mühendis): 1-2 platform mühendisi
• Orta (50-200 mühendis): 3-5 platform mühendisi
• Büyük (200-500 mühendis): 5-10 platform mühendisi
• Enterprise (500+ mühendis): 10-20+ platform mühendisi

Yaygın kılavuz (endüstri standardı değil): her 30-50 uygulama geliştiricisi için ~1 platform mühendisi. Bu oran platform olgunluğu, organizasyonel karmaşıklık ve otomasyon seviyesine göre önemli ölçüde değişir.

Araç Seçenekleri#

Portal gerçekten gerektiğinde, production’da zaten React ve TypeScript çalıştıran organizasyonlar Backstage’e, çalıştırmayanlar ticari bir platforma yöneliyor.

Backstage (Spotify’dan Open Source)#

2020’de açık kaynak yapılan Backstage, en büyük ekosistem ve pazar payına sahip. React/TypeScript frontend ve Node.js backend’li plugin tabanlı mimari.

Güçlü Yönler:

• Karmaşık gereksinimler için yüksek düzeyde özelleştirilebilir
• Zengin plugin ekosistemi (100+ plugin)
• Ücretsiz ve açık kaynak
• Büyük topluluk desteği
• Birleşik developer deneyimi

Zorluklar:

• Önemli implementasyon çabası (tipik 3-6 ay)
• React/TypeScript/SAML uzmanlığı gerekiyor
• Self-hosting gerekli (veya Roadie gibi managed servis kullan)
• Dik öğrenme eğrisi
• Devam eden bakım yükü

Backstage bir framework: onu benimsemek, IDP’yi Backstage bileşenlerinden inşa etmek demek ve ekipler bu işin ne kadarının kendilerine kaldığını düzenli olarak hafife alıyor.

Port (Ticari Platform)#

Port, frontend kodu yazmadan IDP kurmayı hedefleyen, SaaS olarak sunulan ticari bir platform.

Güçlü Yönler:

• Çok daha hızlı time-to-value (aylar yerine haftalar)
• React/TypeScript uzmanlığı gerekmiyor
• Mükemmel onboarding deneyimi
• GitHub/GitLab’den otomatik import
• Daha az bakım yükü
• Dahili tutorial’lar ve kılavuzlar
• Dinamik inventorying (CI/CD flow’ları, cluster’lar, environment’lar)
• Gelişmiş arama ve RBAC

Zorluklar:

• Implementasyon hala uzun (3-6 ay rapor edildi)
• Önemli lisanslama maliyetleri (rakiplerden daha yüksek)
• Backstage’den daha az özelleştirilebilir
• Vendor lock-in endişeleri
• Daha yüksek toplam sahip olma maliyeti

Platform Engineering için AWS Servisleri#

AWS Proton (Not: 7 Ekim 2026’da kullanımdan kalkıyor)

• Infrastructure template vending için managed servis
• Platform mühendisleri standartları tanımlıyor, developer’lar self-servis yapıyor
• Organizasyonlar alternatifleri planlamalı

Amazon EKS (Elastic Kubernetes Service)

• Platform temelleri için fully managed Kubernetes
• EKS Blueprints: Komple EKS kurulumu için seçilmiş template’ler
• Platform engineering desenleri iyi destekleniyor
• Backstage, Port, özel IDP’lerle entegrasyon

AWS CDK (Cloud Development Kit)

Programlama dillerinde Infrastructure as Code. Platform golden path’leri oluşturmak için mükemmel:

// Platform ekibi yeniden kullanılabilir construct oluşturuyor
import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';
import { Construct } from 'constructs';

export interface StandardApiServiceProps {
  serviceName: string;
  team: string;
  runtime: lambda.Runtime;
  handler: string;
  codeAsset: lambda.Code;
}

export class StandardApiService extends Construct {
  public readonly api: apigateway.RestApi;
  public readonly function: lambda.Function;

  constructor(scope: Construct, id: string, props: StandardApiServiceProps) {
    super(scope, id);

    // Standart konfigürasyonla Lambda
    this.function = new lambda.Function(this, 'Handler', {
      runtime: props.runtime,
      handler: props.handler,
      code: props.codeAsset,
      timeout: cdk.Duration.seconds(30),
      memorySize: 1024,
      environment: {
        SERVICE_NAME: props.serviceName,
        TEAM: props.team,
      },
      // Observability dahili
      tracing: lambda.Tracing.ACTIVE,
      insightsVersion: lambda.LambdaInsightsVersion.VERSION_1_0_229_0,
    });

    // Standart ayarlarla API Gateway
    this.api = new apigateway.RestApi(this, 'Api', {
      restApiName: props.serviceName,
      // Security default'ları
      defaultCorsPreflightOptions: {
        allowOrigins: apigateway.Cors.ALL_ORIGINS,
        allowMethods: apigateway.Cors.ALL_METHODS,
      },
    });

    // Standart entegrasyon
    const integration = new apigateway.LambdaIntegration(this.function);
    this.api.root.addProxy({ defaultIntegration: integration });

    // Standart tag'ler
    cdk.Tags.of(this).add('Service', props.serviceName);
    cdk.Tags.of(this).add('Team', props.team);
    cdk.Tags.of(this).add('ManagedBy', 'Platform');
  }
}

// Developer'lar golden path'i kullanıyor
const service = new StandardApiService(this, 'UserService', {
  serviceName: 'user-service',
  team: 'platform',
  runtime: lambda.Runtime.NODEJS_20_X,
  handler: 'index.handler',
  codeAsset: lambda.Code.fromAsset('./dist'),
});

AWS Service Catalog

• Onaylanmış AWS kaynakları için vending machine
• Önceden yapılandırılmış product portfolio’ları
• Bütçe kontrolleri ve governance
• AWS Proton’a alternatif

Diğer Önemli Araçlar#

• Humanitec: Platform orchestration, uygulama konfigürasyonuna odaklanıyor
• Kratix: Kubernetes üzerinde platform-as-a-product framework’ü
• Crossplane: Kubernetes API’lerini kullanarak infrastructure composition
• Terraform Cloud/Enterprise: Ekipler için workspace yönetimi
• Pulumi: State management ile multi-language IaC
• ArgoCD / Flux: Kubernetes deployment’ları için GitOps
• Cortex: Developer scorecard’ları ve standart takibi

Başarı Metrikleri#

DORA Metrikleri (Geleneksel DevOps)#

Dört Ana Metrik:

1. Deployment Frequency: Kod ne sıklıkla production’a deploy ediliyor
2. Lead Time for Change: Commit’ten production’a geçen süre
3. Time to Restore Service: Hatadan kurtarma süresi
4. Change Failure Rate: Sorun yaratan deployment’ların yüzdesi

Elite Performans Gösterenler (DORA 2024):

• Günde birden fazla deploy
• Lead time < 1 gün
• Kurtarma süresi < 1 saat
• Failure rate < %5

DORA’nın Platform Engineering için Sınırlamaları#

Kritik boşluk: DORA, software delivery performansını ölçüyor. Platform engineering’in etkinliği ayrı bir soru ve dört ana metrik onu yanıtlamıyor.

DORA’nın kaçırdıkları:

• Infrastructure yönetim kalitesi
• Security ve compliance iyileştirmeleri
• Platform kullanılabilirliği ve developer mutluluğu
• Tech debt azaltma (başarısızlığa neden olmadıkça)
• Scalability ve maintainability çalışmaları
• Day 2-N operations iyileştirmeleri

Platform’a Özgü Metrikler#

Developer Experience (DevEx) Metrikleri:

• Platform Adoption Rate: Alternatiflere karşı IDP kullanan ekip yüzdesi
• Self-Service Success Rate: Yardım olmadan tamamlanan self-servis işlemlerin yüzdesi
• Time to First Deployment: Yeni ekibin platformu kullanarak deploy süresi
• Developer Satisfaction Score: Üç aylık anketler (NPS veya özel)
• Tool Fragmentation Score: Developer’ların kullanması gereken araç sayısı
• Onboarding Time: Yeni mühendislerin üretkenliğe ulaşma günleri

Platform Health Metrikleri:

• Golden Path Usage: Standart template’leri kullanan deployment yüzdesi
• Support Ticket Volume: Platform ile ilgili yardım istekleri (azalma trendi = başarı)
• Platform Uptime: Platform servislerinin kullanılabilirliği
• Template Update Velocity: Platform yeteneklerinin ne kadar hızlı geliştiği
• Documentation Coverage: Dokümante edilen platform özelliklerinin yüzdesi

Business Impact Metrikleri:

• Cost Optimization: Standardizasyon yoluyla infrastructure harcama azaltımı
• Security Posture: Güvenlik açığı azaltımı, compliance iyileştirmeleri
• Velocity Impact: Platform benimseme öncesi/sonrası ekip throughput’u
• Operational Efficiency: Azaltılmış toil, otomasyon kapsamı

Önerilen Yaklaşım (DX Core 4 Framework):

Kantitatif DORA metriklerini bunlarla birleştir:

1. Speed: Deployment frequency, lead time
2. Effectiveness: Self-servis başarısı, time to value
3. Quality: Change failure rate, security posture
4. Business Impact: Maliyet tasarrufları, ekip verimliliği

Dört boyutu birlikte raporla.

Platform metrik takip örneği:

// Platform metrik toplama örneği
interface PlatformMetrics {
  deployments: {
    total: number;
    viaGoldenPath: number;
    selfService: number;
    requiredSupport: number;
  };
  adoption: {
    totalTeams: number;
    teamsUsingPlatform: number;
    activeUsers: number;
  };
  performance: {
    avgTimeToFirstDeploy: number; // günler
    avgSelfServiceDuration: number; // dakikalar
    supportTickets: number;
  };
  satisfaction: {
    npsScore: number;
    surveyResponses: number;
  };
}

// Golden path kullanımını takip et
function trackDeployment(method: 'golden-path' | 'custom' | 'manual') {
  metrics.deployments.total++;
  if (method === 'golden-path') {
    metrics.deployments.viaGoldenPath++;
  }
  // Golden path benimseme oranı
  const adoptionRate =
    (metrics.deployments.viaGoldenPath / metrics.deployments.total) * 100;

  console.log(`Golden path benimseme: ${adoptionRate.toFixed(1)}%`);
}

Golden Path Nerede Kırılır#

Stratejik Anti-Pattern’ler#

Platform’u portal ile karıştırmak yaygın bir tuzak: platform backend’dir, yani API’ler, orchestration ve golden path’ler; portal ise bunun üzerindeki sadece UI katmanıdır, bu yüzden önce arayüzü inşa etmek arkasında hiçbir şey olmayan bir kabuk üretir. Product management disiplinini tamamen atlamak bir başka tuzak: kullanıcı araştırması yapılmadan inşa edilen bir platform sonradan düşük benimseme ve developer hayal kırıklığı olarak geri döner; çözüm dış ürünlerde kullanılan aynı product disiplinini uygulamak ve developer’ları müşteri olarak görmektir. Platformu zorunlu kılmak bu boşluğu kapatmıyor; zorla benimsetme direnç, workaround ve shadow IT doğuruyor, çünkü zorunlu bir araç bile developer’ların zaten bildiği alternatiflerle rekabet etmek zorunda kalıyor. “Field of Dreams” zihniyeti, yaparsan gelirler varsayımı, aynı araştırma adımını atlıyor; platform developer’ların gerçekten hissettiği bir sıkıntıyı çözmeli, bu da araştırmayla başlayıp sonucu pilot ekiplerle doğrulamak anlamına geliyor.

Implementasyon Anti-Pattern’leri#

Pilotu en büyük veya en kritik serviste başlatmak henüz yeni olan platform üzerinde çok fazla baskı yaratıyor ve başarısız bir pilot platformun ihtiyaç duyduğu güvenilirliğe zarar veriyor; istekli bir ekip ve kritik olmayan bir servisle başlamak bu riski önlüyor. Tanıdık olmayan config formatları, eksik dokümantasyon ve tutarsız API’lerle aşırı karmaşık bir platform developer’lara ondan kaçınmayı öğretiyor, bu yüzden basitlik, tutarlılık ve dokümantasyon en başından bulunmalı. Ticket sistemlerine aşırı bağımlılık, platformun ortadan kaldırması gereken darboğazı yeniden yaratıyor: ticket’lar eski süreçte olduğu gibi teslimatı yavaşlatıyor ve developer’ları hayal kırıklığına uğratıyor; çözüm gerçek self-servis ve minimal onay workflow’larıdır. Özelleştirmeye izin vermeyen templates-as-a-service yaklaşımı ekipleri workaround’lara, shadow IT’ye ve terk edilmiş template’lere itiyor; template’leri net sınırlar içinde özelleştirmeye açık bir başlangıç noktası olarak ele almak onları kullanımda tutuyor.

Organizasyonel Anti-Pattern’ler#

Tüm senior mühendisleri platform ekibine taşımak kağıt üzerinde verimli görünür ama development ekiplerinde bilgi boşlukları bırakır; insanları platform ekibi içinde döndüren dengeli bir dağılım bu tuzağı önler. İlk teslimattan sonra dağılan bir platform ekibi platformu bakımsız bir çapaya dönüştürür, bu yüzden yatırım taahhüdü proje bazlı değil uzun vadeli olmalı. Harcama limitleri olmadan self-servis kontrolsüz cloud maliyetlerine yol açar; çözüm bütçe kontrolleri, otomatik harcama limitleri ve maliyet görünürlüğüdür.

Başlangıç: Pratik Yol Haritası#

Faz 1: Temel

• En büyük 3-5 developer sıkıntı noktasını belirle (anketler, görüşmeler)
• Platform vizyonu ve başarı metriklerini tanımla
• İlk platform ekibini oluştur (2-3 kişi)
• Pilot ekibi seç (istekli ekip, kritik olmayan servis)
• Mevcut durumu dokümante et (araçlar, workflow’lar, sıkıntı noktaları)

Faz 2: MVP Geliştirme

• Bir golden path oluştur (örn. standart API servis template’i)
• Basit servis catalog oluştur (manuel uygun)
• Self-servis workflow implement et (CLI veya basit UI)
• Açık dokümantasyon yaz
• İstekli ekiple pilotu deploy et

Faz 3: Doğrulama

• Pilot geri bildirimini topla (ne işe yarıyor, ne yaramıyor)
• Baseline metriklerini ölç (deploy süresi, memnuniyet)
• Geri bildirimlere göre golden path’te iterasyon yap
• 2-3 ekibe daha genişlet
• Öğrenmeleri dokümante et ve roadmap’i ayarla

Faz 4: Ölçeklendirme

• 2-3 golden path daha ekle (yaygın kullanım senaryoları)
• Developer portal oluştur veya benimse (Backstage/Port kararı)
• Observability ve security entegre et
• Maliyet kontrollerini implement et
• Benimsemeyi pilot ekiplerin ötesine, organizasyonun geneline genişlet
• Destek kanalları kur

Faz 5: Olgunlaşma

İyileştirme artık ayrı bir faz değil, sürekli bir iş haline gelir: metrikler iterasyonu yönlendirir, gelişmiş özellikler (AI yardımı, otomatik optimizasyon) fırsat buldukça eklenir, ekipler arası işbirliği ve API kararlılığı açık sorumluluklara dönüşür ve internal kullanıcı grupları platformun topluluğunu canlı tutar.

Varsayılanın Sınırları#

Dar varsayılan (tek golden path, tek pilot ekip, portaldan önce backend, gönüllü kullanımla ölçülen benimseme) platform gençken ve organizasyon birkaç yüz mühendisin altındayken geçerli. Çoğu ekibin beklediğinden de uzun süre geçerli kalıyor, çünkü ikinci yolun bakım maliyeti birincisiyle aynı.

Üç durumda bunun dışına çıkılır. Bir regülasyon ya da güvenlik temeli yolu isteğe bağlı olmaktan çıkarıp zorunlu kıldığında, sinyal artık benimseme değil compliance kapsamı olur. Catalog zaten neyin kime ait olduğunu gösteren tek güvenilir envanterse, portal erkene alınır. Platform ekibi birden fazla yolu aynı anda güncel tutacak büyüklükteyse, genişlik derinliğin önüne geçer.

İşe yarayan sonraki adım en küçüğü: her ekibin zaten şikayet ettiği sıkıntı noktasını seç ve onun için ticket’ı kaldır.

Kaynaklar#

• CNCF Platform Teknik Raporu (yeni sekmede açılır) - Dahili geliştirici platformlarının, yeteneklerinin ve olgunluk düzeylerinin CNCF TAG App Delivery kanonik tanımı
• Platform Mühendisliği Olgunluk Modeli (yeni sekmede açılır) - Geçici araçlardan yönetilen, optimize edilmiş platform ürünlerine ilerleme için CNCF rehberi
• Platform Mühendisliği Nedir? - CNCF (yeni sekmede açılır) - Platform mühendisliğinin güncel CNCF tanımı, hedefleri ve DevOps ile ilişkisi
• Ürün Olarak Platform - platformengineering.org (yeni sekmede açılır) - Dahili geliştirici platformlarına ürün düşüncesini uygulamaya dair topluluk kaynağı
• Team Topologies - Platform Mühendisliği (yeni sekmede açılır) - Team Topologies’in “platform ekibi” ve “en ince uygulanabilir platform” kavramlarının IDP tasarımına uygulanması
• Platform Mühendisliği Nedir? - platformengineering.org (yeni sekmede açılır) - Platform mühendisliği hedefleri ve altın yollar üzerine topluluk tanımı ve temel okuma
• DORA (yeni sekmede açılır) - Metrikler bölümünde aktarılan dört ana metriğin ve performans eşiklerinin kaynağı
• Backstage (yeni sekmede açılır) - Açık kaynak developer portal framework’ünün resmi dokümantasyonu, catalog entity formatları dahil
• Port (yeni sekmede açılır) - Araçlar bölümünde ele alınan ticari SaaS alternatifinin ürün dokümantasyonu