Sashank Purighalla
katkıda bulunan
Daha düşük vaat donanım maliyetleri, yeni başlayanları hizmetleri buluta taşımaya teşvik etti, ancak birçok ekip bunu verimli veya uygun maliyetli bir şekilde nasıl yapacağından emin değildi. Başlangıçtaki geliştiriciler, her bir bulut sağlayıcıyla bağımsız olarak çalışan birden çok uygulama kodu tabanını sürdürebileceklerini düşündüler.
Artık yönetmenin çok zaman aldığını ve herkes için her şey olmaya çalışmanın zafer olmadığını fark ettiler.
Bulut altyapısının devreye alınması, uygulama izleme ve etkinlik günlüğü gibi analiz araçlarını ve yazılım çözümlerini de içerir ve bu da birçok geliştiricinin analiz felci yaşamasına neden olur. Bu nedenle bulut tekeşliliği, yeni başlayanlar için genel kabul görmüş çalışma ilkesidir. Ancak her şirketin bu sınırlar içinde süresiz olarak faaliyet gösterme lüksü yoktur.
Gerçekçi olmak gerekirse, uygulama olgunluğunu ve çalıştırma maliyetlerini kontrol altında tutmak için bir bulut altyapı sağlayıcısına karar vermeden önce mevcut araçları analiz etmek çok önemlidir.
Ya ihtiyacınız var:
Bunları alana kadar, başlamak için en iyi uygulamalardan bazılarını burada bulabilirsiniz. Yeni başlayanların bulutta karşılaştığı sorunlara, bulut uygulamalarınızın sonucunu nasıl tanımlayacağınıza, bulut altyapınızın ne zaman güncellenmesi gerektiğini nasıl bileceğinize ve bir araç kombinasyonunun nasıl kullanılacağına bir göz atalım.
Bulut altyapısı söz konusu olduğunda, yeni başlayanlar için iki seviye vardır:
Uygulama olgunluğunu ve çalıştırma maliyetlerini kontrol altında tutmak için bir bulut altyapı sağlayıcısına karar vermeden önce mevcut araçları analiz etmeniz çok önemlidir.
Her iki seviyedeki kurucular ve karar vericiler, bulut bilişimi yönetmek için gereken derin teknik uzmanlıkla mücadele ediyor. Örneğin, çözümünü AWS’de oluşturmuş olan orta ölçekli bir girişim bana ulaştı, ancak tek odak noktası her şeyi çalışır duruma getirmekti (seviye 1). Bu nedenle, birikmiş teknik borçları vardı ve yüzlerce sunucu, birkaç düzine benzersiz hizmet, üçüncü taraf araçları, kısmi günlük kaydı ve kötü uygulanmış hizmet ağıyla bulut mimarisi karmaşıktı.
Daha sonra bu şirket, tüm bulut çözümünün Azure’ın bir alt kümesi olan Azure-China’da (seviye 2) bulunmasında ısrar eden Çin merkezli yeni bir müşteriyle sözleşme imzaladı. Şirketin bu yeni ortamda hiçbir fikri yoktu.
Farklı bulut sağlayıcıları üzerinde eşitliğe sahip paralel çözümler oluşturmak maliyetli olabilir ve çok fazla çaba gerektirebilir. Ancak bu şirket için alternatif, önemli bir sözleşmeyi kaybetmekti. Başka seçenekleri yoktu.
Kodu çoğaltmak ve iki farklı ortamda çalışacak şekilde yeniden ayarlamak için şirketin geliştiricileri, ilgili tüm uygulamaları, hizmetleri ve hususları öğrenmeye çalışırken daha fazla analiz felciyle karşı karşıya kalabilirdi. Bu nedenle startup’lar, ilgili test ve güvenlik doğrulamalarını gerçekleştirirken buluttan bağımsız mimari oluşturmak, kod yazmak ve hedef bulutlarına dağıtımları otomatikleştirmek için platformlara ihtiyaç duyar.
Birçok girişim, bulut altyapısı için bir “oluştur ve düzelt” modelini izler. Bunun nedeni, başlangıç geliştiricilerinin gördükleri ilk aracı seçmeleri ve ardından şirketin bağlı kalmasıdır (lisanslar veya sıkı bağlantı nedeniyle). Veya diğer bulut katmanlarıyla nasıl etkileşime girdiği açısından optimal olmayabilecek birinin tavsiyesini alırlar. Ardından, uygun analizlerin ve mevcut araçların denenmesinin olmaması, garip değiş tokuşlara ve istenmeyen iş blokajlarına yol açar.
genel-24