托管服务终结DevOps！

作者简介：Andrey Akselrod是Smartling公司的首席技术官兼联合创始人。

我们所知道的DevOps已死。赞同我这个观点的人也许为数不多，但是DevOps的时代已经即将翻篇。然而，这对有些人来说可能不会大吃一惊。

虽然某些行业设法无需做出根本性变化，存活了数年、可能甚至数十年，但是软件行业绝对不是这样。开发人员在不断重新发明轮子，而我们的工具和实践在现有技术的基础上，不断加以改进，因而完全变得越来越好。这几种变化正是导致了DevOps当初大行其道。

那么，为什么现在还活蹦乱跳的DevOps会销声匿迹？从某些方面来看，它就是一个“完美风暴”场景。好多事件撞到一起，大大改变了现状。而这一切始于敏捷开发和持续部署实践这个概念，并最终得到了广泛采用。

当初发明DevOps，是为了以此统一开发人员和IT运维（系统管理员），帮助他们找到共同基础。前提是，实现开发和部署工具自动化，这需要这两个学科领域之间的协作。但是还得有人过来编写所需的工具集。因此，大多数公司决定成立DevOps团队，结合两方面的专长，支持开发人员。

旧模式是将代码扔给另一头负责部署代码的系统管理员，这种模式不适用于敏捷流程和持续部署实践。要是哪里出了问题，那么这是谁的负责？是部署代码的人员，还是开发人员？开发人员不是非常了解部署，而系统管理员不是非常了解代码本该如何运行。

从某种程度上来说，这正是带来质量保证（AQ）团队的同样的反模式（antipattern）――借用安德鲁·凯尼格（Andrew Koenig）普及的一个术语；而如今，质量保证也行将就木；没人能够在持续部署过程当中使用质量保证。开发人员负责全面测试自动化，并确保代码可正常运行。一旦代码经过验证、准备就绪，就发布出去，并在生产环境中启用。开发人员知道，进入生产环境后的代码出现问题，自己要负责。

因而，我们宣称“所有部署都应该自动化”，DevOps团队应运而生，而市场对于DevOps的定义本身存在相当大的混乱。胖女人唱歌，系统管理员成了DevOps，他们开始学习Python来开发工具。对操作系统和网络略知一二的开发人员加入进来，帮助他们开发。

曾经一度，一切好得不能再好。DevOps团队愉快地开发自定义工具，让开发人员只要摁一下按钮，就可以将代码部署到生产环境；但是他们仍要管理许多基础设施，就像系统管理员之前所做的那样――数据库得熟练地安装、复制、集群和缓存等。

DevOps本身已成为持续部署过程中一个毫无必要的步骤。

但好景不长，另一个问题浮现出来。没人想往DevOps投入大笔的资金；毕竟，DevOps团队并不编写产品的新颖功能；坦率地说，它们其实是成本中心中的成本中心。团队的成员少得不能再少――他们做的是必要的基本工作，但是让工具达到出色的可重用性这个地步，并让开发人员拥有足够控制权以便自行配置工具却很难。一下子，DevOps成了瓶颈。而这一切就不如当初那么美好了。

那么，DevOps消亡是谁之过？很简单，那就是大家的朋友：云。

而我在这里所说的云，实际上是托管服务（managed service）。

如今，开发人员日益求助于托管服务，以满足工具集和基础设施方面的需求――这些是传统上由DevOps团队管理的任务。亚马逊网络服务（AWS）及其他托管服务提供商都带来了一种大大简化的工作方式，降低开发人员方面的复杂性，因而让他们专注于软件开发，而不是安装数据库，确保备份、冗余和正常运行等方面。换句话说，托管服务消除了DevOps团队被迫要处理的许多棘手问题。

虽然这对一些人来说可能很难接受，但是唯一的结论就是，DevOps团队正在带来他们当初所要解决的同一个问题。DevOps是为了加快流程而成立的，但由于如今托管服务具有的性质，你不再需要整个团队来提供便利――为什么不仅仅教所有开发人员如何利用云端的基础设施工具？事实上，就像之前的质量保证一样，DevOps本身已经成为持续部署过程中一个毫无必要的步骤。正因为如此，它过时了。

DevOps是否一定会完全消失？不会！事实上，它会依托在现有的开发团队上。究其核心，DevOps其实是一种文化，这些年来它培养的非常重要的技能应该传授给所有开发人员，尤其是那些下一代开发人员。

不过，DevOps角色本身会在不同的状态下呈现――主要用来管理治理问题，比如集中式安全和成本管理，因为虽然云提供了灵活性，用户可以根据需要，立即配置新的软件和工具，但是另一方面，你得小心行事――不然，你会无意中配置过多资源，到头来就要花一大笔费用。

DevOps作为一个团队早晚会消失，但是其实践会传承给整个开发团队，那样我们就能继续在它在过去带给我们的成果这一基础上加以改进。

DevOps已死，DevOps不朽！

相关阅读：