Pek çok şirket, AWS, Azure & Co.’ya genellikle çok fazla para ödediklerinin farkına çok geç varıyor. Bunun neden böyle olduğunu iX yazarı Martin Loschwitz ile konuştuk. Ayrıca çıkışınızı en baştan nasıl en iyi şekilde planlayabileceğinizi ve hiper ölçekleyiciye sonsuza kadar takılıp kalmayacağınızı da açıklıyor.
Duyuru
Martin Gerhard Loschwitz, OpenStack, Ceph, Kubernetes ve bunlarla ilgili her şey konularında serbest çalışan bir gazeteci, eğitmen ve danışmandır.
Birçok şirket Microsoft, AWS ve Google bulutlarına geçiyor. Maliyetlerden tasarruf etmek istiyorsunuz ve sonra bunun düşündüğünüzden daha pahalı, hatta çoğu zaman çok daha pahalı olacağını fark ediyorsunuz. Bu neden oluyor ve neden önceden bilmiyoruz?
Bunun birçok nedeni var. Birçok şirket başlangıçta maliyet hesaplaması için sunulan araçları kullanıyor ancak hesaplamaları çok az kaynağa ihtiyaç duyulduğunu varsayıyor. Ayrılmış kaynaklar genellikle beklenenden daha pahalıya mal olur; bunun nedeni, bulutlarda belirli hizmetlerin (Hizmet Olarak Yük Dengeleyici, LBaaS) kullanımı gibi bireysel faktörlerin çok çeşitli faktörleri telafi etmesidir, ancak bu, sağlayıcının portföyü genelinde tek tip değildir. Bazı kaynak türleri trafik için ücret alırken, diğerleri daha çok belirli bir zaman dilimindeki istek sayısına dayalıdır. Çok fazla deneyiminiz yoksa, genellikle tek tek öğeleri unutursunuz ve ardından kaba bir uyanış yaşarsınız.
Satıcı değişiklik yaptıktan sonra mevcut konfigürasyonların ortamda çalışır durumda tutulması için düzenli olarak gereken çalışma da önemli ölçüde hafife alınmaktadır. Hatta bazı şirketler bulutu bile terk ediyor çünkü kapsamlı CI/CD işlem hatları o kadar çok devam eden maliyete neden oluyor ki, kendi donanımlarında daha az otomasyonla çalışmanın daha ucuz olması mümkün oluyor. Ancak bu faktörün önceden hesaplanması da oldukça zordur. Ve ne kadar yüksek olduğuna bağlı olarak, bulut yolculuğuna ilişkin hesaplamanın tamamının geçersiz olduğunu bile görebilirsiniz.
Tedarikçiyi değiştirmek veya altyapınızın tamamını veya bir kısmını kullanmaya geri dönmek zaman ve para açısından neden genellikle bu kadar pahalı?
Her hiper ölçekleyicinin müşterileri kendi platformlarında tutma konusunda çıkarı vardır. AWS & Co.’nun klasik kilitleme efektlerini kullanmasının nedeni budur. AWS CloudFormation, AWS EKS, dahil edilen izleme araçları ve diğer birçok bileşen, Amazon AWS’ye son derece özel olacak şekilde tasarlanmıştır. Azure ve Google bunu farklı şekilde yapmıyor. Yani sorun şu: Süreçleriniz AWS için optimize edilmişse, başka bir sağlayıcıya geçmek genellikle uygulamanızın yaşam döngüsü yönetiminin büyük ölçüde yeniden yazılması anlamına gelir. Ayrıca LBaaS gibi hizmetleri sunabilecek şirket içi bir bulut genellikle mevcut değildir. İlgili hizmetlerin daha sonra kendi araçlarıyla değiştirilmesi gerekir; bu da yine geliştirme kaynaklarını tüketir.
Yeni iX, bulut maliyetleri ve buluttan çıkış hakkındaki kapak konusuna ek olarak NIS2, Siber Dayanıklılık Yasası ve diğer yönergelerle 2024’te bizi hangi düzenlemelerin beklediğini de kapsıyor. Ayrı bir makale, enerji verimliliği yasasının veri merkezleri için ne anlama geldiğini gösteriyor. Artı: Kubernetes için en iyi depolama seçeneğini nasıl bulabilirim, biyometrik FIDO belirteçlerinin ne kadar güvenli olduğu, Javascript’in yerine geçecek Elm işlevsel dili ve çok daha fazlası. Tüm konulara genel bir bakış burada bulunabilir.
Şirketler çıkış başarısını garantilemek için en iyi hangi teknikleri kullanmalıdır?
Genel olarak, CI/CD ortamlarınızı geliştirirken Terraform gibi genel araçları kullandığınızdan emin olmanız yararlı olacaktır. Bunlar dahili bir soyutlama sunar, böylece yöneticinin yalnızca bir yük dengeleyicinin başlatılması gerektiğini belirtmesi gerekir. AWS, Azure veya GCP’de araç daha sonra platformun sunduğu kaynağı kullanır. Bu, daha önce açıklanan, otomasyonunuzu platformda güncel tutma sorunu gibi bazı sorunların önlenebileceği anlamına gelir. En iyi ihtimalle böyle bir durumda Terraform gibi dağıtım aracınızı bulutun değişen ihtiyaçlarını karşılayabilecek yeni bir sürüme güncellemeniz yeterlidir.
Aksi takdirde olağan tavsiye geçerlidir: Bir ortam ne kadar genel olarak tasarlanmışsa, bir platformdan diğerine geçmenin o kadar kolay olması muhtemeldir. Daha sonra yalnızca birkaç adımda farklı bir ortamda bir PoC kurulumu oluşturabilirsiniz; geriye kalan tek şey verileri taşımaktır. Ortak bir veri tabanı kullanırsanız hayatınız da kolaylaşacaktır. Burada MySQL kullanılıyorsa mysqldump gibi araçlarla geçiş kolaylıkla yapılabilir.
Bay Loschwitz, yanıtlarınız için çok teşekkür ederim! Buluttaki maliyet tuzakları, buluttan çıkış planlaması, hiper ölçekleyicilere alternatif olarak egemen bulut sağlayıcıları ve SaaS sağlayıcısı 37signals’ın buluttan çıkışına ilişkin ayrıntılı bir röportaj hakkında ayrıntılı makaleler, bugün Haberler Shop’ta mevcut olan mevcut iX’te bulunabilir ve şu adreste mevcuttur: kiosklar.
“Üç soru ve cevap” serisinde iX, ister bilgisayar önündeki kullanıcının bakış açısı, ister yöneticinin bakış açısı, ister yöneticinin günlük yaşamı olsun, günümüzün BT zorluklarının özüne inmek istiyor. bir yönetici. Günlük uygulamalarınızdan veya kullanıcılarınızdan önerileriniz var mı? Hangi konuyu kısa ve doğrudan okumak istersiniz? O halde bize yazmaktan veya forumda yorum bırakmaktan çekinmeyin.
(ulw)
Haberin Sonu
Duyuru
Martin Gerhard Loschwitz, OpenStack, Ceph, Kubernetes ve bunlarla ilgili her şey konularında serbest çalışan bir gazeteci, eğitmen ve danışmandır.
Birçok şirket Microsoft, AWS ve Google bulutlarına geçiyor. Maliyetlerden tasarruf etmek istiyorsunuz ve sonra bunun düşündüğünüzden daha pahalı, hatta çoğu zaman çok daha pahalı olacağını fark ediyorsunuz. Bu neden oluyor ve neden önceden bilmiyoruz?
Bunun birçok nedeni var. Birçok şirket başlangıçta maliyet hesaplaması için sunulan araçları kullanıyor ancak hesaplamaları çok az kaynağa ihtiyaç duyulduğunu varsayıyor. Ayrılmış kaynaklar genellikle beklenenden daha pahalıya mal olur; bunun nedeni, bulutlarda belirli hizmetlerin (Hizmet Olarak Yük Dengeleyici, LBaaS) kullanımı gibi bireysel faktörlerin çok çeşitli faktörleri telafi etmesidir, ancak bu, sağlayıcının portföyü genelinde tek tip değildir. Bazı kaynak türleri trafik için ücret alırken, diğerleri daha çok belirli bir zaman dilimindeki istek sayısına dayalıdır. Çok fazla deneyiminiz yoksa, genellikle tek tek öğeleri unutursunuz ve ardından kaba bir uyanış yaşarsınız.
Satıcı değişiklik yaptıktan sonra mevcut konfigürasyonların ortamda çalışır durumda tutulması için düzenli olarak gereken çalışma da önemli ölçüde hafife alınmaktadır. Hatta bazı şirketler bulutu bile terk ediyor çünkü kapsamlı CI/CD işlem hatları o kadar çok devam eden maliyete neden oluyor ki, kendi donanımlarında daha az otomasyonla çalışmanın daha ucuz olması mümkün oluyor. Ancak bu faktörün önceden hesaplanması da oldukça zordur. Ve ne kadar yüksek olduğuna bağlı olarak, bulut yolculuğuna ilişkin hesaplamanın tamamının geçersiz olduğunu bile görebilirsiniz.
Tedarikçiyi değiştirmek veya altyapınızın tamamını veya bir kısmını kullanmaya geri dönmek zaman ve para açısından neden genellikle bu kadar pahalı?
Her hiper ölçekleyicinin müşterileri kendi platformlarında tutma konusunda çıkarı vardır. AWS & Co.’nun klasik kilitleme efektlerini kullanmasının nedeni budur. AWS CloudFormation, AWS EKS, dahil edilen izleme araçları ve diğer birçok bileşen, Amazon AWS’ye son derece özel olacak şekilde tasarlanmıştır. Azure ve Google bunu farklı şekilde yapmıyor. Yani sorun şu: Süreçleriniz AWS için optimize edilmişse, başka bir sağlayıcıya geçmek genellikle uygulamanızın yaşam döngüsü yönetiminin büyük ölçüde yeniden yazılması anlamına gelir. Ayrıca LBaaS gibi hizmetleri sunabilecek şirket içi bir bulut genellikle mevcut değildir. İlgili hizmetlerin daha sonra kendi araçlarıyla değiştirilmesi gerekir; bu da yine geliştirme kaynaklarını tüketir.
Yeni iX, bulut maliyetleri ve buluttan çıkış hakkındaki kapak konusuna ek olarak NIS2, Siber Dayanıklılık Yasası ve diğer yönergelerle 2024’te bizi hangi düzenlemelerin beklediğini de kapsıyor. Ayrı bir makale, enerji verimliliği yasasının veri merkezleri için ne anlama geldiğini gösteriyor. Artı: Kubernetes için en iyi depolama seçeneğini nasıl bulabilirim, biyometrik FIDO belirteçlerinin ne kadar güvenli olduğu, Javascript’in yerine geçecek Elm işlevsel dili ve çok daha fazlası. Tüm konulara genel bir bakış burada bulunabilir.
Şirketler çıkış başarısını garantilemek için en iyi hangi teknikleri kullanmalıdır?
Genel olarak, CI/CD ortamlarınızı geliştirirken Terraform gibi genel araçları kullandığınızdan emin olmanız yararlı olacaktır. Bunlar dahili bir soyutlama sunar, böylece yöneticinin yalnızca bir yük dengeleyicinin başlatılması gerektiğini belirtmesi gerekir. AWS, Azure veya GCP’de araç daha sonra platformun sunduğu kaynağı kullanır. Bu, daha önce açıklanan, otomasyonunuzu platformda güncel tutma sorunu gibi bazı sorunların önlenebileceği anlamına gelir. En iyi ihtimalle böyle bir durumda Terraform gibi dağıtım aracınızı bulutun değişen ihtiyaçlarını karşılayabilecek yeni bir sürüme güncellemeniz yeterlidir.
Aksi takdirde olağan tavsiye geçerlidir: Bir ortam ne kadar genel olarak tasarlanmışsa, bir platformdan diğerine geçmenin o kadar kolay olması muhtemeldir. Daha sonra yalnızca birkaç adımda farklı bir ortamda bir PoC kurulumu oluşturabilirsiniz; geriye kalan tek şey verileri taşımaktır. Ortak bir veri tabanı kullanırsanız hayatınız da kolaylaşacaktır. Burada MySQL kullanılıyorsa mysqldump gibi araçlarla geçiş kolaylıkla yapılabilir.
Bay Loschwitz, yanıtlarınız için çok teşekkür ederim! Buluttaki maliyet tuzakları, buluttan çıkış planlaması, hiper ölçekleyicilere alternatif olarak egemen bulut sağlayıcıları ve SaaS sağlayıcısı 37signals’ın buluttan çıkışına ilişkin ayrıntılı bir röportaj hakkında ayrıntılı makaleler, bugün Haberler Shop’ta mevcut olan mevcut iX’te bulunabilir ve şu adreste mevcuttur: kiosklar.
“Üç soru ve cevap” serisinde iX, ister bilgisayar önündeki kullanıcının bakış açısı, ister yöneticinin bakış açısı, ister yöneticinin günlük yaşamı olsun, günümüzün BT zorluklarının özüne inmek istiyor. bir yönetici. Günlük uygulamalarınızdan veya kullanıcılarınızdan önerileriniz var mı? Hangi konuyu kısa ve doğrudan okumak istersiniz? O halde bize yazmaktan veya forumda yorum bırakmaktan çekinmeyin.
(ulw)
Haberin Sonu