Platform Engineering: Dahili Geliştirici Platformu Rehberi [2026]

Platform Engineering Nedir?

Platform engineering, yazilim gelistirme ekiplerinin uretkenligini artirmak icin self-service altyapi ve araclar sunan bir muhendislik disiplinidir. Gartner'in 2024 raporunda "en onemli 10 teknoloji trendi" arasina giren bu yaklasim, 2026 itibariyle kurumsal yazilim organizasyonlarinin yuzde 80'inde bir sekilde benimsenmis durumdadir. Temel amaci, gelistiricilerin altyapi karmasikligi ile ugrasmasini onlemek ve onlari is degerine odaklanabilecekleri bir ortam saglamaktir.

Smart Maple olarak Ankara merkezli projelerimizde goruyoruz ki, DevOps'un "herkes her seyi yapsin" felsefesi belirli bir olcekte tikanma noktasina ulasiyor. Elli gelistiriciyi asan ekiplerde her birinin Kubernetes, Terraform, CI/CD pipeline konfigurasyonu ve guvenlik politikalarini anlamasi beklenemez. Bilissel yuk (cognitive load) arttikca gelistiricilerin urettigi is degeri duser, hata orani artar ve is memnuniyeti azalir. Platform engineering, bu tikanikligi cozmek icin DevOps ilkelerini bir urun mantigi ile paketler. Gelistiriciler altyapi detaylarini bilmek zorunda kalmadan, standart ve guvenli yollarla uygulamalarini deploy edebilir hale gelir.

DevOps'tan Platform Engineering'e Gecis

DevOps kulturel bir donusumdu ve "gelistirme ile operasyon arasindaki duvarlari yikin" diyordu. Platform engineering ise bu kulturun olceklenebilir bir urun haline getirilmesidir; yikilan duvarlarin yerine self-service koprular kurar. DevOps ilkeleri temel kalir, ancak uygulama bicimi degisir. Artik her gelistirici kendi pipeline'ini sifirdan yazmak yerine, platform ekibinin sundugu standart sablonlari kullanir. Bu durum gelistiriciyi kisitlamaz; aksine onu altyapi karmasikligindan kurtararak asil isine odaklanmasini saglar.

Team Topologies kitabinin yazarlari Matthew Skelton ve Manuel Pais'in tanimladigi dort ekip tipinden biri olan "platform ekibi", tam olarak bu islevi ustlenir. Diger ekiplerin (stream-aligned teams) hizli ve bagimsiz calisabilmesi icin gerekli altyapiyi bir urun olarak sunar.

Internal Developer Platform (IDP) Konsepti

Dahili gelistirici platformu (IDP), gelistiricilerin kod yazma disindaki operasyonel islerini otomatiklestiren, standartlastiran ve basitlestiren bir urun katmanidir. IDP'nin amaci, bir gelistiricinin yeni bir mikroservis olusturmak istediginde Jira ticket'i acip gunlerce beklemek yerine, bir portal uzerinden birkac dakika icinde reposu, CI/CD pipeline'i, staging ortami ve monitoring dashboard'u hazir hale getirmesidir. Bir IDP tipik olarak bes temel katmandan olusur:

Katman	Islevi	Ornek Araclar
Gelistirici Portali	Servis katalogu, dokumantasyon, self-service UI	Backstage, Port, Cortex
Orkestrasyon	Workflow yonetimi, deployment pipeline	Argo Workflows, Tekton, GitHub Actions
Altyapi Yonetimi	IaC, kaynak provisioning	Terraform, Crossplane, Pulumi
Gozlemlenebilirlik	Log, metrik, trace toplama ve goruntuleme	Grafana Stack, Datadog, OpenTelemetry
Guvenlik ve Uyumluluk	Policy enforcement, secret yonetimi, zafiyet tarama	OPA, Vault, Trivy

Bu bes katmanin birlikte calismasi, gelistiricilere uctan uca bir deneyim sunar. Gelistirici portali on yuz gorevini gorurken, arka planda orkestrasyon ve altyapi katmanlari isin agir kismini halleder. Gozlemlenebilirlik ve guvenlik katmanlari ise uretilen her kaynagi otomatik olarak izler ve politikalara uygunlugunu denetler. Onemli olan, bu katmanlarin birbirinden bagimsiz olarak evrilebilmesidir; monolitik bir platform yerine, modular bir yaklasim benimsemek uzun vadeli basarinin anahtaridir.

Self-Service Altyapi ve Golden Path Yaklasimi

Golden path (altin yol), organizasyonun oneridigi ve destekledigi standart gelistirme yoludur. Bu, zorunlu bir kisitlama degil, en az surtumeyle en hizli sonuca ulastiran rehberli bir rotadir. Gelistiriciler bu yoldan sapabilir ancak golden path uzerinde kalmak her zaman daha hizli ve daha guvenlidir. Deneyimlerimize gore golden path kullanildiginda gelistiricilerin yuzde 90'i standart yolu tercih eder cunku acik ara en hizli yoldur. Kalan yuzde 10 icin platform ekibi ozel destek saglar.

Golden Path Bilesenleri

Sablon repolar: Yeni servisler icin onceden yapilandirilmis proje iskeletleri sunar. Ornegin bir Node.js mikroservisi icin Dockerfile, Helm chart, CI pipeline, test altyapisi, loglama konfigurasyonu ve health check endpoint'leri hazir gelir. Gelistirici tek bir komutla bu sablonu kullanarak yeni projesini baslatir ve dakikalar icinde calisan bir servise sahip olur.

Self-service katalog: Gelistirici portal uzerinden "Yeni PostgreSQL veritabani olustur", "Redis cache ekle" veya "Kafka topic olustur" gibi islemleri tek tikla yapar. Arka planda Terraform veya Crossplane planlari calisir, gerekli IAM rolleri atanir ve connection string'leri otomatik olarak uygulamanin secret store'una eklenir.

Otomatik uyumluluk: Golden path uzerinden olusturulan her kaynak, organizasyonun guvenlik politikalarina, naming convention'larina ve tagging standartlarina otomatik olarak uyar. Bu sayede denetim ve uyumluluk surecleri kolaylasir, guvenlik ekiplerinin is yuku azalir.

Platform Ekibi Organizasyonu ve Sorumluluklar

Platform ekibi, bir ic urun ekibi gibi calisir. Musterileri, organizasyondaki diger gelistirme ekipleridir. Bu ekibin basarisi, gelistiricilerin platformu gonullu olarak benimsemesine baglidir; zira zorlama ile benimseme surdurulebilir degildir. Platform ekibi, gelistiricilerle duzenli olarak gorusur, geri bildirim toplar ve platformu surekli iyilestirir.

Rol	Sayi	Sorumluluk
Platform Product Manager	1	Gelistirici ihtiyaclarini onceliklendirme, yol haritasi yonetimi
Platform Engineer	2-4	IaC, orkestrasyon, otomasyon gelistirme, eklenti yazimi
Developer Advocate	1	Dokumantasyon, egitim, workshop'lar, geri bildirim toplama
SRE / Reliability Engineer	1-2	Platformun kendisinin guvenilirligi, SLA yonetimi, kapasite planlama

Platform bir urun gibi yonetilmelidir: kullanici arastirmasi yapilmali, NPS olculmelidir. Gelistiricilere platforma gecis zorla dayatilmamalidir; deger gorunur olursa benimseme dogal olarak artar. Platform ekibi, is birimlerinden bagimsiz bir yatay ekip olarak konumlanmali ve her sprint'te en az yuzde 20 kapasitesini gelistirici geri bildirimlerine ayirmalidir. Ayrica platform ekibinin kendi ic SLA'lari olmalidir; ornegin "yeni ortam taleplerine 4 saat icinde yanit verme" gibi somut taahhutler benimsemeyi hizlandirir.

Backstage, Kratix ve Port: Platform Araclari

2026 itibariyle platform engineering ekosistemi olgunlasmis durumdadir ve uc ana kategoride araclari incelemek gerekir.

Gelistirici Portallari

Backstage, Spotify tarafindan acik kaynakli olarak gelistirilmis olup en yaygin gelistirici portali olmaya devam etmektedir. Eklenti mimarisi ile servis katalogu, TechDocs, Kubernetes dashboard ve scaffolder ozelliklerini tek catida toplar. Buyuk organizasyonlar icin son derece esnektir ancak kurulumu ve bakimi deneyim ve zaman gerektirir. Port ve Cortex ise SaaS alternatifleri olarak daha hizli baslangic saglar; ancak ozellestirme esnekligi daha sinirlidir ve aylik lisans maliyetleri kucuk ekipler icin yuksek olabilir.

Altyapi Orkestrasyonu

Kratix, platform-as-a-product felsefesini Kubernetes uzerinde hayata gecirir. "Promise" adi verilen soyutlamalar ile platform ekipleri, gelistiricilere sunulacak servisleri tanimlar. Crossplane ise Kubernetes API'si uzerinden herhangi bir bulut kaynagini yonetmeye imkan tanir; AWS RDS, GCP Cloud SQL veya Azure Cosmos DB gibi kaynaklari Kubernetes manifest'leri ile olusturabilirsiniz.

Politika ve Guvenlik

OPA (Open Policy Agent) ile deployment politikalari kod olarak tanimlanir: "container image'lari yalnizca onaylanmis registry'den cekilebilir", "her servisin health check endpoint'i olmalidir" veya "production ortamina yalnizca imzalanmis artifact'lar deploy edilebilir" gibi kurallar otomatik olarak uygulanir. Bu kurallar, guvenlik ekiplerinin manuel denetim yukunu buyuk olcude azaltir.

Gelistirici Deneyimi (DX) Metrikleri

Platform yatiriminin getirisini olcmek icin iki temel cerceve kullanilir. Bu metrikleri duzenli olarak takip etmek, platform ekibinin dogru alanlara yatirim yapmasini saglar.

DORA Metrikleri

Metrik	Elite	Yuksek	Orta	Dusuk
Deployment Sikligi	Talep uzerine (gunluk+)	Haftalik	Aylik	6 ay+
Lead Time for Changes	< 1 saat	1 gun - 1 hafta	1-6 ay	6 ay+
Change Failure Rate	< %5	%5-10	%10-15	> %15
MTTR	< 1 saat	< 1 gun	1 gun - 1 hafta	1 hafta+

SPACE Cercevesi

SPACE, gelistirici uretkenligini bes boyutta degerlendirir: Satisfaction (memnuniyet anketi ve eNPS skoru), Performance (kod kalitesi, hata orani ve musteri etkisi), Activity (commit, PR ve deployment sayilari; tek basina yaniltici olabilir), Communication (code review suresi, dokumantasyon kalitesi ve bilgi paylasimi) ve Efficiency (onboarding suresi, ilk deploy'a kadar gecen sure ve bekleme sureleri).

Platform engineering'in en somut etkisi, yeni bir gelistiricinin ilk basarili production deploy'una kadar gecen sureyi kisaltmasidir. Bu sure olgun platformlarda 1-2 gune inerken, platform olmayan ortamlarda 2-4 haftayi bulabilmektedir. Bu metrik tek basina platform yatiriminin getirisini gostermeye yeter.

Platform Olgunluk Modeli

Organizasyonlar platform yolculugunda dort asamadan gecer. Her asama farkli yetenekler, yatirimlar ve organizasyonel olgunluk gerektirir:

Seviye	Tanim	Ozellikler
Seviye 0 - Ad Hoc	Standart yok	Her ekip kendi toolchain'ini kurar, tribal knowledge hakim, tekrarli is yuku yuksek
Seviye 1 - Temel	Paylasilan CI/CD	Ortak pipeline sablonlari, merkezi artifact repository, temel dokumantasyon
Seviye 2 - Standart	Self-service portal	Gelistirici portali aktif, golden path tanimli, otomatik provisioning mevcut
Seviye 3 - Optimum	Olculebilir platform urunu	Dahili SLA'lar, platform NPS takibi, surekli iyilestirme dongusu, FinOps entegrasyonu

Cogu Turkiye merkezli organizasyon 2026'da Seviye 0 ile Seviye 1 arasindadir. Smart Maple olarak musavirlik yaptigimiz projelerde hedef, 6-12 ay icinde Seviye 2'ye ulasmaktir. Seviye 3'e gecis ise genellikle 18-24 aylik bir surec gerektirir ve organizasyonel olgunlukla dogru orantilidir. Her seviye gecisi, sadece teknik degil ayni zamanda kulturel bir donusumu de icerir.

Build vs Buy Karari

Platform olusturma surecinde en kritik karar, ne kadarinin ic kaynaklarla gelistirilecegi ve ne kadarinin hazir cozumlerle karsilanacagidir.

Build (kendiniz gelistirin) secenegi su durumlarda uygundur: Organizasyonunuzda 50'den fazla gelistirici varken ozel is surecleri gerekiyorsa, mevcut Kubernetes altyapiniz olgunsa ve platform muhendisligi kapasitesi mevcutsa veya regulasyon gereksinimleri nedeniyle veri ve altyapi uzerinde tam kontrol gerekiyorsa bu yolu secin. Maliyet olarak daha yuksektir ancak uzun vadede tam esneklik saglar.

Buy (hazir cozum satin alin) secenegi su durumlarda tercih edilmelidir: 50'den az gelistirici ile hizli sonuc alinmak istendiginde, platform muhendisligi deneyimi sinirli oldugunda veya Humanitec, Port gibi SaaS cozumleri mevcut is ihtiyaclarini karsiladiginda bu yol daha pragmatiktir. Baslangic maliyeti dusuktur ancak olceklendikce lisans ucretleri artabilir.

Hibrit yaklasim cogu organizasyon icin en dogru yoldur: Backstage gibi acik kaynakli bir temel uzerine, ihtiyaca gore ozel eklentiler gelistirmek. Bu yaklasim hem maliyet avantaji saglar hem de tam esneklik sunar. Smart Maple olarak genellikle bu hibrit modeli oneriyoruz cunku organizasyonlar buyudukce ihtiyaclari degisir ve acik kaynakli bir temel bu degisime uyum saglamaya en uygun zemindir.

Turkiye'de Platform Engineering Benimsenmesi

Turkiye'deki yazilim ekosistemi, platform engineering konusunda hizla olgunlasmaktadir. Ozellikle fintech, e-ticaret ve SaaS sektorlerinde 100'den fazla gelistiriciye sahip organizasyonlar ciddi platform yatirimlari yapmaktadir. Bankacilik sektorunde BDDK uyumlulugu ve veri lokalizasyonu gereksinimleri, platform engineering'i yalnizca bir verimlilik araci degil ayni zamanda bir uyumluluk araci haline getirmektedir.

Turkiye'ye ozel bazi zorluklar mevcuttur. Yetenek kisitliligi en buyuk engeldir; platform muhendisligi DevOps, SRE ve urun yonetimi deneyimini birlestiren nadir bir beceri setidir ve bu profilde muhendis bulmak oldukca zordur. Kulturel direnc ozellikle buyuk kurumsal yapilarda "biz hep boyle yapiyorduk" anlayisi ile kendini gosterir ve degisim yonetimi stratejisi gerektirir. Bulut maliyet hassasiyeti ise kur dalgalanmalari nedeniyle bulut harcamalarinin onceden planlanmasini zorlastirir; platform ekiplerinin FinOps'u da gundemine almasi sart olur.

Basari icin onerilerimiz: Kucuk baslayin ve tek bir ekibin en buyuk agri noktasini cozecek minimal bir platform ile yola cikin. Ilk 90 gunde somut bir deger gosterin; ornegin deployment suresini yuzde 50 kisaltmak veya yeni servis kurulum suresini gunlerden dakikalara indirmek, yonetim kademesinin destegini kazanmak icin yeterlidir. Platform engineering ile ilgilenen muhendisleri bir araya getiren Community of Practice toplantilari duzenleyin ve bilgi paylasiMini tesvik edin.

Uygulama Stratejisi ve Yol Haritasi

Platform engineering yolculugunu uc fazda planlamanizi oneriyoruz:

Faz 1: Kesfet ve Temelle (Ay 1-3)

Gelistirici anketi ve bire bir mulakatlarla agri noktalarini belirleyin. Mevcut toolchain envanterini cikartin ve tekrarli isleri tespit edin. Ilk golden path'i en yaygin kullanim senaryosu icin olusturun; ornegin yeni bir REST API servisi sablonu. Backstage veya benzeri bir portal ile servis katalogu kurun ve mevcut servisleri bu kataloga aktarin. Bu fazda amac, hizli bir kazanim elde ederek organizasyonda guven insa etmektir.

Faz 2: Standartlastir ve Genislet (Ay 4-8)

Self-service veritabani, cache ve mesaj kuyrugu provisioning'i ekleyin. CI/CD pipeline sablonlarini tum ekiplere sunun ve migrasyon icin destek saglayin. OPA ile guvenlik politikalarini kod olarak tanimlayin ve otomatik denetim mekanizmalari kurun. DORA metriklerini toplamaya baslayin, dashboard'a aktarin ve haftalik olarak ekiplerle paylasin. Bu fazda ikinci ve ucuncu golden path'leri de tanimlayin; ornegin frontend uygulamasi ve event-driven servis sablonlari.

Faz 3: Olcumle ve Optimize Et (Ay 9-12)

Platform NPS ve gelistirici memnuniyet anketlerini duzenli olarak yapin. Maliyet gozlemlenebilirligi icin FinOps entegrasyonu saglayin ve ekip bazinda bulut harcama raporlari sunun. Preview ortamlari, canary deployment ve chaos engineering gibi ileri seviye ozellikler ekleyin. Platform ekibini sonuclara ve kullanici buyumesine gore genisletin. Bu fazin sonunda platform, organizasyonun vazgecilmez bir parcasi haline gelmis olmalidir.

Sonuc

Platform engineering, DevOps'un dogal evrimidir ve gelistiricilerin altyapi karmasikligi yerine is degerine odaklanmasini saglar. Ancak basari, teknoloji seciminden once kulturel ve organizasyonel hazirliga baglidir. Dogru platform araci secmek onemlidir, ancak daha da onemlisi platform ekibinin urun odakli bir zihniyetle calismasi ve gelistirici geri bildirimlerini surekli olarak platformun yol haritasina yansitmasidir.

Smart Maple olarak, Ankara ve Turkiye genelinde platform engineering danismanligi ve IDP kurulum hizmetleri sunuyoruz. Kucuk bir baslangicla buyuk etkiler yaratmak mumkundur; onemli olan dogru noktadan baslamak ve sureci veri odakli yonetmektir. Platform yolculugunuza baslamak veya mevcut DevOps sureclerinizi bir ust seviyeye tasimak icin Smart Maple ekibi ile iletisime gecin.