软件基础设施 2.0：一个愿望单
编者按：作者受无服务器云计算模式的启发，基于软件基础设施的现状提出了多个未来新一代软件基础设施改进方向和思路。
软件基础设施（我包括所有以 *aaS 结尾的东西，或任何与之类似的东西）是一个令人兴奋的领域，特别是因为（尽管「新鲁特主义者」可能会说）它每年都在变得更好！我喜欢研究快速变化的东西。
在过去的几个月里，我想了很多关于未来 5-10 年的发展方向，我的脑海中已经形成了一个愿望清单（但都是我个人的偏见）！你可能不同意。没关系——这些基本上是我正在做的预测，或者至少是一个愿望清单。如果其中一些（但不是全部）是正确的，也没关系。让我分享其中细节吧。
软件为愉悦而生
您知道蹩脚的软件有多么蹩脚，对用户来说如此明显，以至于您想知道为什么要发布它？一个超级迟钝的触摸屏界面，或者一个预约软件，它会强制您进入和退出可能的日期，并在它告诉您是否可用之前填写一大堆信息。我们都见过这样的垃圾设计，而且它们通常以同样的方式「垃圾」：感觉就像没有人真正使用过这个产品，然后说，嘿，这有点烦人，也许我们应该做把它做得更直观？
在 99% 的情况下，我想他们最终会遇到这种情况，因为有人列出了很长的需求清单，但清单上没有任何内容可以确保产品体验令人愉快。就像，有人从一堵墙的便利贴开始，上面写着「作为用户，我想……」。我认为这在逻辑上是有道理的——你可以定义一个用户应该能够做 x、y、z 的需求，但你不能定义体验不应该糟糕。
无论如何，我觉得这适用于 90% 的软件基础架构产品。
我的意思是，作为用户，我可以在 AWS 中建立一个静态网站，但在控制台中需要 45 个步骤，如果您以前从未这样做过，其中 12 个步骤非常混乱。而且做起来也超级慢，每当我犯错时，我最终都会陷入某种奇怪的状态，也许我把东西弄坏了，我可能不得不重新开始。可悲的是，这是软件基础设施的当前状态。
最好的公司如何构建消费级产品有很多值得学习的地方。他们如何使用数据来识别用户体验槽点，并不断尝试改变以使用户体验变得更容易。我在这里非常希望自然选择会偏爱易于上手和使用有趣的产品。第一步是，我们只需要更多的替代品，而不仅仅是少数几家大型垄断企业。我们等不及了。
真正的无服务器（云计算）
我们在云计算方面已经历 10 年了？大多数公司（至少是我与之交谈的公司）在云平台中运行他们的东西。那么，为什么软件仍然表现得好像云不存在一样呢？
- 集群一词对于云平台中的最终用户来说是不合时宜的！我已经在云中运行东西，随时都有可用的弹性资源。为什么我必须考虑底层资源池？只为我维护它。
- 我不想在加载之前配置任何东西。
- 我不想为闲置资源付费。让我为我实际使用的任何资源付费。
- 无服务器并不意味着它是一个可按需启动的虚拟机，可以在空闲期间将其实例状态保存到磁盘。
我可以继续列举更多，但我不会。我梦想着一个真正无服务器的世界。例如，我不想考虑未来的资源需求，我只想让事情神奇地处理它。好消息是我认为我们实际上每年都在接近这个梦想！
这样做的美妙之处在于，许多配置内容都神奇地消失了。大多数初创公司的竞争优势是通过业务逻辑而不是容量规划和容量管理来交付业务价值！
不仅如此，从资源利用的角度来看，多租户实际上是真正的「免费午餐」，因此任何汇集资源的机会都代表着真正的双赢交易。在全球范围内的大规模数据中心，它很大——取决于你是谁，但你可能会对节省的大量碳排放感到兴奋，或者对企业净利润率的提高感到兴奋（我想我两者都喜欢！）
快速
我的意思不是快速，是快速的服务请求。我们的软件在这方面做得很好！老实说，我认为它有多棒令人震惊：您可以在边缘运行函数，并在全球范围内获得毫秒级的响应时间。
没法上速度的工作任务是建立数字服务基础设施。如果我在 AWS 控制台中进行更改，或者如果我向 Kubernetes 添加一个新的 pod，或者其它什么，我希望这在几秒钟内发生。我不是要求毫秒！请至少让它不到一秒钟。如果我们可以在几毫秒内处理请求，那么我毫不怀疑我们可以做到。我们拥有基本即时启动虚拟机和容器的技术。
速度很重要，因为这对工程师来说是一种严重的时间浪费。我觉得我已经浪费了几年时间盯着一些基础设施的变化来启动。我会得马上回到这个话题，因为我认为这是一个重要的话题！
临时资源
我使用过的几乎所有基础设施都将资源视为无限期存在的东西。如果我在云中创建一个数据库，它会一直存在，除非我做任何事情，否则它将永远把控制台弄得一团糟，我会永远为此付钱。
我以前觉得这样挺好的！我的理由是，如果你想运行一个测试套件，只需自己在本地运行数据库，也许在一个容器中。这对于某些东西来说很好，但我开始认为这可能很糟糕：
- 构建您自己的基础架构副本需要大量工作，以便您可以在本地运行它。
- 开发-投产的增量变得更大。云基础设施的工作方式与本地运行的方式总是存在细微的差异。
- 很多云基础设施是专有的，不可能在本地运行！
我的深切愿望是让创建临时资源变得容易。您的测试套件需要数据库吗？以某种方式在云中创建它，以便在您的测试套件完成后进行「垃圾回收」。针对云基础设施运行测试！
我愚蠢的看法是，我觉得过去 5 年的辩论大致是这样的：
（要 100% 清楚，我在这篇博文中所提倡的不一定是立即在用户面前推出新版本，尽管出于本博文未涵盖的其它原因，我通常支持这一点：去读读 Charity Majors 发布的文章。我的意思是——让我在整个构建和测试代码的过程中尽可能多地使用类似生产环境的基础设施。）
与之前关于让我快速创建资源的观点相结合，关于临时资源的观点变得强大了 100 倍。代码如何开发的一般模式是基础架构与逻辑分离，并且逻辑是独立测试的。稍微简化一下，你可以想象一组嵌套迭代（循环）的开发过程，其中每个迭代的循环时间在每个级别都呈指数级恶化：
越是外圈的循环级别，我们的执行成本变得越高，反馈周期变得越慢。这与生产力有着极其密切的关系！需要注意的关键是将关注点从外部循环转移到内部循环是多么重要。将迭代速度降低一个数量级会对完成工作产生巨大影响。
拥有快速的临时云基础设施资源能力，将使我们能够将许多基础设施问题从最外层循环转移到最内层循环。这使您可以在几秒钟或至少几分钟内获得反馈，而不是几小时或更长时间。
代码不是配置
我能想到的至少有 4 种方式可以与基础设施进行交互：
- 网页界面
- 本地配置，然后运行一些与系统对话的命令行客户端
- API，您必须自己构建客户端
- 客户端库
第一个很棒，但通常仅用于入门。一旦你设置了一些图形界面的东西，你通常不会拿图形界面的东西进行变更，并且可能只将它用于监控等。
本地配置似乎是一般的下一步。这在一段时间内很好，但有一半的时间你会意识到：
- 实际上，我希望这个框架由更高级别的另一个框架控制。在这种情况下，您有两个（都是不好的）选项：公开两个框架的配置，或者让最外层的框架为另一个框架动态生成配置。
- 您需要动态生成资源，可能是在 for 循环或其它方式中。
现在你突然从 YAML 转移到使用 Jinja 或 Handlebars 或其他任何东西生成的 YAML。慢慢地，您开始向这些模板语言添加自定义函数，以便更轻松地生成配置。最终，它演变成拥有自己的文档的超级定制 DSL。
这太烦人了！ 10 次中有 10 次，我更喜欢通过一个漂亮的小客户端库访问所有内容。反过来，这个库可能是一个围绕可靠 API 的简单封装器。现在我可以编写自己的 for 循环了！我可以动态生成东西！我不必学习自定义 DSL！世界又变为一个令人快乐的地方。
为生产力而生
我想把它总结为一个元点，它本身并不是一个真正的点，而是更多的心态改变，也许是所有其它点的必然结果。
基础设施感觉就像是为解决硬性可扩展性和可靠性问题而构建的。有一些惊人的基础设施，我很敬畏它们——必须经过多少艰苦的思考才建成呀。但是很少有东西是为了优化开发人员的生产力而构建的。我认为从长远来看，「获胜」的工具通常是直接为此优化的工具。实际上，这不仅仅是生产力，还有质量，这些工具推动了质量与生产力的取舍点「向上和向右」偏移：
我的观点是，新的取舍曲线让你「兑现」更多改进收益：也许纯粹是因为更高的质量，也许纯粹是因为更高的生产力，也许两者兼而有之。
对我来说，这代表了未来 5-10 年的巨大机会和差距。 我迫不及待地等待工程师释放另一个数量级的生产力。 有很多软件等待我们开发！
