2016年六大OpenStack & Docker发展趋势预测
虽然此前已经多次提及，但在这里我要再次强调2015年作为云计算全面崛起元年的重要地位，这在很大程度上是因为这一年内出现了众多值得高度关注的大事件——包括戴尔/EMC的合并，而这些标志性事件意味着新的时代已然来临。这是一种直白而决绝的表态，意味着全部传统IT厂商都需要努力争取自己的生存空间，否则必将为历史所淘汰。
这场演进或者说革命则让OpenStack处于非常有趣的定位之上，目前已经有大量“企业级”厂商——从思科到惠普再到IBM——开始将相当比例的资源投入到OpenStack项目的推动工作当中。而Mirantis等新兴厂商亦凭借着英特尔向其投入的1亿美元确立了自己在新生代企业当中的领导地位。此外，红帽公司在这场竞逐当中仍然表现良好，并继续依靠自身强大的Linux发行版牢牢锁定着现有客户群体。
我们还亲眼见证了Platform 9以及Stratoscale等新兴厂商的快速崛起，它们不仅给传统主流企业造成巨大冲击，同时也威胁到了Mirantis及红帽等新生代领导者。因此，考虑到以上状况，2015年绝对是个值得认真回顾的精彩年份。
不过2015年的一切已然“俱往矣”，着眼于2016年做出展望显然更具有现实意义。
我做出的第一项预测就是，作为OpenStack（也包括任何其它云技术）核心服务之一的计算服务将在新一年中发生巨大变化，即由原本的虚拟机管理程序为核心转变为容器加裸机组合模式。
事实上，根据最新发布的OpenStack用户调查显示，有31%的受访者将裸机、LXC以及容器以混合方式加以使用。这种方式也成为本届OpenStack东京峰会上的热门新闻，而且OpenStack能够支持一切计算资源的能力也正是其在云技术领域拥有差异化优势的关键所在。值得强调的是，这也与Hedvig公司市场营销副总裁Rob Whiteley的观点不谋而合——他曾在2016年预测中表示Docker将成为OpenStack内的第二大重要虚拟机管理方案。
除此之外，2015年当中我们也经历了NFV（即网络功能虚拟化）在OpenStack社区之内的快速崛起，这也是电信与企业IT之间实现大融合的标志性事件之一。
这份最新调查报告显示，容器与NFV如今已经成为OpenStack社区当中最受关注的两大创新成果，其重要程度甚至超过了PaaS。
2014年是Docker强势崛起的一年，而以其为代表的容器技术也彻底打乱了整个技术行业的阵脚。Docker的发展速度太快、规模太过庞大，以至于无法为单一持有者所掌控。因此谷歌与CoreOS于2015年4月联名要求Docker方面放松其底层核心引擎控制权，同时将剩余堆栈部分向插件开放以避免其内部生态系统中的竞争问题。2015年6月，Docker宣布其正式在Linux基金会指导下建立产业联盟。
现在回想起来，我认为自己当初做出的2015年预测确实比较靠谱，而这也让我有了撰写这份2016年OpenStack发展预测的动力。正如Adrian Cockcroft所言，“IT支出没能跟上开发人员的发展脚步。如果大家相对于采纳新型技术成果而更关注成本支出，则意味着您的思路已经跟不上时代了”。
而且正如之前所提到，我将引用OpenStack用户调查以及其它一些报告内容，并以此为基础配合个人分析做出预测。（所引用的资源列表将在文章最后统一列出。）
2016年OpenStack/私有云发展预测
房间里的大象（即少被谈及但却真实存在的事物）
我还记得当初OpenStack项目刚刚诞生的日子，那时候我们曾经倾向于将其与Linux系统相比较。事实上，二者之间确实存在着诸多共通之处——它们都属于大型开源项目，而且直接立足于数据中心架构核心位置。然而经过了六年的发展与演进，我意识到这种比喻其实存在着很大的问题。云体系在复杂程度方面要远远高于操作系统，而且其面临的最大挑战也并不单纯在于技术层面或者成本支出。要想在云业务领域取得成功，大家需要具备能够与Amazon、谷歌以及其它云服务供应商相近的技能储备、组织结构以及企业文化。很明显，绝大多数企业——甚至包括那些拥有大型内部数据中心的企业——并不具备这样的技能储备与内部文化。而且更重要的是，云业务的投资回报率目前仍不明确。
这意味着如果在构建OpenStack发行版时完全假定遵循等同于Linux发行版的开发模式，那么其从核心层面就将存在着严重问题。因为Linux发行版的构建思路会假设企业自身拥有IT部门，且相关技术人员有能力通过获取发行版并利用典型IT方式——即由红帽、Ubuntu、Mirantis等厂商提供技术支持——实现云环境运营。但实际情况是，绝大多数IT部门根本没有充分的技术力量来搞定这一系列难题，而将其转化为云业务的举措似乎也无法带来明确的投资回报。
这又响应了其它预测结论，例如Rob Whiteley曾经提出的观点：人才，而非技术，才是OpenStack实现成功的头号关键因素。
另外一种有趣的现象在于，这种人才层面的空缺导致采用OpenStack技术的小型企业越来越少，而真正对其加以运用的大型企业则持续增长，正如以下示意图所显示：
考虑到当前构建私有云（包括OpenStack在内）所面临的诸多难题，对于小型企业来讲，最具实际意义及经济效益的作法应该是采用公有云或者简单的Docker架构基础设施，而非将资源投入到OpenStack当中。更重要的是，即使某些大型企业也仅仅在把小规模OpenStack部署体系视为专用解决方案。通过下图可以看到，大型企业也仍然很难确切把握OpenStack的投资回报水平。
预测一：指定OpenStack设备与托管部署项目将开始取代传统发行版模式
就目前/短期来看，企业将需要依赖于其它能够提供完整OpenStack运营环境的供应商来建立自己的云体系。这意味着我们将看到企业客户摆脱现有发行版模式——即选择预打包设备并配合与之相适应的特定底层硬件——束缚，转向更为灵活的实现方向。事实上，Mirantis、惠普以及思科都在引领着这一风潮，而Stratoscale等初创企业也开始加入进来。
在我看来，我们还将看到更多企业选择OpenStack的托管版本，在这种情况下他们将把整体私有云运营体系外包给擅长这一领域的第三方专业厂商。Rackspace公司以及CSC、埃森哲等传统系统集成商将在这方面占据优势地位。
总结起来，以上解决方案都能在一定程度上解决企业在运营OpenStack云时技能储备不足的问题，但这还并不足以帮助我们将OpenStack作为首选运行环境——而这正是我们实现业务敏捷性并降低成本的必要前提。为了能够让OpenStack继续在市场上获得关注与采纳，相关社区必须迈向软件发行版这一固有局限，并同其它低成本云方案实现对接。考虑到这一点，我提出了下一项预测……
预测二——新型OpenStack平台崛起，利用OpenStack作为其它私有/公有云中的通用型抽象层
VMware公司已经发布将利用VIO支持OpenStack。关于VIO，有趣的一点是其利用OpenStack作为立足于传统VMware堆栈之上的抽象层，这意味着VMware用户可以在投入OpenStack怀抱的同时继续享受VMware基础设施的出色成熟性水平。这还允许此类用户继续运用自己的现有VMware技能储备，并大大简化由VMware向OpenStack这一过渡过程。
Platform 9是一家初创企业，承诺立足于Amazon或者其它云资源交付一项OpenStack服务。着眼于Platform 9方案，其最大的亮点在于能够显著降低运行OpenStack的入门门槛，而且得以利用AWS、Google Cloud Compute、VMware乃至其它云服务供应商底层云资源的成熟度与成本效益，从而将OpenStack作为一种通用型抽象层运行在全部现有云平台之上。
预测三：PaaS已死，新PaaS长存
Docker提供一套独特的部署模式，这直接导致传统的特定PaaS方案变得毫无吸引力。而最近的OpenStack用户调查也显示，作为专门围绕Docker打造的补充性方案Kubernetes以及微服务架构已经获得快速发展势头，此外Docker Swarm、Mesos以及Cloudify也运作良好。而更有趣的是，这份清单当中的全部成员都采用了不同于PaaS内“Heroku”型应用管理与自动化机制的新型解决途径。Cloud Foundry目前仍然处于领先集团，而OpenShift则以较小差距位居第三，不过Cloud Foundry与OpenShift还需要对自己的整体产品进行梳理，从而适应面向容器的迁移趋势。而最值得指出的一点在于，OpenShift已经开始针对Kubernetes进行重构。
另一项有趣的事实是，这份清单中没有任何一个上榜项目属于OpenStack发行版的组成部分。一种可能的解释在于，用户可能更倾向于把自己的应用平台从其基础设施当中解耦出来。
着眼于2016年，我预计全部应用程序平台都将面向容器及Kubernetes提供支持。Mesos与Kubernetes已经在很大程度上成为彼此互补的方案组合。我认为这两套平台将继续发展并构成完善的堆栈体系，而二者之间的交集部分则更多以备选竞争方案而非互补方案的形式存在。目前尚不确定的是，戴尔收购EMC的举措是否会给Pivotal带来影响，而Docker/Kubernetes的崛起也将成为Pivotal/Cloud Foundry快速发展的催化剂。我认为OpenShift在这种背景下将拥有更为有利的市场定位，因为其已经在很大程度上开始向Kubernetes倾斜。不过需要指出的是，OpenShift选择Kubernetes作为基础的作法可能导致引入另一额外抽象层的风险，因此其最终结果或者说价值回报目前尚无法确定。
尽管我们可以看到容器技术已经迎来了明确的扩展态势，但我认为真正实现全面容器化恐怕还需要经过多年的推进，而微服务架构的普及甚至需要花费更长时间。考虑到这一点，我认为2016年年内市场还不太可能将大部分负载部署并运行在微服务/Kubernetes这类混合型工作负载环境当中。在这方面，比较理想的实现方式是利用Kubernetes作为面向微服务架构的部署目标，并利用其它编排方案运行数据库、大数据、事件处理以及各类更为复杂的工作负载。与此同时，Cloudify与OpenStack/Magnum已经被定位为集成平台，其允许用户向其中粘合多种不同类型的工具与工作负载。
预测四：别无选择之下，电信行业将成OpenStack采纳之先锋。
尽管OpenStack的投资回报率在企业领域受到公有云服务的有力冲击，但OpenStack在电信运营商层面却成为惟一的解决方案——换言之，电信运营商惟有借此方能与迅速崛起的公有云服务供应商相抗衡。考虑到这一点，我们可以从下图当中看到，网络功能虚拟化（简称NFV）机制开始在OpenStack用户当中快速普及开来：
我预计在2016年当中，电信行业将成为OpenStack部署领域的绝对龙头，其接纳程序远超企业客户。
预测五：第二代OpenStack？以原生方式将Docker与OpenStack相结合需要对OpenStack核心做出本质化调整
将Docker集成至OpenStack当中的方案就目前而言主要分为两种，其一为将Docker视为额外的计算节点，其二则是利用Magnum对Kubernetes及Mesos等堆栈层提供支持。
尽管这看起来算是不错的起点，但却未能发挥容器技术的相当一部分核心价值，即提供一套完整的计算、网络与存储堆栈。
为了全面迎接容器时代的来临，OpenStack将需要超越现有核心架构，转而着眼于潜在的、专门为容器提供原生支持的新型OpenStack核心。红帽公司似乎在这方面走在了时代前列，而且其已经于本届东京OpenStack峰会上发布了一套容器原生堆栈。（值得注意的是，此次发布的方案与现有OpenStack服务几乎无甚关联。）我认为在2016年当中，我们将迎来Docker以原生方式集成至OpenStack核心当中的一波浪潮。我认为由此带来的结果就是，下一代OpenStack将直接提供原生容器解决方案并因此在易用性与轻量性方面超越其现有版本。
预测六：混合云开始登上核心舞台
自诞生之日开始，OpenStack项目就一直被视为AWS及其它云服务的替补性方案。
不过在真实世界当中，OpenStack一直被用于同其它云环境相对接——目前最流行的使用方式就是利用VMware作为其私有端，而由AWS充当公有云端。
话虽如此，大部分用户实际已经建立起了自己的一套松散私有云环境，其中分别使用OpenStack、VMware或者Amazon元素，而且不同环境之间几乎没有任何交集。之所以采用这类方案，部分原因在于真正建立起一套严格的混合云部署体系确实非常困难。
而目前的变数则包括以下三项：
工具——新型编排框架与网络虚拟化机制如今使得跨越多个云环境的自动化应用程序部署流程成为可能。
由于消除了对专用镜像格式的依赖性，容器的可移植打包单元使得我们能够将同一软件包以前所未有的轻松方式运行在多种云环境当中。
大部分云服务提供共同的内置容器支持基础，这使得我们能够更轻松地将工作负载在不同云环境间往来迁移。
使用混合云战略的另一大重要动机在于投资回报率。正如我之前所提到，构建OpenStak项目的成本往往相当惊人。而削减OpenStack基础设施规模的一大重要举措在于将OpenStack同其它公有云相结合，这意味着私有云实例拓展至按需实例，并借此提升业务敏捷性且降低总体使用成本。
考虑到上述因素，我们相信2016年各OpenStack项目将把建立更为紧密的混合云方案作为首要目标甚至是先决条件。
容器与Kubernetes的介入，再加上OpenStack提供的TOSCA支持能力，将共同通过TOSCA解析器项目体现出效果，与此同时Cloudify亦将在此类方案当中获得一席之地。
最后说明：变化是惟一不变的要素
在这个瞬息万变的世界当中，对未来做出准确预测实在不是件容易的事。
而OpenStack最令我赞赏的一点在于，其显然高度关注并尊重来自用户的需求与反馈声音。本次OpenStack用户调查报告的投资规模一项也证实了上述结论。截至目前，这份最新用户调查已经是最为全面且明确的统计观点。在这里要感谢相关人员的付出与努力！
在此次预测当中，我引用了大量来自用户调查及其它预测性报告的内容，具体条目将在下方一一列出。希望对丰富资料的汇总能够让此次发布的预测结果更为精确。
无论如何，变化是惟一不变的要素——因此如果要总结出一条放之四海而皆准的建议，那么我希望大家能够“积极拥抱变化”。在规划自己的2016年OpenStack发展战略时，请大家保证自己的选择足以快速接入新型技术成果，而这种创新工作的实现速度将高度取决于这种接入速度。
