For those who continue to view Amazon(s amzn) Web Services as bare-bones infrastructure, the company’s new OpsWorks may come as a shock.
The service, based on technology Amazon acquired when it bought Peritor last year, lets AWS users configure and manage their applications more easily without resorting to custom tools. According to Amazon, OpsWorks — which uses the OpsCode Chef framework — handles rollback, patch management, auto scaling and auto healing.
The service — free to users of EC2 and other AWS services — takes on some of the tasks traditionally done using Scalr, Rundeck or Opscode Chef or Puppet (see disclosure.) Although most of those other tools do higher level work than what OpsWorks promises. And, as one GigaOM reader commented, OpsWorks also takes aim at some of the tasks that Rightscale takes care of for AWS customers.
But Dan Belcher, co-founder of Stackdriver,a Boston-based startup that works with AWS, said it is actually a boon to both customers and many partners in the Amazon ecosystem. “Customers have struggled since the birth of AWS to come up with a reasonable way of organizing their resources. Everyone does it differently,” he said.
“Because the taxonomy of OpsWorks is available by API customers can create dashboards and policies to manage their resources. Because of that API, we literally woke up this morning and supported OpsWorks,” he added. There’s more here on the Stackdriver blog.
According to Amazon’s press statement OpsWorks Amazon can:
- Create a Stack. A stack contains the set of Amazon EC2 instances and instance blueprints, called layers, used to launch and manage these instances (e.g., all the PHP servers and the MySQL database used for your production web application). Apps, user permissions, and resources are scoped and controlled in the context of the stack.
- Define the layers of your stack. A layer defines how to set up and configure a set of instances and related resources such as volumes and Elastic IP addresses. AWS OpsWorks includes layers for common technologies such as Ruby, PHP, HAProxy, Memcached, and MySQL, and makes it easy to extend existing layers or create custom layers. Lifecycle events can be used to trigger Chef recipes on each instance to perform specific configuration tasks. For example, the deploy event could trigger a script to create a database table for a new app.
- Assign instances to your layers.Create instances in configurations you choose, including instance size, Availability Zone, volume creation and RAID configuration, EIP, security group, and operating system. Start your instances, or apply them to auto scaling groups.
- Define and deploy your apps. To define an app, tell AWS OpsWorks where to find your code and specify additional deployment tasks, such as database configuration. AWS OpsWorks supports a variety of repositories such as Git, SVN, HTTP, and Amazon S3. When you deploy the app, AWS OpsWorks will pull code from your repository, place it on the instances, and run the specified deployment tasks so that your application is properly configured. Afterwards, you can view your app’s deployment logs to review the deployment steps, verify its functionality, and debug any issues.
For a brief intro to OpsWorks, here’s the Amazon video.
The addition of OpsWorks to the AWS repertoire shows how Amazon is serious about adding higher-level and more intricate services to its stack as it hopes to lure more enterprise accounts. Those additions can be a double edged sword — they add functionality that many customers want but are getting from open-source and third-party toolsets. What’s good for AWS and some of its customers is definitely not a plus for some AWS partners.
Disclosure: Puppet Labs is backed by True Ventures, a venture capital firm that is an investor in the parent company of this blog, Giga Omni Media. Om Malik, founder of Giga Omni Media, is also a venture partner at True.