How technology changes the rules for doing agile (技术如何改变敏捷的规则)

How technology changes the rules for doing agile (技术如何改变敏捷的规则)

Containers and Kubernetes were not here when we started doing agile. But they change what used to be the hardest part: Applying agile beyond a small group, to the whole organization

By Matt Hicks | January 17, 2018

当我们开始推行敏捷时,还没有容器和 Kubernetes。但是它们改变了过去最困难的部分:将敏捷性从小团队应用到整个组织。

— Matt Hicks(作者)

CIO Containers Ecosystem
More companies are trying agile and DevOps for a clear reason: Businesses want more speed and more experiments – which lead to innovations and competitive advantage. DevOps helps you gain that speed. But doing DevOps in a small group or startup and doing it at scale are two very different things. Any of us who’ve worked in a cross-functional group of 10 people, come up with a great solution to a problem, and then tried to apply the same patterns across a team of 100 people know the truth: It often doesn’t work. This path has been so hard, in fact, that it has been easy for IT leaders to put off agile methodology for another year.

越来越多的企业正因为一个非常明显的原因开始尝试敏捷和 DevOps : 企业需要通过更快的速度和更多的实验为创新和竞争性提供优势。而 DevOps 将帮助我们得到所需的创新速度。但是,在小团队或初创企业中实践 DevOps 与进行大规模实践完全是两码事。我们都明白这样的一个事实,那就是在十个人的跨职能团队中能够很好地解决问题的方案,当将相同的模式应用到一百个人的团队中时就可能无法奏效。这条道路是如此艰难,以至于 IT 领导者最简单的应对就是将敏捷方法的推行再推迟一年。

But that time is over. If you’ve tried and stalled, it’s time to jump back in.


Until now, DevOps required customized answers for many organizations – lots of tweaks and elbow grease. But today, Linux containers and Kubernetes are fueling standardization of DevOps tools and processes. That standardization will only accelerate. The technology we are using to practice the DevOps way of working has finally caught up with our desire to move faster.

到目前为止,DevOps 需要为许多组织提供个性化的解决方案,因此往往需要进行大量的调整以及付出额外的工作。但在今天, Linux 容器 和 Kubernetes 正在推动 DevOps 工具和过程的标准化。而这样的标准化将会加速整个软件开发过程。因此,我们用来实践 DevOps 工作方式的技术最终能够满足我们加快软件开发速度的愿望。

Linux containers and Kubernetes are changing the way teams interact. Moreover, on the Kubernetes platform, you can run any application you now run on Linux. What does that mean? You can run a tremendous number of enterprise apps (and handle even previously vexing coordination issues between Windows and Linux.) Finally, containers and Kubernetes will handle almost all of what you’ll run tomorrow. They’re being future-proofed to handle machine learning, AI, and analytics workloads – the next wave of problem-solving tools.

Linux 容器和 Kubernetes 正在改变团队交互的方式。此外,你可以在 Kubernetes 平台上运行任何能够在 Linux 运行的应用程序。这意味着什么呢?你可以运行大量的企业及应用程序(甚至可以解决以前令人烦恼的 Windows 和 Linux 之间的协调问题)。最后,容器和 Kubernetes 能够满足你未来将要运行的几乎所有工作。它们正在经受着未来的考验,以应对机器学习、人工智能和分析工作等下一代解决问题工具。

Think about machine learning, for example. Today, people still find the patterns in much of an enterprise’s data. When machines find the patterns (think machine learning), your people will be able to act on them faster. With the addition of AI, machines can not only find but also act on patterns. Today, with people doing everything, three weeks is an aggressive software development sprint cycle. With AI, machines can change code multiple times per second. Startups will use that capability – to disrupt you.


Consider how fast you have to be to compete. If you can’t make a leap of faith now to DevOps and a one week cycle, think of what will happen when that startup points its AI-fueled process at you. It’s time to move to the DevOps way of working now, or get left behind as your competitors do.

考虑一下你需要多快才能参与到竞争当中。如果你对于无法对于 DevOps 和每周一个迭代周期充满信心,那么考虑一下当那个创业公司将 AI 驱动的过程指向你时会发生什么?现在是时候转向 DevOps 的工作方式了,否则就会像你的竞争对手一样被甩在后面。

How are containers changing how teams work?


DevOps has frustrated many groups trying to scale this way of working to a bigger group. Many IT (and business) people are suspicious of agile: They’ve heard it all before – languages, frameworks, and now models (like DevOps), all promising to revolutionize application development and IT process.

DevOps 使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多 IT(和业务)人员之前都听说过敏捷相关的语言、框架、模型(如 DevOps),而这些都有望彻底应用程序开发和 IT 流程,但他们还是对此持怀疑态度。

It’s not easy to “sell” quick development sprints to your stakeholders, either. Imagine if you bought a house this way. You’re not going to pay a fixed amount to your builder anymore. Instead, you get something like: “We’ll pour the foundation in 4 weeks and it will cost x. Then we’ll frame. Then we’ll do electrical. But we only know the timing on the foundation right now.” People are used to buying homes with a price up front and a schedule.

向你的受众“推销”快速开发冲刺也不是一件容易的事情。想象一下,如果你以这种方式买了一栋房子 —— 你将不再需要向开发商支付固定的金额,而是会得到这样的信息:“我们将在 4 周内浇筑完地基,其成本是 X,之后再搭建房屋框架和铺设电路,但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。

The challenge is that building software is not like building a house. The same builder builds thousands of houses that are all the same. Software projects are never the same. This is your first hurdle to get past.


Dev and operations teams really do work differently: I know because I’ve worked on both sides. We incent them differently. Developers are rewarded for changing and creating, while operations pros are rewarded for reducing cost and ensuring security. We put them in different groups and generally minimize interaction. And the roles typically attract technical people who think quite differently. This situation sets IT up to fail. You have to be willing to break down these barriers.


Think of what has traditionally happened. You throw pieces over the wall, then the business throws requirements over the wall because they are operating in “house-buying” mode: “We’ll see you in 9 months.” Developers build to those requirements and make changes as needed for technical constraints. Then they throw it over the wall to operations to “figure out how to run this.” Operations then works diligently to make a slew of changes to align the software with their infrastructure. And what’s the end result?

想想传统情况下会发生什么。业务会把需求扔过墙,这是因为他们在“买房”模式下运作,并且说上一句“我们 9 个月后见。”开发人员根据这些需求进行开发,并根据技术约束的需要进行更改。然后,他们把它扔过墙传递给运维人员,并说一句“搞清楚如何运行这个软件”。然后,运维人员勤就会勤奋地进行大量更改,使软件与基础设施保持一致。然而,最终的结果是什么呢?

More often than not, the end result isn’t even recognizable to the business when they see it in its final glory.  We’ve watched this pattern play out time and time again in our industry for the better part of two decades. It’s time for a change.

通常情况下,当业务人员看到需求实现的最终结果时甚至根本辨认不出。在过去 20 年的大部分时间里,我们一次又一次地目睹了这种模式在软件行业中上演。而现在,是时候改变了。

Your operations teams are responsible for the host that will run the containers and the security footprint, and that’s all.

It’s Linux containers that truly crack the problem – because containers close the gap between development and operations. They allow both teams to understand and design to all of the critical requirements, but still uniquely fulfill their team’s responsibilities. Basically, we take out the telephone game between developers and operations. With containers, we can have smaller operations teams, even teams responsible for millions of applications, but development teams that can change software as quickly as needed. (In larger organizations, the desired pace may be faster than humans can respond on the operations side.)

Linux 容器能够真正地解决这样的问题,这是因为容器弥合开发和运维之间的鸿沟。容器技术允许两个团队共同理解和设计所有的关键需求,但仍然独立地履行各自团队的职责。基本上,我们去掉了开发人员和运维人员之间的电话游戏。有了容器技术,我们可以使得运维团队的规模更小,但依旧能够承担起数百万应用程序的运维工作,并且能够使得开发团队可以更加快速地根据需要更改软件。(在较大的组织中,所需的速度可能比运维人员的响应速度更快。)

With containers, you’re separating what is delivered from where it runs. Your operations teams are responsible for the host that will run the containers and the security footprint, and that’s all. What does this mean?


First, it means you can get going on DevOps now, with the team you have. That’s right. Keep teams focused on the expertise they already have: With containers, just teach them the bare minimum of the required integration dependencies.

首先,这意味着你现在可以和团队一起实践 DevOps 了。没错,只需要让团队专注于他们已经拥有的专业知识,而对于容器,只需让团队了解所需集成依赖关系的必要知识即可。

If you try and retrain everyone, no one will be that good at anything. Containers let teams interact, but alongside a strong boundary, built around each team’s strengths. Your devs know what needs to be consumed, but don’t need to know how to make it run at scale. Ops teams know the core infrastructure, but don’t need to know the minutiae of the app. Also, Ops teams can update apps to address new security implications, before you become the next trending data breach story.


Teaching a large IT organization of say 30,000 people both ops and devs skills? It would take you a decade. You don’t have that kind of time.

想要为一个大型 IT 组织,比如 30000 人的团队教授运维和开发技能?那或许需要花费你十年的时间,而你可能并没有那么多时间。

When people talk about “building new, cloud-native apps will get us out of this problem,” think critically. You can build cloud-native apps in 10-person teams, but that doesn’t scale for a Fortune 1000 company. You can’t just build new microservices one by one until you’re somehow not reliant on your existing team: You’ll end up with a siloed organization. It’s an alluring idea, but you can’t count on these apps to redefine your business. I haven’t met a company that could fund parallel development at this scale and succeed. IT budgets are already constrained; doubling or tripling them for an extended period of time just isn’t realistic.

当人们谈论“构建新的云原生应用程序将帮助我们摆脱这个问题”时,请批判性地进行思考。你可以在 10 个人的团队中构建云原生应用程序,但这对《财富》杂志前 1000 强的企业而言或许并不适用。除非你不再需要依赖现有的团队,否则你无法一个接一个地构建新的微服务:你最终将成为一个孤立的组织。这是一个诱人的想法,但你不能指望这些应用程序来重新定义你的业务。我还没见过哪家公司能在如此大规模的并行开发中获得成功。IT 预算已经受到限制;在很长时间内,将预算翻倍甚至三倍是不现实的。

When the remarkable happens: Hello, velocity


Linux containers were made to scale. Once you start to do so, orchestration tools like Kubernetes come into play – because you’ll need to run thousands of containers. Applications won’t consist of just a single container, they will depend on many different pieces, all running on containers, all running as a unit. If they don’t, your apps won’t run well in production.

Linux 容器就是为扩容而生的。一旦你开始这样做, Kubernetes 之类的编制工具就会发挥作用 ,这是因为你将需要运行数千个容器。应用程序将不仅仅由一个容器组成,它们将依赖于许多不同的部分,所有的部分都会作为一个单元运行在容器上。如果不这样做,你的应用程序将无法在生产环境中很好地运行。

People say “How do we change planning to actually take advantage of this ability to experiment?”

Think of how many small gears and levers come together to run your business: The same is true for any application. Developers are responsible for all the pulleys and levers in the application. (You could have an integration nightmare if developers don’t own those pieces.) At the same time, your operations team is responsible for all the pulleys and levers that make up your infrastructure, whether on-premises or in the cloud.  With Kubernetes as an abstraction, your operations team can give the application the fuel it needs to run – without being experts on all those pieces.


Developers get to experiment. The operations team keeps infrastructure secure and reliable. This combination opens up the business to take small risks that lead to innovation. Instead of having to make only a couple of bet-the-farm size bets, real experimentation happens inside the company, incrementally and quickly.


In my experience, this is where the remarkable happens inside organizations: Because people say “How do we change planning to actually take advantage of this ability to experiment?” It forces agile planning.


For example, KeyBank, which uses a DevOps model, containers, and Kubernetes, now deploys code every day. (Watch this video in which John Rzeszotarski, director of Continuous Delivery and Feedback at KeyBank, explains the change.) Similarly, Macquarie Bank uses DevOps and containers to put something in production every day.

举个例子,使用 DevOps 模型、容器和 Kubernetes 的 KeyBank 如今每天都会部署代码。(观看 视频 ,其中主导了 KeyBank 持续交付和反馈的 John Rzeszotarski 将解释这一变化。)类似地,Macquarie 银行也借助 DevOps 和容器技术每天将一些东西投入生产环境。

Once you push software every day, it changes every aspect of how you plan – and accelerates the rate of change to the business. “An idea can get to a customer in a day,” says Luis Uguina, CDO of Macquarie’s banking and financial services group. (See this case study on Red Hat’s work with Macquarie Bank).

一旦你每天都推出软件,它就会改变你计划的每一个方面,并且会 加速业务的变化速度 。Macquarie 银行和金融服务集团的 CDO,Luis Uguina 表示:“创意可以在一天内触达客户。”(参见对 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.

Macquarie 的例子说明了速度的力量。这将如何改变你的经营方式?记住,Macquarie 不是一家初创企业。这是 CIO 们所面临的颠覆性力量,它不仅来自新的市场进入者,也来自老牌同行。

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.

Macquarie 的例子说明了速度的力量。这将如何改变你的经营方式?记住,Macquarie 不是一家初创企业。这是 CIO 们所面临的颠覆性力量,它不仅来自新的市场进入者,也来自老牌同行。

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.

所有这些都说明现在正是打造伟大事业的好时机。考虑到市场创新的速度,你需要不断地创造伟大的东西来保持客户的忠诚度。因此,如果你一直在等待将赌注押在 DevOps 上,那么现在就是正确的时机。容器技术和 Kubernetes 改变了规则,并且对你有利。



lookatthemyt 发布于12:19 上午 - 9月 29, 2019


BTW, if you have time, please visit my blog and if you like the posts, please follow my blog 🙂 #FollowforFollow 🙂


%d 博主赞过: