Kod Olarak Altyapı (Infrastructure as Code, IaC)

Kod Olarak Altyapı (IaC), bulut altyapısını — sunucular, ağlar, veritabanları, yük dengeleyiciler, izinler — bir bulut sağlayıcısının web konsolunda kaynakları elle tıklayarak oluşturup yapılandırmak yerine, sürüm kontrolünde saklanan makine tarafından okunabilir yapılandırma dosyaları aracılığıyla tanımlama ve yönetme pratiğidir. Araçlar arasında Terraform (buluttan bağımsız, en yaygın benimsenen), AWS CloudFormation ve CDK (AWS'ye özgü) ve Pulumi (özel bir yapılandırma formatı yerine genel amaçlı programlama dilleri kullanan IaC) bulunur. AI/SaaS geliştiricileri için neden önemli: elle yapılandırılmış altyapı ("ClickOps") kırılgan ve tekrarlanamazdır — çalışan bir production ortamı üreten her tıklamayı güvenilir bir şekilde hatırlayabilecek veya belgeleyebilecek kimse yoktur; bu, felaket kurtarma, ortam paritesini (staging'in production ile eşleşmesi) ve yeni ekip üyelerinin işe alımını acı verici derecede yavaş ve hataya açık hale getirir. IaC, sürüm kontrolünün uygulama kodu için çözdüğü şekilde bunu çözer: altyapı değişiklikleri incelenebilir bir diff'ten, bir değişiklik geçmişinden geçer ve aynı ortam sıfırdan güvenilir bir şekilde yeniden oluşturulabilir — gerçekten özdeş bir staging ortamı kurmak veya bir bulut bölgesindeki felaket bir arızadan hızla kurtulmak için kritik. Nasıl çalışır: altyapı, yapılandırma dosyalarında (örneğin Terraform'un HCL'i) bildirimsel olarak tanımlanır — "Bu izinlere sahip X adlı bir S3 bucket, bu boyutta bir Postgres RDS örneği ve 443 portunda trafiğe izin veren bir güvenlik grubu istiyorum" — ve bir planlama adımı bu istenen durumu altyapının gerçek mevcut durumuyla karşılaştırarak neyin oluşturulacağı, değiştirileceği veya yok edileceğine dair bir diff üretir. Bir insan (veya otomatik bir pipeline) bu planı uygulanmadan önce inceler ve onaylar; bu noktada araç, gerçekliği bildirilen yapılandırmaya uydurmak için bulut sağlayıcısının API'lerini çağırır. Uygulamalı örnek: bir SaaS ekibinin, büyük bir sürümü test etmek için production ile özdeş yeni bir staging ortamı kurması gerekiyor. Tüm altyapıları Terraform'da tanımlandığından — VPC, veritabanı örneği boyutu ve yapılandırması, yük dengeleyici kuralları, IAM izinleri — tam olarak neyin oluşturulacağını önizlemek için `terraform plan -var environment=staging` çalıştırıyorlar, planı inceliyorlar (oluşturulacak 47 kaynak) ve tüm ortamı sıfırdan yaklaşık on dakikada sağlamak için `terraform apply` çalıştırıyorlar; bu, aynı kod tabanından üretildiği için (yalnızca farklı bir değişken kümesiyle) production'ın yapılandırmasıyla tam olarak eşleşmesi garanti edilir — ortam başlangıçta elle inşa edilmiş olsaydı günler süren, hataya açık elle yeniden inşaya kıyasla. Tüm yapılandırma uygulama koduyla birlikte sürüm kontrolünde yaşadığından, staging ve production arasındaki herhangi bir kazara sapma — örneğin birinin konsol aracılığıyla elle bir güvenlik grubu ayarını değiştirmesi — bir sonraki `terraform plan` çalıştırıldığında sessizce "staging'de çalışıyor, production'da bozuluyor" sürprizine neden olmak yerine beklenmedik bir diff olarak açıkça ortaya çıkar.