Spotify 2012’de \”Squad modeli\”ni duyurduğunda yüzlerce şirket aynı yapıyı kopyaladı. Sonuç çoğu zaman hayal kırıklığı oldu; çünkü şirketler modelin görünür yapısını aldı, altyapı felsefesini almadı. Aynı hata 2018’den itibaren DevOps’la yaşandı: Her takımın kendi CI/CD boru hattını kurması, kendi izleme yığınını seçmesi \”özerklik\” diye sunuldu. Ama bir noktada geliştiriciler altyapı yönetimiyle boğulmaya başladı ve yazılım yazmak için vakit kalmadı. Platform mühendisliği bu krizin yanıtıdır.
\n\n
Platform Mühendisliği DevOps’un Neresine Oturur?
\n
DevOps bir kültür ve işbirliği anlayışıdır; platform mühendisliği ise bu anlayışı operasyonel bir ürüne dönüştürür. Gartner’ın 2024 raporuna göre büyük kuruluşların %80’i 2026 itibarıyla platform mühendisliği ekiplerine sahip olacak. Temel fark: DevOps’ta her takım kendi altyapısını yönetir; platform mühendisliğinde ayrı bir takım (platform team), diğer geliştirici takımları için \”altın yol\” (golden path) sunar. Bu, merkezi bir IT despotizmine dönüş değil; seçilmiş standartların self-servis biçimde sunulmasıdır.
\n\n
Internal Developer Platform (IDP) Nedir?
\n
IDP, geliştiricilerin ihtiyaç duydukları altyapı, araç ve servislere bağımsız biçimde erişebildiği bir ürün katmanıdır. Bir IDP tipik olarak şunları kapsar:
\n
- \n
- Self-servis ortam sağlama (staging, dev, preview ortamları tek komutla)
- Standart CI/CD şablonları ve dağıtım boru hatları
- Merkezi gözlemlenebilirlik (log, metrik, iz) entegrasyonu
- Servis kataloğu ve bağımlılık haritası
- Güvenlik ve uyumluluk kontrolleri (shift-left)
\n
\n
\n
\n
\n
\n
Backstage (Spotify’dan açık kaynak), Port ve Cortex bu alanda en yaygın çözümlerdir. Backstage’in 2024 verilerine göre 2.500’den fazla şirket aktif olarak kullanmaktadır.
\n\n
Kurulum Senaryosu: 200 Geliştirici, 40 Mikro Servis
\n
Bu ölçekteki bir kurumda IDP’siz yaşananlar genellikle şöyledir: Her takım farklı bir cloud provider SDK kullanır, staging ortamı oluşturmak 3-5 iş günü alır, üretim olaylarında hangi servisin sahibi olduğu belirsizleşir. Platform mühendisliği yolculuğu genellikle üç aşamada ilerler:
\n
- \n
- Aşama 1 — Keşif: Geliştirici anketi ile en büyük sürtünme noktaları tespit edilir (genellikle ortam kurulumu ve dağıtım süreci).
- Aşama 2 — Altın Yol: En kritik iş akışı için opinionated bir şablon yazılır, diğer takımlar gönüllü olarak benimser.
- Aşama 3 — Ürün Olarak Platform: Backstage veya benzer bir portal üzerinden self-servis sunulur, NPS (Net Promoter Score) ve bildirim sayısı izlenir.
\n
\n
\n
\n\n
Mit: Platform Mühendisliği Özerkliği Kısıtlar
\n
En yaygın direniş budur. Ancak veri farklı bir tablo çiziyor: Humanitec’in 2023 State of Platform Engineering raporunda, yüksek performanslı platform mühendisliği uygulayan şirketlerde geliştirici özerklik algısının %34 arttığı ölçüldü. Nedeni basit: Geliştiriciler artık hangi Terraform modülünü kullanacaklarını araştırmak yerine kendi işlerine odaklanabiliyor. Özerklik kısıtlanmıyor; sürtünme azaltılıyor.
\n\n
Hangi Metriklerle Başarı Ölçülür?
\n
Platform ekibinin performansını izlemek için DORA metrikleri ve ek göstergeler birlikte kullanılmalıdır:
\n
- \n
- Ortam kurulum süresi (hedef: 30 dakikanın altı)
- Geliştirici self-servis oranı (platform üzerinden talepler / toplam talepler)
- Altyapı destek bildirimi sayısı (azalmalı)
- Ortalama dağıtım süresi (DORA: deployment frequency, lead time)
\n
\n
\n
\n
\n\n
Platform Ekibini Kurarken Yapılan Üç Hata
\n
Yanlış başlangıçlar çoğunlukla tekrarlanır: Birincisi, geliştirici ihtiyaçlarını sorgulamadan araç seçmek — ürün gibi düşün, IT projesi gibi değil. İkincisi, platform ekibini IT departmanına bağlamak; platform mühendisleri mühendislik örgütünde oturmalı. Üçüncüsü, tek seferlik kurulum gibi davranmak — platform, sürekli geliştirilen bir üründür ve kullanıcı geri bildirimi olmadan evrilemez.