Serverless, Mikroservis ve DevOps: Modern Bulut Mimarisi

Yazılım geliştiren ya da kendi iş uygulamalarını işleten şirketler için bulut, yalnızca sunucuların taşındığı bir yer değildir. Serverless, mikroservis, konteyner ve DevOps gibi kavramlar uygulamaların nasıl tasarlandığını, nasıl yayına alındığını ve nasıl işletildiğini kökten değiştirir. Ancak bu kavramlar çoğu zaman moda terimler olarak, her soruna çözüm gibi sunulur. Bu yazıda modern bulut mimarisinin temel yapı taşlarını, hangi durumda gerçekten fayda sağladıklarını ve hangi durumda gereksiz karmaşıklık yarattıklarını pratik bir bakışla ele alıyoruz.

Monolitten Mikroservise: Ne Zaman Gerekli?

Monolitik mimaride uygulamanın tüm işlevleri tek bir kod tabanında geliştirilir, tek parça olarak derlenir ve yayına alınır. Mikroservis mimarisinde ise uygulama sipariş, stok, faturalama veya bildirim gibi iş yeteneklerine göre bağımsız servislere ayrılır. Her servis kendi verisini yönetir, diğerleriyle çoğunlukla REST API'ler veya mesaj kuyrukları üzerinden haberleşir ve ayrı ayrı yayına alınabilir.

Mikroservisin vaat ettiği avantajlar gerçektir: Ekipler birbirini beklemeden çalışabilir, yoğun yük alan bir bölüm tek başına ölçeklenebilir, bir servisteki hata tüm sistemi durdurmaz. Ancak bu avantajların bir bedeli vardır. Dağıtık bir sistemde ağ gecikmesi, servisler arası veri tutarlılığı, sürüm uyumluluğu, hata ayıklama ve izleme çok daha zordur.

Mikroservise geçişi haklı çıkaran işaretler şunlardır:

• Birden fazla ekip aynı kod tabanında çalışıyor ve yayınlar sürekli birbirini bekliyor.
• Uygulamanın belirli bir bölümü diğerlerinden çok daha fazla yük alıyor ve ayrı ölçeklenmesi gerekiyor.
• Küçük bir değişiklik bile tüm uygulamanın yeniden test edilmesini ve yayına alınmasını gerektiriyor.
• Farklı bölümlerin farklı teknoloji, performans veya güvenlik gereksinimleri var.

Küçük bir ekip tarafından geliştirilen, yükü öngörülebilir bir iş uygulaması için ise iyi tasarlanmış bir modüler monolit çoğu zaman daha doğru tercihtir. Kod içinde net sınırlarla ayrılmış modüller, ileride gerekirse servislere bölünmeyi de kolaylaştırır.

Serverless (Sunucusuz) Mimari Nasıl Çalışır?

Sunucusuz mimaride sunucular ortadan kalkmaz; yalnızca yönetimleri tamamen bulut sağlayıcısına geçer. Geliştirici belirli bir olaya yanıt veren küçük işlevler yazar; sağlayıcı bu işlevi olay gerçekleştiğinde çalıştırır, yüke göre otomatik ölçekler ve çalışmadığı sürede işlem kaynağı ayırmaz. AWS Lambda, Azure Functions ve Google Cloud Functions bu modelin en bilinen örnekleridir.

Bir işlevi tetikleyen olaylar çok çeşitlidir: bir HTTP isteği, depolama alanına yüklenen bir dosya, kuyruğa düşen bir mesaj, veritabanında değişen bir kayıt veya zamanlanmış bir görev. Ücretlendirme genellikle çağrı sayısı ve çalışma süresi üzerinden yapılır; işlev çalışmadığında işlem ücreti oluşmaz.

Sunucusuz yaklaşım yalnızca işlevlerden ibaret değildir. Yönetilen veritabanları, mesaj kuyrukları, API ağ geçitleri ve kimlik hizmetleri gibi bileşenler de sunucu yönetimi gerektirmeden kullanılabilir. Bu bileşenler bir araya geldiğinde, ayrı bir altyapı ekibi olmayan küçük bir yazılım ekibi bile ölçeklenebilir bir uygulama işletebilir.

Dikkat edilmesi gereken teknik sınırlamalar da vardır:

• Soğuk başlangıç (cold start): Bir süredir çağrılmayan işlev ilk istekte gecikmeli yanıt verebilir. Gecikmeye duyarlı uygulamalarda bu durum için önlem alınmalıdır.
• Çalışma süresi sınırları: İşlevlerin tek seferde çalışabileceği süre sınırlıdır; uzun süren işlemler parçalara bölünmeli veya farklı bir hizmette çalıştırılmalıdır.
• Durumsuz yapı: İşlevler çağrılar arasında durum tutmaz; oturum ve iş verisi harici bir depoda saklanmalıdır.
• Sağlayıcıya bağımlılık: Tetikleyiciler ve entegrasyonlar sağlayıcıya özgü olduğundan taşınabilirlik azalır.

Konteyner ve Kubernetes'in Yeri

Konteynerler, uygulamayı tüm bağımlılıklarıyla birlikte paketleyerek geliştiricinin bilgisayarında, test ortamında ve üretimde aynı şekilde çalışmasını sağlar. Docker bu alanda standart haline gelmiş araçtır. Konteynerleri, serverless ile sanal makine arasında bir orta nokta olarak düşünebilirsiniz: Altyapı ayrıntılarını soyutlar, ancak çalışma ortamı üzerinde daha fazla kontrol bırakır.

Çok sayıda konteynerin birden fazla sunucu üzerinde çalıştırılması, ölçeklenmesi, güncellenmesi ve arıza durumunda yeniden başlatılması için bir orkestrasyon katmanı gerekir. Kubernetes bu alanın fiili standardıdır; Azure Kubernetes Service, Amazon EKS ve Google Kubernetes Engine gibi yönetilen hizmetler kontrol düzleminin yönetimini sağlayıcıya bırakır.

Kubernetes güçlü ama karmaşık bir platformdur. Ağ, depolama, güvenlik politikaları, sürüm yükseltmeleri ve izleme konularında gerçek bir uzmanlık gerektirir. Az sayıda servisi olan bir uygulama için Azure Container Apps, AWS Fargate veya Google Cloud Run gibi daha basit yönetilen konteyner hizmetleri, Kubernetes'in operasyon yükü olmadan konteyner avantajlarını sunar.

DevOps ve CI/CD ile Hızlı ve Güvenli Yayın

Mimari ne olursa olsun, modern bulut uygulamalarının asıl faydası yazılımın hızlı, sık ve güvenli biçimde yayına alınabilmesinden gelir. DevOps, geliştirme ve operasyon ekiplerinin ortak hedefler, ortak araçlar ve otomasyonla birlikte çalıştığı bir yaklaşımdır. Bir araç satın alarak değil, çalışma biçimini değiştirerek uygulanır. Bir DevOps altyapısının temel bileşenleri şunlardır:

1. Sürüm kontrolü: Uygulama kodunun yanında altyapı tanımlarının ve yapılandırmaların da Git gibi bir sürüm kontrol sisteminde tutulması.
2. Sürekli entegrasyon (CI): Her kod değişikliğinde otomatik derleme, birim testleri, kod kalitesi ve güvenlik taramalarının çalışması.
3. Sürekli teslimat (CD): Testleri geçen sürümün otomatik olarak test ortamına, onay sonrasında da üretime aktarılması. GitHub Actions, Azure DevOps Pipelines ve GitLab CI ile bulut sağlayıcılarının kendi hizmetleri olan AWS CodePipeline ve Google Cloud Build yaygın kullanılan araçlardır.
4. Kod olarak altyapı (IaC): Sunucuların, ağların ve hizmetlerin Terraform, Bicep veya CloudFormation gibi araçlarla kod olarak tanımlanması. Böylece ortamlar tekrarlanabilir, denetlenebilir ve hızla yeniden kurulabilir hale gelir.
5. Güvenli yayın stratejileri: Yeni sürümü önce kullanıcıların küçük bir kısmına açmak (canary), iki ortam arasında geçiş yapmak (blue-green) ve sorun halinde hızla geri dönebilmek.
6. Gözlemlenebilirlik: Log, metrik ve dağıtık izleme (tracing) verilerinin merkezi olarak toplanması. Mikroservis ortamında bir isteğin hangi servislerden geçtiğini görmeden hata ayıklamak son derece zordur; izleme yaklaşımını ağ ve uygulama izleme yazımızda ayrıntılandırdık.

Güvenlik bu zincirin sonunda değil, her halkasında yer almalıdır. Bağımlılık taramaları, konteyner imajı taramaları, gizli bilgi (secret) tespiti ve altyapı kodunun güvenlik kontrolleri CI hattına eklendiğinde açıklar üretime ulaşmadan yakalanır. Bu yaklaşım DevSecOps olarak adlandırılır.

DevOps olgunluğunu izlemek için yaygın kullanılan dört gösterge vardır: yayın sıklığı, bir değişikliğin koddan üretime ulaşma süresi, yayınların hataya yol açma oranı ve bir kesintiden sonra hizmetin yeniden ayağa kalkma süresi. Bu göstergeleri düzenli takip etmek, iyileştirmenin nerede gerektiğini gösterir.

Kullanım Senaryoları ve Uygun Olmayan Durumlar

Modern bulut mimarisinin en iyi sonuç verdiği senaryolar şunlardır:

• Olay tabanlı arka plan işleri: Yüklenen belgelerin işlenmesi, görsellerin boyutlandırılması, fatura veya rapor üretimi, e-posta ve bildirim gönderimi.
• Entegrasyonlar: ERP, e-ticaret, kargo ve ödeme sistemleri arasında veri aktaran küçük servisler.
• Değişken trafikli API'ler: Mobil uygulama arka uçları, kampanya dönemlerinde yükü aniden artan e-ticaret servisleri.
• Zamanlanmış görevler: Gece çalışan veri aktarımları, temizlik ve raporlama işleri.
• IoT ve veri akışları: Sahadaki cihazlardan gelen verilerin toplanması ve ön işlenmesi.
• Sektöre özgü modüller: Sanayi ve imalat işletmelerinde üretim hattı verisini ERP'ye aktaran servisler, sağlık kuruluşlarında randevu ve hasta kayıt işlevlerinin bağımsız modüllere ayrılması, lojistik firmalarında sevkiyat durumu bildirimleri.

Uygun olmayan veya dikkat gerektiren durumlar ise şunlardır:

• Sürekli yoğun yük altında çalışan ve düşük gecikme gerektiren sistemler. Burada sabit kapasiteli konteyner veya sanal makineler daha öngörülebilir ve ekonomik olabilir.
• Uzun süreli ve durum tutan işlemler.
• Kararlı çalışan ve seyrek değişen bir iş uygulamasını yalnızca modern görünsün diye yeniden yazmak.
• Ekipte dağıtık sistem, konteyner ve otomasyon yetkinliğinin bulunmaması.

Maliyet ve Operasyon Etkileri

Serverless modelde düşük ve değişken trafikte maliyet oldukça avantajlıdır, çünkü kullanılmayan kapasite için ödeme yapılmaz. Ancak trafik sürekli yüksek olduğunda çağrı başına ücretlendirme, sabit kapasiteli bir konteyner veya sanal makineden daha pahalıya gelebilir. Hatalı bir döngüde kendini tekrar tekrar tetikleyen bir işlev ise kısa sürede beklenmedik bir fatura oluşturabilir. Bu nedenle bütçe alarmları, çağrı sınırları ve eşzamanlılık kısıtları baştan tanımlanmalıdır. Konunun genel çerçevesini bulut maliyet optimizasyonu yazımızda ele aldık.

Operasyon tarafında ise iş yükü kaybolmaz, yalnızca biçim değiştirir. İşletim sistemi yaması ve sunucu bakımı azalır; buna karşılık servis sayısının artmasıyla izleme, sürüm yönetimi, kimlik ve erişim yetkileri, ağ politikaları ve maliyet takibi daha fazla önem kazanır. Toplam sahip olma maliyetini hesaplarken yalnızca bulut faturasını değil, ekip yetkinliği, eğitim, araç lisansları ve operasyon zamanını da hesaba katın.

Geçiş Adımları ve Sık Yapılan Hatalar

Mevcut bir uygulamayı modern mimariye taşırken her şeyi baştan yazmak yerine kademeli ilerlemek riskleri azaltır. Önerdiğimiz sıralama şöyledir:

1. Mevcut durumu çıkarın: Uygulamanın bileşenlerini, bağımlılıklarını, veri akışlarını ve yük profilini belgeleyin.
2. Önce otomasyonu kurun: Mimariye dokunmadan önce sürüm kontrolü, CI/CD ve kod olarak altyapıyı devreye alın. Bu adım tek başına bile yayın hızını ve güvenilirliği belirgin biçimde artırır.
3. Konteynerleştirin: Uygulamayı mevcut haliyle konteynere alarak ortamlar arasındaki farkları ortadan kaldırın.
4. Kenarlardan başlayın: Raporlama, bildirim veya dosya işleme gibi görece bağımsız işlevleri ayrı servislere veya sunucusuz işlevlere taşıyın. Eski sistemi adım adım daraltan bu yaklaşım strangler fig deseni olarak bilinir.
5. Gözlemlenebilirliği büyütün: Her yeni servisle birlikte log, metrik ve izleme altyapısını genişletin.
6. Ölçün ve karar verin: Her adımın maliyet, performans ve yayın hızı üzerindeki etkisini değerlendirerek bir sonraki adıma geçin.

Sık yapılan hatalar ise şunlardır:

• Gerçek bir ihtiyaç olmadan mikroservise geçip dağıtık bir monolit, yani ayrı çalışan ama birbirine sıkı bağlı servisler oluşturmak.
• Tüm servislerin aynı veritabanını paylaşması.
• Sunucusuz işlevleri çok sayıda işi üstlenen tek bir büyük işlev olarak yazmak ya da işlevleri birbirini zincirleme ve doğrudan çağıracak şekilde sıkı bağlamak. İşlevler küçük, tek amaçlı ve kuyruklar üzerinden gevşek bağlı olmalıdır.
• İzleme ve log altyapısını sonraya bırakmak.
• Konteyner imajlarını ve bağımlılıkları güvenlik taramasından geçirmemek.
• Gizli bilgileri kod içinde veya düz metin yapılandırma dosyalarında tutmak.
• Ekip eğitimini ve süreç değişimini ihmal edip yalnızca araçlara yatırım yapmak.

Geçişin genel planlama çerçevesi için buluta geçiş rehberimize de göz atabilirsiniz.

Sonuç

Serverless, mikroservis, konteyner ve DevOps birbirinin alternatifi değil, doğru yerde birlikte kullanıldığında güçlenen yapı taşlarıdır. Başarının anahtarı mimariyi trendlere göre değil, iş gereksinimine, yük profiline ve ekibinizin yetkinliğine göre seçmektir. Ümraniye Bilişim'in bulut çözümleri ekibi, mevcut uygulamanızı değerlendirip size uygun hedef mimariyi ve kademeli geçiş planını birlikte oluşturabilir. Uygulamanızı birlikte ele almak için ücretsiz ön görüşme talep edebilirsiniz.