Bulut Platformları: Public, Private ve Hibrit Bulut

Karar iş yükü bazında veriliyor, kurum bazında değil. "Biz buluta geçiyoruz" cümlesi tek başına bir karar değil, bir niyet.

Üç özelliğe bakılıyor. Talep değişkenliği: yükünüz gün içinde ya da mevsimsel olarak kat kat değişiyorsa public cloud'un esnekliği doğrudan para kazandırıyor; sabit bir yükte aynı esneklik için prim ödemiş oluyorsunuz. Veri hassasiyeti: verinin hangi ülkede ve hangi tesiste duracağı düzenlenmişse, seçim orada başlıyor ve maliyet ikinci sıraya düşüyor. Gecikme toleransı: şirket içindeki bir sisteme sıkı bağlı bir uygulama, buluta taşındığında her çağrıda ağ gecikmesi ödüyor.

Pratikte çoğu kurumda sonuç hibrit oluyor, ama bilinçli bir hibrit ile "yarısını taşıdık, kalanı öyle kaldı" arasında büyük fark var. Birincisinde her iş yükünün nerede durduğunun bir gerekçesi vardır ve o gerekçe yazılıdır.

Genelde evet, ve bunu peşinen bilmek doğru karar vermeyi kolaylaştırıyor.

Üç kalemde artıyor. Veri çıkış ücretleri: sağlayıcılar veriyi içeri almayı ucuz, dışarı çıkarmayı pahalı tutuyor; iki bulut arasında sürekli veri akıyorsa bu kalem birikiyor. İki ayrı uzmanlık: her sağlayıcının kendi kimlik modeli, ağ mimarisi ve hizmet adları var; ekibin ikisini birden derinlemesine bilmesi gerekiyor. İki ayrı işletim seti: izleme, yedekleme, maliyet raporlaması ve güvenlik politikaları iki kez kuruluyor.

Buna karşılık multi-cloud'un iki meşru gerekçesi var: tedarikçi bağımlılığını azaltmak (özellikle pazarlık gücü açısından) ve düzenleyicinin ikinci bir sağlayıcı istemesi.

Yanlış gerekçe "daha ucuz olur" beklentisi. Mevcut dağılımınızın gerçek maliyetini ölçüp gösteriyoruz; karar o sayıdan sonra veriliyor.

Neredeyse her zaman aynı üç sebep, ve üçü de ölçülebilir.

Kapatılmamış kaynaklar. Test için açılan bir ortam işi bitince kapatılmıyor. Bunu bulan şey etiketleme disiplini: her kaynağın sahibi, ortamı ve son kullanma tarihi etiketlenmişse, sahipsiz ve süresi geçmiş kaynaklar bir raporda çıkıyor.

Fazla boyutlandırma. Örnek boyutu genellikle en kötü senaryoya göre seçiliyor ve bir daha gözden geçirilmiyor. Gerçek kullanım ölçüldüğünde CPU'nun %10'unu kullanan makineler çıkıyor.

Unutulan diskler ve snapshot'lar. Sanal makine silindiğinde diski silinmiyor. Snapshot'lar birikiyor. Bunlar faturada tek tek küçük, toplamda büyük kalemler.

İlk adım envanter ve etiketleme. Ne olduğunu bilmeden kesmek riskli: sahibi bilinmeyen bir kaynağı kimse güvenle kapatamaz. Envanter kurulduktan sonra ilk üç ayda genellikle anlamlı bir düşüş çıkıyor.

Analizi ve takibi biz yapıyoruz; satın alma kararı sizde kalıyor.

Rezervasyon, belirli bir kapasiteyi bir ya da üç yıllığına taahhüt edip ciddi bir indirim almak demek. Kazancı büyük ama taahhüt geri alınamıyor; yanlış hesaplanmış bir rezervasyon, kullanılmayan kapasite için üç yıl ödemek anlamına geliyor.

Bu yüzden analiz kullanım geçmişine dayanıyor: hangi iş yükü gerçekten sürekli çalışıyor, hangisi mevsimsel, hangisi önümüzdeki yıl kapanacak. Yalnızca birinci gruba taahhüt öneriliyor.

Takip de işin parçası: taahhütlerin bitiş tarihleri izleniyor. Sessizce sona eren bir rezervasyon, faturanın bir ay içinde beklenmedik biçimde sıçraması demek; ve bu, kimsenin bakmadığı durumlarda gerçekten oluyor.

Evet, ve devralma her zaman bir envanter çalışmasıyla başlıyor.

İlk soru "hangi hesaplar var"; ve cevabı çoğu kurumda beklenenden uzun oluyor: bir proje için açılmış, sonra unutulmuş hesaplar, bir çalışanın kişisel kartıyla açtığı abonelikler, satın alınan bir şirketten devralınan ortamlar.

İkinci soru "kimde yetki var". Ayrılmış çalışanların hâlâ açık erişimi, paylaşılan yönetici hesapları ve süresi dolmayan anahtarlar burada çıkıyor.

Üçüncü soru "hangi kaynak neye hizmet ediyor". Bu çıkarılmadan işletim devri yapılmıyor: sahibi bilinmeyen bir kaynağı kimse güvenle kapatamaz, ve kapatılamayan kaynak sonsuza kadar faturada kalıyor.

Envanter çıktıktan sonra devir kademeli oluyor: önce izleme ve raporlama, sonra rutin işlemler, en son değişiklik yetkisi.

Hayır, ve bunu söyleyen bir sağlayıcıya temkinli yaklaşmak doğru olur.

Buluta taşınmanın karşılığını vermediği iş yükleri var. Sabit, öngörülebilir ve yüksek kaynak tüketen yükler (büyük veritabanları, sürekli çalışan hesaplama işleri) kendi donanımınızda çoğu zaman daha ucuza dönüyor. Amortismanı bitmiş bir donanımın maliyeti neredeyse yalnızca enerji ve bakımken, aynı kapasite bulutta her ay tam fiyat ödetiyor.

İkinci durum: şirket içindeki bir sisteme sıkı bağlı uygulamalar. Uygulama bulutta, veritabanı içeride kalırsa her sorgu ağ üzerinden gidiyor ve performans düşüyor.

Üçüncüsü: değişmeyecek eski uygulamalar. Buluta taşımak onları modernleştirmiyor, yalnızca başka birinin donanımında çalıştırıyor.

Doğru soru "buluta geçelim mi" değil, "hangi iş yükü nereye ait".

Seçim oradan başlıyor ve diğer bütün kararlar ona göre şekilleniyor.

Önce gereksinimin tam olarak ne olduğu netleştiriliyor, çünkü "veri Türkiye'de kalsın" cümlesi tek başına yeterli değil. Üretim verisi mi, yedekler de mi? Günlük kayıtları ve izleme verisi dahil mi? Destek sırasında bir mühendisin ekranında verinin görünmesi aktarım sayılıyor mu?

Bu sorular cevaplandıktan sonra seçenekler daralıyor: yurt içinde bölgesi olan bir public cloud sağlayıcısı, yurt içi bir özel bulut, ya da ikisinin birleşimi.

Yapılandırmanın kendisi de kilitleniyor: bölge kısıtı politika olarak tanımlanıyor, böylece yanlış bölgede kaynak açılması engelleniyor. Bu kilit olmadan, doğru kurulmuş bir ortam altı ay sonra birinin aceleyle açtığı bir kaynakla bozulabiliyor.

Bir kısmı öyle, ve hangi kısmın olduğunu bilmemek en yaygın güvenlik açığının kaynağı.

Sağlayıcılar bunu "paylaşılan sorumluluk modeli" diye tanımlıyor. Sağlayıcı fiziksel güvenlikten, hypervisor'dan ve altyapı katmanından sorumlu. Siz işletim sisteminden, uygulamadan, kimlik ve erişim yönetiminden, ağ yapılandırmasından ve verinin kendisinden sorumlusunuz.

Pratikte ihlallerin büyük çoğunluğu sağlayıcının katmanında değil, müşterinin katmanında oluşuyor: herkese açık bırakılmış bir depolama kovası, çok geniş yetki verilmiş bir rol, yamalanmamış bir sunucu, koda gömülü bir anahtar.

Yani "bulutta olduğu için güvenli" doğru değil. Doğru olan şu: bulut, güvenliği sağlamak için gereken araçları sunuyor, ama açık kurulmuş bir kapıyı sizin yerinize kapatmıyor.

Planlanabilir bir kesinti oluyor; sürpriz bir kesinti olmaması hedefleniyor.

Taşıma yöntemine göre değişiyor. Sürekli çoğaltmayla yapılan taşımada veri arka planda aylarca senkronlanıyor ve son geçiş dakikalar sürüyor; genelde bir hafta sonu penceresinde. Tek seferlik kopyalamayla yapılan taşımada kesinti verinin boyutuna bağlı ve saatler sürebiliyor.

Kesintiyi belirleyen asıl şey veri değil bağımlılıklar: uygulama taşındığında hangi sistemlere bağlanacağı, DNS'in ne zaman değişeceği, geri dönüş planının ne olduğu. Bunlar önceden yazılmadığında "iki saatlik pencere" gece yarısına kadar uzuyor.

Her taşımanın bir geri dönüş noktası oluyor: belirlenen saate kadar doğrulama tamamlanmazsa eski ortama dönülüyor. Bu kararın eşiği önceden yazılıyor, o gece tartışılmıyor.