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