12 KiB
技术如何改变敏捷的规则
越来越多的公司正因为一个非常明显的原因开始尝试敏捷和DevOps: 企业需要借助更快的速度和更多的实验来提供创新和竞争性优势。而DevOps将帮助我们得到所想要达到的创新速度。但是，在小团队或初创企业中实践DevOps和进行大规模实践完全是两码事。我们都明白这样的一个事实，那就是在10人的跨职能团队中能够很好地解决问题的方案，当将同样的模式应用到100人的团队中时就可能无法奏效。这条道路是如此艰难，以至于IT领导者很容易将敏捷方法的推行再推迟一年。
但那样的时代已经结束了。如果你已经尝试过，但是没有成功，那么现在是时候重新开始了。
直到现在，DevOps需要为许多组织提供个性化的解决方案，因此往往需要进行大量的调整以及额外的工作。但在今天，Linux容器和Kubernetes正在推动DevOps工具和过程的标准化。而这样的标准化将会加速整个软件开发过程。因此，我们用来实践DevOps工作方式的技术最终能够满足我们加快软件开发速度的愿望。
Linux容器和Kubernetes正在改变团队交互的方式。此外，你可以在Kubernetes平台上运行任何能够在Linux运行的应用程序。这意味着什么呢？你可以运行大量的企业及应用程序(甚至可以解决以前令人烦恼的Windows和Linux之间的协调问题)。最后，容器和Kubernetes将能够满足未来所有运行内容的需求。它们正在经受着未来的考验，以应对机器学习、人工智能和分析工作等下一代解决问题工具。
参考相关文章,[4 container adoption patterns: What you need to know. ]
让我们以机器学习为例来思考一下。今天，人们可以在大量的企业数据中找到一些模式。当机器发现这些模式时(想想机器学习)，你的员工就能更快地采取行动。随着人工智能的加入，机器不仅可以发现模式，还可以对模式进行操作。如今，三个星期已经成为了一个积极的软件开发冲刺周期。有了人工智能，机器每秒可以多次修改代码。创业公司会利用这种能力来“打扰你”。
考虑一下你需要多快才能参与到竞争当中。如果你对于无法对于DevOps和每周一个迭代周期充满信心，那么考虑一下当那个创业公司将AI驱动的过程指向你时会发生什么？现在是时候转向DevOps的工作方式了，否认就会像你的竞争对手一样被甩在后面。
容器技术如何改变团队的工作？
DevOps使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多IT(和业务)人员之前都听说过语言、框架、模型(如DevOps)等承诺将会彻底应用程序开发和IT过程的全部相关内容，但他们还是对于敏捷持怀疑态度。
[ 想要获取来自其他CIO们的建议吗？不放参考下我们的综述性资源, DevOps: The IT Leader's Guide. ]
向你的涉众“推销”快速开发冲刺也不是一件容易的事情。想象一下，如果你以这种方式买了一栋房子：
你将不再需要向开发商支付固定的金额，而是会得到这样的信息：“我们将在4周内浇筑完地基，其成本是X，之后再搭建房屋框架和铺设电路，但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。
挑战在于构建软件与构建房屋不同。同一个建筑商建造了成千上万个完全相同的房子，而软件项目从来都各不相同。这是你要克服的第一个障碍。
开发和运维团队的工作方式确实不同：我之所以知道这一点是因为我曾经从事过这两方面的工作。我们往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些想法完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。
想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作：“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。然后，运维人员勤就会奋地进行大量更改，使软件与基础设施保持一致。然而，最终的结果是什么呢？
通常情况下，当业务人员看到需求实现的最终结果时甚至根本辨认不出。在过去20年的大部分时间里，我们一次又一次地目睹了这种模式在软件行业中上演。而现在，是时候改变了。
Linux容器能够真正地解决这样的问题，这是因为容器缩小了开发和运维之间的间隙。容器技术允许两个团队共同理解和设计所有的关键需求，但仍然独立地履行各自团队的职责。基本上，我们去掉了开发人员和运维人员之间的电话游戏。
因为容器技术，我们可以使得运维团队的规模更小，但依旧能够承担起数百万应用程序的运维工作，并且能够使得开发团队可以更加快速地根据需要更改软件。(在较大的组织中，所需的速度可能比运维人员的响应速度更快。)
使用容器，您可以将所需要交付的内容与它运行的位置分开。你的运维团队只需要负责运行容器的主机和安全的内存占用，仅此而已。这意味着什么呢？
首先，这意味着你现在可以和团队一起实践DevOps了。没错，只需要让团队专注于他们已经拥有的专业知识，而对于容器，只需让团队了解所需集成依赖关系的必要知识即可。
如果你想要重新训练每个人，往往会收效甚微。容器技术允许团队之间进行交互，但同时也会为每个团队提供一个围绕该团队优势而构建的强大边界。开发人员会知道需要消耗什么，但不需要知道如何使其大规模运行。运维团队了解核心基础设施，但不需要了解应用程序的细节。此外，运维团队也可以通过更新应用程序来解决新的安全问题，以免你成为下一个数据泄露的热门话题。
想要为一个大型IT组织，比如30000人的团队教授运维和开发技能？那或许需要花费你十年的时间，而你可能并没有那么多时间。
当人们谈论“构建新的云原生应用程序将帮助我们摆脱这个问题”时，请批判性地进行思考。你可以在10个人的团队中构建云原生应用程序，但这对《财富》杂志前1000强的企业而言或许并不适用。除非你不再需要依赖现有的团队，否则你无法一个接一个地构建新的微服务：你最终将得到一个竖井式的组织。这是一个诱人的想法，但你不能指望这些应用程序来重新定义你的业务。我还没见过哪家公司能在如此大规模的并行开发中获得成功。IT预算已经受到限制；在很长一段时间内将预算翻倍甚至三倍是不现实的。
当奇迹发生时: 你好, 速度
Linux容器就是为扩容而生的。一旦你开始这样做，Kubernetes之类的编制工具就会发挥作用，这是因为你将需要运行数千个容器。应用程序将不仅仅由一个容器组成，它们将依赖于许多不同的部分，所有的部分都会作为一个单元运行在容器上。如果不这样做，你的应用程序将无法在生产环境中很好地运行。
思考一下有多少小滑轮和杠杆组合在一起来支撑你的业务，对于任何应用程序都是如此。开发人员负责应用程序中的所有滑轮和杠杆。(如果开发人员没有这些组件，您可能会在集成时做噩梦。)与此同时，无论是在线下还是在云上，运维团队都会负责构成基础设施的所有滑轮和杠杆。做一个较为抽象的比喻，使用Kubernetes，你的运维团队就可以为应用程序提供运行所需的燃料，但又不必成为所有方面的专家。
开发人员可以进行实验，运维团队则保持基础设施的安全和可靠。这样的组合使得企业敢于承担小风险，从而实现创新。不同于打几个孤注一掷的赌，公司中真正的实验往往是循序渐进的和快速的。
从个人经验来看，这就是组织内部发生的显著变化：因为人们说：“我们如何通过改变计划来真正地利用这种能力进行实验？”它强制执行敏捷计划。
举个例子，使用DevOps模型、容器和Kubernetes的KeyBank如今每天都会部署代码。(观看视频7，其中主导了KeyBank持续交付和反馈的John Rzeszotarski将解释这一变化。)类似地，Macquarie银行也借助DevOps和容器技术每天将一些东西投入生产环境。
一旦你每天都推出软件，它就会改变你计划的每一个方面，并且会加速业务的变化速度。Macquarie银行和金融服务集团的CDO，Luis Uguina表示：“创意可以在一天内触达客户。”(参见9对Red Hat与Macquarie银行合作的案例研究)。
The right time to build something great
The Macquarie example demonstrates the power of velocity. How would that change your approach to your business? Remember, Macquarie is not a startup. This is the type of disruptive power that CIOs face, not only from new market entrants but also from established peers.
The developer freedom also changes the talent equation for CIOs running agile shops. Suddenly, individuals within huge companies (even those not in the hottest industries or geographies) can have great impact. Macquarie uses this dynamic as a recruiting tool, promising developers that all new hires will push something live within the first week.
At the same time, in this day of cloud-based compute and storage power, we have more infrastructure available than ever. That's fortunate, considering the leaps that machine learning and AI tools will soon enable.
This all adds up to this being the right time to build something great. Given the pace of innovation in the market, you need to keep building great things to keep customers loyal. So if you've been waiting to place your bet on DevOps, now is the right time. Containers and Kubernetes have changed the rules - in your favor.
Want more wisdom like this, IT leaders? Sign up for our weekly email newsletter.
via: https://enterprisersproject.com/article/2018/1/how-technology-changes-rules-doing-agile
作者：Matt Hicks 译者：JayFrank 校对：校对者ID