复杂性正在杀死软件开发者

现代软件系统日益增长的复杂性正在慢慢杀死软件开发人员。你怎样才能重新获得控制权，而又能充分利用这些技术所能提供的优势？

"复杂性是致命的，"Lotus Notes的创建者和微软的老员工Ray Ozzie 在2005年的一份非常有名的内部备忘录中写道。"它在吞噬开发者的生命；它使产品难以规划、构建和测试；它带来了安全挑战；它使用户和管理员感到沮丧。"

如果Ozzie认为当时的情况很复杂，你不禁要问他会如何看待软件开发者在 云原生时代所面临的复杂性。

在过去我们通常会构建一个单体架构的应用程序，并把它们部署在一个看得见摸得着的物理服务器上。而现在单体架构应用会被分解成多个微服务，打包成容器，用Kubernetes进行部署，在分布式云环境中托管，这一转变标志着我们的软件的复杂程度有了明显的提升。再加上用户对于丰富功富和软件体验的更高期望，使得软件设计需要更多考虑安全性和弹性：对开发者的要求从未如此之高。

"当你转向如此普遍的微服务环境时，复杂性明显增加，"亚马逊首席技术官Werner Vogels在 2019年的AWS峰会上说。"在所有东西都在一个单体应用中的日子里，它更容易吗？是的，对于某些部分来说肯定是这样。"

或者，正如他的同事，AWS的devops产品营销主管 Emily Freeman在2021年所说，现代软件开发是 "关于熵的研究，它不会变得更简单。"

另一方面，复杂的技术从未像现在这样容易被使用，它们通常是一些单一的API：从基本的库和框架，到图像识别能力，甚至整个支付技术。使用这些已有的技术进行简单地组装，并在上面建立你的业务逻辑。但这真的那么简单吗？

"成为一名软件开发人员从来没有像今天这样困难，"咨询顾问、前Walt Disney企业技术战略总监Nigel Simpson说。"虽然我们已经看到了能力的提升，通过使用应用开发和机器学习的高级框架，使开发人员能够做得更多，但这是有代价的。爆炸式增长的选择和技术发展的速度使开发者很难跟上时代潮流，许多开发者陷入了困境"。

基本与偶然的复杂性

软件机构Simple Thread的联合创始人Justin Etheredge对基本的和偶然的复杂性进行了有益的区分，他告诉InfoWorld："基本的是你所工作的商业领域的复杂性，事实上企业是极其复杂的环境，所以他们试图解决的问题本身就很复杂。另一个领域是偶然的：这是我们的工具以及我们为了解决一个问题而在工具上构建的部分所带来的复杂性。"

云原生时代迎来了比以往任何时候都更多的、潜在的偶然复杂性，这导致了开发者和他们的领导之间的矛盾：前者希望利用他们更多地利用工具，后者则希望他们专注于为客户提供价值。

Etheridge说："鉴于 今天对软件开发人员的需求，公司没有手段来推动开发人员走向主要为客户提供价值的思维模式。"让更多的工程师以这种方式思考是一个挑战。

选择的弊端

云计算和开放源码软件运动的普及，使开发人员在构建和运行更多可扩展、有弹性、模块化和可更新的应用程序方面的选择数量以不可阻挡的速度上升。

Humanitec公司的创始人Kaspar von Grünberg在接受InfoWorld采访时说："以前的一切都简单得多，不是因为我们这个行业犯了错，而是因为这些系统的需求急剧增长，我们必须加快交付的速度。

云原生计算基金会（CNCF）维护着一个交互式的图表，其中包含了构成云原生生态系统的 近1000种独特服务，其中许多是免费和开源的。此外，三大云计算供应商，亚马逊网络服务、微软Azure和谷歌云都向客户提供约200种独特的服务，涉及计算、存储、数据库、分析、网络、移动、开发工具、管理工具、物联网、安全和企业应用。

"目前，应用程序开发的过程实在是太碎片化了；每个企业架构都是三层的，每个数据库都是关系型的，每个商业应用都是用Java编写并部署到应用服务器的日子已经过去了，"RedMonk的分析师Stephen O'Grady在 2020年的一篇博文中写道。"现如今，基础设施的唯一最具决定性的特征是：没有单一的决定性特征。它是多样化的，甚至是错误的"。

或者，正如 前Tumblr首席技术官Marco Arment在2015年写道："由于大多数现代网络开发环境中涉及的工具数量庞大以及它们迅猛的演化速度，Web应用开发从未像今天这样复杂、令人费解。"

云计算供应商 在产品开发方面通过采取久经考验的方法（小型化、独立、双比萨团队为响应客户需求而构建服务）得到的结论是：开发人员已经在很大程度上被授予自主选择权，选择如何将这些众多的工具、模块以一种能够提供商业价值的方式组装在一起。

"在云中，你就像糖果店里的孩子"，金融服务企业Two Sigma的平台工程主管Camille Fournier在接受InfoWorld采访时说，"但随着你的成长，并试图让事情能有机结合起来，复杂性绝对会成倍增加。"

这导致许多人质疑这种程度的选择总体来说对普通的软件开发人员是否是一个积极因素。或者，正如O'Grady在 2020年的那篇博文中总结的那样，"在某些情况下，庞大的可用工具清单所固有的复杂性可能成为一种优势，而不是一种麻烦。"

让我们建立一个内部平台

这种日益增长的复杂性导致许多组织采用集中式平台模式，即由 内部平台团队负责审核工程师最需要的工具，建立模板，并 规划黄金路径，以缓解他们进入生产的旅程，同时也集中了 财务管理、安全和治理等功能，以减轻单个开发人员的认知负担。

以音乐流媒体巨头Spotify为例，Spotify产品经理Gary Niemen在 2020年的一篇博文中写道："回顾六年左右的时间，Spotify曾经（现在仍然）致力于以团队的自治来实践敏捷工程的文化。"这带来了所有的优势，也带来了复杂的问题，包括一个碎片化的开发者工具生态系统。也就是，找到如何做某事的唯一方法是问你的同事。"

随着Spotify规模的扩大，它发现原本推动其快速增长的方法实际上已经开始失效。它需要进行整合和简化。"那些被证实有效的或推荐的工具应该很容易被找到。该工具的使用方法应该是清晰的。在使用方面，应该有高质量的用户说明。而且，如果用户碰到问题，在哪里获得支持应该是显而易见的，"Niemen写道。

Humanitec的von Grünberg在 2021年的一篇博文中写道，一个好的内部开发者平台的关键是，在为希望继续完成手头工作的开发者提供自助服务和抽象出最没有价值的任务之间找到平衡，而不使开发者感到受限。

"拥有黄金路径的想法不是为了限制或扼杀工程师，也不是为了设定标准而设定标准。有了黄金路径，团队就不必重新发明轮子，有更少的决定要做，并且可以将他们的生产力和创造力用于更高的目标"，Spotify产品经理Niemen 写道："他们可以重新开始快速行动"。

问题是，"开发人员喜欢重新发明轮子。没有什么比建造一个更好的捕鼠器更让我满意的了，"顾问Simpson说。但在这个世界上，很多答案就在Stack Overflow上，这是否是对开发者时间的最佳利用？

微软开发者部门产品副总裁Amanda Silver说："总会有一些组织试图钳制，而另一些组织则试图赋予开发者权力。核心是开发者速度的概念。我们可以建立系统，让开发者可以写出只有他们能写的代码，而不会分心或有负担地去学习那些对他们来说没有区别的领域。"

旅游技术公司Amadeus成立于1987年，经历了这些技术变革的浪潮，它在大型机上建立了最初的应用程序，在21世纪初转向在开放的Linux平台上构建，现在则主要倾向于 用Kubernetes编排调度的容器化应用程序。

Amadeus的基础设施和云计算主管Edouard Hubin告诉InfoWorld："我们的开发者需要能够在我们提供的核心基础上进行开发，所以这个想法是一种平台方法，我们为他们提供能力。新技术为安全性和稳定性带来了更多的复杂性。当你开放这样一个系统时，你希望有稳定性。数据驱动型应用的兴起对我们来说是一个完全不同层次的复杂性....。它带来了一种编写应用程序和建立反馈循环的新方法。所有这些东西都是新的，并带来了复杂性。"

因此，Hubin希望在他能做到的地方隐藏复杂性，要么通过内部团队设计解决方案，要么在有价值的地方使用托管服务。以数据库为例，Amadeus曾经管理自己的MongoDB实例，但现在使用 供应商管理的MongoDB Atlas选项。该公司对 管理的Kubernetes也采取了类似的观点。

这并不意味着工程师不会推动新的工具进入生态系统。"有时你必须说不，"Hubin说。"最近，我们有一些人试图引入一个新的数据库。他们说得有道理，但如果标准选项不是很好，对公司来说，控制我们使用的数据库的种类[仍然]总体上更有益。"

每个大型组织都有一个广泛的工程师群体，一些人专注于建立有弹性的系统，并以最快的速度向客户提供功能，而另一些人则拼命地想修补最新的技术。两者都有价值，但需要谨慎管理，Two Sigma的Fournier说。s

她说："你需要的是那些兴奋地审视底层原理并了解精通新事物的人--因为我需要有人来管理裸金属的Kubernetes集群--但我也需要那些兴奋地研究新事物、了解它如何工作、确定它在整个公司的有用之处的同时--以及好的伙伴来做原型并确定是否值得投资来解锁一项新事物。"

供应商如何应对复杂性

与云计算软件业务中的许多同行一样，谷歌云的首席开发者倡导者Kelsey Hightower认为，目前提供给开发者的选择水平既是 "礼物，也是诅咒"。

礼物是有一个近乎无限的技术目录可供构建。诅咒是开发人员 "被拉入我们将基础设施泄露给他们的工作流程的情况"。现在，随着许多供应商专注于托管服务和抽象化，钟摆似乎正在向另一个方向摆动。在巨大的分裂之后，我们是否应该进行一次大整合？

"这个职业不仅仅是写代码；那是达到目的的手段，"Hightower说。"也许我们在说，我们已经创造得足够多了，可以暂停创造新的东西，让我们所拥有的东西成熟起来，回到我们各自的角色，即消费技术。也许这就是我们在过去十年中看到的devops和协作运动的圆满结局。"

市场正在通过不断增加的独特的服务、托管选项、框架、类库和平台来应对这种复杂性，以帮助开发者应对其环境的复杂性。

"当然，没有供应商现在或将来能够提供每一个必要的部分。即使是拥有最多样化的应用组合和历史上前所未有的发布节奏的AWS，也不可能满足每一个开发者的需求，也不可能拥有每一个相关的开发者社区，"O'Grady在 2020年的一篇博文中写道。

尽管如此，"有充分的证据表明，我们正在逐渐摆脱将买家和开发者送入迷宫般的过道，让他们承担挑选原件和从头组装的任务。如果云计算的第一个时代是由基元（译者注：包括非常底层的基础设施、类库等）定义的，那么它的日子就要结束了。O'Grady在 另一篇文章中写道，"下一个时代可能是由我们在这些基元之上建立的抽象概念来定义的，正如计算行业自成立以来所做的那样。

虽然将这些基元组装成连贯的内部平台已被证明是许多以工程为主导的组织的成功解决办法，但更多的 传统企业绝对会寻求他们的供应商来帮助他们缓解这种复杂性。

Kubernetes的创始人之一、现任VMware研发副总裁的Craig McLuckie在接受InfoWorld采访时说："复杂程度不如环境中的不一致性"。他认为自己的角色是寻找方法，"让开发者在处理环境的复杂性增加时生活得更轻松，这是由工具链的碎片化和高度可扩展系统的本质所推动的。"

正如MongoDB布道者Matt Asay最近为InfoWorld所写的那样，"如今云计算的真正故事是谁能最好地整合各种云服务。云将变得更加有趣，准确来说是以一种变得更加无聊的方式实现。

需要机械共鸣

如果我们正坐在大简化的悬崖边上，我们是否失去了作为一个软件开发者的本质？

正如英国传奇赛车手杰基-斯图尔特（Jackie Stewart）所说："你不一定要成为一名工程师才能成为一名赛车手，但你必须有机械共鸣。" 或者说，要成为真正的伟大，你必须对你所操作的机器有所了解。

虽然现代的软件开发人员不能指望对他们建立的复杂的、可扩展的、分布式的系统有充分的机械共鸣，但也应该尽可能多地去了解可以找到一个掌握的元素。

"开发者喜爱秩序的人。我们喜欢了解系统是如何工作的，一直到底层的硬件和我们正在建立的架构。但与此同时，也有许多其他领域，你不一定想深入了解它，"微软的Silver说。

许多开发人员和他们的团队的任务是确定他们的专业知识在哪里最有价值，在哪里被浪费在重新发明轮子上。"咨询师Simpson说："我们最好的希望是公司能认识到这个问题，并努力让开发人员摆脱对机器是如何工作的担心。回到构建软件，这是他们最擅长的事情。"

软件开发者从来没有像今天这样有如此多的复杂性和选择，但也从来没有像现在这样多的选择来把它抽象化。这只是归结于你和你的组织在追求你们的目标时能承受多少复杂性。