“复杂性是致命的，”Lotus Notes 的创建者和微软资深人士 Ray Ozzie在 2005 年的一份内部备忘录中写道。“它让开发人员的生活枯竭；它使产品难以计划、构建和测试；它带来了安全挑战；这会导致用户和管理员感到沮丧。”
如果 Ozzie 认为当时事情很复杂，您不禁会想知道他会如何看待软件开发人员在云原生时代面临的复杂性。
从在您可以触摸的服务器上托管的单体架构中构建应用程序，到将它们分解为多个微服务、打包成容器、与Kubernetes协调并托管在分布式云环境中的转变，标志着在我们软件的复杂程度。再加上对功能丰富的消费级体验的期望，这些体验在设计上是安全且有弹性的，而且从未对开发人员提出过更多要求。
亚马逊首席技术官 Werner Vogels在 2019 年 AWS 峰会期间表示：“当您转向如此普遍的微服务环境时，复杂性会明显增加。” “在一切都在一个整体中的日子里会更容易吗？是的，对于某些部分肯定是这样。”
或者，正如他的同事、AWS 的 DevOps 产品营销主管Emily Freeman在 2021 年所说的那样，现代软件开发是“一项关于熵的研究，它并没有变得更简单。”
另一方面，复杂的技术从未如此简单地使用现成的，通常是通过一个 API——从基本的库和框架到图像识别功能，甚至整个支付堆栈。只需在上面组装和构建您的业务逻辑。但真的有那么简单吗？
“成为一名软件开发人员从未像今天这样困难，”沃尔特迪斯尼公司顾问兼企业技术战略前总监奈杰尔辛普森说。“虽然我们已经看到功能的升级，使开发人员能够通过使用高级框架进行应用程序开发和机器学习来做更多事情，但这需要付出代价。选择的爆炸式增长和开发速度使开发人员很难跟上时代精神，许多开发人员都陷入了困境。”
基本复杂性与偶然复杂性软件机构 Simple Thread 的联合创始人 Justin Etheredge 有助于区分基本复杂性和偶然性复杂性。他告诉 InfoWorld，“本质上是你所工作的业务领域的复杂性，事实上，企业是极其复杂的环境，所以他们试图解决的问题本质上是复杂的。另一个区域是偶然的；这就是我们的工具带来的复杂性，也是我们在解决问题时最重要的一层。”
云原生时代迎来了比以往任何时候都更加意外的复杂性的可能性，这在希望利用他们可用的完整工具包的开发人员和希望他们专注于为客户提供价值的老板之间形成了冲突.
“鉴于当今对软件开发人员的需求，公司没有能力推动开发人员建立一种主要为客户提供价值的思维模型，”Etheridge 说。“让更多工程师这样思考是一个挑战。”
选择的缺点云计算和开源软件运动的共同流行已经见证了可供开发人员构建和运行更具可扩展性、弹性、模块化和可更新性的应用程序的可用选项数量以不可阻挡的速度增加。
“以前一切都简单得多，不是因为我们作为一个行业犯了错误，而是因为这些系统的需求急剧增长，我们必须加快发货速度，”帮助公司的初创公司 Humanitec 的创始人 Kaspar von Grünberg 说。在接受 InfoWorld 采访时建立自己的开发者平台。
云原生计算基金会 (CNCF) 维护了一个交互式图形，其中包含构成云原生生态系统的近 1,000 种独特服务，其中许多是免费且开源的。此外，三大云提供商——亚马逊网络服务、微软 Azure 和谷歌云——都为客户提供大约 200 种独特的服务，涵盖计算、存储、数据库、分析、网络、移动、开发人员工具、管理工具、物联网、安全和企业应用程序。
“在这一点上，应用程序开发过程过于分散；每个企业架构都是三层的，每个数据库都是关系型的，每个业务应用程序都是用 Java 编写并部署到应用程序服务器的时代已经结束，”RedMonk 分析师 Stephen O'Grady 在 2020 年的一篇博客文章中写道。“当今基础设施的一个最具决定性的特征是没有单一的决定性特征。它是多种多样的。”
或者，正如前 Tumblr 首席技术官 Marco Arment 在 2015 年回写的那样，“由于大多数现代网络中涉及的工具数量（及其快速变化），网络开发从未像今天这样复杂或复杂。开发环境。”
云供应商在产品开发中采用的久经考验的方法（小型、独立、两个比萨饼团队构建服务以响应客户需求）的后果之一是，开发人员在很大程度上有权选择如何组合这么多以提供业务价值的方式将构建块组合在一起。
金融服务公司 Two Sigma 平台工程负责人 Camille Fournier 在接受 InfoWorld 采访时说：“你就像一个在云端糖果店里的孩子。” “但随着你的成长并试图将事情整合在一起，复杂性绝对会成倍增加。”
这导致许多人质疑这种选择水平对普通软件开发人员来说是否是积极的。或者，正如O'Grady 在 2020 年的那篇博文中总结的那样，“在某些情况下，庞大的可用服务目录所固有的复杂性可能会变成一种力量而不是一种负担。”
让我们建立一个内部平台这种日益增长的复杂性导致许多组织采用中央平台模型，其中内部平台团队的任务是审查工程师最需要的工具、构建模板并绘制黄金路径以简化他们的生产之旅，同时集中功能例如财务运营、安全和治理，以减轻个体开发人员的认知负担。
以音乐流媒体巨头 Spotify 为例。Spotify 产品经理 Gary Niemen在 2020 年的一篇博文中写道： “回溯六年左右，Spotify 曾经（现在仍然）致力于打造具有自治团队的敏捷工程文化。” “在带来所有优势的同时，它也带来了复杂性，包括一个支离破碎的开发者工具生态系统，其中唯一的方法就是询问你的同事。”
随着 Spotify 的扩展，它发现推动其快速增长的方法实际上开始放慢它的速度。它需要整合和简化。“祝福或推荐的工具应该很容易被发现。使用该工具的过程应该很清楚。在此过程中应该有高质量的用户说明。而且，如果用户遇到困难，从哪里获得支持应该很明显，”尼门写道。
Humanitec 的 von Grünberg 写道，一个良好的内部开发人员平台的关键是在想要继续手头工作的开发人员的自助服务和抽象最不有价值的任务之间找到平衡，同时又不会让开发人员感到受到限制。2021 年的博客文章。
“拥有黄金路径背后的想法不是限制或扼杀工程师，也不是为此设定标准。有了黄金路径，团队就不必重新发明轮子，做出更少的决定，并且可以利用他们的生产力和创造力来实现更高的目标。他们可以重新开始快速行动，”Spotify 产品经理 Niemen写道。
问题是，“开发人员喜欢重新发明轮子。没有什么比建造更好的捕鼠器更让我满意的了，”顾问辛普森说。但在 Stack Overflow 上有很多答案的世界里，这是对开发人员时间的最佳利用吗？
微软开发人员产品部 CVP Amanda Silver 表示：“总会有一些组织试图压制，而另一些组织则试图赋予开发人员权力。核心是开发人员速度的概念。我们可以构建系统，让开发人员可以编写只有他们才能编写的代码，并且不会分心或负担学习对他们来说没有差异的领域。”
旅游科技公司 Amadeus 成立于 1987 年，经历了这些技术变革的浪潮，在大型机上构建了原始应用程序，在 2000 年代初转向在开放式 Linux 平台上构建，现在非常倾向于精心编排的容器化应用程序与 Kubernetes。
“我们的开发人员需要能够在我们提供的核心之上进行开发，因此我们的想法是一种平台方法，我们为他们提供功能，”Amadeus 基础设施和云主管 Edouard Hubin 告诉 InfoWorld。“新技术为安全性和稳定性带来了更多复杂性。当您打开这样的系统时，您需要稳定性。数据驱动应用程序的兴起对我们来说是一个完全不同的复杂程度......它带来了一种编写应用程序和构建反馈循环的新方法。所有这些都是新事物并带来复杂性。”
因此，Hubin 希望通过内部团队设计解决方案或在有意义的地方为托管服务付费，尽可能隐藏复杂性。以数据库为例。Amadeus 过去管理自己的 MongoDB 实例，但现在使用供应商管理的 MongoDB Atlas 选项。该公司对托管 Kubernetes 也持类似观点。
这并不意味着工程师不会推动将新工具引入生态系统。“有时你不得不说不，”胡斌说。“最近，我们有人试图引入一个新的数据库。他们说得有道理，但如果标准选项不是那么好，那么公司总体上[仍然]更好地控制我们使用的数据库数量。”
每个大型组织都有大量的工程师，其中一些专注于构建弹性系统并快速向客户交付功能，而另一些则拼命想修补最新技术。两者都有价值，但需要谨慎管理，Two Sigma 的 Fournier 说。
“你需要那些热衷于了解新事物并了解新事物的人——因为我需要人们来管理裸机 Kubernetes——但我也需要那些对研究新事物、了解它的工作原理、确定它的位置感到兴奋的人对整个公司都很有用——好的合作伙伴可以用来制作原型并确定是否值得投资来解锁它，”她说。
供应商如何应对复杂性与云软件行业的许多同行一样，谷歌云的首席开发人员倡导者 Kelsey Hightower 将当前可供开发人员选择的级别视为“礼物和诅咒”。
礼物是几乎无限的技术目录可供构建。诅咒是开发人员“被拉进了我们将基础设施泄露到他们的工作流程中的情况。” 现在，随着许多供应商专注于托管服务和抽象，钟摆似乎正在以另一种方式摆动。在大分裂之后，我们是否应该进行大整合？
“这个职业不仅仅是编写代码；这就是达到目的的手段，”海托尔说。“也许我们是说我们已经构建了足够多的东西，可以暂停构建新事物，使我们拥有的东西成熟并回到我们各自的消费技术角色。也许这就是我们在过去十年中看到的 DevOps 和协作运动的圆满结局。”
市场正在通过不断增长的自以为是的服务、托管选项、框架、库和平台列表来应对这种复杂性，以帮助开发人员应对其环境的复杂性。
“当然，没有供应商能够或将能够提供所有必要的部件。即使 AWS 拥有最多样化的应用程序组合和前所未有的发布节奏，也无法满足所有开发人员的需求，也无法拥有所有相关的开发人员社区，”O'Grady 在 2020 年的一篇博文中写道。
话虽如此，“有充分的证据表明，我们正在逐渐远离将买家和开发商送入迷宫般的过道，让他们承担挑选原始产品和从头开始组装的任务。如果云的第一个时代是由原语定义的，那么它的时代即将结束。下一个很可能被定义为，正如计算行业自成立以来，我们建立在这些原语之上的抽象，“奥格雷迪在另一篇文章中写道。
虽然将这些原语组装到连贯的内部平台中已经证明对于许多工程主导的组织来说是一种成功的解决方法，但更多的传统企业绝对会寻求他们的供应商来帮助他们减轻这种复杂性。
Kubernetes 联合创始人、现 VMware 研发副总裁 Craig McLuckie 在接受 InfoWorld 采访时表示：“复杂性与其说是环境的不一致，不如说是问题。” 他认为自己的角色是寻找方法“使开发人员的生活更轻松，以应对日益复杂的环境，这是由工具链的碎片化和高度可扩展系统的性质驱动的。”
正如 MongoDB 布道者 Matt Asay 最近为 InfoWorld 写的那样，“如今云的真实故事是谁能够最好地集成各种云服务。云即将变得更加有趣，正是因为变得更加乏味。”
需要机械同情如果我们正处于极大简化的边缘，我们是否会失去成为软件开发人员的本质？
正如传奇的英国赛车手杰基·斯图尔特 (Jackie Stewart) 所说：“要成为一名赛车手，您不必是工程师，但您必须对机械有同情心。” 或者，要真正做到出色，您必须了解您正在操作的机器。
虽然现代软件开发人员不能希望对他们构建的复杂、可扩展、分布式系统有完全的机械同情，但在尽可能多的理解中可以找到精通的元素。
“开发人员是系统人员。我们喜欢了解系统是如何工作的，一直到裸机和我们正在构建的架构。但与此同时，您不一定想深入了解各种领域，”微软的 Silver 说。
许多开发人员及其团队的任务是确定他们的专业知识最有价值的地方以及重新发明轮子的地方被浪费了。“我们最大的希望是让公司认识到这个问题，并努力让开发人员摆脱担心机器如何工作的业务——并回到构建软件，这是他们最擅长的，”顾问辛普森说.
软件开发人员从来没有比今天更多的复杂性和选择，但也从来没有更多的选择来抽象它。这只是取决于您和您的组织在追求目标时可以承受多少复杂性。
从实际生产环境和一家企业的发展考虑，应该避免重复造轮子，但也需要在泛用性以及实用性上保持良好的平衡，为了泛用性导致业务复杂和繁重也是需要避免的。在我看来，行业的最终发展是以云平台承载系统，每个云平台都是负责不同的业务容器和微服务。软件开发人员希望系统是抽象化的，泛用性的，当然这种泛用性不是为了妥协其他业务专门去特殊处理的泛用性。
