Over the last few years, the field of information technology has seen a somewhat steep rise in the usage of buzzwords to describe the inner workings of software development and management. This is ironic in light of the rise of low/no-code platforms and other tools that attempt to bridge teams that previously had difficulties communicating/collaborating (think Productboard for PMs and external teams; Zeplin for designers and other stakeholders). Despite the two trends´ opposing tendencies (one aggrandizes the field of software dev, the other democratizes it), there still remains the salient need to connect the various communities. Indeed, a bridge of sorts needs to be built to enable laymen to interact more confidently and fluently with their technical counterparts.

在过去的几年中，信息技术领域使用流行语来描述软件开发和管理的内部工作方式时出现了急剧上升的趋势。 具有讽刺意味的是，鉴于低代码/无代码平台和其他工具的出现，这些工具试图弥补以前沟通/协作困难的团队(为产品经理和外部团队设计Productboard；为设计师和其他利益相关者设计Zeplin)。 尽管有两种趋势相反的趋势(一种趋势强化了软件开发人员的领域，另一种趋势使其民主化了)，但是仍然仍然存在着连接各个社区的迫切需求。 确实，需要建立各种桥梁，以使外行人员可以更自信和流畅地与技术同行进行互动。

For that connection to be built, it is my belief that two things must happen. First, even before they step into the same (virtual) room as their technical peers, non-engineers — call them business and operations owners — need to develop the not necessarily deep background requisite to understand why and how software development practices have emerged in their current form. Second, laypeople must make the effort to learn the language of developers and technical program managers. Empathy cannot be brokered by sitting in an ivory tower and by gandering a sideways look downhill — in fact, one has to come down and engage, which will be for naught if the communication is misaligned, incomprehensible, and dare we say, nonexistent at times for fear of revealing one’s true ignorance.

为了建立这种联系，我相信必须发生两件事。 首先，即使在与技术同行进入同一个(虚拟)房间之前，非工程师(称为业务和运营所有者)也需要开发不一定深刻的背景知识，以了解他们为什么以及如何出现软件开发实践。当前形式。 其次，外行人必须努力学习开发人员和技术项目经理的语言。 坐在象牙塔上并在下坡上弯腰摆姿势不能调解同情心-实际上，人们必须下降并参与进来，如果沟通错位，难以理解且敢于说有时不存在，这将是无济于事的因为害怕透露自己的真正无知。

To that end, I´ve taken a first stab at explaining for non-technical persons a trendy subject matter that has become mainstream: microservices and containers. The goal is to document the rise of microservices; where containers came from; and why managed services that enable the orchestration of containers are so crucial for software development teams.

为此，我首先尝试为非技术人员解释一种趋势主题，该主题已成为主流：微服务和容器。 目的是记录微服务的兴起； 容器来自哪里； 以及为什么支持容器编排的托管服务对软件开发团队如此重要。

Episode I: The Monolithic Menace

第I集：整体威胁

To start, I believe it is important to grasp the evolution of modern software development best practices. Back in the day, in a galaxy far far away, development teams would develop what we call ´monolithic applications´. The name implies that there was one layer to the application — in other words, there was one connecting tissue between the application, data, and infrastructure layer.

首先，我认为掌握现代软件开发最佳实践的发展很重要。 过去，在遥远的星系中，开发团队将开发我们所谓的“整体应用程序”。 该名称意味着应用程序只有一层-换句话说，在应用程序，数据和基础结构层之间存在一层连接组织。

Netflix is the example par excellence to document the rise of microservices as they´ve been transparent on that subject for quite some time. Their applications started off as monolithic (though you´ll see that is no longer the case) as it had its advantages. Monolithic application structure helped their development team focus on business logic. The team used all the same tools, namespaces, and frameworks so there was no need to really spend a lot of time overseeing those investments as they were homogenous. The development team started out as small, which meant that if there were changes to be made they could be done quickly because the application code base was centralized. Maintenance was consequently easy to manage as well since there was only one code base to oversee.

Netflix的例子是出类拔萃记录微服务作为在这个问题上一直they've透明的崛起相当长的一段时间。 他们的应用程序从一开始就具有整体性(尽管您会发现情况不再如此)，因为它具有自己的优势。 整体式应用程序结构帮助他们的开发团队专注于业务逻辑。 团队使用了所有相同的工具，名称空间和框架，因此，由于这些投资是同质的，因此无需花费大量时间来监督这些投资。 开发团队起步时很小，这意味着如果要进行更改，则可以快速完成，因为应用程序代码库是集中的。 因此，维护也很容易管理，因为只有一个代码库可以监督。

But then Netflix started to scale their team, as they had to grow to cope with new product requirements. The following challenges started to take root. As new team members joined, the cognitive load became too much to handle. A new developer that was onboarding would have to understand the entire code base in order to piece exactly where their contribution would fit in. This slowed down developer productivity. Development also slowed down because to sync and update features the entire application codebase had to be updated. This meant that pushing to production would start taking weeks, sometimes months. And if there was a bug, it would take a very long time to find the break point because the entire code base had to be combed through since everything was interconnected.Some parts of the application (for instance, at first the log in page, then eventually the payment service component) had to scale separately than other services. But because the application was monolithic the entire application had to scale out, which meant that infrastructure utilization wasn ́t optimized, and costs ballooned. Netflix essentially became a victim of their own success.

但随后Netflix开始扩大规模，因为他们必须成长以应对新产品的需求。 以下挑战开始生根。 随着新团队成员的加入，认知负担变得难以应付。 刚入职的新开发人员必须了解整个代码库，才能准确划分出他们的贡献所在。这降低了开发人员的生产率。 开发也减慢了速度，因为必须同步更新和更新整个应用程序代码库的功能。 这意味着开始投入生产将需要数周甚至数月的时间。 而且，如果存在错误，由于需要将整个代码库进行梳理，因为所有内容都是相互连接的，因此将需要很长的时间才能找到断点。应用程序的某些部分(例如，首先登录页面，那么最终付款服务部分)必须与其他服务分开扩展。 但是由于应用程序是整体的，因此整个应用程序必须横向扩展，这意味着基础架构利用率没有得到优化，并且成本激增。 Netflix本质上成为了自己成功的受害者。

Enter the microservices revolution. Netflix, much like companies that came face to face against similar challenges, eventually moved away from monolithic design patterns by adopting a services architecture. We´re skipping through the adolescence phase — which was known as ´service oriented´ architecture — but suffice to say that developers started to decouple the functional pieces that constituted these monolithic applications. By doing so, they would focus on the microservices, or in other words, the components of the application that each had a particular role and/or function to fulfill. So in the Uber app, matching to a taxi is a microservice; handling payment information and processing it is another; filling out your profile page is another.

进入微服务革命。 就像许多面对类似挑战的公司一样，Netflix最终通过采用服务架构摆脱了单一的设计模式。 我们正在跳过青春期阶段，即称为“面向服务”的体系结构，但是足以说明开发人员开始将构成这些整体应用程序的功能部件分离。 通过这样做，他们将专注于微服务，或者换句话说，每个应用都有特定的角色和/或功能来实现。 因此，在Uber应用程序中，匹配出租车是一项微服务。 处理付款信息并处理它是另一回事； 填写您的个​​人资料页面是另一回事。

This type of architecture was facilitated by an innovation in software development called containers. Previously, the operations team would maximize the utilization of compute and storage resources thanks to virtualization — a hypervisor would create a guest copy of the underlying host OS. Containers, in contrast, would package only the application and its dependencies (system, libraries, runtime). It is lightweight because it doesn’t carry the full operating system, which means starting it up and down is very fast; there are less resources to boot up and down. Additionally, containers are portable because they do not depend on the underlying hardware — it can run on any environment. Moreover, containers could be built in any language preferred by its author (developer), and because it was portable (deployable in any environment), companies could hire wide ranges of talent as they were not beholden to the underlying platform. Hiring a deeper talent pool capable of writing and deploying code asynchronously was a shifting point in regards to the ability of developers to be more agile and work in a distributed manner (the de facto modus operandi morendi of the post covid world now…)

通过称为容器的软件开发创新来促进这种类型的体系结构。 以前，由于虚拟化，运维团队将最大限度地利用计算和存储资源-虚拟机监控程序将创建基础主机OS的来宾副本。 相反，容器将仅打包应用程序及其依赖项(系统，库，运行时)。 它是轻量级的，因为它没有完整的操作系统，这意味着启动和启动非常快。 上下启动的资源较少。 另外，容器是可移植的，因为它们不依赖底层硬件-它可以在任何环境下运行。 而且，容器可以用其作者(开发人员)喜欢的任何语言来构建，并且由于它是可移植的(可以在任何环境中部署)，所以公司可以雇用各种各样的人才，因为他们不依赖底层平台。 在开发人员变得更加敏捷和以分布式方式工作的能力方面，雇用一个能够异步编写和部署代码的更深层次的人才库是一个转移点(现在，后共创世界的实际运作方式 ……)

What are the benefits of having a microservices based architecture? First, it is now easier to onboard new developers — rather than having them to understand the entire codebase, they can focus on their sliver (the service they will be working on) to begin contributing code immediately. Second, isolating microservices means that their entire lifecycle can be managed separately — you no longer have to coordinate the entire monolithic codebase to push every time you want to update one microservice. On top of that, if one service goes down, it doesn’t take down the entire application. Third, you can scale microservices separately, maximizing the utilization of infra resources without overprovisioning.

拥有基于微服务的架构有什么好处？ 首先，现在让新开发人员更容易上岗-与其让他们了解整个代码库，不如让他们专注于自己的Sliver(他们将要从事的服务)以立即开始编写代码。 其次，隔离微服务意味着可以单独管理它们的整个生命周期-您不再需要协调整个整体式代码库来每次要更新一个微服务时就进行推送。 最重要的是，如果一项服务出现故障，则不会关闭整个应用程序。 第三，您可以分别扩展微服务，从而最大程度地利用基础设施资源，而无需过度配置。

Episode V: I am your father, Kubernetes

第五集：我是你的父亲Kubernetes

But the Cinderella story doesn’t end there — after all, she does forget her glass slipper at some point right before sneaking out at midnight, leading to the traditional Disney story denouement… The same will happen vis à vis our damsel in distress, containers. Just when microservices seems too good to be true, we run into the inherent complexity that follows a steep growth in microservices. One can imagine that as an application gets more complex, with hundreds of features that must all interact with one another, the number of microservices not only explodes, but their communication pathways also seem to multiply exponentially. Take a look at Amazon and Netflix´s microservice mapping — convoluted, no?

但是，灰姑娘的故事并没有就此结束–毕竟，她确实在某个时候忘记了自己的玻璃拖鞋，然后在午夜潜行之前，导致了传统的迪斯尼故事结局……同样的事情也将发生在我们遇险者，装满容器的少女身上。 就在微服务似乎太好了以至于无法实现时，随着微服务的急剧增长，我们遇到了固有的复杂性。 可以想象，随着应用程序变得越来越复杂，具有数百个必须相互交互的功能，微服务的数量不仅会爆炸，而且它们的通信路径也将成倍增加。 看看Amazon和Netflix的微服务映射-复杂，不是吗？

In simplistic terms, the shift to a modern distributed architecture, which we would describe as microservices based, had left enterprises unable to monitor, manage and secure their modular application components in a consistent and reliable manner. Developer teams are left with the challenge of managing and orchestrating the underlying infrastructure of those microservices and the communication between them.

简而言之，向现代分布式体系结构的转变(我们将其描述为基于微服务)使企业无法以一致和可靠的方式监视，管理和保护其模块化应用程序组件。 开发人员团队面临的挑战是管理和协调这些微服务的基础架构以及它们之间的通信。

And thus was born kubernetes, which stems from the Greek κυβερνήτης, or ´helmsman,´ not oddly inappropriate when you think of its underlying purpose. Kubernetes is metaphorically the helmsman on the river Styx, shepherding, managing, guiding the constituents on its boat — the containers. Indeed, Kubernetes oversees the orchestration of containers. Simplified, that means Kubernetes is a set of application programming interfaces that orchestrate your containers on your behalf, so that your infrastructure becomes abstracted. When you install Kubernetes it handles the compute, networking and storage on behalf of user workloads. This allows you to focus on your application, and not worry about the underlying environment. And, let´s not forget, Kubernees is portable, which means if you have containers on one cloud platform you could take it to another — or even on premise.

因此诞生了kubernetes，它源自希腊语κυβερνήτης，即“舵手”，当您想到其基本目的时，这并不奇怪。 Kubernetes隐喻是Styx河上的舵手，负责管理，引导和引导船上的成分-集装箱。 实际上，Kubernetes负责监督容器的编排 。 简化，这意味着Kubernetes是一组应用程序编程接口，可以代表您编排容器，从而使基础架构变得抽象。 当您安装Kubernetes时，它将代表用户工作负载处理计算，网络和存储。 这使您可以专注于应用程序，而不必担心底层环境。 而且，请不要忘记，Kubernees是便携式的，这意味着，如果您在一个云平台上拥有容器，则可以将其带到另一个云平台，甚至可以在内部使用。

That being said, setting up and managing Kubernetes on your own isn´t easy. By far the single biggest obstacle to using k8s is learning how to install and manage your own cluster. While kubernetes will handle the management of underlying infra, you still need to set up kubernetes to launch that action. Kelsey Hightower, a Dev Advocate for Google, wrote up a step by step process on how to set up a K8s (kubernetes in short hand) cluster (the hard way…):

话虽这么说，要自行设置和管理Kubernetes并不容易。 到目前为止，使用k8s的最大障碍是学习如何安装和管理自己的集群。 尽管kubernetes将处理基础设施的管理，但您仍然需要设置kubernetes来启动该操作。 Google的开发代言人Kelsey Hightower逐步制定了有关如何建立K8s(简称Kubernetes)集群的过程(困难的方式……)：

• Choosing a cloud or bare metal provider选择云或裸机提供商
• Provisioning machines供应机器
• Picking an OS and container runtime选择一个操作系统和容器运行时
• Configure networking: IP ranges for pods (for sake of simplicity, think of them as the underlying unit of containers), software defined networks, load balancers配置网络：pod的IP范围(为简单起见，将其视为容器的基础单元)，软件定义的网络，负载平衡器
• Setting up security: generate certs and configure encryption设置安全性：生成证书并配置加密
• Starting up clusters services like domain name server, logging and monitoring启动群集服务，例如域名服务器，日志记录和监视

And once you have all these pieces together, you can finally start to use k8s and deploy your first application. And you’re feeling great and happy because k8s is awesome! But then, you have to roll out an update…

一旦将所有这些部分放在一起，就可以最终开始使用k8并部署您的第一个应用程序。 而且，由于k8s很棒，您会感到既幸福又快乐！ 但是然后，您必须推出更新...

…and you enter the land of “day 2” operations, where you not only need tooling but considerable operational expertise to manage the lifecycle of a k8s cluster. Basically, you run into the following challenges:

…然后进入“第2天”运营的领域，您不仅需要工具，还需要大量的运营专业知识来管理k8s集群的生命周期。 基本上，您会遇到以下挑战：

• Multiple Kubernetes clusters are difficult to manage: your developers end up having to manage the underlying kubernetes clusters, and even if they punt that over to the ops team, the coordination between the two hamstrings productivity. And if you have a small team, it puts even more of a load on your developer team´s productivity since they have to shoulder the responsibility of an invisible ops team.

  多个Kubernetes集群很难管理 ：您的开发人员最终不得不管理底层的kubernetes集群，即使他们将这些资金投入运营团队，这也阻碍了两个生产力的协调。 而且，如果您的团队很小，那么开发人员的生产力将承受更大的负担，因为他们必须承担隐形操作团队的责任。

• Monitoring and troubleshooting Kubernetes is difficult: ´shifting left´in devops language means incorporating testing early and often in your dev cycle. The corollary to that entails instrumenting early so you have visibility sooner on what is breaking, and where it is breaking in your code base. Testing and monitoring at scale is difficult as those are systems that need to be instrumented and managed.

  监视和故障排除Kubernetes是困难的：用devops语言“向左移动”意味着尽早并经常在开发周期中进行测试。 随之而来的必然结果是尽早进行检测，因此您可以更早地了解代码库中发生了什么以及它在哪里破坏了。 大规模测试和监视非常困难，因为这些系统需要进行检测和管理。

• Scaling kubernetes: Versioning multiple clusters is time consuming and difficult, placing an undue burden on the operations team who had to configure that infrastructure in the first place. Indeed, to scale the platform (ie add more clusters or resize the size of each cluster), manually run through configuration scripts need to be executed.

  扩展kubernetes ：对多个集群进行版本控制既耗时又困难，这给必须首先配置该基础架构的运营团队带来了不适当的负担。 实际上，要扩展平台(即添加更多群集或调整每个群集的大小)，需要执行手动运行的配置脚本。

So managed service offerings emerged to address the pain inherent to handling autonomously and manually the orchestration of kubernetes. Microsoft (where I used to work for), released Azure Kubernetes Service; AWS has two offerings (EKS/ECS); and Google (hello paycheck provider) has Google Kubernetes Engine (fun fact Google was the founder of the eponymous open source container platform). We´ll draw a comparison between all three at another time, but suffice to say that these vendors manage kubernetes on your behalf so you can focus on writing code rather than managing setting up virtual machines and configuring your compute and storage options.

因此，托管服务产品应运而生，以解决自动和手动处理kubernetes编排的固有痛苦。 微软(我曾经工作过的地方)发布了Azure Kubernetes服务； AWS有两种产品(EKS / ECS)； Google(您好，薪水提供者)拥有Google Kubernetes Engine(事实证明Google是同名开源容器平台的创始人)。 我们将在另一时间对这三个进行比较，但足以说这些供应商代表您管理kubernetes，因此您可以专注于编写代码，而不是管理设置虚拟机以及配置计算和存储选项。

Episode VI: The Return of Ms. Product Owner?

第六集：产品负责人的归还？

A non-engineer persona (like your esteemed author) needs to understand the origins of microservices and containers as they provide the foundation for modern software development architecture. Processes — including but not limited to agile development, gitops — are corollary subjects, one to explore later, but the matters addressed in the preceding pages remains foundational as it showcases how over time we’ve improved the manner by which teams can build, test, and ship applications. We´ve studied the rise of such architectural patterns to appreciate how far we´ve come, and hopefully along the way we´ve picked up terms that will enable business wonders to speak more confidently the language of technical peers.

非工程师角色(例如您尊敬的作者)需要了解微服务和容器的起源，因为它们为现代软件开发体系结构提供了基础。 流程(包括但不限于敏捷开发，gitops)是必然的主题，稍后将进行探讨，但是前几页中解决的问题仍然是基础，因为它展示了随着时间的推移，我们如何改善团队的构建，测试方式，并提供应用程序。 我们已经研究了这种架构模式的兴起，以了解我们走了多远，并希望我们沿用的术语能够使业务奇迹更自信地讲技术同行的语言。

Remember that microservices and containers are tied inextricably to the requirements of the modern era: speed and agility. Competition in the market has never been fiercer, and will only be exacerbated in time. To stay ahead of competitors, Ms. Product Owner needs to be able to iterate faster than her competition; react even more quickly to critical feedback and errors in order to maintain and protect her brand´s equity; and innovate at a rate that eclipses her competition. Now that she knows how microservices — powered by containers — can help address her goals, she can now collaborate with her technical peers by drawing out a map of her application´s architecture; and contribute ideas on what new features and components can be added while still fitting into the fabric of its constituent microservices. A bridge of sorts has been born from her appreciation for and understanding of her technical counterparts tools and practices.

请记住，微服务和容器与现代的需求密不可分：速度和敏捷性。 市场竞争从未如此激烈，只会随着时间的推移而加剧。 为了保持领先地位，产品负责人女士必须能够比竞争对手更快地迭代； 对重要的反馈和错误做出更快React，以维护和保护她的品牌资产； 并以超越竞争对手的速度进行创新。 现在，她知道由容器支持的微服务如何能够帮助实现其目标，她现在可以通过绘制应用程序体系结构图与技术同行进行协作。 并就可以添加哪些新功能和组件提出建议，同时仍可适应其组成的微服务的结构。 她对同行技术工具和实践的欣赏和理解为她架起了一座桥梁。