1. GİRİŞ

Self‑Service Infrastructure (öz‑servis altyapı) modern yazılım organizasyonlarının altyapı ile geliştirici ekipleri arasındaki sürtüşmeyi azaltmak için kullanılan bir yaklaşımdır. Amaç, geliştiricilerin ihtiyaç duydukları altyapı kaynaklarını (kubernetes cluster, veritabanı, messaging, storage vb.) talep etmek ve yönetmek için operatörlere bağımlı olmadan, güvenli ve kontrol edilmiş bir yol sunmaktır. Bu yaklaşım, developer productivity (DX), hız ve operasyonel ölçeklenebilirlik hedeflerini aynı anda destekler.

Neden bugün konuşuluyor?

• Bulut ve konteyner tabanlı mimarilerin yaygınlaşması, altyapı taleplerini dinamik hale getirdi; manuel süreçler sürdürülemez oldu.
• Developer Experience ve hızlı teslimat beklentileri arttı; altyapı taleplerinin self‑service olarak karşılanması gerekliliği belirginleşti.
• Güvenlik, uyumluluk ve maliyet kontrolü gereksinimleri altyapı taleplerini merkezi politikalarla kısıtlayacak mekanizmalar gerektiriyor — self‑service bunu policy as code ile sağlar.

Kimler için önemli?

• Platform mühendisleri ve SRE ekipleri — altyapıyı self‑service hale getirerek operasyonel yükü azaltır.
• Geliştiriciler — altyapı talep süreçlerini hızlandırır ve tekrar kullanılabilir şablonlarla çalışır.
• Güvenlik ve uyumluluk ekipleri — merkezi policy enforcement ve audit log ile kontrol sağlar.

Hangi problemleri çözüyor?

• Uzun altyapı talep bekleme süreleri
• Tekrarlayan, hataya açık manuel işlemler
• Dağınık ve tutarsız altyapı konfigürasyonları

2. KAVRAMSAL TEMELLER

2.1 Tanım

Self‑Service Infrastructure, geliştiricilerin portal, CLI veya API aracılığıyla altyapı kaynaklarını talepten dağıtıma kadar yönetebildiği, ancak platform tarafından tanımlı policy, güvenlik ve maliyet sınırları içinde kalarak gerçekleştirdiği bir modeldir. Bu model genelde bir developer portal (Backstage vb.), IaC (Terraform/Pulumi), GitOps flow ve policy engine (OPA/Kyverno) kombinasyonu ile kurulur.

2.2 Temel bileşenler

• Developer Portal / Catalog: Self‑service işlemler için UI/CLI; şablonlar, dokümantasyon ve operational metadata içerir.
• Infrastructure as Code (IaC): Terraform, Pulumi gibi modüler, versioned kodla altyapı tanımı.
• GitOps & CI/CD: Manifestlerin git ile single source of truth olarak yönetilmesi; ArgoCD/Flux ile otomatik apply.
• Policy as Code: OPA / Kyverno ile güvenlik, naming, resource limits gibi kuralların otomatik doğrulanması.
• Identity & Access Management: Kimlik doğrulama, RBAC, kısa ömürlü credentials (STS) ve audit log.
• Cost Governance: Cloud cost allocation, tagging, quota ve chargeback mekanizmaları.

2.3 Terminoloji

• Golden Path: Platformun önerdiği, güvenli ve test edilmiş self‑service yol.
• Escape Hatch: Golden Path dışına kontrollü çıkış için onay/approval mekanizmaları.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE VERİ AKIŞI

3.1 Sistem mimarisi — Control Plane ve Data Plane

Self‑Service Infrastructure genelde iki katmana ayrılır: Control Plane (portal, policy engine, Git repos, CI) ve Data Plane (kubernetes cluster'lar, managed services, network, storage). Control Plane, kullanıcı taleplerini alır, IaC modüllerini parametrize eder, policy kontrolleri çalıştırır ve son adımda GitOps veya CI üzerinden Data Plane'e değişiklikleri uygular.

3.2 Tipik istek akışı

1. Geliştirici portal üzerinden yeni bir servis şablonu seçer veya bir kaynak talep eder (ör. Postgres instance).
2. Portal, gerekli parametreleri toplar ve bir IaC/manifest PR'si oluşturur ya da doğrudan parametrelenmiş bir template'i Git deposuna yazar.
3. CI pipeline, IaC validation (tflint, validate), unit testler ve security scanning (tfsec, checkov) çalıştırır.
4. Policy engine (OPA/Kyverno) PR üzerinde kontrolleri yapar; eğer kurallar sağlanıyorsa PR merge edilir veya onay mekanizması tetiklenir.
5. GitOps controller (ArgoCD/Flux) değişikliği algılar ve Data Plane üzerinde kaynağı oluşturur; audit log üretilir.
6. Platform, cost tag'leri, limits ve izleme entegrasyonunu otomatik olarak uygular; geliştirici bilgilendirilir.

3.3 Otomasyon ve tekrar kullanılabilir modüller

IaC modülleri (Terraform modules, Pulumi components) self‑service dünyasında kritik öneme sahiptir: parametrik, versiyonlanmış ve test edilmiş modüller platformun güvenliğini ve tutarlılığını sağlar. Modüller, golden path deneyiminin yapı taşlarıdır ve escape hatch gerektiren durumlarda bile yeniden kullanılabilir yapı blokları olarak hizmet eder.

3.4 Güvenlik ve kimlik

Kimlik yönetimi ve kısa ömürlü credential'lar (AWS STS, GCP Workload Identity Federation, Kubernetes OIDC) self‑service süreçlerinde önem taşır. Platform, servis hesaplarını ve erişimleri policy as code ile otomatik tanımlar; ayrıca secrets management (Vault, KMS) üzerinden erişim kontrolü sağlar.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — Internal self‑service araçlar

Netflix, geliştiricilere self‑service araçlar ve sabitlenen golden path'ler sağlayarak geliştirme hızını ve güvenilirliği arttırmıştır. Orta ve büyük ölçekli şirketlerde benzer platform yaklaşımları gözlemlenmektedir.

4.2 Uber — altyapı self‑servise dönüşüyor

Uber, global ölçekli altyapısında self‑service ve otomasyonla operasyonel maliyetleri düşürdü; özel gereksinimler için ise approval ve guardrail mekanizmaları kullanıldı.

4.3 AWS / GCP / Azure müşterileri

Çok sayıda şirkette self‑service altyapı, managed services (RDS, Memorystore), terraform module katalogları ve GitOps ile birleşerek uygulanmaktadır. Bulut sağlayıcıların native araçları (Service Catalog, Landing Zone) bu süreci hızlandırır, fakat vendor‑agnostic modüller lock‑in riskini azaltır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Geliştirici bağımsızlığı: altyapı talepleri hızlanır, bekleme süreleri kısalır.
• Tekrarlanabilirlik: IaC modülleri ile tutarlı altyapı kurulumları sağlanır.
• Güvenlik ve uyumluluk: policy as code ile merkezi kontrol ve audit gerçekleşir.
• Maliyet kontrolü: tagging, quota ve FinOps entegrasyonu ile maliyet yönetimi iyileşir.

Sınırlamalar

• Karmaşıklık: Control plane kurulum ve işletimi ek operational yük getirir.
• Öğrenme eğrisi: IaC modüllerini doğru tasarlamak ve policy'leri yazmak uzmanlık gerektirir.
• Yanlış tasarım riskleri: Çok katı veya çok gevşek politikalar DX'i olumsuz etkileyebilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Aşamalandırılmış rollout: pilot birimlerle başlayın, telemetri ile davranışı doğrulayarak genişletin.
• Golden Path oluşturun: çoğu geliştirici için ön tanımlı, güvenli ve test edilmiş şablonlar sağlayın.
• Escape hatch ve approval workflow'ları tasarlayın: acil veya özel durumlar için kontrollü esneklik bırakın.

Performans ve ölçeklenebilirlik

• IaC modüllerini küçük, tek sorumluluk prensibine uygun olarak tasarlayın ve versiyonlayın.
• GitOps controller'larının performansını ve reconciliation frekansını izleyin; büyük ortamlar için sharding planlayın.

Güvenlik

• Policy as Code (OPA/Kyverno) ile IaC ve runtime kontrollerini zorunlu kılın.
• Secrets yönetimini merkezi ve short‑lived credential kullanan bir mimariyle sağlayın.

Cost governance

• Otomatik tagging, quota ve cost alert'leri kurun; ekip bazlı chargeback/showback süreçleri oluşturun.

8. SIK YAPILAN HATALAR

• Her isteği otomatikleştirirken policy ve validation adımlarını atlamak — güvenlik açığı oluşur.
• Çok katı golden path'ler — geliştiriciler workaround arar ve platformu benimsemezler.
• IaC modüllerini yeterince test etmemek — prod sürümlerde hatalarla karşılaşılır.
• Cost‑tagging ve quota mekanizmalarını baştan planlamamak — beklenmeyen maliyet artışları.

9. GELECEK TRENDLER

1. AI destekli self‑service: Telemetry ve usage verilerinden öneriler üreten, otomatik şablon ve konfigürasyon öneren akıllı portal'lar.
2. Platform as Data: Platform verileri ML modelli analizlerle kapasite, cost ve güvenlik optimizasyonu sağlar.
3. eBPF ve kernel‑level optimizations: Data plane optimizasyonları ile daha hafif ve verimli resource provisioning.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Self‑service infrastructure ne zaman gerekli olur?

   Takım sayısı ve servis sayısı arttığında; manuel altyapı talepleri darboğaz oluşturuyorsa self‑service düşünülmelidir. Genelde 10+ ekip ve çok sayıda environment olduğunda fayda öne çıkar.

2. 2. GitOps kesinlikle gerekli mi?

   GitOps self‑service için güçlü bir pattern sağlar (audit, rollback, declarative). Mutlaka gerekli olmasa da tavsiye edilen uygulamadır.

3. 3. IaC modüllerini nasıl test ediyorsunuz?

   Unit test, integration test (terratest gibi), plan/diff doğrulamaları ve policy validation (OPA/Kyverno) ile test edilir. Ayrıca staging ortamlarında ephemiral environment'lar ile doğrulama yapılmalıdır.

4. 4. Policy as Code hangi sorunları çözer?

   Naming convention, resource limits, network policy, encryption requirement gibi kuralları otomatik uygulayarak insan hatasını azaltır ve compliance sağlar.

5. 5. Cost governance nasıl entegre edilir?

   Otomatik tagging, quota, cost center atama ve FinOps dashboard'ları ile. Ayrıca provisioning aşamasında cost estimate sunmak geliştiricinin bilinçli seçim yapmasını sağlar.

6. 6. Escape hatch kullanımına nasıl izin verilir?

   Approval workflow (manual onay, time‑bounded approvals) ile; escape hatch'ler auditlenir ve limitlenir.

7. 7. Self‑service ölçeği nasıl planlanır?

   Önce kritik, sık tekrar edilen kaynaklar için şablonlar oluşturun (k8s service, DB, cache). Ölçeklendikçe daha fazla kaynak ve modül ekleyin; telemetry ile usage'i izleyin.

8. 8. Güvenlik hangi aşamada devreye alınmalı?

   En başından itibaren: IaC validation, secrets management, identity ve policy as code ile güvenlik tasarıma dahil edilmelidir.

Anahtar Kavramlar

Self‑Service Infrastructure

Geliştiricilerin altyapı kaynaklarını policy kontrollü, self‑service olarak talep edebildiği model.

IaC (Infrastructure as Code)

Altyapı konfigürasyonlarının kod ile tanımlanması; versiyonlama ve test imkanı sağlar.

GitOps

Manifestlerin git üzerinden deklaratif olarak yönetilmesi ve otomatik olarak Data Plane'e uygulanması.

Policy as Code

Güvenlik ve uyumluluk kurallarının kod ve otomatik doğrulama ile uygulanması.

Golden Path

Platform tarafından önerilen, güvenli ve test edilmiş self‑service yol.

Öğrenme Yol Haritası

1. 0–1 ay: IaC temelleri (Terraform/Pulumi) ve temel cloud servislerini öğrenin. Küçük bir modul ile başlayın.
2. 1–3 ay: GitOps (ArgoCD/Flux), CI tooling ve policy as code (OPA/Kyverno) entegrasyonlarını uygulayın.
3. 3–6 ay: Developer portal (Backstage) ve self‑service şablonlar oluşturun; pilot ekiplerle test edin.
4. 6–12 ay: Cost governance, multi‑cluster GitOps, escape hatch policies ve AI destekli optimizasyonlar üzerine çalışın.