Bilgelik için Hacker News kalabalığına bakmamam gerektiğini bilmeliyim. Son zamanlarda HN'de biri ilginç bir soru sordu: âÂÂHiç geçiş yaptınız mı?â HN olarak, yanıtlar neredeyse o kadar ilginç değildi. Aslında, nispeten az sayıda kişi, uygulamalarını özel veri merkezlerinde çalıştırmayı tercih ederek soruya hiç yanıt vermedi. Diğerleri, daha büyük işletmelere değil küçük dükkanlara yönelik tavsiyeler verdi.

Yine de gürültüye rağmen, dizide küçük bir sinyal *vardı*. Belirli bir buluttan en iyi şekilde yararlanmak istiyorsanız, hizmetlerini satın almanız gerekecek ve bu da geçişi zorlaştırıyor. Oh, ve hiper ölçekleyicilerden daha iyi bir bulut oluşturabileceğinizi düşünüyorsanız, asıl noktayı kaçırıyor olabilirsiniz.

== Bana jeneriği göster ==

Şirketler belirli bir bulut üzerinde geliştirmeyi seçtikten sonra, onları harekete geçmeye iten nedir? HN yanıtlarını okurken, "krediler"birincil motivasyon kaynağıdır. Böyle bir bal küpünün daha büyük işletmelere ne kadar hitap ettiği belli değil, ancak belirli bir demografi için geçiş, geçiş yapmaya değecek kadar Google Cloud [veya Azure veya AWS] kredisi ile motive edilebilir. .Ü¢ÂÂ

Ne yazık ki, David Linthicum'un ayrıntılı olarak açıkladığı gibi, bu tür basit bir maliyet/fayda analizi, bulutta çalıştırmanın tüm gizli maliyetlerini gözden kaçırır.

Görünüşe göre GitLab'ın keşfettiği gibi, krediler geçişi teşvik edebilir, ancak bunun için ödeme yapmaları gerekmez. HN yorumunda açıklandığı gibi, âÂÂGitLab'da AWS'den Azure'a, ardından Google Cloud'a geçtik.â Neden ilk etapta AWS'den vazgeçelim? Para bir sorundu, ancak AWS doğası gereği daha pahalı olduğu için değil. Aksine, kurulumla ilgili bir sorundu: âÂÂÇoğu şirket gibi [AWS ile başlarken] maliyetlere, kuruluma vb. çok az dikkat edildi. Sonuç olarak, parayı temelde ateşe veriyorduk. Birlikte, bize bir yıllık fatura değerinden tasarruf ettirecek ücretsiz Azure kredileri için bir teklif geldi ( o zaman biraz para

Kulağa harika geliyor, değil mi? âÂÂTaşınmak oldukça acı vericiydi ve ⦠ücretsiz kredileri *çok* hızlı tükettik.â Daha sonra şirket Google Cloud'a geçmeye karar verdi (açıklanamayan nedenlerle), ve geçişin yine "zorlu bir süreç"olduğunu keşfetti.
Yorum yapan kişi bu deneyimden ne öğrendi? âÂÂGeriye dönüp baktığımda, bir şirket kuracak olsaydım, muhtemelen Hetzner veya başka bir uygun fiyatlı çıplak metal sağlayıcısı gibi bir şeye bağlı kalırdım. Bulut hizmetleri *eğer hizmetlerini mümkün olan en geniş ölçüde kullanırsanız* harikadır, ancak vakaların %90'ında, faydalar buna değmeden çok büyük bir maliyet faktörü haline geldiğinden şüpheleniyorum.¢ÂÂ

Bana göre bu kesinlikle yanlış ders.

== Hala bulutu anlamıyorum ==

Tüm ileti dizisini okursanız, kendin yap bulutunun (Hetzner veya diğer özel sunucu barındırıcılarında) gitmenin yolu olduğuna dair kendinden emin birçok iddia bulacaksınız. (Burada, burada ve burada.) Dedikleri gibi, genel bulut kendi sunucunuzdan çok daha yavaş ve daha pahalıdır. . BT profesyonellerinin bulutu kolayca "buluttan"kurtarabileceği fikri yanlıştır ve konu dışıdır.

Bulut hiçbir zaman gerçekten para biriktirmekle ilgili olmadı. Bu, esnekliği ve üretkenliği en üst düzeye çıkarmakla ilgilidir. Bir HN yorumcunun işaret ettiği gibi, âÂÂÇok küçük bir ekip üzerinde çalışıyorum. Operasyon olarak ikiye katlanan birkaç geliştiricimiz var. Hiçbirimiz sistem yöneticisi değiliz veya olmak istemiyoruz. Bizim durumumuz için, Amazon'un ECS [Elastik Konteyner Hizmeti] zamandan ve paradan büyük bir tasarruf sağlıyor.â Nasıl? Sysadmin işlevlerini kaldırarak ekibin önceden doldurması gerekiyordu. âÂÂEvet, daha önce sahip olduğumuz sorunların çoğu yetkin bir sistem yöneticisi tarafından çözülebilirdi, ancak asıl mesele bu; iyi bir sistem yöneticisini işe almak bizim için çok daha pahalı Amazon'a biraz fazladan ödeme yapmaktan ve onlara âÂÂlütfen bu kapsayıcıları bu yapılandırmayla çalıştırın.â âÂÂ

Bulutu doğru yapıyor.

Diğerleri, sunucusuz seçeneklere geçerek sistem yöneticilerine olan ihtiyacı daha da azalttıklarını öne sürüyor. Evet, belirli bir buluta özgü hizmetleri ne kadar çok araştırırsanız, bir sağlayıcı size ne kadar kredi verirse versin geçiş yapmak o kadar kolay olmaz. Ancak, tartışmaya açık bir şekilde, altyapı tekerleklerini her zaman yeniden icat etmedikleri için geliştiricileriniz önemli ölçüde daha üretkense, geçiş yapma isteğiniz o kadar az olur.
Bir şirket, belirli bir buluta kilitlenmekten açıkça kaçınmaya çalıştı. âÂÂÜrünümüzü 3AWS, Azure, IBM üzerinde devreye alınacak ilk andan itibaren geliştirdik.â Nasıl yani? FaaS/IaaS ([AWS] Lambda, [Amazon] S3, [Amazon] API [Gateway], Kubernetes olan en küçük ortak paydaya bağlı kalarak Kulağa basit geliyor, değil mi? kesinlikle kolay değildi. Çoklu bulut olmak için tek bir bulutta [kalsaydık] bize çok yardımcı olabilecek araçları da göz ardı ettik. âÂÂBelirli paylaşılan özellikler arasında geçiş yapmak mümkündür, ancak kesinlikle birkaç tıklama veya birkaç Jenkins işi uzakta değildir. Arada geçiş yapmak tam zamanlı bir iştir. AWS'de yaptığınız o küçük VM işini nasıl yapacağınızı bulmak , artık Azure'da, zaman ve öğrenme alacak. Ve AWS IAM ile Azure [Active Directory] izni arasında geçiş? Zaman, zaman ve zaman.âÂÂ

Başka bir deyişle, çoklu bulutun üstesinden gelmek kolay değildir ve geçiş de öyle değildir. Bu, ikisinin de nihayetinde buna değmediği anlamına mı geliyor? Şart değil. SADA'nın (önemli bir Google Cloud iş ortağı) CTO'su Miles Ward'ın açıkladığı gibi, başka bir buluta geçmek için zorlayıcı nedenler olabilir. âÂÂPek çok kişi için, işleri halletmek yalnızca kullanım kolaylığı ve verimlilikten ibarettir; diğerleri için dikkat ve ortaklıktır; üçüncü bir grup için saçma maliyet avantajları; ve dördüncüsü, performansı ve güvenilirliğidir. Bu nedenle, "müşteriler bu dört alandan birinde veya birçoğunda boşluklar gördüklerinde hareket ederler".Ü¢ÂÂ

Ward muhtemelen haklı: Göç etmek için zorlayıcı nedenler *olabilir*. âÂÂcloud X'in bana 50.000$ kredi teklif etmesinin çok ötesine geçmesi gereken, taşımanın toplam sahip olma maliyetinin tam bir analizini yaptığınızdan emin olun.â Ayrıca, sizden önce kendi bulutunuzu kurmaya karar verirseniz, tüm kendi altyapınızı yönetmenize ilişkin maliyetleri hesaba katmaya değer.