Terraform ile yapılan pratik karşılaştırma, AWS ECS Express Mode'u geleneksel ECS ile ölçüyor

Express Mode sizin için ne oluşturuyor

dev.to rehberine göre Express Mode, tam bir ECS Fargate dağıtımı ortaya çıkarmak için yalnızca bir container image'ı ve bir altyapı rolüne ihtiyaç duyuyor. Arka planda bir VPC, subnet'ler, security group'lar, listener kurallarıyla birlikte bir Application Load Balancer, HTTPS yapılandırması, auto-scaling politikaları, metrikler, alarmlar ve health check'ler oluşturuyor — yani geleneksel bir ECS projesinin elle tanımlamak zorunda olduğu bileşenlerin aynısını.

Express Mode'un kendisi için ayrı bir ücret yok; yalnızca oluşturduğu kaynaklar için ödeme yapıyorsunuz. Tek bir Application Load Balancer ayrıca 25'e kadar Express Mode servisi tarafından paylaştırılabiliyor; yazar bunu, birden fazla workload çalıştırırken maliyetleri düşürmenin bir yolu olarak öne çıkarıyor.

Geleneksel referans noktası

Karşılaştırmayı adil tutmak için aynı Flask portfolyo uygulaması — Foundation, Advanced ve Production olarak etiketlenmiş üç sürümde yayımlanan — tek bir repository'nin iki dizininde tutulan Terraform koduyla her iki yaklaşımla da dağıtıldı.

Geleneksel yapılandırma; provider kurulumunu, varsayılan VPC ve subnet sorgularını, 5000 numaralı portu açan bir security group'u ve IAM rolleri, policy attachment'ları, task definition ve servisiyle birlikte ECS cluster'ını kapsıyor. Bir shell script'i, uygulama URL'sini oluşturmak için çalışan task'ın ağ arayüzünün public IP'sini alıyor.

Yazarın sonuç hakkındaki değerlendirmesi çarpıcı: tüm bu koda rağmen dağıtım hâlâ bir load balancer, HTTPS, metrikler, alarmlar ve scaling politikalarından yoksun. Express Mode'un varsayılan olarak ürettiğiyle aynı seviyeye ulaşmak, hatırı sayılır miktarda daha fazla Terraform gerektirecekti.

Express Mode üzerinden dağıtım

Express varyantı, yapılandırmasının büyük kısmını tek bir aws_ecs_express_gateway_service kaynağında topluyor; bunu değişkenler için dosyalar, özelliğin gerektirdiği execution ve altyapı rolleri ve canlı uygulama URL'sini içeren output'lar destekliyor.

Takas edilen şey hız. Geleneksel yığın bir iki dakika içinde çalışırken, Express dağıtımı yazarın testinde yaklaşık sekiz on dakika sürdü — ek süre, load balancing, TLS ve autoscaling katmanlarının oluşturulmasına gitti.

Her iki yolla sürüm güncelleme

Uygulama güncellemeleri iki yolda da benzer şekilde işliyor: Terraform yapılandırmasındaki Docker image etiketini değiştirin ve tekrar apply edin. Yazar, Flask uygulamasını bu şekilde çevresindeki altyapıya dokunmadan v1'den v2'ye ve oradan v3'e taşıdı.

Ekran görüntüleri alırken yaşanan yanlışlıkla yapılan bir rollback ek bir noktayı ortaya koydu: Terraform yön kayıtsızdır. v2'yi dağıttıktan sonra image etiketini v1'e geri çevirmek, eski sürümü hiç itiraz etmeden dağıttı.

Elden geçirmeden çıkan uyarılar

Demo image'ları AMD64 için oluşturulmuştu; yazar, ARM64 image'ların — örneğin Apple Silicon makinelerde yerel olarak oluşturulanların — eşleşen ECS task yapılandırması gerektirdiğini ve ARM64'ü Express Mode altında çalıştırmanın kurulum koşullarına bağlı olarak daha zahmetli olabileceğini belirtiyor. Rehberde ayrıca yalnızca kolaylık olsun diye AdministratorAccess'e sahip bir IAM hesabı kullanıldı; yazar bunun demo ortamı dışında açıkça önerilmediğini vurguluyor.

Neden önemli

Express Mode, TLS sonlandırma, health check'ler, autoscaling ve alarmlar gibi production kalıbındaki varsayılanları — bunların genellikle gerektirdiği uzun Terraform modüllerini sürdürmeden — isteyen ekiplere yönelik görünüyor. Karşılaştırma, seçimin basitçe yeni ile eski arasında olmadığını gösteriyor: geleneksel yol hâlâ daha hızlı ortaya çıkıyor ve her kaynak üzerinde tam kontrol sunarken, Express Mode daha yavaş bir ilk apply karşılığında çok daha küçük bir yapılandırma yüzeyi ve birçok servisi barındırabilen paylaşımlı bir load balancer sağlıyor. Mevcut ECS varlıklarını taşımayı değerlendiren kuruluşlar için bu çalışmanın ortaya çıkardığı pratik sorular şunlar: Express Mode hangi miktarda elle yazılmış ağ ve scaling kodunun yerini alabilir ve ARM64 image'lar gibi uç gereksinimler mevcut kısıtlamalarına uyuyor mu.