当我们开始敏捷时，没有容器，也没有Kubernetes。但他们改变了过去最困难的部分：将敏捷性从一个小团队应用到整个组织。出于一个非常明显的原因，越来越多的企业正在试验敏捷和DevOps：需要更快的速度和更多的试验来为创新和竞争力提供优势。DevOps将帮助我们获得所需的创新速度。但是在小团队或初创公司中实践DevOps与大规模实践是两码事。我们都明白，在十人跨职能团队中运作良好的解决方案在应用于一百人团队时可能效果不佳。这条路是如此艰难，以至于IT人员最简单的反应就是将敏捷方法的采用再推迟一年。但那个时代已经结束了。如果您已经尝试过但没有奏效，那么现在是时候重新开始了。到目前为止，DevOps需要为许多组织提供单独的解决方案，通常需要大量调整和额外的工作。但如今，Linux容器和Kubernetes正在推动DevOps工具和流程的标准化。这种标准化将加速整个软件开发过程。因此，我们用来实践DevOps工作方式的技术终于满足了我们加速软件开发的愿望。Linux容器和Kubernetes正在改变团队交互的方式。此外，您可以在Kubernetes平台上运行任何可以在Linux上运行的应用程序。这是什么意思？你可以运行大量的企业和应用程序（甚至可以解决以前烦人的Windows和Linux之间的协调问题）。容器和Kubernetes几乎可以处理您将来要运行的任何工作。他们正在针对机器学习、人工智能和分析工作等下一代问题解决工具进行面向未来的验证。让我们以机器学习为例来考虑一下。今天，人们可以在大量的公司数据中找到模式。当机器发现这些模式（想想机器学习）时，您的员工可以更快地采取行动。随着人工智能的加入，机器不仅可以发现模式，还可以对其采取行动。今天，一个积极的软件开发冲刺是三周。有了人工智能，机器每秒可以修改代码很多次。创业公司会利用这种能力来“打扰你”。考虑一下您在比赛中需要多快。如果您对DevOps和每周一次迭代没有信心，请考虑一下当该初创公司将AI驱动的流程指向您时会发生什么？是时候转向DevOps的工作方式了，否则就会像您的竞争对手一样被甩在后面。容器技术如何改变团队的工作方式？DevOps让许多试图将这种工作方式扩展到更大规模的团队感到沮丧。许多IT（和业务）人员都持怀疑态度，尽管他们之前听说过与敏捷相关的语言、框架、模型（如DevOps）有望彻底改变应用程序开发和IT流程。向您的听众“推销”快速开发冲刺也不容易。想象一下，如果你以这种方式买了房子——而不是向开发商支付固定金额，你会得到类似的东西：“我们将在4周内浇筑地基，成本是X，然后是房屋框架和电线将在稍后建造，但我们只能知道完成地基的时间表。”人们习惯于以预付价格和交付时间表购买房屋。挑战在于构建软件与建造房屋不同。同一个建造者通常会建造数千个相同的房屋，而软件项目永远不会相同。这是你必须克服的第一个障碍。开发和运营团队的工作方式不同，我知道这一点，因为我在这两个方面都做过工作。企业倾向于以不同的方式激励他们，开发人员因做出改变和创造而获得奖励，而运营专家因为降低成本和确保安全而得到奖励。我们会把他们分成不同的群体，尽量减少互动。而这些角色往往会吸引那些以完全不同的方式思考的技术人员。但这样的解决方案注定要失败，你必须打破壁垒在开发和运营之间。想想在传统情况下会发生什么。企业将需求抛到墙外，因为他们在“买房”中运营se”模式，然后说“9个月后见。”开发人员根据这些要求进行构建，并根据技术限制要求进行更改。然后，他们把它扔过墙给操作人员并说“弄清楚如何运行这个软件”。然后，操作人员努力进行大量更改以使软件与基础架构保持一致。然而，最终的结果是什么？通常，业务人员在看到需求实现的最终结果时甚至都没有意识到这一点。在20年的大部分时间里，我们已经看到这种模式一次又一次地在软件行业上演。而现在，是时候做出改变了。Linux容器可以真正解决这个问题，因为容器弥合了开发和运维之间的鸿沟。容器技术允许两个团队共同理解和设计所有关键需求，但仍然独立履行各自的团队职责。借助容器技术，我们可以让运维团队变得更小，但仍然能够承担百万级应用的运维，让开发团队能够更快速地根据需要更改软件。（在较大的组织中，所需的速度可能比操作人员的响应速度更快。）使用容器，您可以将需要交付的内容与其运行的地方分开。您的运维团队只负责运行容器的主机和安全的内存占用，仅此而已。这是什么意思？首先，这意味着您现在可以与您的团队一起实践DevOps。没错，就是让团队专注于他们已经拥有的专业知识，而有了容器，就让团队了解所需的集成依赖的必要知识。如果你试图重新培训每个人，没有人会擅长所有事情。容器技术允许团队进行交互，但也为每个团队提供了围绕该团队优势构建的强大边界。开发人员将知道要消耗哪些资源，但不知道如何使其大规模工作。运营团队了解核心基础设施，但不了解应用程序的细节。此外，运营团队还可以在您成为下一次数据泄露的主体之前更新应用程序以解决新的安全问题。想向大型IT组织（比如30,000人）传授操作和开发技能？那可能需要你十年的时间，而你可能没有那么多时间。当人们谈论“构建新的云原生应用程序将帮助我们摆脱这个问题”时，批判性地思考。你可以在一个10人的团队中构建云原生应用程序，但这可能不适用于《财富》MagazineTop1000。你不能一个一个地构建新的微服务，除非你不再需要依赖现有的团队：你最终会形成一个孤立的组织。这是一个诱人的想法，但您不能指望这些应用程序重新定义您的业务。我还没有看到任何公司在这种规模的并行开发方面取得成功。IT预算已经受到限制；将它们增加一倍甚至三倍在很长一段时间内都是不现实的。当奇迹发生时：你好，VelocityLinux容器是为扩展而构建的。一旦你开始这样做，像Kubernetes这样的编排工具就会发挥作用，因为你将需要运行数千个容器。应用程序不会只由一个容器组成，它们将依赖于许多不同的部分，所有这些部分都将作为一个单元在容器上运行。如果不这样做，您的应用程序将无法在生产环境中正常运行。想想有多少小滑轮和杠杆组合在一起来支持您的业务，这对任何应用程序都是如此。开发人员负责应用程序中的所有滑轮和杠杆。（如果开发人员没有这些组件，您可能会遇到集成噩梦。）同时，运营团队负责构成基础架构的所有滑轮和杠杆，无论是离线还是在云端。做一个更抽象的类比，使用Kubernetes，您的运营团队可以提供应用程序运行所需的燃料，而无需成为所有方面的专家。开发人员进行实验，运营团队确保基础架构安全可靠。这样的结合使得企业敢于冒小风险实现创新。公司的真正试验往往是渐进和快速的，而不是做出一些全有或全无的赌注。根据个人经验，这就是组织内部发生巨大变化的原因：因为人们说，“我们如何才能真正利用这种通过改变计划进行试验的能力？”它强制执行敏捷计划。例如，使用DevOps模型、容器和Kubernetes的KeyBank现在每天都会部署代码。（观看视频，在KeyBank领导持续交付和反馈的JohnRzeszotarski解释了这一变化。）同样，MacquarieBank每天都在使用DevOps和容器将一些东西投入生产。一旦您每天推出软件，它就会改变您计划的各个方面，并加快您业务的变化速度。“想法可以在一天内到达客户手中，”MacquarieBankandFinancialServicesGroup的CDOLuisUguina说（参见RedHat与MacquarieBank的合作案例研究）。是时候创造伟大的东西了Macquarie的例子说明了速度的力量。这将如何改变您开展业务的方式？请记住，麦格理不是一家初创公司。这是CIO面临的颠覆性力量，不仅来自新的市场进入者，也来自老牌同行。开发人员的自由也改变了运营敏捷商店的CIO的人才方程式。突然间，大公司的个人（即使不在最热门的行业或地区）可以产生巨大的影响。Macquarie将这一变化用作招聘工具，向开发人员承诺所有新员工将在第一周内推出新产品。同时，在这个基于云计算和存储功能的时代，我们拥有比以往任何时候都多的可用基础设施。这是幸运的，考虑到机器学习和人工智能工具很快就会实现飞跃。所有这些都表明，现在是打造伟大事物的好时机。鉴于市场创新的速度，您需要不断创造伟大的东西来保持客户忠诚度。因此，如果您一直在等待将赌注押在DevOps上，那么现在正是时候。容器和Kubernetes改变了游戏规则，而且对您有利。
