Platform Engineering: Internal Developer Platform Nasıl Oluşturulur

spinny:~/writing $ vim platform-engineering-internal-developer-platform.md

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~

NORMAL · platform-engineering-internal-developer-platform.md [readonly]277 lines · :q to close

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.

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.

6## Platform Engineering Nedir?

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.

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~