RightScale CTO认为AWS新发布的OpsWorks是个“时代的错误”

2月18日，AWS发布了新的云运维产品：AWS OpsWorks。在Amazon CTO Werner Vogels的博客上，他这样介绍该产品：

这是一个灵活的应用管理解决方案，自带自动化工具，能让你为自己的应用及其支撑基础设施，对它们进行控制。OpsWorks让你可以管理完整的应用生命周期，包括资源准备、配置管理、应用部署、软件更新、监控和访问控制。

与其他AWS的应用管理服务一样，OpsWorks不收取任何额外费用。

他接下来详细指出了该工具的几个特点。

• 灵活：OpsWorks可支持多种应用架构，并可与任何有脚本式安装方式的软件一起工作。因为OpsWorks使用Chef框架，开发者可以使用现有的“菜谱”（recipe），或利用其他数百个社区构建的配置。
• 自动化：OpsWorks提供事件驱动配置系统，以及丰富的部署工具，让用户可以完成定制部署、回滚、补丁管理、自动扩展和自动修复。比如，OpsWorks可以基于用户制定的配置（要部署的代码、RAID配置等）来设置实例，使用基于负载或是基于时间的策略完成应用自动化扩展，检测并替换错误实例等。
• 运维控制：OpsWorks提倡使用运维管理，比如模板安全组等，同时支持对应用的任何配置进行定制。

除这些常见功能外，OpsWorks还提供一些独特的功能：

• 建模和对任何应用的支持：用户可以选择在Amazon Linux或Ubuntu中部署应用。OpsWorks让用户可以按层（layer）建模，层用来定义一系列资源如何放在一起管理、配置。比如，可以为应用定义web层，其中包括EC2实例、包含RAID配置和加载点的EBS存储、Elastic IP等。也可以为每个层定义软件配置，包括安装脚本和初始化任务。OpsWorks还提供很多常用技术的预定义层，比如Ruby、PHP、HAProxy、Memcached、MySQL等。用户可以创建包含多种Python应用的大型应用，这些应用安装在Django上，连接CouchDB数据库，这些都可以使用Chef完成。
• 自动化任务：OpsWorks让用户可以自动化管理动作。包括自动化错误回复、包管理、EBS存储RAID设置等。OpsWorks支持不中断的配置，使用生命周期事件完成，比如某个自动扩展事件发生后，OpsWorks会自动更新实例的配置，以适应环境变化。
• 控制访问：用户可以选择哪些IAM用户可以访问应用资源，并为他们分配权限。

OpsWorks是AWS整体应用管理解决方案的一部分。

• AWS Elastic Beanstalk：使用常见应用容器，比如Java、PHP、Python、Ruby和.NET，构建web应用和web服务。用户只要上传代码，Elastic Beanstalk就可以自动化完成剩余工作。Elastic Beanstalk支持最常见的web架构、应用容器和框架。
• AWS CloudFormation：组件（ building block ）服务，让用户使用领域特定语言准备和管理任何AWS资源。只要定义JSON模板，就可以使用它们来部署和管理AWS资源、操作系统和应用代码。CloudFormation的目标是在不规定特定开发或运维技术的前提下，为用户提供基础管理能力。

在最后，Werner指出OpsWorks基于一家柏林公司Peritor的技术，该公司研发了scalarium，并在2012年被AWS收购。

作为以提供AWS管理为主的解决方案起家的的RightScale，AWS这一系列工具和解决方案无疑对他们构成了威胁。RightScale CTO Thorsten von Eicken在官方博客上提出了自己的一些思考。

在他看来，客户需要更全面的管理解决方案，OpsWorks的出现就是明确证明。

他提到：6年前，他们刚起步的时候，早期客户的需求十分基础，只要帮助他们迁移到云上，提供工具和预定义模板即可。到2013年，情况完全不同。

组织仍然需要“最佳实践”的帮助和建议，仍然需要工具和现成的资产。但是云计算还得适配复杂的环境，能够贯穿整个组织，任何云管理解决方案，都需要着眼未来的灵活性，以满足公司多样化和演化的需求。即使是小型企业，他们经验也更丰富，有更全面的期望，因此对云管理解决方案的要求更高。所以，仅仅满足六年前的需求是不够的。

在Thorsten看来：“异质性（heterogeneity）”是一个核心需求。从云计算早期发展开始，云计算供应商的多样性就已经体现出来。客户希望选择最佳的云，所以RightScale提供多种云平台解决方案。在当今这个“多云”的世界，人们越来越需要基于标准化框架的云管理平台，以避免任何厂商锁定情况。

Thorsten指出：

在AWS“向上层移动（move up the stack）”策略中，有一个明显趋势：依赖开源软件的专有版本，这让客户越来越依赖AWS。我们认为：这与客户的需求相违背。举个例子，几年前，我们就已经将Chef集成到RightScale中，当时必须扩展Chef的功能，以满足客户需求。后来，Chef不断演进，现在提供了缺少的功能，我们也正在准备采用最新版本的Chef，以保证为客户提供兼容他们运维工作的Chef。令人吃惊的是，即使Chef现在有这些功能，AWS还是选择了Chef的旧版本放在OpsWorks中。

……

我们的数据库模板，已经预配置为支持冗余的主从架构，应对灾难恢复，这让客户在面对最近的AWS故障时仍可运行。但OpsWorks没有解决这些问题。

……

这个初步版本的OpsWorks仅仅解决了云管理的一小部分问题。

最后，Thorsten总结：

不管怎么样，OpsWorks无疑将会在AWS诸多工具中占有自己的位置，问题在于：将重点放在一个云上的管理解决方案是否能得到更广泛应用。如今的时代，客户已经扩展到诸多大企业中，他们使用很多技术方案的组合，而且市场中也已经有诸多大云提供者，还有针对特定用途的云提供者、以及快速发展的私有云部署，这样一种单一云管理解决方案，似乎是时代的错误。

网友Jeff Schneider在评论中指出：

Amazon发布的这个服务很奇怪，因为有的功能重复，有的功能还不足。OpsWorks也许根本就不应该发布。……AWS很可能要在未来几年都得支持这个产品。AWS再次让我惊讶，他们已经开始展现出夕阳中的领导者的“风采”。

Thorsten也同意他的观点：

缺少与其他服务的集成确实让人迷惑，我想这会随着时间改变。至于与CloudFormation和其他AWS工具的重叠，我觉得AWS好像是在放出测试气球，希望用户找出哪些对他们来说最好……