Bulut, DevOps ve veri hizmetleri

Altyapı işinde sıra, sonucu belirler. CI/CD hattı olmayan bir Kubernetes kümesi ya da yedeği hiç sınanmamış bir veritabanı, kurulu olsa bile risk taşır. Çalışma genellikle aşağıdaki sırayla ilerler.

Migrasyon sistemi bir yerden başka bir yere taşımaktır; maliyet optimizasyonu ise taşıdıktan sonra neyin ne kadar kullanıldığını ayarlamaktır. İkisi sık karıştırılır. Taşıma üç yoldan biriyle yapılabilir: sistemi olduğu gibi taşımak, bazı bileşenleri yönetilen bulut hizmetleriyle değiştirmek ya da mimariyi buluta göre yeniden tasarlamak. İlki genellikle en kısa yol, sonuncusu en çok emek isteyen yoldur.

Geçişte kesinti planlanır: veri aktarımı, DNS değişikliği, eski sistemin bir süre yedekte tutulması ve sorun çıkarsa geri dönüş adımı yazılı hâle getirilir. Verinin hangi ülkedeki veri merkezinde tutulacağı da KVKK açısından değerlendirilir.

Bulut faturası çoğu zaman mimari kararların toplamıdır. Fatura çoğu zaman şu kalemlerde şişer: kullanılmayan kaynaklar, gereğinden büyük seçilmiş sunucular, mesai dışında açık kalan test ortamları, depolama sınıfları ve veri çıkış ücretleri. Etiketleme, bütçe uyarıları ve taahhütlü kullanım seçenekleri bu kalemleri görünür ve yönetilebilir kılar. AWS danışmanlığı bu işi AWS'nin hizmet ve fiyatlandırma yapısına göre yürütür; bulut danışmanlığı ise sağlayıcıdan bağımsız karşılaştırma yapar.

Kubernetes güçlü bir platformdur ama bir işletme yüküdür: küme sürümlerini yükseltmek, ağ ve erişim kurallarını yönetmek, kaynakları izlemek sürekli emek ister. Birkaç servisten oluşan ve trafiği öngörülebilir bir uygulama için yönetilen bir uygulama platformu ya da basit bir konteyner kurulumu çoğu zaman daha uygundur.

Çok sayıda servis, değişken yük, birden çok ekibin bağımsız yayın yapması ve standart bir işletim modeli ihtiyacı kümeyi haklı kılar. Kubernetes kurulumunda küme tek başına yeterli değildir; ağ politikaları, gizli bilgi yönetimi, otomatik ölçekleme ve izleme de tasarımın parçasıdır.

Uygulama veritabanı anlık işlem için tasarlanır; ağır raporlar aynı veritabanını yorduğunda hem rapor yavaşlar hem de kullanıcılar etkilenir. Raporlama yükü bir veri ambarına ya da okuma kopyasına ayrıldığında iki taraf da rahatlar.

Veritabanı seçiminde ilişkisel ya da doküman tabanlı yapı, veri hacmi, tutarlılık gereksinimi ve ekibin bilgisi birlikte değerlendirilir. Yavaş çalışan sorgular çoğunlukla yeni bir sunucu almadan önce indeks ve sorgu düzeltmesiyle çözülür; bu yüzden donanım büyütmeden önce ölçüm yapılır.

Yedek, geri yüklenebildiği ölçüde yedektir. Bu yüzden düzenli geri yükleme denemesi yapılır ve iki ölçü baştan konuşulur: ne kadar veri kaybına katlanılabileceği (RPO) ve sistemin ne kadar süre kapalı kalabileceği (RTO). Bu iki yanıt yedekleme sıklığını ve mimarinin maliyetini belirler.

Bulut yönetim konsolunda çok faktörlü doğrulama, her kullanıcıya yalnızca gereken yetki, ortak hesap yerine kişisel hesap ve değişikliklerin kayıt altına alınması temel kurallardır. Kurulum tamamlandıktan sonra güncelleme, izleme ve olay müdahalesi için bakım ve destek modeli ya da DevOps danışmanlığı kullanılabilir.