摘要
本文介绍了为什么在一个好的公有云或私有云中必须要有一个编排系统来支持云上自动化，以及实现这个编排系统的困难和各家的努力。同时提供了一套实现编排系统的原型，它包括了理论分析及主体插件框架，还给出一些细节控制的建议。希望有助于大家对 “资源编排&应用编排”概念有更深的了解，也希望以开放的心态与大家一起努力，使得云真的像水电一样自然和普及。
1、为什么需要云上自动化
IT领域的自动化要求无需多言，每个程序员都知道这是必须品。自动化脚本，自动化测试，自动化部署等等，都是为了程序及围绕此程序的各类程序员跑的更加欢快。那么在云上我们是否还需要自动化？简单而言，初次使用无需考虑；深度用户需要云上自动化。
具体体现在：1.1 重复性的执行动作
在云上验证应用上线的工作中，有很多的事情是需要重复操作的。比如环境的销毁和重建；或者扩容的场景下，重复地完成多个新实例的配置动作。一旦此类操作的频率变高，比如一天一次或者一天多次的时候，你一定会觉得繁琐，并且开始尝试如何使得整个流程变的自动化，从而保证每一次执行是可重复的。也许你会写些Shell或者Python脚本，或者你主动调用云提供商的API，甚至借助某些工具如Chef，Puppet来完成这个目的。
重复是催生自动化的首要条件。
1.2 节约时间
在云上使用服务，有些操作是非常耗时的，比如创建数据库，创建VM，都需等待分钟级别的时间。一旦需要串行的创建多个耗时任务，就需要用户持续等待一段时间。而此时如果可以将整个流程自动化，则可以释放人为的等待过程，使程序员去完成其他更有价值的任务。
云上的流程自动化后，执行动作的总体耗时并不会减少，只是这段等待时间可以被转移，比如放在深夜执行。也正是这个原因（耗时没有减少，只是转移了），所以自动化后时间的节省，还是要以重复性为前途的。假如只是一次性的操作，那么“自动化节约的时间” vs “完成自动化的时间”一般都是不划算的。
1.3 基础环境的复制
这里的基础环境是指Infrastructure，是指应用跑在云上所需要的所有云服务的集合。例如一个典型Web网站的3层架构，前端+后台+数据库。在云上的某个区（例如华北区）域搭建好一套完整的系统后，遇到需要在华南区甚至另一个云提供商的云上，重新搭建一样的环境的时候，就会有系统复制的需求。是靠程序员手动一个一个组件的安装？还是自动化的一键重复部署？在有后者能力的情况下，当然后者是首选。
现在很多云厂商都推行一个叫做 Infrastructure As Code 的概念，使用机器可以理解的配置文件，来代替人工交互式的配置动作。并且这种配置文件可以通过版本管理系统像代码一样进行版本管理。这样对于企业的好处主要体现有3个：减小成本、提高效率、降低风险。
减小成本很好理解，如上提到的，自动化可以将人力转移到其他任务上，提高程序员的产出。而效率的提升主要体现在通过自动化的配置可以将环境安装的实施过程缩短，如果有多个组件或者团队交互的话，提升效率就更明显了。同时自动化可以消除人为的错误，可重复的执行特性也提升实施过程的可靠性。
1.4 自助式服务
云上服务，如果做得好，应该是自助式的，就像自来水和电一样，即开即用，按需付费。只有这样子才可以支持任意的自动化按需供给、按需扩容，也才是云本身所具备的含义。
所以这一条理由其实是对云提供商提出的要求，你的云平台要能够支持用户自助式的按需使用各种云服务，并提供相应的使用计量信息（账单）和使用报告。只有当平台的后端实现流程是全自动化的，才能做到给用户的体验是完全自助式的。这跟淘宝商家的“有货随便拍”一个道理，否则没到下单前都得跟店家沟通，无法做到按需自助式使用。
1.5 自动化的成本
任何需要自动化的东西，前提就是你需要重复的执行，只有当自动化的收益大于重复的成本，才会有自动化的需求出现。假如任务只是一次性的，那就不存在自动化的需求。相反我们相信从收益方面考虑，精心人工操作一遍会比将流程自动化更为划算。
好比有时候路上遇到口渴并不会想安装一套自来水，还不如直接买一瓶矿泉水来的实在，而在家里，则需要安装一套自来水系统，因为你每天都需要使用水。
云上的自动化提供了一种可靠性，它使得云资源，云服务的每一次创建的行为都是一致的，任何用户，任何组织的执行都是可重复的；同时也消除了由于人为操作可能的失误所带来的问题，是云上深度用户的必需品。
2、云上自动化演进
2.1 自动化面临的困难
（1）云服务的种类丰富多样，导致想要完成全面的自动化并非易事。一个典型的云平台会提供了ECS（虚机），EVS（硬盘），VPC（网络），RDS（数据库），ELB（负载均衡） 等等一系列数都数不清的服务。有一个新的术语叫做 AWS fatigued，就是说AWS每年都会上线各种新服务&新特性，使得用户对新上线的服务&特性都感到了“AWS疲乏”，疲于使用。
（2） 云服务间的创建存在复杂的依赖关系。最典型的例子就是，当创建EIP的时候，需绑定VM，而创建CM的时候，又需要先创建Subnet，建Subnet的前提就是需要先有VPC。层层的依赖，以及交叉依赖，都为开发者在企图自动化的道路设置了拦路虎，使得完成自动化的成本大大提高。根据前面提到的成本大于重复性收益的时候，自动化就会被放弃。
（3） 云上资源的使用方式与传统方式不同。用户从资源的完全拥有者变成资源的使用者，后台权限的降低，导致你无法掌控一切，使得不那么方便的定位资源初始化失败原因（也许云平台本身的Bug导致）。有时候不得不联系云提供商求助了解失败原因。另外在使用流程上也会稍有改变，原来你的软件包一次拷贝就到了验证环境，而在云上，也许你需要中转跳板才能达到目的。这些都加剧了自动化的实施困难。
2.2 自动化的尝试
这里直接给一个图来总结了云上自动化的尝试历程，可以更加直观的了解这一领域的发展情况。不过在资源供给自动化和资源编排上其实边界也没有那么的明显，可以看到主要的差异是在灵活的语法上。在已有的自动化模板里面逐步增加一些灵活的语法，基本可以达到灵活编排的目的。
