Fit2Cloud DevOps平台助力企业实现应用全生命周期管理

　　亚马逊，在2013年12月18日宣布旗下的Amazon Web Service（AWS）正式在中国提供服务。与此同时，越来越多的国内创业企业开始积极进入AWS生态圈，基于AWS提供增值服务。近日，国内的创业团队Fit2Cloud正式对外开放其Beta服务。Fit2Cloud与AWS OpsWorks类似，提供云应用生命周期管理服务，但Fit2Cloud具备很多OpsWorks不具备的特性。“虽然Fit2Cloud现在名不见经传，但相信随着AWS服务在中国的开展及Cloud Native应用开发的兴起，用户会逐步认识到Fit2Cloud所带来的全栈自动化管理的价值。AWS中国首期发布的服务中不包括OpsWorks，我相信Fit2Cloud可以弥补这个空档”， Fit2Cloud负责人表示。“当然，除了AWS，我们计划也支持其他的公有云，如Azure, 阿里云等”，Fit2Cloud负责人谈及后续发展计划时表示。　

　　Cloud-Native应用的兴起和挑战
　　
　　在AWS出现之前，“Cloud-Native应用”这个概念并不存在。经过多年的发展， 出现了大量构建、运行于AWS之上的成功的Cloud-Native应用，如Netflix、Zynga、Pinterest、Heroku、Reddit等。Cloud-Native应用的核心改变是：Fit App to Infra，而不是Fit Infra to App。既要充分利用IaaS的可编程性、可扩展性等特性，又要解决IaaS的不可靠问题，这是云时代软件开发的新挑战。

　　显然解决这个挑战的就是PaaS，但是狭义的PaaS如Cloud Foundry, Openshift等，在给开发人员带来方便的同时，也限制了开发人员对全栈的控制。不同用户的应用系统差异很大，不同的业务、不同的架构、不同的框架、不同的语言、不同的OS、不同的部署环境等。对于复杂的系统，用户需要的是对全栈的控制权。传统PaaS限制了开发人员的选择权和控制权，而Fit2Cloud 云开发DevOps平台则是帮助开发和运营人员更好去实现全栈的控制权和全生命周期的管理。

　　Fit2Cloud：事件驱动的、可编程的DevOps平台，实现应用全栈自动化管理

　　基于Fit2Cloud，用户可以通过对应用的全栈自动化管理，包括：
　　
　　环境创建自动化：创建VMs、网络、存储、负载均衡，协调不同角色VMs的创建过程和配置;

　　软件安装和配置自动化: 操作系统配置，比如创建用户、组，设置ulimit参数, 各种Runtimes如JDK的安装等;

　　基础软件安装和配置自动化:  基础软件如mysql/nginx。这些软件的特点是变动不频繁;

　　应用部署和升级自动化: 部署应用代码，比如war包、db脚本、php/rails代码等;

　　监控和告警自动化: 如果发现异常，需要能够自动发出告警信息;

　　故障恢复自动化: 在异常发生时，系统可以发现并进行自动处理恢复;

　　自动伸缩自动化: 业务存在高峰期和低谷期，系统应该是可以自动伸缩;

　　基于Fit2Cloud，用户可以实现DTAP(开发环境-测试环境-Staging环境-生产环境)之间的无缝衔接。开发/QA/产品环境都是通过相同方法来自动化创建和管理，可以避免多种环境管理不一致所导致的一序列问题。

　　相比于OpsWorks, Fit2Cloud的优势是什么？

　　1. OpsWorks与Chef绑定紧密：OpsWorks与Chef绑定,这导致只能用Chef; 而Fit2Cloud的Event Handler可以用任何脚本语言实现，不仅可以使用Shell, python, Ruby, 还可以在脚本中可以调用Chef/Puppet。

　　2. OpsWorks不支持On-Premise部署和定制化修改 ：对于大型企业来说，会有自己的特定需求，On-premise部署和可定制性非常重要。

　　3. OpsWorks不支持其他公有云： OpsWorks只支持AWS, 不支持其他的IaaS, 不支持混合云, Fit2Cloud将来可以支持其他的IaaS。

　　4. OpsWorks暂时不支持Beijing Region：AWS 北京区域不提供OpsWorks 服务。而Fit2Cloud会抽象掉Beijing Region和其他Global regions之间的差异。用户可以在Cluster中使用所有Region的资源。

　　5. OpsWorks单个Stack的资源局限在一个Region内：受限于底层实现(Cloud Watch & AutoScaling Group)，OpsWorks一个Stack内的所有资源都是位于一个Region之内。

　　6. OpsWorks不能处理不同VM之间的事件(Orchestration)： 举例而言, 当启动一台新的mysql后， 我们想自动把mysql的地址配置到Webapp的配置文件中，在OpsWorks中，按照例子，需要先手动启动mysql, 然后等mysql启动后，人用肉眼获得MySQL的IP, 然后手动配置到chef的Cookebook里，从VM的provision到自动的配置，需要人手工干预，无法实现环境VM自动化到配置自动化之前衔接的自动化。