Her birkaç yılda bir, genelde bir satıcı tarafından, bir işletmeye "buluta geçmesi" gerektiği söylenir. Tek bir karar, apaçık bir cevabı varmış gibi sunulur. İkisi de doğru değil.

Özellikle mühendislik ve kurumsal ekipler için — sistemlerin özelleştiği, verinin ağır olduğu, kesintinin pahalıya mal olduğu yerde — bulut bir varış noktası değildir. Sistem sistem verilen bir dizi karardır. İyi bir bulut stratejisi, çoğunlukla hangi kararın nerede geçerli olduğunu bilmektir.

DZDSoft'ta hem cloud-native geliştirme hem danışmanlık yapıyoruz; yani bize "şunu taşı" kadar sık "onu taşıma" dedirtiyorlar. Nasıl düşündüğümüz aşağıda.

Bulut, tek bir karar değildir

"Buluta göç etmek" en az üç çok farklı seçimi gizler; her birinin maliyeti ve getirisi farklıdır.

Çoğu ekibin hatası bunlardan birini her şeye uygulamaktır. Tüm sistemi lift-and-shift edersin — problemlerini daha pahalı bir adrese taşımış olursun. Her şeyi yeniden kurarsın — zaten çalışan yazılımı yeniden yazmakla iki yıl geçirirsin. Gerçek bir bulut stratejisi her sisteme doğru yaklaşımı atar.

Neyi taşı, neyi tut

Her şey buluta ait değildir; bunu söylemek nostalji değil, mühendisliktir.

Taşımaya iyi adaylar:

• Değişken/sivri yük taşıyan, always-on donanıma para yakan sistemler.
• Coğrafi erişim ya da hızlı ölçekleme gerektiren her şey.
• Managed service'lerin (veritabanı, depolama, kuyruk) gerçek operasyonel maliyeti kaldırdığı workload'lar.

Çoğu zaman on-premise ya da hibrit tutmak daha iyi:

• Veri ikametgahı (data residency) kurallarına bağlı sistemler — KVKK, GDPR ya da sözleşmelerin verinin fiziksel olarak nerede duracağını dikte ettiği yerde.
• Öngörülebilir, sabit workload'lar — sahip olunan donanımın basitçe daha ucuz olduğu.
• Yakında bir yere gitmeyecek legacy ekipmanla derin entegrasyonlar.

Kimsenin bütçelemediği gizli maliyetler

Manşetteki bulut fiyatı nadiren gerçek fiyattır. Ekipleri şaşırtan faturalar, satış sunumunun atladığı parçalardan gelir:

• Egress ücretleri — veriyi dışarı taşımak, bulutların en çok sessizce ücretlendirdiği yerdir.
• Over-provisioning — lift-and-shift genelde aynı büyük sunucuları taşır, artık aylık kiralık.
• Vendor lock-in — ne kadar çok managed service benimsersen, ayrılmak o kadar zor ve pahalı olur.

Bu yüzden maliyet disiplini (kimilerinin FinOps dediği) stratejinin ilk gününden itibaren yer almalı — ilk ürkütücü faturadan sonraki temizlik değil. Infrastructure as code — Terraform ve benzeri — burada da önemli: okuyabildiğin, versiyonlayabildiğin, yeniden kurabildiğin altyapı, maliyetini gerçekten kontrol edebildiğin altyapıdır.

Cloud-native yeniden kurmak ne zaman değer?

Yeniden kurmak en pahalı ve en güçlü seçenektir. Bir sistem işin çekirdeğiyse ve mevcut mimarisi büyümenin ya da maliyetin tavanıysa haklıdır.

Cloud-native — container'lar, orkestrasyon, managed veri servisleri, autoscaling — şu durumlarda yeniden kurma maliyetini çıkarır: yük gerçekten değişkense, ekibin sık ve güvenli değişiklik göndermesi gerekiyorsa ya da büyüdükçe mevcut maliyet eğrisi kötüleşiyorsa. Bunların dışında yeniden kurmak, genelde aynı yere ulaşmanın pahalı bir yoludur.

Bulut stratejine mi ihtiyacın var, yoksa sadece bir migration'a mı?

Bir satıcı sana migration teklif ediyorsa, önce o migration'ın hizmet etmesi gereken stratejin var mı diye sor. Muhtemelen şu durumlarda stratejiye ihtiyacın var:

Biz nasıl yaklaşıyoruz?

Buluta tek bir evet/hayır muamelesi yapmayı reddederek başlıyoruz. İşimiz sistem sistem: hangisi lift-and-shift, hangisi re-platform, hangisi yeniden kurulur ve — önemlisi — hangisi tam olduğu yerde bırakılır. Sonra kurulması gerekeni kurarız, infrastructure as code ile; sonuç kontrol edilebilir olur, bir kara kutu değil.

Diğer işlerimizdeki aynı disiplin burada da geçerli: bulut stratejinde danışmanlık yapan mühendisler, migration'ı da kuracak olanlardır — böylece tavsiye, bir slaytta iyi görünene göre değil, gerçekten ne gerektirdiğine göre şekillenir.