1 
2Yazılım sistemleri daha karmaşık hale geldikçe  -  mikroservisler, Kubernetes, çoklu bulut, CI/CD pipeline'ları, gözlemlenebilirlik yığınları  -  geliştiriciler altyapıya daha fazla, ürün geliştirmeye daha az zaman harcıyorlar. **Platform Engineering**, karmaşıklığı soyutlayan ve geliştiricilere daha hızlı teslimat için self-servis araçlar sunan bir iç platform oluşturarak bu sorunu çözer.
3 
4Gartner, 2027 yılına kadar **yazılım mühendisliği organizasyonlarının %80'inin** platform ekipleri oluşturacağını öngörüyor. Bu rehberde, Platform Engineering'in ne olduğunu, neden önemli olduğunu ve sıfırdan bir Internal Developer Platform'un nasıl oluşturulacağını inceleyeceğiz.
5 
6## Platform Engineering Nedir?
7 
8Platform Engineering, yazılım mühendisliği organizasyonları için self-servis yetenekleri sağlayan araç zincirleri ve iş akışları tasarlama ve oluşturma disiplinidir. Çıktı, bir **Internal Developer Platform (IDP)**  -  geliştiriciler ile altyapı arasında yer alan bir katmandır.
9 
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17 
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24 
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31 
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43 
44### Platform Engineering vs DevOps
45 
46Platform Engineering, DevOps'un yerine geçen bir şey değildir  -  bir sonraki evrimdir. DevOps "sen yap, sen çalıştır" dedi. Platform Engineering "yapma ve çalıştırmayı zahmetsiz hale getireceğiz" diyor.
47 
48| Boyut | DevOps | Platform Engineering |
49|-------|--------|---------------------|
50| **Odak** | Kültür ve pratikler | Ürünler ve self-servis |
51| **Yaklaşım** | Her ekip altyapıyı yönetir | Platform ekibi altyapıyı soyutlar |
52| **Bilişsel Yük** | Yüksek (her ekip her şeyi öğrenir) | Düşük (altın yollar sağlanır) |
53| **Çıktı** | CI/CD pipeline'ları, IaC betikleri | Internal Developer Platform |
54| **Kullanıcılar** | Tüm mühendislik | Platform ekibi mühendisliğe hizmet eder |
55 
56## Platform Engineering Neden Önemli
57 
58### Bilişsel Yük Sorunu
59 
60Tipik bir modern organizasyonda, bir geliştiricinin anlaması gerekenler:
61 
62- Git iş akışları ve dallanma stratejileri
63- CI/CD pipeline yapılandırması
64- Konteyner oluşturma ve kayıt defteri yönetimi
65- Kubernetes manifest'leri ve Helm Charts
66- Bulut sağlayıcı hizmetleri (AWS/GCP/Azure)
67- Ağ, DNS, TLS sertifikaları
68- İzleme, loglama, uyarı kurulumu
69- Veritabanı sağlama ve geçişler
70- Güvenlik politikaları ve uyumluluk
71 
72Bu, gerçek üründen odağı uzaklaştıran muazzam bir bilişsel yüktür.
73 
74### Altın Yol
75 
76Platform Engineering, **altın yollar** kavramını tanıtır  -  yaygın görevler için görüşlü, iyi desteklenen ve belgelenmiş yollar. Altın yol bir zorunluluk değildir; geliştiriciler *sapabilir*, ama platform doğru olanı kolay olan yapar.
77 
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88 
89**Yeni bir mikroservis oluşturmak için altın yol örneği:**
901. Geliştirici portalda "Yeni Backend Servisi" seçer
912. Dil/framework seçer (Node.js, Go, Python)
923. Platform otomatik oluşturur: Git deposu, CI/CD pipeline'ı, Kubernetes namespace'i, izleme panoları ve uyarı kuralları
934. Geliştirici depoyu klonlar ve hemen kodlamaya başlar
94 
95## Internal Developer Platform Oluşturma
96 
97### Katman 1: Developer Portal
98 
99Portal, geliştiriciler için tek giriş noktasıdır. En popüler açık kaynak seçenek **Backstage**'dir (Spotify tarafından oluşturulmuş, şimdi bir CNCF projesi).
100 
101Temel özellikler:
102- **Servis kataloğu**: Her servis, sahibi, belgeleri ve bağımlılıkları
103- **Yazılım şablonları**: En iyi uygulamalarla entegre yeni servisler için iskele
104- **Teknik belgeler**: Kod olarak belgeler, işlenmiş ve aranabilir
105- **Eklenti ekosistemi**: Özel işlevsellikle genişletilebilir
106 
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127 
128### Katman 2: Altyapı Soyutlama
129 
130Geliştiriciler doğrudan Terraform veya Kubernetes YAML yazmamalıdır. Platform soyutlamalar sağlamalıdır.
131 
132**Araçlar:**
133- **Crossplane**: Kubernetes-yerel altyapı sağlama
134- **Terraform modülleri**: Önceden oluşturulmuş, test edilmiş altyapı modülleri
135- **Pulumi**: Gerçek kod olarak altyapı (TypeScript, Python, Go)
136 
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149 
150RDS parametreleri, VPC alt ağları, güvenlik grupları ve yedekleme politikaları yapılandırmak yerine, geliştirici sadece `size: small` ve `backup: daily` belirtir. Platform gerisini halleder.
151 
152### Katman 3: CI/CD Standardizasyonu
153 
154Ekiplerin her birinin kendi pipeline'larını oluşturmaması için CI/CD'yi standardize edin.
155 
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163 
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172 
173**Temel pratikler:**
174- Ekiplerin dahil ettiği (kopyalamadığı) paylaşımlı CI/CD şablonları
175- Otomatik güvenlik taraması (SAST, bağımlılık denetimi)
176- Standardize dağıtım stratejileri (canary, blue/green)
177- Başarısız sağlık kontrollerinde otomatik geri alma
178 
179### Katman 4: Gözlemlenebilirlik
180 
181Geliştiricilerin hazır panolar ve uyarılar alması için önceden yapılandırılmış izleme.
182 
183- **Metrikler**: Prometheus + Grafana, servis başına standart panolar
184- **Loglama**: Merkezi toplama ile yapılandırılmış loglama (Loki, ELK)
185- **İzleme**: OpenTelemetry ile dağıtık izleme
186- **Uyarılar**: Makul varsayılanlarla PagerDuty/Opsgenie entegrasyonu
187 
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199 
200## Başarıyı Ölçme
201 
202Platformunuzun çalıştığını nasıl bilirsiniz? Bu metrikleri takip edin:
203 
204### DORA Metrikleri
205- **Dağıtım sıklığı**: Kodun üretime ne sıklıkta ulaştığı
206- **Değişiklikler için teslim süresi**: Commit'ten üretime kadar geçen süre
207- **Değişiklik başarısızlık oranı**: Arızalara neden olan dağıtımların yüzdesi
208- **Ortalama kurtarma süresi**: Bir olaydan sonra hizmeti geri yükleme süresi
209 
210### Platforma Özel Metrikler
211- **İlk dağıtıma kadar süre**: "Yeni servis"ten ilk üretim dağıtımına kadar ne kadar süre
212- **Geliştirici memnuniyeti (NPS)**: Kullanıcılarınızı düzenli olarak anket yapın
213- **Self-servis oranı**: Bilet olmadan işlenen altyapı isteklerinin %'si
214- **Altın yol benimseme**: Önerilen yolu izleyen servislerin %'si
215 
216## Yaygın Hatalar
217 
218### 1. Çok Erken Çok Fazla Oluşturma
219Büyük bir vizyon değil, en büyük acı noktasıyla başlayın. Dağıtımlar acı vericiyse, oradan başlayın. Sağlama haftalarca sürüyorsa, oradan başlayın.
220 
221### 2. Platformu Ürün Olarak Görmemek
222Platform ekibinin bir ürün yöneticisine, kullanıcı araştırmasına ve geri bildirim döngülerine ihtiyacı vardır. Geliştiriciler müşterilerinizdir  -  ihtiyaçlarını anlayın.
223 
224### 3. Çekmek Yerine Zorunlu Kılmak
225En iyi platformlar, geliştiricilerin hayatını kolaylaştırdıkları için gönüllü olarak benimsenir. Kullanımı zorunlu kılmanız gerekiyorsa, platformunuz yeterince iyi değildir.
226 
227### 4. Geliştirici Deneyimini Göz Ardı Etmek
228Kötü UX'li bir platform kullanılmayacaktır. Net belgelere, yardımcı hata mesajlarına ve hızlı geri bildirim döngülerine yatırım yapın.
229 
230## Başlarken
231 
232İlk IDP'nizi oluşturmak için pratik bir yol haritası:
233 
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239 
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243 
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247 
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251 
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256 
257### Minimum Uygulanabilir Platform
258 
2591. **Servis kataloğu** (Backstage)  -  neyin var olduğunu ve kimin sahip olduğunu bilin
2602. **Bir servis şablonu**  -  en yaygın servis türünüz için altın yol
2613. **Standardize CI/CD**  -  ekiplerin dahil ettiği paylaşımlı pipeline
2624. **Temel belgeler**  -  platformu nasıl kullanacağınız, nereden yardım alacağınız
263 
264Bu MVP'yi 2-3 mühendislik ekibiyle 2-3 ayda oluşturabilirsiniz.
265 
266## Sonuç
267 
268Platform Engineering, ilk günden mükemmel platformu oluşturmakla ilgili değildir. Geliştiriciler üzerindeki bilişsel yükü kademeli olarak azaltarak ürün geliştirmeye odaklanmalarını sağlamakla ilgilidir. Küçük başlayın, etkiyi ölçün ve geliştirici geri bildirimlerine göre iterasyon yapın.
269 
270Platform Engineering'e yatırım yapan organizasyonlar önemli bir rekabet avantajına sahip olacaktır: daha hızlı teslimat, daha mutlu geliştiriciler ve daha güvenilir sistemler.
271 
272**Kaynaklar:**
273- [Team Topologies](https://teamtopologies.com/)  -  platform ekiplerini popüler hale getiren kitap
274- [Backstage](https://backstage.io/)  -  Spotify'ın açık kaynak geliştirici portalı
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  topluluk tanımı ve en iyi pratikler
276- [platformengineering.org](https://platformengineering.org/)  -  topluluk, etkinlikler ve kaynaklar
277