Cloud-Native Geliştirme
.NET Core · Docker · Kubernetes
Uygulamayı buluta taşımak, onu cloud-native yapmaz.
Cloud-native geliştirme, uygulamanın bulut ortamının davranışına göre tasarlanmasıdır: durum tutmayan (stateless) çalışma, yapılandırmayı ortamdan alma, sağlık kontrolleri, yatay ölçeklenme ve arıza anında kendini toparlama. Bir uygulamayı sanal makineden konteynere almak tek başına bunların hiçbirini getirmez.
Bulut göçlerinin çoğu şu noktada tıkanıyor: uygulama taşınıyor, mimari taşınmıyor. Sonuç, eski sorunların daha pahalı bir faturayla devam etmesi oluyor.
.NET Core, Docker ve Kubernetes ile bunu günlük pratiğe dönüştürüyorum: ölçeklenen, kendini iyileştiren ve maliyeti öngörülebilir uygulamalar. Amaç en yeni teknolojiyi kullanmak değil, sistemin yükü karşılarken ayakta kalması ve faturanın tahmin edilebilir olması.
Her projenin cloud-native olması da gerekmiyor. Trafiği öngörülebilir, tek bölgede çalışan ve ekibi küçük bir uygulamada Kubernetes çoğu zaman çözdüğünden fazla sorun yaratır. Doğru cevap, uygulamanın gerçek yüküne bakmakla başlıyor.
Bulut yolculuğunuza bakalım
Bu çalışma ne zaman gerekli?
Cloud-native'e geçiş bir moda değil, belirli sorunların cevabı. En sık şu üç durumda anlamlı.
Yük dalgalanıyor
Kampanya, sezon ya da gün içi yoğunluk sunucuyu zorluyorsa; sabit kapasite yerine yüke göre ölçeklenen bir kurgu hem dayanıklı hem daha ucuz oluyor.
Sürüm çıkmak kesinti demek
Her yayında sistemin kapanması gerekiyorsa sorun genelde uygulamanın durum tutma ve yapılandırma biçiminde. Kesintisiz geçiş bunu düzeltmeden mümkün olmuyor.
Bulut faturası açıklanamıyor
Fatura beklenenin üzerindeyse sebep çoğu zaman fiyatlandırma değil mimari: boşta duran kapasite, yanlış katmanda tutulan veri ve gereksiz veri transferi.
Neler yapıyorum?
Konteynerleştirme
Docker ile her ortamda aynı davranan, küçük ve güvenli imajlar.
Kubernetes üzerinde çalıştırma
Otomatik ölçeklenme, sağlık kontrolleri ve kesintisiz sürüm geçişi.
Yapılandırma ve gizli bilgi
Ortam değişkenleri ve secret yönetimiyle, koda gömülmeyen yapılandırma.
Gözlemlenebilirlik
Merkezî log, metrik ve izleme — sorunu kullanıcıdan önce siz görürsünüz.
Servis sınırları
Monolit mi, modüler monolit mi, mikroservis mi — sınırları veriye ve ekip yapısına göre çiziyoruz, modaya göre değil.
Maliyet tasarımı
Ölçeklenme kuralları, kaynak limitleri ve veri katmanı seçimiyle faturayı öngörülebilir hale getiriyoruz.
Nasıl ilerliyoruz?
Bulut faturası, mimarinin aynasıdır. Doğru tasarlanmış bir sistem hem daha hızlı hem daha ucuz çalışır.
Uygulamayı hazırlama
Durum (state), yapılandırma ve bağımlılıkları bulut için gözden geçiriyoruz.
Konteynerleştirme
Uygulamayı güvenli ve küçük imajlarla Docker'a taşıyoruz.
Orkestrasyon
Kubernetes üzerinde ölçeklenme, sağlık kontrolü ve sürüm stratejisini kuruyoruz.
Gözlemleme ve iyileştirme
Log, metrik ve maliyet verisiyle sistemi sürekli iyileştiriyoruz.
Geçişte en sık takılınan üç yer
Durum (state) uygulamanın içinde kalıyor. Oturum bilgisi, yüklenen dosya ya da önbellek sunucunun diskinde duruyorsa, ikinci bir kopya açtığınız anda sistem tutarsız davranmaya başlar. Cloud-native'in ilk şartı, uygulamanın hangi kopyasına gidilirse gidilsin aynı cevabı vermesidir; bu yüzden durum dışarı — veritabanına, Redis'e ya da nesne depolamaya — taşınır.
Yapılandırma koda gömülü. Bağlantı dizesi ve API anahtarı derlenmiş dosyanın içindeyse her ortam için ayrı bir sürüm üretmek gerekir. Yapılandırmanın ortamdan okunması, aynı imajın test ve üretimde çalışabilmesi demek — sürüm güvenilirliğinin temeli bu.
Sağlık kontrolü yok. Orkestrasyon katmanı, bir kopyanın gerçekten hizmet verebilir durumda olup olmadığını ancak uygulamanın söylemesiyle bilebilir. Sağlık uçları olmayan bir sistemde Kubernetes trafiği hazır olmayan kopyaya yönlendirir ve arızayı büyütür.
Bu üçü düzeldiğinde ölçeklenme, kesintisiz yayın ve maliyet kontrolü kendiliğinden mümkün hale gelir. Sürüm hattını da aynı anda otomatikleştirmek isterseniz CI/CD ve DevOps tarafına bakabilirsiniz; ekibin bu pratikleri kendi başına sürdürmesi için mentorluk ve ekip eğitimi ayrı bir başlık.
Sık sorulan sorular
Cloud-native ne demek, uygulamayı buluta taşımaktan farkı ne?
Buluta taşımak, uygulamayı olduğu gibi bir bulut sunucusunda çalıştırmaktır; mimari değişmez. Cloud-native ise uygulamanın bulutun davranışına göre tasarlanmasıdır: durum tutmayan çalışma, ortamdan okunan yapılandırma, sağlık kontrolleri ve yatay ölçeklenme. Birincisi altyapıyı, ikincisi uygulamanın kendisini değiştirir.
Kubernetes her projeye gerekli mi?
Hayır. Kubernetes'in getirdiği esneklik, beraberinde işletme yükü de getiriyor. Trafiği öngörülebilir, tek bölgede çalışan ve küçük bir ekibin baktığı uygulamalarda çoğu zaman yönetilen bir konteyner servisi ya da düz bir sunucu daha doğru karar. Kubernetes'i gerçekten çok servisli, dalgalı yüklü sistemlerde öneriyorum.
Mevcut .NET uygulamamız konteynere alınabilir mi?
.NET Framework üzerinde çalışan eski uygulamalarda geçiş önce .NET'in güncel sürümüne taşımayı gerektirebiliyor. .NET Core ve sonrası uygulamalar genelde sorunsuz konteynerleşiyor; asıl iş imajı küçültmek, durum bağımlılıklarını ayıklamak ve sağlık uçlarını eklemek oluyor.
Bulut faturası neden beklenenden yüksek çıkıyor?
En sık üç sebep: boşta duran ama sürekli açık kalan kaynaklar, verinin yanlış katmanda tutulması (sık okunan veriyi soğuk depolamada ya da tersi) ve bölgeler arası veri transferi. Üçü de mimari kararlar; fiyat listesiyle değil tasarımla çözülüyor.
Hangi bulut sağlayıcıyla çalışıyorsunuz?
En çok Azure ile çalışıyorum, ancak kurduğum yapıların büyük bölümü konteyner ve Kubernetes üzerine oturduğu için sağlayıcıdan büyük ölçüde bağımsız kalıyor. Sağlayıcıya özel bir servise bağlanmak gerekiyorsa bunu bilinçli ve yazılı bir karar olarak alıyoruz.
Bu çalışma ne kadar sürer?
Tek bir uygulamanın konteynerleştirilip ölçeklenebilir hale getirilmesi genelde birkaç hafta. Çok servisli bir sistemin bütününde ise iş, servis sınırlarının yeniden çizilmesini de kapsayabildiği için daha uzun sürüyor. Kapsamı ilk görüşmeden sonra birlikte netleştiriyoruz.
Buluta geçişi düşünüyorsanız ya da faturanız beklediğinizden yüksekse
Mevcut mimariye birlikte bakalım; nereden başlanacağını konuşalım. İlk görüşme ücretsiz.
Mimari için ön görüşme talep edinBu mimari kararları projenizin bütününde birlikte almak isterseniz Antalya yazılım danışmanlığı sayfasına bakabilirsiniz.