中国IDC圈6月28日报道，开发人员在企业计算中扮演日益重要的角色，包括搞清楚运行其开发的应用程序的基础设施。容器和软件定义数据中心（SDDC）因而处在于这种转变的前沿。
好了，运维团队，咱们不妨坦率地谈谈开发人员吧。你可能讨厌他们给你的工作带来了多大的麻烦。可能一听到有人重复调研公司Redmonk的格言“开发人员是新的当权者”，就会退缩。你可能觉得，开发人员盲目崇拜容器很疯狂。你还可能鄙视“DevOps”，觉得这是一种阴险的方法，让开发人员得以搞砸运维工作。
可是你猜怎么着？开发人员拥有控制权，一切表明他们拥有了更大的控制权。
在软件构建的世界里，对开发人员来说，软件正变得易于获取、更灵活适应。开源、云计算、容器，所有这些技术旨在让开发人员可以提高生产力，以至于备受运维团队钟爱的软件定义数据中心（SDDC）在很大程度上也将取决于开发人员。
给我让开，我在编程
容器是表明开发人员的地位持续上升的最新佐证。New Relic公司的第二次年度用户调查显示，开发人员在纷纷采用容器，绕开运维团队实施的种种限制。New Relic的战略营销高级主管阿布纳。杰默纳（Abner Germanow）对数据发表意见时特别指出：
[开发团体]无法如愿以偿地迅速获得虚拟机或服务器。这一幕屡见不鲜，运维团队饶有兴致地想改善开发管道，却眼看着对新服务器或新虚拟机的请求突然没了踪影，他们试图搞清楚发生了什么，结果发现原来开发团队部署了Docker.
正如开发人员菲利普。豪尔（Philipp Hauer）指出的那样，虽然Docker对开发团队来说可能具有似乎显而易见的优点（比如说可以全面控制执行环境），但容器也有助于运维团队，比如可以减少维护应用程序环境的工作量。容器解决了众多问题，比如服务生命周期管理（即我如何启动一个应用程序实例？），依赖项管理（即我如何确保这在生产环境中以同样的方式运行？），以及服务发现（即我如何连接到数据库？）。
这些优点让开发人员很高兴。
然而，正如豪尔继续指出的那样，容器可能很难群集起来，因为它们共享同样的内核，所以无法像虚拟机那样可以隔离开来。容器还带来了管理新的一层引起的额外复杂性。
无论克服企业内部的容器蠕变（container creep）现象面临什么样的固有困难，试图控制和约束它们为时太晚。运维团队面临的问题是，他们当初为了让运维有条不紊、井然有序而积极采用软件定义数据中心，结果软件定义数据中心将会日益受到困扰他们的开发人员的影响。
软件定义数据中心和容器
运维团队钟爱软件定义数据中心，觉得容器很疯狂。至于开发人员，他们钟情Docker之类的容器，但是觉得软件定义数据中心很疯狂。从它们各自的角度来看都是对的，因为虽然技术有众多相通之处，但是这些不同的用户想从平台获得全然不同的结果。
最终，我们将两者兼而有之――开发人员选择了软件定义数据中心，这表明Docker未来有一条长远而健康的发展道路。
软件定义数据中心是基础设施团队用来虚拟化和聚集硬件，然后分配给应用程序团队的工具。软件定义数据中心解决了诸多问题，比如硬件生命周期管理（即我如何购买新的服务器，并将其添加到数据中心？），驱动程序兼容性（即这只新硬盘会与我所有的现有工作负载兼容吗？），以及资源利用率（即我如何把更多工作负载塞入到现有的服务器上？）软件定义数据中心旨在为在上面运行应用程序的基础设施管理性能、安全性、可用性和稳定性。
这时候，容器登场了，扮演跨云控制平面这一角色。
应用程序团队已经厌倦了与每一个软件定义数据中心整合起来，以便让自己的应用程序易于移植。应用程序团队可以与像Kubernetes、Swarm或Mesos这样的容器运行时环境整合起来，而不是与软件定义数据中心整合起来。所有的“移植”工作如今在容器运行时环境中进行。重要的是，业界正在让Kubernetes、Swarm和Mesos可以在所有的软件定义数据中心上运行，那样你就没必要操心了。
运维团队和钟爱它们的厂商（比如VMware）正在竞相支持这些新的系统管理工具。反过来，像Kubernetes这些工具开始融入面向开发人员的功能特性。按照Kubernetes博客上的内容介绍：“Kubernetes不仅定义了便于管理员执行管理操作的API，还定义了便于容器化应用程序与管理平台进行交互的API.”后一种API对Kubernetes来说是新的，但是我们预计它应该会迎合开发人员。
如果由此认为诸如此类的工作表明开发人员已赢了，可能太过了。然而，起码这一点颇有说服力：新兴一代的运维工具在不断完善的道路上牢记开发人员的要求。毕竟，开发人员才是新的当权者。
热门专题
