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

阅读数:1043 2013 年 2 月 28 日

话题:AWSDevOps架构

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 整体应用管理解决方案的一部分。 image

  • 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 好像是在放出测试气球,希望用户找出哪些对他们来说最好……