请不要忘记“运维”

PaaS并不是一个陌生的话题，在新兴的容器世界里，我们如何看待运维和PaaS的关系呢? 又如何重新思考Dev与Ops的定位呢? 本文作者就此分享了自己的一些独特见解。比如作者说：Docker 最棒的一点在于它为开发和运维划分了一个清晰的界线：任何在容器内部的都是开发所关注的，而外部则是运维的天下。

是否还记得PaaS何时兴起?

五六年前PaaS的概念才刚刚兴起，当时有很多人（包括我自己）都认为运维这个职业将会因此走向衰亡。因为你可以把运维的工作交给PaaS平台，然后去专注于自己所擅长的事情，所以应该不会再有人愿意去干那些和机器打交道的基础服务方面的杂活吧？

现在，六年过去了，我们最终看到的是PaaS大量失败的案例，我开始意识到我错了，PaaS 并不是我想要的未来，它并不能够完全解决基础服务方面的一些难题，而仅仅只是让这些问题稍有缓和罢了。

在一开始，PaaS服务提供商每个月投入数百到数千美金的经费和资源培养客户，而最后只能眼睁睁看着他们离开，然后投入到云服务提供商的怀抱。

眼下的现实情况是公共的PaaS服务已经沦为一些菜鸟入门学习的平台，而那些游戏的胜利者们已经抛弃了PaaS，而选择在众多的云服务平台上搭建自己的服务器来承载他们的服务。

我之前曾经写过一篇文章，讲述了我为什么认为如此创新和流行的公共PaaS服务不能完全征服世界的一些见解，所以在这边便不再赘述。但是这里有一个论点我想再深入强调一下，就是我个人认为我们也许又犯了一个同样的错误，那就是“运维这个职业即将消亡”的这个预测。

相信从公共PaaS服务到开发者们所做的每件需要运维（我能称之为DevOps吗?）参与的事情里我们看到的和解读到的，你可以感觉到“运维”其实离我们并不是很遥远，然而它始终处在一个即将消亡的风口浪尖。我想这种“运维即将消亡”的思想多数来自于我们之中那些幸运的没有去到一个大型或者老牌企业工作过的朋友，或者是单纯以技术角度去看待这个问题而非企业的角度的朋友。

任何企业都依然需要运维的工作。如果他们并非如此的话，那么他们一定是把这些事情重新定义了一下（就比如开发穿上了运维的帽子，然后干起了搬机器的活）或者是临时的把这些事情外包给了一些公共PaaS服务提供商，就像现在很多企业实际所做的那样。

这并不是简单的技术架构问题，也和业务结构有一定关系。在业务逻辑里，对于创新（Dev）和保持稳定收益（Ops）有各自不同的生命周期，而我们有充分的理由告诉那些想用所研发的技术在大的方向上使得企业腾飞的开发者们大可不必承担所有的事情，而他们也必须认识到这一点。

在这里，就我个人来说，我觉得公共PaaS没能真正兴盛的最大原因在于：随着业务规模的增长，企业们需要规范和简化他们的运维，而这就造成了运维人员重新从外部PaaS服务提供商接管过来本就属于运维的工作（或者，更恰当的说，是这些企业会将开发者们安排到不同的业务周期）。

反之，这也就是为什么像Cloudfoundry这样的私有PaaS服务比他们的公共服务兄弟做的更出彩的原因之所在：他们是运维人员的工具，也同样迎合开发人员的需求。他们之所以如此成功是因为他们认识到了运维真正的存在价值：他们充当的是一个为运维人员提供服务的资源管理工具集而不是一个发明出来用以替代“运维”的工具。

让我们不要再忘了运维

然而，我感觉我们在这个新兴的容器世界也许又会再次犯下我们之前在公共PaaS所犯过的同样的错误。大多数用于在生产环境运行和管理容器的解决方案显得过于以开发为中心了。他们并没有一个清晰的界限指明应用应该如何规范的停止服务，基础服务的一些需求应该怎样去实现。

类似Docker Swarm这样的工具是在概念的层次上指明开发和运维如何在最初从各自的角度去使用这些工具集的很好的例子，然而在应用规范方面我们仍然有大量的工作需要去做：怎样去定义服务的概念，他们如何去跟其他的实体交互，在与其它实体交互时他们应该使用什么样的协议，等等。这些都是应用层面规范的问题。

接下来我们需要面对的是一系列的运维方面的问题：怎样把资源装载到我们的基础架构，如何构建我们所需要的实体，如何约束每个服务的服务范畴以及他们如何定位其它反映基础服务配置的实体（译者注：比如说定位到同一个IDC或网络通信质量高的服务实体，而不是随机选择），等等。

当我关注到类似Swarm和Compose这样从不同的功能清晰划分的工具集时内心备受鼓舞。然而它们并没有在API中对开发和运维做很大的区分。举个例子，Compose（持续工作中的）倾向于支持所有的Docker CLI命令行选项参数，而大部分（也许不是全部）的Docker CLI 命令行参数是纯粹的以开发为中心设计的。

Docker 最棒的一点在于它为开发和运维划分了一个清晰的界线：任何在容器内部的都是开发所关注的，而外部则是运维的天下。当前版本的Compose API以及开发的 Swarm 在某种程度上来说反而是模糊了这个划分的边界。

我们正在努力试图让这个划分变得更清晰并且体现到实际的企业生产业务中。manifest.yml和services.yml的划分或是我们UI的构建方式都是一些我们试图推动这一愿景的最初的尝试。关于这些，我们非常欢迎得到您的一些想法和反馈。

原文链接：Let’s not forget about Ops （翻译：吴佳兴 http://www.dockerone.com/article/322）

本文链接：https://www.yunweipai.com/4472.html