1. GİRİŞ

Infrastructure as Code (IaC) modern bulut altyapılarının temel disiplinlerinden biridir. IaC, altyapı kaynaklarını (network, compute, storage, IAM, DNS vb.) sürümlenebilir, test edilebilir, tekrar üretilebilir ve otomatik olarak uygulanabilen kod olarak tanımlama pratiğidir. Bulut sağlayıcılarının sunduğu API'ler ve orkestrasyon araçları sayesinde altyapı artık manuel tıklamalarla değil, yazılımla yönetiliyor. Bu dönüşüm; hız, tutarlılık, izlenebilirlik, güvenlik ve maliyet yönetimi açısından kritik değerdedir.

Bu konu neden bugün önemli?

• Bulut kaynak tüketimi ve kompleks mimariler artıyor; manuel süreçler ölçeklenemez hâle geldi.
• Regülasyonlar ve uyum gereksinimleri değişikliklerin izlenmesini zorunlu kılıyor; IaC değişiklikleri Git üzerinden denetlenebilir.
• CI/CD ve GitOps kültürlerinin yaygınlaşmasıyla altyapının da yazılım geliştirme döngüsüne entegre edilmesi gerekliliği arttı.

Kimler için önemli?

• Platform mühendisleri, DevOps, SRE ekipleri
• Bulut mimarları ve altyapı yöneticileri
• Geliştiriciler — özellikle cloud‑native uygulama geliştiren ekipler

Hangi problemleri çözüyor?

• Environment drift (çevreler arası tutarsızlık)
• Manuel hatalar ve tekrarlayan operasyonel işler
• Deploy süreçlerinin belirsizliği ve rollback eksikliği

2. KAVRAMSAL TEMELLER

2.1 IaC nedir — kısa tanım

IaC, altyapının kodla tanımlanması ve bu tanımın otomatik olarak uygulanmasını ifade eder. IaC tanımları; deklaratif ("desired state") veya imperatif (adım adım) olabilir. Deklaratif yaklaşımlar (ör. Terraform, CloudFormation, Bicep) istenen durumu beyan eder; sistem bu durumu sağlamaya çalışır. Imperatif yaklaşımlar (bazı SDK tabanlı Pulumi kullanımları, script'ler) adım adım komutları çalıştırır.

2.2 Temel terminoloji

• Provider: Cloud sağlayıcı veya servis için API adapter'ı (AWS, Azure, Google Cloud, Kubernetes).
• Resource: Oluşturulan altyapı bileşeni (VM, VNet, S3 Bucket).
• Module / Component: Tekrar kullanılabilir altyapı paketleri.
• State: IaC motorunun mevcut kaynak durumunu sakladığı veri (ör. Terraform state).
• Plan/Apply: Değişikliklerin hesaplanması (plan) ve uygulanması (apply) aşamaları.

2.3 Deklaratif vs Imperatif

Deklaratif: Kullanıcı "ne" istediğini belirtir; araç "nasıl" yapılacağını yönetir. Bu yaklaşım idempotent olma eğilimindedir ve genelde daha güvenlidir. Imperatif: Kullanıcı "nasıl" yapılacağını kodlar; adımlar sırayla uygulanır. Her iki yaklaşımın da yeri vardır — seçim kullanım senaryosuna göre yapılmalıdır.

3. NASIL ÇALIŞIR? — Teknik Mimari

3.1 Popüler araçlar ve karşılaştırma

• Terraform (HashiCorp): Deklaratif, provider‑agnostic; modüler yapı, state management, geniş community. En yaygın kullanılan IaC araçlarından biridir.
• Pulumi: SDK tabanlı, imperatif veya deklaratif yaklaşımla programlama dilleri (TypeScript, Python, Go, C#) üzerinden altyapı tanımlamaya izin verir; geliştiricilere tanıdık araç zinciri sunar.
• CloudFormation / AWS CDK: AWS'e özel; CDK ile geliştiriciler altyapıyı yüksek seviyeli dillerle tanımlayıp CloudFormation çıktısı üretebilir.
• Azure Resource Manager (ARM) / Bicep: Azure'e özgü deklaratif çözümler; Bicep, ARM template'lerin daha okunabilir halidir.
• Kubernetes YAML / Helm / Kustomize: Kubernetes kaynak yönetimi için kullanılan manifest araçları; GitOps ile sık kullanılır.

3.2 State yönetimi ve locking

IaC araçlarının çoğu state dosyası kullanır (Terraform state). State, kaynakların IDs, metadata ve ilişkilerini içerir. State'in güvenli, paylaşılan ve kilitlenebilir bir backend'e (S3 + DynamoDB, Azure Storage + blob lease, Google Cloud Storage) taşınması çok önemlidir.

• Remote state: Paylaşılan ekipler için kaçınılmazdır. State backend olarak S3, Azure Blob, GCS veya Terraform Cloud kullanılabilir.
• State locking: Aynı anda birden fazla apply operasyonunun çakışmasını önler; DynamoDB veya state backend'in sunduğu mekanizmalarla sağlanır.
• State sensitivity: State içerisinde gizli bilgi olmamalıdır; secrets referansları kullanın, state'leri şifreleyin.

3.3 Plan & Apply workflow

Tipik CI/CD entegrasyonu şu şekildedir: Developer PR açar → CI pipeline terraform plan (veya Pulumi preview) çalıştırır → plan çıktısı PR'a eklenir ve incelenir → onay sonrası apply tetiklenir (genelde pipeline veya manuel onay) → state güncellenir. Bu model deployment riskini azaltır ve değişikliklerin gözden geçirilmesini sağlar.

3.4 Modules, packages ve testability

Altyapıyı modüler hale getirmek, bakım ve reuse açısından kritiktir. Terraform module'ları, Pulumi component'leri ve CDK construct'ları bu amaçla kullanılır. Modüller unit seviyesinde test edilmeli (terratest, kitchen‑terraform), entegrasyon testleri için ephemeral environment'lar kullanılmalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — Repeatable infra ve resilience

Netflix ve benzeri ölçeklerde altyapı kodu, cluster bootstrap, altyapı şablonları ve otomatik recovery senaryolarının oluşturulmasında kritik rol oynar. IaC ve chaos engineering birlikte kullanılarak, altyapıda beklenmeyen hatalar senaryoları test edilir.

Uber — Bölgesel altyapı ve multi‑account yönetimi

Bölgesel dağıtımlar, account izolasyonu ve networking karmaşıklığı IaC ile kodlanır. Modulizasyon, naming convention ve account provisioning otomatikleştirilir.

Amazon — Policy as code ve güvenlik

AWS kurumlarında IaC taramalarına SAST benzeri kontroller entegre edilir; IAM policy'leri, SCP ve guardrails IaC şablonlarıyla enforce edilir.

OpenAI / MLOps — Ortam reproducibility

MLOps boru hatları için veri kaynakları, feature store, model serving endpoint'leri IaC ile kurulur. Reproducible infra, model kaynağı ve ortam variant'larının aynı koşullarda çalışmasını sağlar.

Stripe — Compliance ve audit

Finansal uygulamalarda IaC, audit trail ve deployment geçmişi için kritik bir kayıt katmanı sunar. Ayrıca otomatik testler ve policy validation ile regülasyon gereksinimleri desteklenir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Tutarlılık: Environment'lar kodla tanımlı olduğunda prod/test/dev tutarlılığı sağlanır.
• Versiyonlama ve audit: Değişiklikler Git commit'leri ile izlenebilir.
• Otomasyon: Tekrarlayan insan görevleri otomatikleştirilir, MTTR azalır.
• İzlenebilir deploys: Plan ve apply çıktıları incelenip değişikliklerin etkisi değerlendirilebilir.

Sınırlamalar

• State yönetimi zorluğu: Paylaşılan state, erişim ve locking sorunları yaratabilir.
• Tooling bağımlılığı: Her tool'ün kendine özgü davranışı ve sürümlere bağlılık getiren ekosistemi vardır.
• Learning curve: IaC kalıplarını doğru kurmak ve test etmek başlangıç maliyeti getirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• State'i remote ve kilitlenebilir backend'e taşıyın (örn. S3 + DynamoDB, Terraform Cloud, Azure Storage).
• Plan adımını CI'de otomatik çalıştırın; apply adımını onaylı veya otomatik pipeline ile yönetin.
• Modüler yapı kurun: environment bazlı overlay'lar ve reusable module'lar kullanın.
• Secrets'ı Git dışında yönetip manifest'lerde referanslayın (Vault, Azure Key Vault, AWS Secrets Manager).

Performans ve maliyet optimizasyonu

• Provisioning sırasında paralel kaynak oluşturma limitlerini sağlayın ve dependency graph'ı optimize edin.
• Resource tagging ile maliyet takibi ve chargeback için doğru etiketleme yapın.
• Idle resource'ları otomatik tespit edip kapatma politikaları uygulayın (autoscaler/policy).

Güvenlik

• Policy as code (OPA, Terraform Sentinel) ile CI aşamasında güvenlik politikalarını zorunlu kılın.
• IAM rollerini least‑privilege prensibine göre düzenleyin; role assumption ve temporary credential'ları tercih edin.
• Supply chain güvenliği için SBOM, image scanning ve provider credential yönetimini sıkılaştırın.

Test ve doğrulama

• Unit & integration test: terratest, kitchen‑terraform veya Pulumi test framework'lerini kullanın.
• Ephemeral environment'lar: Test için geçici cluster veya resource setleri kurup testleri çalıştırın.
• Drift detection: Plan aşamasında drift uyarılarını raporlayın ve otomatik remediation stratejileri belirleyin.

8. SIK YAPILAN HATALAR

• State'i yerel dosya olarak tutmak: paylaşımsız, çatışmalara açık ve güvenlik riski taşır.
• Secrets'ı düz metin olarak Git'e koymak: kritik güvenlik hatasıdır.
• Modül versiyonlandırmasını ihmal etmek: breaking change'ler ekipleri olumsuz etkiler.
• Plan'ı incelemeden doğrudan apply yapmak: beklenmeyen kaynak silinmeleri ve maliyet artışlarına yol açar.
• Rollback stratejisi olmadan DB migration'ları yapmak: veri uyumsuzlukları risklidir.

9. GELECEK TRENDLER

1. Policy as Code ve continuous compliance: IaC pipeline'ları, regülasyon uyumunu otomatik şekilde doğrulayacak.
2. AI destekli infra öneri ve optimizasyon: Machine learning ile resource sizing, cost prediction ve anomaly detection çözümleri yaygınlaşacak.
3. GitOps ile tighter integration: IaC ve GitOps yaklaşımları birleşerek uygulama + infra değişikliklerinin birlikte yönetildiği workflow'lar ortaya çıkacak.
4. Infrastructure as Software: Altyapı projeleri yazılım mühendisliği süreçlerine daha da entegre olacak; test, code review ve dependency management standartları uygulanacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. IaC ile başlamanın en pratik yolu nedir?

   Small steps: Önce basit bir VPC veya network bileşeni ile başlayın, Terraform veya Bicep ile tanımlayın, remote state ve CI plan adımı entegrasyonu yapın. Kademeli olarak modülize edip diğer kaynaklara genişletin.

2. Terraform mı Pulumi mi seçmeliyim?

   Team profiline göre: Terraform provider‑agnostic ve geniş ekosistem sunar; Pulumi geliştirici deneyimini (dillerle altyapı tanımı) ön planda tutar. Büyük ekiplerde Terraform yaygın tercih edilirken, uygulama geliştiricilere yakın ekiplerde Pulumi avantajlı olabilir.

3. State dosyası güvenliğini nasıl sağlarsınız?

   State'i şifrelenmiş remote backend'e taşıyın (SSE), erişimi IAM ile kısıtlayın, state locking kullanın ve sensitive output'ları minimize edin.

4. Secrets'ı Git'te nasıl güvenli tutarım?

   Secrets'ı Git'te düz metin olarak tutmayın. SealedSecrets, External Secrets veya Vault gibi çözümler kullanın. Eğer şifrelenmiş saklayacaksanız, anahtar yönetimini güvenli bir KMS ile yapın.

5. IaC testlerini nasıl organize ederim?

   Unit testler modül seviyesinde, integration testler ephemeral environment'larda ve end‑to‑end testler staging üzerinde çalıştırılmalıdır. Terratest, kitchen‑terraform ve Pulumi test araçları yaygındır.

6. Drift nasıl tespit edilir ve yönetilir?

   Plan aşamasında farkları raporlayın, düzenli reconcile cron'ları çalıştırın ve önemli drift'lar için otomatik remediation tetikleyin veya değişiklik talepleri oluşturun.

7. IaC ile veri migration'ları nasıl yapılmalı?

   Migration'ları backward/forward compatible şekilde tasarlayın, veri dönüşümlerini küçük adımlarla uygulayın ve feature flags ile yeni kodu kontrollü açın. Rollback planlarını önceden oluşturun.

8. IaC pipeline performansı nasıl optimize edilir?

   Parallel job'lar, remote state performansı, module caching ve partial/targeted apply stratejileri ile pipeline sürelerini azaltın.

Anahtar Kavramlar

IaC

Infrastructure as Code — altyapının kod ile tanımlanması ve otomatik uygulanması.

State

Altyapı motorunun mevcut kaynak durumunu tuttuğu kayıt.

Module / Component

Tekrar kullanılabilir altyapı tanımı.

Policy as Code

Güvenlik ve uyumluluk kurallarının kod ile tanımlanması ve otomatik validasyonu.

GitOps

Git'i tek kaynak olarak kullanıp deklaratif manifest'leri controller ile reconcile eden operasyon yaklaşımı.

Öğrenme Yol Haritası

1. 0–1 ay: Temel AWS/Azure/GCP kavramları, CLI ve IAM öğrenin; basit Terraform veya Bicep örnekleri kurun.
2. 1–3 ay: Terraform modülleri, remote state, provider konfigürasyonu ve CI entegrasyonu üzerinde çalışın.
3. 3–6 ay: Test otomasyonu (terratest), policy as code (OPA) ve secrets yönetimi uygulamalarını entegre edin.
4. 6–12 ay: Multi‑account, multi‑region ve multi‑cluster scenaryolarında IaC'yi ölçeklendirin; GitOps pratiklerini uygulayın.
5. 12+ ay: Infrastructure as Software yaklaşımında derinleşin: release süreçleri, module governance, cost engineering ve AI destekli optimizasyonlar üzerinde çalışın.