关键要点

• 即使没有一个微服务，也有可能实现云原生服务
• 在开始云本机转换之前，必须弄清楚云本机对您的团队意味着什么，以及要解决的真正问题是什么
• 如果发布涉及繁重的仪式、不经常发布，并且如果所有的微服务必须同时发布，那么微服务体系结构的好处就不会实现
• 持续集成和部署是您要做的事情，而不是购买的工具
• 过度的治理扼杀了云计算的速度，但是如果你没有足够的关注正在被消耗的东西，就会有严重的浪费

在去年的伦敦QCon上，我提供了一个关于文化而不是容器的云本地会话。让我开始思考文化在cloud native中的作用的是一篇来自Bilgin Ibryam的InfoQ文章。Bilgin所做的一件事是将云本地架构定义为许多通过智能管道连接的微服务。我看了之后觉得它和我写的应用程序完全不同，尽管我以为我写的是云本地应用程序。我是IBMGarage的一员，帮助客户获得云本地服务，但我很少在我的应用程序中使用微服务。我创建的应用程序大部分看起来不像比尔金的图表。这是不是意味着我做错了，或者云本地的定义有点复杂？

我不想单挑比尔金，因为比尔金的文章被称为“后库伯内特斯时代的微服务”，所以如果他在那篇文章中不经常谈论微服务，那就有点可笑了。同样，几乎所有的云原生定义都将其等同于微服务。我到处都看到这样的假设：微服务等于本地服务，云本地服务等于微服务。甚至云原生计算基金会也曾将云原生定义为所有关于微服务和所有关于容器的内容，其中包含一些动态编排。说cloud native并不总是涉及微服务，这让我处于一个特殊的位置，因为我不仅说Bilgin错了，我还说cloud native计算基金会错了——他们对cloud native了解多少？我肯定我知道的比他们多，对吧？

嗯，显然我不知道。在这件事上我站错了历史的一边。我承认这一点(尽管我站在历史的错误一边，但我注意到CNCF已经更新了他们对cloud native的定义，尽管微服务和容器仍然存在，但它们似乎不像以前那么强制性，所以一点历史可能站在我这边！）。不管是对是错，我还是会死在我的小山上；这种云本地服务比微服务更重要。微服务就是一种方式。他们不是唯一的方法。

事实上，你在我们的社区里看到了一系列的定义。如果你问一群人“云原生”是什么意思，有些人会说“生于云”。这是在微服务成为一种东西之前，云原生的最初定义。有人会说这是微服务。

有些人会说，“哦，不，不仅仅是微服务，而是Kubernetes上的微服务，这就是云原生的方式”。我不喜欢这个，因为对我来说，cloudnative不应该是一个技术选择。有时我会将Cloud native用作DevOps的同义词，因为许多Cloud native原则和实践与DevOps所教授的内容相似。

有时我看到cloudnative被用作“我们正在开发现代软件”的一种说法：“我们将使用最佳实践；它是可以观察到的；它将是健壮的；我们将经常发布并自动化所有内容；简言之，我们将利用过去20年所学的一切，以这种方式开发软件，这就是为什么它是云本地的”。在这个定义中，云只是一个给定的-当然它在云上，因为我们在2021年开发这个。

有时我看到Cloud native只是指云。我们已经习惯于听到云本地的说法，以至于每次我们谈论云时，我们都会觉得必须在后面加上一个'-native'，但我们实际上只是在谈论云。最后，当人们说Cloud native时，有时他们的意思是幂等的。问题是，如果你说Cloud native表示幂等，其他人会问，“什么？我们所说的“幂等”是什么意思？如果我拿走它，关掉它，然后再启动它，没有什么坏处。这是云服务的基本要求。

有了所有这些不同的定义，我们不完全确定在使用Cloud native时要做什么，这有什么奇怪的吗？

为什么？

“我们到底在努力实现什么？”是一个极其重要的问题。当我们在考虑技术选择和技术风格时，我们想从“我在做云计算，因为其他人都在这么做”退后到“我到底在解决什么问题？”公平地说，CNCF在他们对云计算的定义前面有一个“为什么”。他们说，“CloudNative是指使用微服务更快地构建伟大的产品。”；我们使用微服务是因为它们能帮助我们更快地生产出优秀的产品。

这是我们后退一步，以确保我们了解我们正在解决的问题。为什么我们不能更快地生产出优秀的产品呢？跳过这一步很容易，我想我们每个人有时都会为此感到内疚。有时候，我们真正想解决的问题是，其他人都在做，所以我们害怕错过，除非我们开始做。一旦我们这样说，FOMO就不是一个很好的决策标准。更糟糕的是，“我的简历看起来很枯燥”绝对不是选择科技的正确理由。

为什么是云？

我想知道为什么我们应该以云本地的方式做事；我们想退一步说，“我们为什么要在云上做事呢？”原因如下：

• 成本：当我们第一次开始把东西放到云上时，价格是主要的动力。我们说，“我有这个数据中心，我必须支付电费，我必须付钱给维护它的人。我要买所有的硬件。当我可以使用其他人的数据中心时，我为什么要这样做？“在您自己的数据中心和其他人的数据中心之间节省成本的原因是您自己的数据中心必须为最大的需求储备足够的硬件。这可能是大量的容量，大部分时间都没有使用。如果是别人的数据中心，你可以集中资源。当需求量很低时，你就不会为额外的容量买单。
• 弹性：云为你省钱的原因就是因为这种弹性。你可以扩大规模；你可以缩小。当然，这已经是老新闻了。我们都认为弹性是理所当然的。
• 速度：我们现在对云感兴趣的原因是速度。不一定是硬件的速度，尽管有些云硬件可以快得让人眼花缭乱。云是使用gpu的一种很好的方式，它或多或少是使用量子计算机的唯一方式。不过，更普遍地说，我们可以通过云将一些东西推向市场，比我们必须将软件打印到CD-rom上并将其发送给人们，甚至我们必须在自己的数据中心中建立实例时要快得多。

12个因素

成本节约、弹性和交付速度都很好，但我们只需在云上就可以做到这一点。为什么我们需要云本地？我们之所以需要Cloud native，是因为很多公司发现他们试图去云计算，结果被电死了。

事实证明，在云上，事情需要以不同的方式编写和管理。阐明这些差异导致了12个因素。这12个因素是一组关于如何编写云应用程序以避免触电的规定。

你可以说这12个因素描述了如何编写云本地应用程序，但这12个因素与微服务完全无关。他们都是关于你如何管理你的国家。他们是关于你如何管理日志的。这12个因子帮助应用程序变得幂等，但“12个因子”比“幂等因子”更吸引人。

这12个因素是在Docker上市前两年公布的。Docker容器彻底改变了云的使用方式。集装箱很好，很难夸大它们的重要性。他们解决了许多问题，创造了新的建筑可能性。因为容器非常简单，所以可以跨多个容器分发应用程序。一些公司在100、200、300、400或500个不同的容器上运行单个应用程序。与这种工程能力相比，一个仅仅分布在六个容器中的应用程序似乎有点不够。面对如此少的复杂性，人们很容易想到“我一定是做错了。我不是一个好的开发人员，因为他们在那里”。

事实上，不。这不是一个看你能有多少集装箱的竞争。容器是很好的，但是容器的数量应该根据你的需要来调整。

速度

让我们试着记住-你还需要什么？当我们想到云的时候，我们通常会想到它的速度。我们需要大量集装箱的原因是我们想更快地将新产品推向市场。如果我们有很多集装箱，我们要么把完全一样的东西运到市场上，要么以同样的速度运到市场上，那么突然之间，那些集装箱只是一种成本。它们并没有帮助我们，而且我们正在处理将应用程序分散在整个基础设施中所带来的复杂性。如果我们有这样一个惊人的架构，允许我们对市场做出反应，但我们没有反应，那就是浪费。如果我们有这样的架构，那就意味着我们可以走得很快，但我们不能走得很快，那也是一种浪费。

如何在云原生中失败

这让我想到了如何在Cloud native失败。作为背景，我是个顾问。我是IBM车库里的一名全栈开发人员。我们与初创公司和大公司合作，帮助他们进入云计算领域，并从云计算中获得最大收益。作为其中的一部分，我们帮助他们解决有趣、棘手的问题，我们帮助他们比以前更快地完成软件开发。为了确保我们真正从云计算中获得最大的收益，我们做了一个精益启动，极限编程，设计思维，DevOps；和云本机。因为我是一名顾问，我看到很多客户都在云端之旅中。有时进展顺利，有时也有这些陷阱。以下是我见过的一些聪明客户陷入的陷阱。那么，什么是云本地的呢？

最早的陷阱之一是魔法变形的含义。如果我说的是Cloud native，我指的是一件事，而你说的是Cloud native，我指的是另一件事，我们的沟通会有问题。。。

有时这并不重要，但有时会有很大的不同。如果一个人认为目标是微服务，而另一个人觉得目标是拥有一个幂等系统，哦。或者，如果一个组织的一部分人想进入云计算，因为他们认为这将使他们更快地进入市场，但另一部分人进入云计算只是为了提供与以前完全相同的速度，但更具成本效益，那么我们可能会有一些冲突。

微服务嫉妒

通常，导致人们对目标产生某些困惑的原因之一是，我们有一种自然的倾向，那就是看别人，做奇妙的事情，并想模仿他们。我们想自己去做那些奇妙的事情，而不去考虑我们的环境以及它们是否适合我们。我们IBM的一个同事在和客户谈论微服务时有一个启发。他说，“如果他们开始谈论Netflix，他们只是一直在谈论Netflix，他们从来没有提到一致性，他们从来没有提到耦合，那么他们这样做可能不是出于正确的原因。”

有时我们和客户交谈，他们会说，“好吧，我想让微服务现代化。”好吧，微服务不是我们的目标。没有客户会在你的网站上说，“哦，微服务。顾客会看你的网站，判断它是否满足他们的需求，是否简单愉快，以及其他所有这些。微服务可能是达到这一目的的一个很好的手段，但它们本身并不是一个目标。我还应该说：微服务是一种手段。它们不一定是实现这一目标的唯一手段。

我在IBM车库的一位同事与亚太地区的一家银行进行了一些交谈。这家银行在回应客户时遇到了问题，因为他们的软件都是陈旧的、笨重的、陈旧的。他们还有一个人员问题，因为他们所有的COBOL开发人员都年迈，离开了工作岗位。所以银行知道他们必须现代化。在这种情况下，主要的驱动力不是老龄化的劳动力，而是竞争力和灵活性。他们被竞争对手打败了，因为他们有大量的COBOL代码，而且每次修改都是昂贵而缓慢的。他们说，“好吧，要解决这个问题，我们需要摆脱所有的COBOL，我们需要切换到一个现代的微服务架构。”

到目前为止，还不错。我们正准备加入一些云计算，当时银行补充说他们的发布委员会每年只开两次会。在这一点上，我们回过头来。银行闪亮的新架构将拥有多少微服务并不重要；这些微服务都将被组装成一个巨大的整体发布包，并每年部署两次。这就占用了微服务的开销而没有好处。因为这不是一个看你有多少个容器的竞争，很多容器和缓慢的释放将是一堆绝对没有人赢。

许多微服务被锁定在缓慢的发布节奏中，这不仅不是一场胜利，也可能是一场惨败。当组织尝试微服务时，他们并不总是像图中那样以一个漂亮的解耦微服务架构结束。相反，它们最终会形成一个分布式的整体。这就像一块普通的巨石，但更糟。这种情况之所以特别糟糕，是因为正常的、非分布式的monolith具有编译时类型检查和同步的、有保证的内部通信等功能。在单个进程中运行会损害您的可伸缩性，但这意味着您不能被分布式计算的谬误所困扰。如果你使用同一个应用程序，然后只在互联网上涂抹它，不进行任何类型检查或投资于网络问题的错误处理，你就不会有更好的客户体验；你的客户体验会更糟。

在很多情况下，微服务是错误的答案。如果你是一个小团队，你不需要有很多独立的团队，因为每个独立的团队大约有四分之一的人。假设您没有任何独立发布部分应用程序的计划或愿望，那么您将不会从microservices的独立性中获益。

为了在应用程序的所有这些组件之间提供安全可靠的通信和可发现性，您需要一个服务网格之类的东西。你可能在技术曲线上非常先进，或者对技术曲线有点陌生。你要么不知道什么是服务网格，要么说，“我知道什么是服务网格。太复杂，太夸张了。我不需要服务网。我只打算用我自己的服务网来代替，“这不一定会给你你所希望的结果。您最终仍然会得到一个服务网格，但您必须维护它，因为它是您编写的！

不做微服务的另一个很好的理由是，有时域模型没有那些自然的断开点，这些断开点允许您获得漂亮整洁的微服务。在这种情况下，说“你知道吗？我就不干了。”

云原生意大利面

如果你不离开这个blob，那么你就会遇到下一个问题，那就是Cloud原生的意大利面。当我看Netflix微服务的通讯图时，我总是感到有点惊慌失措。我相信他们知道自己在做什么，他们已经弄明白了，但在我看来，它看起来完全像意大利面。做这项工作需要很多真正扎实的工程和专业技能。如果你没有这方面的专业知识，那么你最终会陷入一个混乱的局面。

我是来和一个挣扎的客户救火的。他们正在开发一个新的应用程序，所以他们当然选择了微服务，尽可能的现代化。他们对我说的第一句话是“任何时候我们改变任何代码，其他的东西就会中断。”这不是微服务应该发生的事情。事实上，这与我们都被告知的如果我们实现微服务会发生什么完全相反。微服务的梦想是它们是解耦的。可悲的是，脱钩并不是免费的。它当然不会仅仅因为你分发了东西就神奇地发生。当你分发东西的时候，你只会遇到两个问题而不是一个。

云原生的意大利面还是意大利面。

我的客户机代码如此脆弱且相互关联的原因之一是，它们有相当复杂的对象模型，其中一些类中有大约20个类和70个字段。在微服务系统中处理这种复杂的对象模型是很困难的。在本例中，他们查看了他们的复杂对象模型，然后决定，“我们知道在我们的微服务之间有公共代码是非常糟糕的，因为这样我们就没有解耦。相反，我们将在所有六个微服务中复制并粘贴这个公共对象模型。因为我们剪切粘贴它而不是链接到它，所以我们是解耦的。如果某件事发生变化时，某件事发生了变化，那么无论代码是链接的还是复制的，都存在耦合。

在这种情况下，什么是“正确”的做法？在理想情况下，每一个微服务都整齐地映射到一个域，而且它们是完全不同的。如果你有一个大的域和很多小的微服务，那就有问题了。解决方案是要么确定域确实很大并合并微服务，要么进行更深层次的域建模，尝试将对象模型分解为不同的有界上下文。

即使是最干净的域分离，在任何系统中，组件之间总会有一些接触点——这就是它成为一个系统的原因。这些接触点很容易出错，即使它们很小，尤其是如果它们是隐藏的。你还记得火星气候轨道器吗？与“坚忍不拔”不同的是，它的设计目的是从安全距离环绕火星运行，而不是在火星上着陆。不幸的是，它离火星太近，被火星的引力吸引，坠毁了。失去探测器是可悲的，而其根本原因是悲剧性的。轨道器由两个模块控制，一个在探测器上，另一个在地球上。探测器舱是半自主的，因为大部分时间从地球上看不到轨道器。大约每三天行星就会排列一次，它就会出现在人们的视野中，地球上的研究小组会对其轨道进行微调。我想指令大概是“哦，我想你需要向左移动一点，如果你不向右移动一点，你会错过火星的”，除了数字。

这些数字导致了这个问题。地球舱和探测器舱是由两个不同的小组建造的两个不同的系统。探测器使用英制单位，喷气推进实验室地面小组使用公制单位。尽管这两个系统看起来是独立的，但它们之间有一个非常重要的耦合点。地面小组每次传达指令时，他们所传达的信息都会以一种无人预料的方式被解读。

这个故事的寓意是，分发系统没有帮助。这个系统的一部分在火星上，另一部分在地球上，你再也找不到比这个更分散的了。

微服务需要消费者驱动的合约测试

在这种情况下，解决方案，正确的做法是真正明确耦合点是什么，以及各方的期望是什么。一个很好的方法是消费者契约驱动的测试。合同测试在我们的行业中还没有得到广泛的应用，尽管它是解决一个大问题的一个干净的解决方案。我认为问题的一部分是，他们可能有点棘手的学习，这已经减缓了采用。关于测试的跨团队协商也可能很复杂——尽管如果关于测试的协商太难，那么关于实际交互参数的协商将更加困难。如果您正在考虑探索契约测试，Spring契约或Pact是一个很好的起点。哪一个适合你取决于你的背景。springcontract很好地集成到了Spring生态系统中，而Pact是框架无关的，支持多种语言，包括Java和Javascript。

契约测试远远超出了OpenAPI验证的功能，因为它检查api的语义，而不仅仅是语法。这是一个比“好吧，两边的字段都有相同的名称，所以我们很好”更有用的检查，它允许你检查，“当我得到这些输入时，我的行为是预期的行为吗？我所说的关于那个API的假设仍然有效吗？“这些是你需要检查的东西，因为如果它们不是真的，事情会变得非常糟糕。

许多公司意识到了这种风险，并且意识到当他们在做微服务时，系统存在不稳定。为了确信这些东西能够协同工作，它们在发布它们之前会强制执行一个UAT阶段。在发布任何微服务之前，有人需要花几个星期的时间测试它在更广泛的系统中是否正常工作。有了这样的开销，释放就不会经常发生了。这就引出了经典的反模式，它实际上不是持续集成和持续部署，也不是I/D。

为什么不支持持续集成和部署

我和很多客户交谈，他们会说，“我们有一个CI/CD。”a会敲响警钟，因为CI/CD不应该是你买的、放在服务器上、欣赏的工具，说“有CI/CD。”CD/CD是你必须要做的事情。这些字母代表持续整合和持续部署或交付。Continuous在这个上下文中的意思是“经常集成”和“经常部署”，如果您不这样做，那么它就是不连续的。

有时我会无意中听到这样的评论：“我将在下周将我的分支合并到我们的CI系统中”。这完全忽略了“CI”中“C”的意思，它代表着连续性。如果你每周合并一次，那是不连续的。这几乎与连续相反。

“D”部分可能更像是一场斗争。如果每六个月才部署一次软件，那么CI/CD服务器可能很有用，但是没有人做CD。可能有“D”，但每个人都忘记了“C”部分。

到底多久才有理由去主打？连续性必须是多连续？甚至我也承认，对连续性的一些严格定义是在团队中编写软件的一种荒谬的方法。如果你把每个角色都推到了主角色，那在技术上是连续的，但这会导致团队的混乱。如果你把每一个承诺都整合起来，并且目标是一小时做几次，那可能是一个相当好的节奏。如果你经常提交并整合每几次提交，你每天都要推几次，所以这也很好。如果您正在进行测试驱动开发，那么在获得一个通过的测试时集成是一个很好的模式。我是一个大倡导者，以主干为基础的发展。TBD在调试、支持机会主义重构以及避免同事们的大意外方面有许多好处。基于主干的开发的技术定义是，您需要每天至少集成一次以计数。我有时听到“一天一次”被描述为“ok”和“只是不连续”之间的酒吧。一周一次真的是问题重重。

你每个月都要进一次，真是太可怕了。当我加入IBM时，我们使用了一个构建系统和一个名为CMVC的代码存储库。就上下文而言，这是大约二十年前的事，我们整个行业都年轻，更愚蠢。我在IBM的第一个工作是帮助构建WebSphereApplicationServer。我们有一个大型的多站点构建，团队每周开会六天，包括星期六，讨论任何构建失败。这个调用有很多关注点，您不希望在WebSphereBuild调用上调用。我刚离开大学，对一个团队的软件开发一无所知，所以一些高级开发人员把我放在他们的翅膀下。我仍然记得的一条建议是，避免在WebSphereBuild调用中的方法是将所有更改保存在本地计算机上六个月，然后将它们全部推到一个批中。

在这个项目上，我还很小，我想，好吧，这似乎不是一个正确的建议，但我想你知道得最好。事后，我意识到WebSphereBuild的崩溃很严重，因为人们在尝试与同事集成之前已经保存了六个月的更改。显然，这没用，我们改变了我们的做事方式。

你应该多久整合一次？

下一个更难的问题是，你应该多久发布一次？就像集成一样，有一系列合理的选择。你可以释放每一个推力。很多科技公司都这么做。如果您在一次迭代中部署一次，那么您仍然处于良好的公司中。一刻一刻都有点难过。你可以每两年发布一次。它现在看起来慢得离谱，但在过去糟糕的日子里，这是我们行业的标准模式

您应该多久部署一次生产？

使部署到生产中的每一个推送都成为可能的原因是部署和发布并不相同。如果我们的新代码太不完整或太吓人，无法实际向用户显示，我们仍然可以部署它，但要将它隐藏起来。我们可以将代码实际放在产品代码库中，但没有任何关联。那很安全。如果我们已经有点太纠结了，我们可以使用特性标志来打开和关闭函数。如果我们觉得更冒险，我们可以做A/B或朋友和家人测试，这样只有一小部分用户看到我们可怕的代码。金丝雀部署是另一个变种预先检测噩梦，在他们击中主流使用。

不释放有两个坏的后果。它延长了反馈周期，这会影响决策，让工程师感到悲伤。从经济上讲，这也意味着有库存（工作软件）摆在货架上，而不是拿出来给客户。精益原则告诉我们，库存闲置，不产生回报，是浪费。

接下来的对话是，为什么我们不能发布这个？什么阻止了更频繁的部署？许多组织害怕他们的微服务，他们想对整个组件进行集成测试，通常是手动集成测试。一位拥有大约60个微服务的客户希望确保，工程师的某些闪光点不可能在不发布其他59个微服务的情况下发布一个微服务。为了实现这一点，他们在一个大批量中为所有的微服务提供了一条管道。这显然不是微服务的价值主张，即它们是可独立部署的。可悲的是，他们觉得这样做最安全。

我们还看到，由于对质量和完整性的担忧，实际上不愿意交付。当然，这些并不可笑。你不想激怒你的顾客。另一方面，正如里德·霍夫曼所说，如果你不为你的第一次发布感到尴尬，那就太晚了。持续改进是有价值的，让事物得到利用也是有价值的。

如果发布不频繁，而且是单一的，那么你就有了这些漂亮的微服务架构，可以让你走得更快，但你走得真的很慢。这是糟糕的生意，也是糟糕的工程。

假设你经常部署。所有保护用户不受半生不熟特性影响的东西，比如自动测试、特性标志、A/B测试、SRE，都需要大量的自动化。通常，当我开始与客户合作时，我们会遇到一个关于测试的问题，他们会说，“哦，我们的测试不是自动化的。”这意味着他们实际上不知道代码是否在任何特定点工作。他们希望它能工作，而且上次检查时它可能已经工作了，但是如果不运行手动测试，我们无法知道它现在是否工作。

问题是，倒退发生了。即使所有的工程师都是最完美的工程师，但外面的世界却不那么完美。他们依赖的系统可能会异常地运行。如果依赖项更新改变了行为，即使没有人做错了什么，也会有一些事情发生破坏。这让我们回到“我们不能发货，因为我们对质量没有信心”。好吧，让我们确定质量的信心，然后我们就可以发货了。

我谈过合同测试。这是便宜和简单的，可以在单元测试级别完成，但是当然，您也需要自动化集成测试。您不希望依赖手动集成测试，否则它们将成为瓶颈。

“CI/CD”似乎已经取代了我们词汇表中的“构建”，但在这两种情况下，它是作为一个工程组织所拥有的最有价值的东西之一。它应该是你的朋友，应该是无处不在的存在。有时候，构建的工作方式是它在Jenkins系统的某个地方运行。有人有点勤奋，不时地去检查网页，发现网页是红色的，然后去告诉同事，最后有人解决了这个问题。更好的是，只是一个被动的构建指标，每个人都可以看到，而不打开一个单独的页面。如果显示器变红了，很明显，有些东西发生了变化，而且很容易看到最近的变化。如果你有一个项目，交通灯就可以工作。如果你有微服务，你可能需要一些像瓷砖一样的东西。即使你没有微服务，你可能会有几个项目，所以你需要比交通灯更完整的东西，即使交通灯很可爱。

“我们不知道什么时候构键坏了”

如果您投资于构建监控，那么您最终会遇到窗口中断的情况。我已经找到了客户，我做的第一件事就是查看了构建，然后我说，“哦，这个构建好像坏了。”他们说，“是的，已经坏了几个星期了。”那时，我知道我有很多工作要做！

为什么烫发坏了？这意味着你不能做自动化集成测试，因为没有什么东西能使它脱离构建。事实上，您甚至不能进行手动集成测试，因此服务间的兼容性可能会恶化，而且没有人会知道。

新的回归不会被发现，因为构建已经是红色的。也许最糟糕的是，它创造了一种文化，这样当其他构建之一变红时，人们就不会那么担心了，因为它更像是：“现在我们有两个红色的。也许我们可以得到整套，然后如果我们把它们都弄红的话，它们就匹配了。

被锁住的完全僵硬的，不灵活的，不云的云

这些都是发生在团队层面的挑战。它们是关于我们作为工程师如何管理我们自己和我们的代码。但是，当然，特别是当你进入一个具有一定规模的组织时，你最终会遇到另一系列的挑战，这就是组织对云所做的。我注意到一些组织喜欢把云变成一个封闭的、完全僵硬的、灵活的、不阴云的云。

你如何使云不阴云密布？你说，“嗯，我知道你可以走得很快，我知道你所有的自动化支持都走得很快，但我们有一个过程。我们有一个架构审查委员会，它很少开会，“它将在项目准备好交付后一个月开会，或者在最坏的情况下，它将在项目交付后一个月开会。即使这东西已经运出去了，我们也要走一趟。该体系结构将在经过实地验证后在纸上进行审查，这是愚蠢的。

有人给我讲过一个故事。一位客户向他们投诉说，IBM卖给他们的一些供应软件不起作用。所发生的事情是，我们承诺，我们漂亮的资源调配软件将允许他们在10分钟内创建虚拟机。这是几年前的事了，那时“十分钟内的虚拟机”是先进而酷的。我们向他们保证会很棒的。

当客户安装并开始使用它时，他们并不觉得它很好。他们本以为可以获得10分钟的资源调配时间，但他们看到的是，他们花了3个月的时间来调配一个云实例。他们回来对我们说，“你的软件完全坏了。你把它卖错了。看，这要花三个月的时间。”我们对此感到困惑，所以我们进去做了一些调查。事实证明，他们已经实施了84步的预批准流程，以获得其中一个实例。

 

“此配置软件已损坏”

技术在那里，但是文化不在那里，所以技术不起作用。这太可悲了。我们拿这个云来说，它是一个美丽的云，它有所有这些奇妙的属性，它让一切变得非常简单，然后组织的另一部分说，“哦，这有点可怕。我们不希望人们真的能做事。我们把它关在笼子里吧！”那种旧式的繁文缛节式的治理是行不通的——而且对每个人来说都很烦人。它不会给出结果。更糟糕的是，这并不能让事情变得更安全。这可能会让他们更不安全。这肯定会让事情变得更慢、更费钱。我们不应该这么做。

我和另一个客户，一家大型汽车公司谈过，他们的云资源调配确实有问题。获取实例需要很长时间。他们认为，“我们要解决这个问题的方法是从供应商A转移到供应商B。”这可能是可行的，只是他们的内部采购实际上很慢。转换供应商将绕过其已建立的采购流程，因此可能会在一段时间内加快速度，但最终，他们的治理团队会注意到新供应商，并实施控制。一旦发生了这种情况，他们就会实施监管，恢复现状。他们本可以承担所有的改变成本，但实际上却没有任何好处。这有点像-我很抱歉地说，我有时很想这样做-如果你看着你的炉子，你决定，“哦，那炉子很脏。打扫会很困难，所以我要搬家，这样我就不用打扫烤箱了。”但是，当然，同样的事情也会发生在另一所房子里，新的烤箱也会变脏。你需要一个更可持续的过程，而不仅仅是更换供应商，以试图超过自己的采购。

如果只有开发人员在改变，如果只有开发人员在使用云计算，那么它就行不通了。这并不意味着一个开发者驱动的免费模式是正确的。如果没有一些治理围绕着它，那么云可以成为一个神秘的钱坑。我们中的许多人都有这样的问题：看着一张云账单，心里想着“嗯，是的，那么大，我不知道这是怎么回事，也不知道是谁在做。”

用云提供硬件是如此容易，但这并不意味着硬件是免费的。还得有人付钱。容易配置的硬件也不能保证硬件是有用的。

当我第一次学习Kubernetes的时候，我当然试过了。我创建了一个集群，但后来我被跟踪了，因为我有太多的工作在进行中。两个月后，我回到我的集群，发现这个集群£一个月1000英镑…而且完全没有价值。那太浪费了，我想起来还是畏缩。

我们的技术允许我们做的很多事情就是让事情更有效率。伟大的管理顾问彼得德鲁克（peterdrucker）说：“没有什么比高效地做那些根本不应该做的事情更无用的了。”高效地创建没有价值的Kubernetes集群是不好的。除了价格昂贵，还有生态影响。有一个库伯内特斯群£价值1000英镑的电能什么都不做对地球不是很好。

对于我描述的许多问题，一开始看起来像是技术问题，实际上是人的问题。我觉得这个有点不同，因为这个看起来像是人的问题，实际上是技术问题。这是一个工具实际上可以提供帮助的领域。例如，工具可以通过检测未使用的服务器并帮助我们将服务器追溯到发起人来帮助我们管理浪费。目前还没有实现这一点的工具，但它正变得越来越成熟。

云来管理你的云

这个云管理工具最终在云上，因此您最终处于递归状态，需要一些云来管理您的云。我的公司有一个多云管理器，它可以查看您的工作负载，计算出工作负载的形状，以及您可以在财务上拥有它的最佳提供商，然后自动进行移动。我想我们可能会看到越来越多这样的软件，它看着它说，“顺便说一句，我可以告诉你，实际上已经有两个月没有流量到他的Kubernetes集群了。你为什么不和霍莉说几句话呢？”

微服务运维混乱

管理云成本变得越来越复杂，这反映了一个更普遍的情况，即云操作越来越复杂。我们正在使用越来越多的云提供商。越来越多的云实例如雨后春笋般涌现。我们到处都有星团，那我们到底该怎么做呢？这就是SRE（站点可靠性工程）的用武之地。

站点可靠性工程旨在使操作更具可重复性和更少的繁琐，以使服务更可靠。它实现这一点的方法之一是将一切自动化，我认为这是一个令人钦佩的目标。我们越是自动化发布之类的事情，我们就越能做到这一点，这对工程师和消费者都有好处。最终的目标应该是释放不是一个事件；一切照旧。

使发布变得非常枯燥。

我们对可恢复性充满信心，而正是SRE给了我们对可恢复性的信心。

我有另一个悲惨的太空故事，这次来自苏联。上世纪80年代，一位工程师想对苏联名为“火卫一”的太空探测器的代码进行更新。当时，是机器代码，都是0和1，都是手写的。很明显，你不想在没有检查的情况下，用手写的机器代码对环绕地球飞行的航天器进行实时更新。在任何推送之前，代码将通过一个验证器，这相当于机器代码的一个linter。

这很有效，直到自动检查器被破坏，需要进行更改。一位工程师说：“哦，但我真的很想做这个改变。我将绕过自动检查，直接把我的代码推送到太空探测器上，因为，当然，我的代码是完美的。”于是他们用手写的机器代码，在没有检查的情况下，对环绕地球飞行的航天器进行了实时更新。可能会出什么问题？

所发生的是一个非常微妙的错误。事情似乎进展顺利。不幸的是，工程师忘记了其中一条指令上的一个零。这将指令从预期指令更改为停止探针充电鳍旋转的指令。火卫一的鳍朝向太阳，这样它就可以收集太阳能，不管它面对的是什么方向。在电池没电之前的两天里，一切正常。一旦探测器没电了，他们就无能为力，因为整个探测器都死了。

这是一个完全不可恢复的系统的例子。一旦它死了，你就再也拿不回来了。你不能只是做些什么然后把它恢复到一个干净的太空探测代码的副本中，因为它在太空中。

像这样的系统是不可恢复的。我们中的许多人相信，我们所有的系统几乎都像太空探测器一样不可恢复，但事实上，很少有系统是可恢复的。

我们真正想要的是在这个频谱的顶端，在那里我们可以在毫秒内返回，没有数据丢失。如果出了什么问题，就说“平，修好了”。这真的很难达到，但有一大堆中间点是现实的目标。

如果我们恢复得很快，但数据丢失了，那就不太好了，但我们可以接受。如果我们有交接和人工干预，那么对经济复苏来说会慢得多。当我们考虑频繁地部署并且非常无聊地部署时，我们希望确信我们已经达到了上限。我们到达那里的方式，切换不好，自动化，好。

 

云计算的成功之道

这篇文章包含了一大堆关于我所看到的可能出错的悲惨故事。我不想给你留下这样的印象：每件事都会出问题，因为很多时候，事情确实进展得很好。CloudNative是开发软件的一种很好的方式，它可以让团队感觉更好，降低成本，让用户更快乐。作为工程师，我们可以花更少的时间在工作上，花更多的时间在我们真正想做的事情上……而且我们可以更快地进入市场。

为了达到这种快乐的状态，我们必须在整个组织中保持一致。我们不能让一个小组说“微服务”，一个小组说“快速”，一个小组说“旧式治理”。这几乎肯定行不通，会有很多脾气暴躁的工程师和愤愤不平的财务官员。相反，一个组织应该在一个整体的层面上同意它试图实现的目标。一旦这个目标达成一致，它应该优化反馈，确保反馈循环尽可能短，因为这是合理的工程。

关于作者

霍莉·康明斯是IBM公司战略的创新领导者，曾在IBM车库担任过几年顾问。作为车库的一部分，她为各个行业的客户提供技术创新，从银行到餐饮，从零售到非政府组织。Holly是Oracle Java冠军、IBM Q大使和JavaOne摇滚明星。她与人合著了曼宁的《行动中的企业OSGi》。

 

原文：https://www.infoq.com/articles/cloud-native-culture

本文：http://jiagoushi.pro/node/1506

讨论：请加入知识星球【首席架构师圈】或者小号【cea_csa_cto】或者QQ【2808908662】