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