播客:容器存储挑战及如何克服它们
我们与Pure Storage的Venkat Ramakrishnan讨论了容器、存储和数据保护中客户面临的挑战。
Ramakrishnan是Portworx的产品和工程副总裁,他谈到客户在部署容器时往往未考虑未来的规模、技术需求和可能产生的成本。Ramakrishnan警告不要使用DIY和开源解决方案,并指出随着容器部署变得更多和更复杂,内部技能需求可能会累积。
下载此播客
容器存储和数据保护的主要挑战是什么?
在深入讨论之前,让我们先思考一下“为什么”。在科技行业,我们经常花很多时间讨论“是什么”,但很少花时间在“为什么”上。为什么人们应该使用容器?为什么人们应该运行Kubernetes?在非常基本的层面上,容器提供了应用程序和数据的可移植性——特别是你可以在任何地方构建你的应用程序并在任何地方运行它,[…]这提供了敏捷性。
敏捷性带来的是速度。但当你提高速度,当你驱动更多速度时,这意味着你支持许多不同的应用程序团队试图更快地构建和迭代他们的应用程序。这意味着你需要提供更多的自动化。
基于容器的部署——基于Kubernetes的部署——的规模可以迅速变得比组织习惯处理的要大得多,因为他们试图提供所有这些好处,并且必须支持许多团队。
当组织达到那个规模时,他们应该有足够的工具来自动化他们的大部分日常任务、大部分日常操作、大部分维护。企业的一个大挑战是缺乏自动化。
Kubernetes试图自动化容器运行时。容器提供了可移植性,但缺乏关于如何编排这些应用程序的自动化——如何提供他们需要的出色性能,如何管理这些应用程序,以及如何保护它们,这样作为管理员,你就不必介入并保护每个容器、每个应用程序。相反,你给应用程序团队足够的工具,这样他们就可以声明式和编程式地访问这些服务,而无需提交工单。
你有所有这些速度、规模和自动化,然后如果它被某人必须提交工单并等待所阻塞,那是一个巨大的障碍。公司的大挑战是自动化,许多工具中缺乏自动化。另一个大挑战是支持不同平台的能力。这意味着中立性。容器的承诺是你在任何地方构建并在任何地方运行它。
但如果你没有一个提供中立性的堆栈,这个承诺就无法实现。民主化底层基础设施是一个关键痛点。没有那个民主化的底层基础设施,尽管在Kubernetes中使用容器,组织还是被拖后腿。
第三件事是安全,因为基于Kubernetes的平台试图将许多开发者和应用程序团队带入一个共享的Kubernetes集群或专用的Kubernetes集群。你正在使用容器在Kubernetes上构建严肃的业务。你如何确保这些应用程序是安全的?你如何确保通过网络的数据是安全的?你如何确保同一共享平台上的不同应用程序团队没有数据泄露?
例如,你不希望销售团队或销售应用程序能够看到人力资源应用程序。你不希望,例如,进入财务的某人的佣金数据对工程部门的某人可见。你如何构建那些多租户应用程序?那是一个大问题。所以,这些是在Kubernetes中采用容器的一些主要挑战。
这些似乎是容器和Kubernetes的好处带来的问题。客户如何开始解决这类问题?
这是我与客户多次进行的对话。我见过客户尝试不同的事情并失败,我总是希望我在他们旅程早期就与他们交谈。
比如?有没有有趣的失败案例?
有很多。有客户认为,“一个特定的存储接口对我来说足够好;我可以带来一切。”他们很快意识到,“不,那个接口不适合我的规模。”
或者他们会说,“我可以通过只使用一切开源来省钱。”他们意识到免费真的不是免费的,因为当涉及到运行关键任务企业时,你需要有人能提供24x7x365支持,能维护软件,不断更新它,并给你继续利用它的能力。
你不必自己构建技术债务。你不需要雇佣一支开发人员大军来运行它。雇佣好的开发人员是一项艰难的工作——找到好的开发人员、好的工程师真的很难,而且技能需求总是不断变化。所以,当某人承担所有这些DIY时,他们本质上是在签署维护工具链、承担技术债务的协议。这对像Google和Microsoft这样的大公司来说是个问题。所有这些公司都在与技术债务斗争,而企业并不适应这个。
我见过客户试图承担技术债务,只是被它淹没,然后说,“好吧,帮我摆脱它。”他们没有预料到规模。他们认为他们只会运行几千个容器。瞧,突然他们运行着10万个容器,他们摇摇欲坠,有太多失败。
有时我们进行这种救援任务,我们将客户从痛苦中解救出来,然后把他们放在正确的道路上。我通常推荐给客户的是:不要战术性地思考,要战略性地思考。不要只看你今天面前的需求;构建一个战术解决方案,然后尝试为你的战略需求扩展它。选择经过验证的路径。看一个经过验证的路径并选择它。很多时候,你认为免费的东西本质上并不免费;你为它支付的实际上会回报自己。
选择能回报自己的解决方案。它让你控制成本,它让你减少运营支出,它让你获得更多基础设施。这类解决方案能回报自己。所以,虽然你最终支付了[而不是免费获得],但它最终变得免费,因为解决方案回报了自己。它提供了更多效率,节省成本,并释放你的组织,这样你可以用它来构建其他东西。
我告诉客户的是要更战略性地思考,并聪明地做出那些选择。我们指导客户如何思考整个生命周期。如果一个开发者带来一个应用程序会发生什么?如果10个应用程序团队、100个应用程序团队带来他们的应用程序会发生什么?如果他们有不同的业务连续性要求呢?如果他们有不同的性能要求呢?不同的安全要求呢?这个应用程序团队可能想要加密他们的静态或传输中的数据,而一个应用程序团队可能只想要多租户。
你如何处理所有这些?这是我指导客户的一件事。[也]思考整个客户旅程。当应用程序退役时会发生什么?或者当他们必须升级到一个新应用程序时?当他们必须将数据从生产环境带到测试环境,用生产数据测试新版本的应用程序时会发生什么?这些都是他们在开始寻找解决方案时发现的事情。
他们试图将解决方案硬塞进他们构建的东西中,它变得一团糟——一个他们集成的复杂大杂烩解决方案。我们告诉客户选择一个足够简单的平台,只需单击一下,就能提供所有这些能力,这样你可以专注于创新、构建应用程序,而不是永远修补你构建的DIY基础设施。
阅读更多关于存储和容器的内容
存储技术解释:Kubernetes、容器和持久存储。 在本指南中,我们看看市场领先的容器平台Kubernetes,它如何工作,持久存储和备份的挑战,以及如何克服它们。 容器存储平台:六大方法开始对齐。 容器存储是一项复杂但至关重要的任务。我们调查了六大存储制造商,看到方法开始围绕管理平台对齐。