Bugüne kadar gördüğüm her bulut geçiş sunumu aynı slaytla açılır: "6 R"nin derli toplu bir tablosu ve ekibin her iş yükü için doğru olanı seçeceğine dair bir söz. Altı ay sonra aynı ekip her şeyi yeniden barındırmış, buna dönüşüm adını vermiş ve sessizce on-prem döneminde ödediğinden daha fazlasını ödüyordur. Çerçeve yanlış değildi. Yanlış olan, karar alma biçimiydi.
Yeniden barındırma, yeniden platformlama, yeniden inşa; bunlar bir kez sipariş verdiğiniz bir menü değildir. Her biri farklı bir geri ödeme eğrisine sahip birer bahistir. Asıl hata, aslında zaman, para ve iş tarafının bunu fark etmesini ne kadar bekleyebileceğinizle ilgili olan bu seçimi teknik bir mesele gibi ele almaktır.
Pazarlama söylemi olmadan üç yol
Tedarikçi cilasını kazıyıp attığınızda farklar apaçık ortaya çıkar.
- Yeniden barındırma (lift-and-shift): İş yükünü olduğu gibi bulut altyapısına taşırsınız. Sanal makineler yine sanal makine olarak kalır. Hızlı, düşük riskli ve uygulamanın çalışma biçiminde neredeyse hiçbir şeyi değiştirmez; sizi zaten zorlayan kısımlar dahil. Bulut faydaları değil, bulut faturası ve bir dizi yeni sorun elde edersiniz.
- Yeniden platformlama (lift-tinker-shift): Çekirdek mimariyi korur, ancak bulutta sizi cezalandıran parçaları değiştirirsiniz. Kendi yönettiğiniz bir veritabanını yönetilen bir hizmete taşıyın. Uygulamayı konteynerleştirin. Statik varlıkları nesne depolamaya aktarın. Mütevazı çaba, gerçek operasyonel kazanımlar.
- Yeniden inşa (refactor): İş yükünü bulutun gerçekte nasıl çalıştığına göre yeniden mimarleştirirsiniz; monoliti parçalarına ayırın, olay güdümlü (event-driven) mimariye geçin, yönetilen ve sunucusuz (serverless) bileşenleri benimseyin. En yüksek maliyet, en yüksek risk ve insanların bulut için ödeme yaptığı esnekliği açığa çıkaran tek yol.
Yeniden barındırma size zaman kazandırır. Yeniden inşa ise yetenek kazandırır. İkisini birbirine karıştırmak, geçiş bütçelerinin tükenme biçimidir.
"Her şeyi yeniden barındırmak" neden güvenli hissettirir ama çoğu zaman değildir
Lift-and-shift caziptir çünkü ölçülebilirdir. Ona bir tarih koyabilirsiniz, risk sınırlıdır ve kimsenin kod yeniden yazması gerekmez. Kesin bir kira bitiş tarihi olan bir veri merkezinden çıkış için çoğu zaman doğru açılış hamlesidir; önce binadan çıkın, sonra optimize edin.
Tuzak şu ki "sonra" hiçbir zaman takvime girmez. Her zaman açık bir VM üzerinde yeniden barındırılmış bir uygulama, bulutun meşhur olduğu maliyet kontrollerinin hiçbirine sahip değildir. Sabit bir kutuyu tümüyle sahiplenmek yerine saatlik kiralıyorsunuz ve verdiğim danışmanlıklarda yeniden barındırılmış iş yüklerinin ilk yılda düzenli olarak on-prem işletme maliyetlerinin %20-40 üzerine çıktığını gördüm. Bulut başarısız olmadı. Kimse hiçbir şeyi yeniden mimarleştirmedi, dolayısıyla hiçbir şey ucuzlamadı; sadece sayaç işlemeye başladı.
Ya bir amaçla yeniden barındırın ya da hiç yapmayın. Eğer bu bir köprüyse, ikinci adımı adlandırın ve onu bir sahibiyle birlikte yol haritasına koyun. İkinci bir adım yoksa, eski veri merkezinizin daha pahalı bir versiyonunu satın almışsınız demektir.
Pazartesi uygulayabileceğiniz bir karar testi
Kırk ağırlıklı sütunlu puanlama matrisini bir kenara bırakın. Önemli her iş yükü için dört soru sorun ve yanıtların sizi bir yola doğru yönlendirmesine izin verin.
1. Son teslim tarihi nedir ve gerçek mi?
Kesin bir çıkış tarihi (kira bitişi, veri merkezinin kapanması, lisansın sona ermesi) sizi güçlü bir şekilde yeniden barındırmaya iter. Sahip olmadığınız zaman, var olan en dürüst kısıttır.
2. Bu iş yükü rekabet avantajı mı yoksa altyapı tesisatı mı?
Sizi farklılaştıran şey; yani müşterilerin gerçekte parasını ödediği şey, mevcut mimari büyümesini sınırladığında yeniden inşayı hak eder. Sıradan, iç kullanıma yönelik araçlar ise neredeyse hiçbir zaman hak etmez. Masraf onay uygulamanızı yeniden inşa etmeyin; kimse bunun için size madalya verecek değildi.
3. Somut sıkıntı nedir ve nerede yaşanıyor?
Uygulama iyi durumdaysa ama kendi yönettiğiniz veritabanı hafta sonlarınızı yiyip bitiriyorsa, bu bir yeniden platformlamadır; baştan yazma değil, hedefe yönelik bir ameliyat. Çözümün büyüklüğünü sorunun büyüklüğüyle eşleştirin.
4. Ekip önerdiğiniz şeyi işletebilir mi?
Dağıtık sistemleri hiç işletmemiş bir ekibe teslim edilen sunucusuz bir yeniden inşa, bir geçiş değil, gelecekteki bir olaydır. Yetkinlik gerçek bir girdidir, bir bahane değil. Beceriler mevcut değilse, ya önce onları geliştirin ya da ekibin gerçekten işletebileceği bir yol seçin.
Sıralama stratejiyi yener
Parçası olduğum en iyi geçişler, en derli toplu çerçeveye sahip olanlar değildi. En akıllıca sıralamaya sahip olanlardı. Çıkışınızı engelleyen iş yüklerini yeniden barındırın. Operasyonel olarak sizi kanatan iki üç sistemi yeniden platformlayın. İşi gerçekten geri tutan tek şeyi yeniden inşa edin; hem de yalnızca o tek şeyi, bitene kadar.
Yolları harmanlamak kararsızlık değildir; portföy düşüncesidir. Farklı iş yüklerinin farklı ekonomileri vardır, dolayısıyla farklı muameleyi hak ederler. Zorlananlar; tek bir R'yi seçip her şeye uygulayan, ardından altyapı tesisatını yeniden inşa etmenin taç mücevherleri kadar pahalıya mal olmasına şaşırmış gibi davranan ekiplerdir.
Nereden başlamalı
Maliyete ve iş açısından kritikliğe göre ilk on iş yükünüzü çıkarın. Her biri için son teslim tarihini, sıkıntıyı ve ekibin hedef durumu işletip işletemeyeceğini yazın. Çoğunun bir öğleden sonrada kendiliğinden yeniden barındırma ya da yeniden platformlamaya ayrıldığını göreceksiniz; bir ya da ikisi ise gerçekten yeniden inşayı hak eder. Stratejiniz, çerçeve değil, işte o kısa listedir.
Tek bir iş yükünü bile taşımadan önce daha zor soruyu sorun: Bu geçişin neyi daha ucuz, daha hızlı ya da daha dayanıklı hale getirmesi gerekiyor ve seçtiğiniz yol bunu gerçekten sağlar mı?