Bu podcast’te, konteynerler ve depolama ve veri koruması ile uğraşırken Pure Storage’ın Venkat Ramakrishnan ile müşteri zorlukları hakkında konuşuyoruz.
Portworx Ürün ve Mühendislik Başkan Yardımcısı Ramakrishnan, gelecek ölçekte düşünmeden konteyner dağıtımları alan müşterilerden, teknik gereksinimleri ve tahakkuk ettikleri maliyetleri konuştu.
Burada, Ramakrishnan, DIY ve açık kaynak çözümlerine karşı uyarıyor ve konteyner dağıtımları daha çok sayıda ve karmaşık hale geldikçe şirket içi becerilerdeki olası gereksinimler.
Konteynerler için depolama ve veri koruma müşterileri için temel zorluklar nelerdir?
Buna atlamadan önce, nedenini düşünelim. Daha sık teknoloji endüstrisinde, ne hakkında konuşmak için çok zaman harcıyoruz, ancak nedenine yeterince zaman harcamıyoruz.
İnsanlar neden kap kullanmalı? İnsanlar neden Kubernetes çalıştırmalı? Çok temel bir düzeyde, kapsayıcılar uygulama ve veri taşınabilirliği sağlar – özellikle uygulamanızı her yerde oluşturabilir ve her yerde çalıştırabilirsiniz. […] Bu çeviklik verir.
Çevikliğin yol açtığı şey hızdır. Ancak hızı artırdığınızda, daha fazla hız kullandığınızda, uygulamalarını çok daha hızlı inşa etmeye ve yinelemeye çalışan birçok farklı uygulama ekibini desteklediğiniz anlamına gelir. Bunun anlamı, çok daha fazla otomasyon sunmanız gerektiğidir.
Konteyner tabanlı bir dağıtımın ölçeği-Kubernetes tabanlı dağıtım-kuruluşların işlemek için kullandıklarından çok daha büyük hale gelebilir, çünkü tüm bu faydaları vermeye çalışıyorlar ve birçok takımı desteklemek zorundalar.
Kuruluşlar bu ölçeğe ulaştığında, günlük görevlerinin çoğunu, günlük operasyonlarının çoğunu, bakımlarının çoğunu otomatikleştirmelerini sağlayacak yeterli araca sahip olmalıdır. İşletmeler için en büyük zorluklardan biri otomasyon eksikliğidir.
Kubernetes bir konteyner çalışma zamanını otomatikleştirmeye çalışır. Konteynerler taşınabilirlik verir, ancak bu uygulamaların nasıl düzenleneceği konusunda otomasyon eksikliği vardır – ihtiyaç duydukları harika performansın nasıl sağlanacağı, bu uygulamaların nasıl yönetileceği ve yönetici olarak, her kapsayıcıyı, her uygulamayı korumak ve her uygulamayı korumak zorunda olmadığınız yerlerde nasıl koruyacağınız. Bunun yerine, uygulama ekiplerine bilet vermek zorunda kalmadan bu hizmetlere bildirici ve programlı olarak erişebilmeleri için yeterli araç verirsiniz.
Tüm bu hıza, ölçeke ve otomasyona sahipsiniz ve sonra bir bilet dosyalamak ve beklemek zorunda biri tarafından engellenirse, bu büyük bir blok. Şirketler için en büyük zorluk otomasyon, birçok araçta otomasyon eksikliği. Diğer büyük zorluk, farklı platformları destekleme yeteneğidir. Bu tarafsızlık anlamına gelir. Konteynerlerin vaadi, her yerde inşa etmeniz ve her yerde çalıştırmanızdır.
Ancak size tarafsızlık sağlayan bir yığınınız yoksa vaat yerine getirilemez. Temel altyapıyı demokratikleştirmek önemli bir ağrı noktasıdır. Ve bu demokratikleştirilmiş altyapı olmadan, Kubernetes’teki konteynerleri kullanmasına rağmen, kuruluşlar geri tutuluyor.
Üçüncü şey güvenliktir, çünkü Kubernetes tabanlı bir platform, birçok geliştirici ve uygulama ekibini ortak bir Kubernetes kümesine veya özel bir Kubernetes kümesine getirmeye çalışır. Konteyner kullanarak Kubernetes’in üstünde ciddi işletmeler inşa ediyorsunuz. Bu uygulamaların güvenli olmasını nasıl sağlıyorsunuz? Ağın üzerinden geçen verilerin güvenli olmasını nasıl sağlıyorsunuz? Aynı paylaşılan platformdaki farklı uygulama ekiplerinin veri sızmasına nasıl sahip olduğundan nasıl emin olabilirsiniz?
Örneğin, satış elemanlarının veya satış ekiplerinin, satış uygulamalarının İK uygulamalarını görebilmesini istemezsiniz. Örneğin, mühendislikteki birine görünür olmak için finansa giren başka birinin komisyon verilerini istemezsiniz. Bu çok kiracılı uygulamaları nasıl oluşturuyorsunuz? Bu büyük bir sorun. Yani, bunlar Kubernetes’te kapları benimsemenin en büyük zorluklarından bazıları.
Bunlar konteynerlerin ve kuberneteslerin faydalarından kaynaklanan sorunlar gibi görünüyor. Müşteriler bu tür sorunlarla nasıl başa çıkmaya başlıyor?
Bu, müşterilerle birçok kez yaptığım bir konuşma. Müşterilerin farklı şeyler denediğini ve başarısız olduğunu gördüm ve her zaman yolculuklarında erken olduklarında onlarla konuşsaydım.
Örneğin? İlginç bir başarısızlığın var mı?
Birçoğu var. ‘Belirli bir depolama arayüzü benim için yeterince iyi; Her şeyi getirebilirim. ‘ Ve yakında ‘Hayır, bu arayüz benim için doğru ölçek değil’ fark ediyorlar.
Ya da ‘Sadece açık kaynakları kullanarak para biriktirmeye çalışabilirim’ diyecekler. Ve özgürce gerçekten ücretsiz olmadığını fark ettiler, çünkü görev açısından kritik işletmeleri çalıştırmak söz konusu olduğunda, size yazılımı sürdürebilecek, güncellemeye devam edebilecek ve yararlanmaya devam edebilecek yetenekler verebilecek 24x7x365 desteği verebilecek birine ihtiyacınız var.
Teknik bir borç inşa etmek zorunda değilsiniz. Bunu yürütmek için bir geliştirici ordusu tutmanıza gerek yok. İyi geliştiricileri işe almak zor bir iştir – iyi geliştiriciler, iyi mühendisler bulmak gerçekten zor bir iştir ve beceri setleri her zaman sürekli talep görür. Yani, birisi tüm bu DIY’yi aldığında, esasen araç zincirini korumak için kaydolurlar. [take on] Teknik borç. Bu, Google ve Microsoft gibi büyük şirketler için bir sorun. Tüm bu şirketler teknoloji borcu ve işletmelerle mücadele ediyor.
Müşterilerin teknik borcu almaya çalıştıklarını, sadece içine gömüldüğünü ve sonra ‘Tamam, beni ondan çıkar’ deyin. Ölçek beklemiyorlar. Sadece birkaç bin kap çalışacaklarını düşünüyorlar. Bakın, aniden 100.000 kap kullanıyorlar ve kenarda sallanıyorlar ve çok fazla başarısızlık var.
Bazen bu kurtarma görevine gidiyoruz ve müşteriyi sefaletlerinden kurtarıyoruz ve sonra doğru yola koyuyoruz. Genel olarak müşterilere tavsiye ettiğim şey: taktiksel olarak düşünmeyin, stratejik düşünün. Bugün önünüzdeki ihtiyaca bakmayın; Taktik bir çözüm oluşturun ve ardından stratejik ihtiyaçlarınız için ölçeklendirmeye çalışın. Kanıtlanmış yollarla gidin. Kanıtlanmış bir yola bakın ve bununla devam edin. Ve çoğu kez özgür olduğunu düşündüğünüz şey aslında ücretsiz değildir; Bunun için ödediğiniz şey aslında kendisi için ne ödeyeceğidir.
Kendileri için ödeme yapan çözümler seçin. Maliyetleri kontrol etmenizi sağlar, operasyonel harcamalarınızı azaltmanıza izin verir ve daha fazla altyapı almanıza izin verir. Bu tür çözümler kendileri için ödeme yapar. Yani, sonunda ödeme yaparken [rather than getting it for] Özgür, sonunda özgürleşir çünkü çözüm kendisi için ödeme yapar. Maliyet tasarrufu sağlayan ve kuruluşunuzu serbest bırakan daha fazla verimlilik sağlar, böylece bunu başka şeyler oluşturmak için kullanabilirsiniz.
Müşterilere anlattığım bir şey, daha stratejik düşünmek ve bu seçimler hakkında akıllı olmaktır. Müşterilere tüm yaşam döngüsü boyunca nasıl düşünülecekleri konusunda koçluk yapıyoruz. Bir geliştirici bir uygulama getirirse ne olur? 10 uygulama ekibi, 100 uygulama ekibi uygulamalarını getirirse ne olur? Farklı iş sürekliliği gereksinimleri varsa ne olur? Farklı performans gereksinimleri varsa ne olur? Farklı güvenlik gereksinimleri ne olacak? Bu uygulama ekibi verilerini dinlenme veya uçuşta şifrelemek isteyebilir ve bir uygulama ekibi sadece çoklu kiracılık isteyebilir.
Tüm bunlarla nasıl başa çıkıyorsunuz? Müşterilere koçluk yaptığım bir şey bu. [Also] Tüm bir müşteri yolculuğunu düşünün. Uygulama emekli olduğunda ne olur? Veya yeni bir uygulamaya yükseltmek zorunda oldukları zaman? Ve uygulamanın yeni sürümlerini prodüksiyon verileriyle test etmek için prodüksiyondan test etmek için veri getirmek zorunda kaldıklarında ne olur? Bunlar, çözüm aramaya başladıklarında keşfettikleri şeyler.
Çözümü inşa ettikleri şeye atmaya çalışıyorlar ve bu bir karışıklık haline geliyor – entegre ettikleri bir çözümün karmaşık bir hodgepodge. Müşterilere, sadece tek tıklamanız için yeterince basit bir platform seçmelerini söyleriz, tüm bu yetenekleri sunar, böylece sonsuza dek inşa ettiğiniz bu DIY altyapısını uğraşmak yerine yenilik, uygulamalar oluşturmaya odaklanabilirsiniz.