无服务器计算–开发和运营团队的未来是什么？

假设您在过去15年左右的时间里一直在关注，无服务器只是正在进行的Ops从战术向战略转变的最新动向。在本文中谈到了无服务器对Ops的真正威胁，无服务器计算的潜在弊端等等。

无服务器计算，就像它继承自云计算主题的其他变体一样，可以归结为“这是别人的计算机”。在无服务器的情况下，它要复杂得多。这是对传统IT模式的肤浅熟悉的最后遗迹终于消失了，迫使任何仍将云计算视为同一个旧事物的人都要面对事实。

人们可以并且确实仍然像对待VM一样对待AMI，这反过来又以与他们始终管理其物理计算基础架构相同的方式进行管理。当然，这几乎完全错过了虚拟化和云计算的要点，但并没有立即失败。这些问题只有随着时间的推移变得明显，在容量和利用率预测的改善，从虚拟化神秘未能实现。更糟糕的是，运行中的僵尸VM消耗了很大一部分可用容量，没有人能够解释或证明它们是合理的，但是每个人都害怕关闭，以防它们变得很重要。

发生这种情况的原因是–令人惊讶！–行动很难。无服务器计算的想法是摆脱日常的事务性Ops任务，让Dev更快地推出代码，并让基础架构主要由自己来管理。与其试图通过让Ops Morlocks大军在幕后努力支持Dev Eloi来“做DevOps”，没有服务器的幕后没有巫师。那里确实是自动化机械，这使开发人员有空去进行他们正在建造的任何东西。

开发团队大多热情地接受了变化。消除部署过程麻烦的任何方法都是好的，如果不需要开发人员选择隐喻的寻呼机，那就更好了。当然，这并不是说无服务器没有问题；毕竟，在我们生活的这个堕落的世界中，这没有任何机会。毕竟，如果云是其他人的计算机，那么无服务器意味着您的代码现在依赖于在其他人的计算机上运行的其他人的代码。这种事情在工作时会很好，但是这种不可靠的远程服务的假设尚未完全内部化。

有关引入的各种依赖关系的示例，请看一下2016年的左键盘崩溃。如果您设法擦除了相关的内存，则左键盘是NPM中的11行模块，实现了基本字符串填充。无论出于何种原因，成千上万的项目都将此作为依赖项，并且当开发人员撤出其所有模块（包括左键盘）时，随之而来的是混乱。

无服务器与Ops有何关系？

对于无服务器的开发人员来说，太多了–但我是一个真正的Ops家伙；我曾经是一名系统管理员，尽管我在Moogsoft担任战略架构职务已经走了很长一段路，但我仍然大多以这种方式思考，而且我在Ops的人们中度过了很多时间。事情是这样的：许多Ops员工会错过无服务器的意义，因为应用程序的使用模型是相同的，并且它们在熟悉的基础架构之上运行–那么，这到底是什么意思呢？当然，开发人员都非常兴奋，但这与Ops有什么关系？

某些操作人员甚至感到受到威胁：“我的工作是照顾服务器，现在您正在谈论摆脱它们！” 这是相同的类别错误，这是由于先将物理服务器叉入VMware，然后再转移到云中，而又没有改变您的想法的缘故。如果您将工作定义为在有人想完成涉及IT的任何事情时把手放在键盘上（如今这意味着几乎所有事情），那么是的，这项工作正在消失。无服务器可能不是棺材的最后钉子，但盖子已经牢牢地固定住了。

假设您在过去15年左右的时间里一直在关注，无服务器只是正在进行的Ops从战术向战略转变的最新动向。Ops并没有积极参与交付每个请求，而是定义了可用基础结构的功能和参数，然后将交付和日常运行移交给自动化。

这听起来像是NoOps，但是我宁愿回到操作员（基本上是磁带骑师）与实际系统管理员之间的旧区别，而不是踢那个蚂蚁山。如果您涉及日常事务，则表示您不是系统管理员。适当的系统管理员会小睡一会，将脚撑在已停用的服务器上，并确保一切正常，以确保安全–因为否则，某些事情已经告诉他们了。

微软自己对无服务器的主张是：“如果您将所有时间都花在构建和部署出色的应用程序上，而又没有时间管理服务器该怎么办？” 这并不意味着不对服务器进行管理，只是不对它们进行手工管理。没有开发人员或用户知道或关注基础结构的详细信息，这是应有的。效用计算意味着计算基础设施与外部人的电网一样有趣。当然，这很重要，如果它破裂了，我们所有人都会度过糟糕的一天，但是除非维护它是您的实际工作，否则您只需插上电源，不要再想一想-维护它的人当然不会花钱他们的日子在乡下开车，手工布线变压器是因为。

到目前为止，一切都很好–但是无服务器计算的潜在弊端是什么？

首先，因为它与（某些）Ops团队如何看待自己及其在世界上的地位相悖，所以很有可能将它作为IT预算之外不断增加的IT支出比例的一部分来进行。是的，那就是臭名昭著的影子IT再来一次。我在Ops团队中度过了很多时间，如果您向他们询问有关无服务器的问题，通常他们会嘲笑并暗示尽管实验室中的某人可能正在玩这种服务器，但没有发生任何严重的事情。然后在下周的第二天，您将看到一份新闻稿，其中介绍了同一家公司如何在AWS Lambda或其他产品上推出巨大的新的关键业务服务。这种事情不会一次发生，而是反复发生。无服务器对Ops的真正危险不是因为它使它们不相关，而是通过忽略它们使自身不相关。

Ops可以通过帮助制定策略来安全地采用这些新方法，从而做出真正的贡献。毕竟，Dev和Ops的无服务器体系结构在概念上都有大量开销。

首先，在您的产品投入生产之前，最好先对其进行测试。（暂停一下，歇斯底里的笑声消失了。）（停顿了更长的时间。）（好吧，我认为我们现在很好。）即使您自己的代码具有良好的测试覆盖率，您如何处理类似左手的代码？垫？或说Google以通常的难懂程度来贬低您所依赖的东西。您如何在测试中说明这一点？

价格如何？Google谈到要“从原型到生产再到星球规模”。这对开发人员在开始构建新事物时非常有用，因为您可以花很多钱就可以开展一个项目。但是，如果你被鞭炮割怎么办？（是的，在那儿显示我的年龄。）一旦在现实世界中碰到，设计决定可能会在白板上进行，可能会对业务产生重大影响。如果容量可以从零增加到无限，那么您的支出也可以。一个不再运行重新映像服务器的优秀Ops团队应该考虑这种事情。

不过，仅仅因为他们不必重新安装操作系统，并不意味着Ops团队处于闲置状态。系统管理员只有在确定自己所护理的系统没有发生任何不良情况的情况下，才能进行恢复性小睡。这曾经意味着在服务器上运行着监视代理程序，并且已经预先仔细定义了故障条件：IF this_happens和that_happens然后wake_up_sysadmin。

如今，平台是自给自足的，并且在很大程度上是自推式的。诀窍是弄清楚了解和反应的重要内容以及可以安全忽略的内容。现代IT的复杂性越过了那种确定性方法在不久前就不再有用的门槛，但是无服务器确实可以解决这个问题。随着服务几乎完全与基础架构的特定部分脱离，旧的跟踪方法不再起作用。

如果Ops不与Dev团队互动-记住，他们已经在无处不在，以某种方式进行Opserver的工作，无论Ops怎么想-这样做的结果就是Dev将Dev解释为损害并绕过它。然后，当不可避免地发生故障时，运维团队的传呼机仍然会打断并打扰他们的睡眠。