Bir üretim şirketi, AWS üzerinde tek bir Amazon EC2 instance'ında monolitik olarak bir rapor oluşturma uygulaması çalıştırmaktadır. Her raporun oluşturulması yaklaşık 20 dakika sürmektedir. Uygulama, sıkıca bağlı modüllere sık sık güncelleme gerektirmekte ve bu da yamalar sırasında kesinti süresine neden olmaktadır. Kesintiye uğradığında, rapor oluşturma baştan başlamaktadır. Şirket, uygulamanın esnek, ölçeklenebilir ve kesinti süresini en aza indirirken kademeli olarak geliştirilebilir olmasını istemektedir. Hangi çözüm bu gereksinimleri karşılar?

Doğru cevap, uygulamayı Amazon Elastic Container Service (Amazon ECS) üzerinde, servis otomatik ölçeklendirme ile mikroservisler olarak çalıştırmaktır. Bu yaklaşım, monolitik uygulamayı daha küçük, bağımsız mikroservislere bölerek esneklik ve kademeli geliştirme sağlar. ECS, bu mikroservisleri yönetir ve servis otomatik ölçeklendirme, talebe göre dinamik olarak ölçeklenmeye olanak tanır. Her bir raporun 20 dakika sürmesi, rapor oluşturma sürecinin birden fazla konteynerde paralel olarak çalıştırılabilmesini ve böylece performansı artırmayı mümkün kılar. Mikroservisler, bir servisin arızalanması durumunda diğerlerini etkilemeyerek kesinti süresini en aza indirir. Diğer seçenekler neden uygun değil: AWS Lambda üzerinde tek bir fonksiyon olarak çalıştırmak, 20 dakikalık rapor oluşturma süresi nedeniyle Lambda'nın varsayılan zaman aşımı limitlerini aşabilir ve karmaşık monolitik bir uygulamayı tek bir fonksiyona dönüştürmek zordur. Amazon EC2 Spot Instances, maliyet etkin olsa da, rapor oluşturma gibi kesintiye uğramaması gereken iş yükleri için uygun değildir çünkü Spot örnekleri AWS tarafından herhangi bir zamanda geri alınabilir. AWS Elastic Beanstalk, dağıtımı basitleştirse de, "all-at-once" dağıtım stratejisi kesinti süresine neden olabilir ve monolitik yapıyı mikroservislere bölme esnekliğini sağlamaz.