CloudFormation ile Terraform Arasındaki Farklar ve Seçim Ölçütleri

Ortak zemin: altyapıyı kodla tanımlamak

CloudFormation ve Terraform, kod olarak altyapı (Infrastructure as Code, IaC) yaklaşımının iki yaygın aracıdır. İkisinde de sunucular, ağlar, veritabanları ve izin tanımları elle konsoldan oluşturulmak yerine bildirimsel (declarative) dosyalarda tarif edilir. Dosyalar sürüm kontrolüne alınır, kod incelemesinden geçer ve aynı tanımdan geliştirme, test ve üretim ortamları tutarlı biçimde kurulur.

İki araç da istenen son durumu tarif etmeyi, kaynaklar arasındaki bağımlılıkları çözüp doğru sırayla oluşturmayı ve değişiklikleri uygulamadan önce görmeyi sağlar. Bu yüzden seçim "hangisi IaC yapar" sorusu değil, kaynakların nerede çalıştığı, durumun kim tarafından tutulduğu ve ekibin iş akışının nasıl kurulduğu sorusudur.

Ölçüt ölçüt temel farklar

• Kapsam: CloudFormation / AWS'nin kendi hizmetidir ve AWS kaynaklarını yönetir. Terraform / HashiCorp'un aracıdır; sağlayıcılar (provider) aracılığıyla API'si olan hemen her platformu, AWS, Azure, Google Cloud, Kubernetes ve GitHub gibi hizmetleri aynı dille yönetir.
• Dil: CloudFormation / şablonlar JSON ya da YAML ile yazılır; parametreler, eşlemeler, koşullar ve yerleşik fonksiyonlarla esneklik sağlanır. Terraform / HCL adlı, insan tarafından okunmak için tasarlanmış yapılandırma dili kullanılır.
• Durum (state): CloudFormation / yığının (stack) durumu AWS tarafında tutulur; kullanıcı ayrı bir durum dosyası yönetmez. Terraform / gerçek kaynaklarla yapılandırma arasındaki eşleşme bir durum dosyasında tutulur; ekip çalışmasında bu dosyanın uzak bir arka uçta, kilitlemeyle ve güvenli erişimle saklanması gerekir.
• Değişiklik önizleme: CloudFormation / değişiklik kümeleri (change sets) ile yığına uygulanacak değişiklikler önceden görülür. Terraform / plan komutu, oluşturulacak, güncellenecek ve silinecek kaynakları onaydan önce listeler.
• Sapma tespiti: CloudFormation / sapma tespiti (drift detection), konsoldan ya da başka yollarla yapılan elle değişiklikleri raporlar. Terraform / her işlem öncesindeki yenileme adımında gerçek altyapı durumla karşılaştırılır ve fark planda görünür.
• Yeniden kullanım: CloudFormation / iç içe yığınlar ve modüllerle. Terraform / modüller ve herkese açık Terraform Registry ile.

Durum yönetimi neden belirleyici bir fark?

Terraform'un durum dosyası, aracın hangi gerçek kaynağın hangi tanıma karşılık geldiğini bilmesini sağlar. Bu esneklik getirir ama sorumluluk da yükler. Durum dosyası varsayılan olarak yerel bir dosyadır; ekip çalışmasında uzak bir arka uca taşınmazsa iki kişinin aynı anda değişiklik yapması çakışmaya, dosyanın kaybolması ise kaynakların sahipsiz kalmasına yol açar. Durum dosyası gizli bilgiler de içerebileceğinden, kilitleme ve erişim denetimi olmayan bir yerde, örneğin sürüm kontrol deposunda tutulmamalıdır.

CloudFormation'da bu yük AWS'dedir. Yığın oluşturma ya da güncelleme başarısız olduğunda hizmet değişikliği geri almaya çalışır ve yığının son durumu konsoldan izlenir. Karşılığında esneklik daha sınırlıdır: AWS dışındaki bir kaynağı yönetmek için özel kaynaklar (custom resources) ve ek kod gerekir. Kısacası CloudFormation durum yönetimini devrederek kolaylık, Terraform durumu sizin elinize bırakarak kapsam genişliği sunar.

Örnek iş akışı: aynı ortam iki araçla

Örneğin bir ekip, bir web uygulaması için ağ, yük dengeleyici, sunucu grubu ve veritabanından oluşan bir ortam kuruyor. CloudFormation ile şablon YAML olarak yazılır, ortam farkları parametrelerle verilir. Güncelleme sırasında bir değişiklik kümesi oluşturulur, inceleme ekibi hangi kaynakların yeniden yaratılacağını görür ve değişiklik kümesi çalıştırılır. Birden çok hesap ve bölgeye aynı tanımı yaymak için StackSets kullanılabilir.

Aynı ortam Terraform ile kurulduğunda ağ ve veritabanı ayrı modüller olarak yazılır, durum dosyası uzak bir arka uçta tutulur. Sürekli entegrasyon hattı her çekme isteğinde plan çıktısını üretir, onaydan sonra apply çalıştırılır. Ekip aynı depoda DNS kaydını başka bir sağlayıcıda, izleme panolarını da ayrı bir hizmette tanımlayabilir; Terraform'un çoklu sağlayıcı yapısı burada fark yaratır.

Hangi durumda hangisi?

CloudFormation daha uygundur: • Altyapının tamamı AWS üzerindeyse ve kurum ek bir aracı işletmek istemiyorsa. • Durum dosyası yönetimi, kilitleme ve arka uç kurulumu gibi işleri hizmete bırakmak isteniyorsa. • AWS'nin kendi yönetişim ve çoklu hesap dağıtım özellikleri yoğun kullanılıyorsa.

Terraform daha uygundur: • Birden çok bulut sağlayıcısı ya da bulut dışı hizmetler (DNS, izleme, kimlik yönetimi, kod deposu) aynı iş akışında yönetilecekse. • Ekip tek bir dil ve araçla farklı platformlarda standart kurmak istiyorsa. • Modül paylaşımı, politika kontrolleri ve plan tabanlı onay akışı merkezi bir platform ekibinin işletim modeline uyuyorsa.

Bazı kurumlar ikisini birlikte kullanır: AWS hesap temeli ve kurumsal kontroller CloudFormation ile, uygulama ekiplerinin çok sağlayıcılı altyapısı Terraform ile yönetilir. Bu durumda hangi kaynağın hangi araçla yönetildiği açıkça ayrılmalıdır; aynı kaynağı iki aracın birden yönetmesi sapma ve çakışma üretir.

Sık yapılan hatalar

• Terraform durum dosyasını yerelde ya da sürüm kontrolünde tutmak; kilitleme olmadığı için eşzamanlı değişikliklerde durum bozulur.
• Konsoldan yapılan acil değişiklikleri koda geri yazmamak; bir sonraki uygulamada değişiklik geri alınır ya da beklenmedik bir kaynak silinir.
• CloudFormation'da tek bir dev şablon yazmak; iç içe yığınlara ve modüllere bölünmeyen şablonlar zor incelenir ve güncellenir.
• Plan ya da değişiklik kümesi çıktısını okumadan onaylamak; yeniden yaratılacak bir veritabanı çoğu zaman bu çıktıda fark edilir.
• Araç seçimini yalnız bugünkü bulut sağlayıcısına göre yapmak; birkaç yıl içinde eklenecek hizmetler ve ekiplerin beceri profili de hesaba katılmalıdır.

Mindset programlarında CloudFormation ve Terraform

AWS CloudFormation ile Altyapı Şablonlama eğitimi şablon anatomisi, parametreler ve koşullar, fonksiyonlar ve bağımlılıklar, modülerleştirme ve iç içe yapılar, değişiklik yönetimi ve sapma kontrolü ile çoklu hesap ve bölge dağıtımını işler. Terraform ile Altyapı Otomasyonu eğitimi ise HCL temelleri, durum yönetimi ve arka uç, modüler mimari, politika ve uyumluluk otomasyonu, CI/CD iş akışları ve çok bulutlu stratejiyi kapsar.

Terraform'u ekip ölçeğinde işletmek isteyenler için Terraform Cloud ve Workspace Yönetişimi eğitimi workspace organizasyonu, erişim kontrolü ve gizli bilgi yönetimi ile politika entegrasyonunu ele alır.