RightScale Blog

Cloud Management Blog
RightScale 2014 State of the Cloud Report
Cloud Management Blog

Thoughts on AWS OpsWorks Application Management

Since RightScale pioneered the category of cloud management six years ago, we’ve watched a variety of players large and small offer software and services targeted at some form of management of cloud applications and resources. We like to keep tabs on these changes, especially from the point of view of how new technologies affect companies' choices as they adopt cloud computing. Last week Amazon Web Services introduced a new application management service called OpsWorks, which joins its patchwork of management tools for its cloud services that includes CloudFormation, AWS Console, and Elastic Beanstalk. While still in beta, OpsWorks is an interesting service and we’d like to share our thoughts on what it means for customers – beyond the fact that it’s a clear validation of the need for a more comprehensive management solution.

First, a bit of context. In the years since RightScale started in 2006, we’ve always focused on customers who were ready to do something in cloud. But as time has passed, we’ve seen a huge shift from startups and web 2.0-style companies, who were the first to adopt cloud, to central IT shops in large enterprises grappling with cloud strategies for diverse application portfolios. With this shift has also come a change in requirements for any cloud management platform.

In the early days, requirements from our customers were pretty basic: “Please tell us how to get our web app into the cloud and help us with tools and preconfigured templates.” To a large degree, these requirements were legacy-free. As we fast-forward to 2013, the picture is very different. Organizations still want “best practices” help and advice, and they still want tools and ready-to-go assets. But cloud computing also has to fit into a complex environment that reaches throughout an organization, so any cloud management solution needs to enable future flexibility to address companies’ diverse and evolving needs. Even smaller enterprises coming to the cloud today have more experience and more sophisticated expectations, raising the bar for what they want out of their cloud management solution. As a result, those basic requirements of six years ago are no longer sufficient.

One key new requirement centers on heterogeneity. It has been apparent from the early days of cloud computing that there would be multiple, significant providers for public and private clouds as well as many specialty cloud providers. Customers have told us that they want the ability to choose the best cloud, public or private, for each of their applications. As a result, we’ve worked hard to create a sophisticated multi-cloud platform that integrates with the varying cloud APIs and, more importantly, bridges the different behaviors of each cloud provider. In today’s multi-cloud world, we see ever-increasing demand for a cloud management platform that provides a standardized framework that helps avoid lock-in to any single cloud provider.

Customers have also told us that they value the flexibility and freedom of choice that comes with open approaches and standards. One of the trends that has been evident in the AWS “move up the stack” is a reliance on proprietary versions of open source technology that seems designed to create greater stickiness for AWS-only solutions. We believe this approach is contrary to what customers want. As an example, at RightScale, we support a variety of multiple load balancing solutions from AWS’ Elastic Load Balancer and Riverbed’s Stingray Traffic Manager to the open-source HAproxy. An example where we forged our own path is when we integrated Chef into RightScale a few years ago and had to extend Chef with additional functionality to meet customer needs. Since then, Chef has continued to evolve, now offering that missing functionality, and we’re in the process of aligning with the latest versions of Chef so that we can offer our customers the choice of any Opscode-compatible Chef offering. Surprisingly, given the current capabilities of Chef, AWS has chosen to fork an older version of Chef for the OpsWorks solution. At the same time, RightScale also supports Puppet and simple shell scripts, since many customers prefer those options and because heterogeneity is the norm in the IT world.

Lastly, RightScale cloud experts have spent a lot of time working with customers to help them architect resilient multi-cloud and multi-region solutions. By working with cloud leaders to deploy their production workloads into the cloud, we have evolved our solutions to fit these sophisticated needs. For example, our database templates are pre-configured for a replicated master-slave for disaster recovery, which enabled our customers to stay up and running during recent AWS outages. OpsWorks doesn’t address these issues.

OpsWorks in this first release addresses only a small part of the cloud management challenge. On the plus side, it has a wizard-like setup flow for basic configurations that is targeted at the DevOps community and possibly the PaaS user. It will be interesting to see how this interface evolves as more advanced features are added. Overall, OpsWorks validates the notion of the need for a higher-level cloud management platform like RightScale that manages the interaction of users, application blueprints, and cloud infrastructure resources. AWS is also following RightScale’s lead by adopting a template approach to server configuration as opposed to virtual machine images that are challenging to update and manage. Our introduction of ServerTemplates™ in 2006 answered the need for fully automated configuration management, a requirement that remains just as critical today for companies of any size who want to create an efficient, automated IT infrastructure.

Ultimately, while OpsWorks will no doubt take its place as another tool in the AWS wheelhouse, the question is whether a management solution that is so focused on a single cloud will find broad adoption. At a point in time where the customer base has broadened to include many large enterprises that use a diverse portfolio of technologies and where the market has broadened to include multiple public mega-clouds, many specialty cloud providers, and fast multiplying private cloud deployments, such a single-cloud management system seems almost anachronistic.

I’m interested in hearing your thoughts, so please share your comments below. And better yet, continue the discussion by joining us at the upcoming RightScale Compute conference on April 25-26 in San Francisco. It is the first truly customer-focused multi-cloud conference, where you’ll be able to hear from a variety of companies using cloud as well as leading voices in the cloud community. We’ll feature content that covers everything from hands-on training to business strategy to technical deep dives.


Comments

Thorsten, Your comments echo those I made last week: http://www.transcendcomputing.com/2013/02/oddly-amazon-launches-opsworks/ This is an odd service for Amazon to release due to the amount of duplicate function and lack of features. OpsWorks probably shouldn't have made it out of the gates. The achilles heal of PaaS will be the political difficulties related to retiring mistakes. AWS will most likely have to support this for years to come. For AWS to impress me (again), they'll begin to show leadership in sunsetting services. Jeff
Jeff, thanks for the comment, the lack of integration with other services is indeed puzzling--I assume that will come over time. Wrt overlap with CloudFormation and other AWS tools it feels like AWS is launching trial balloons and expects users to figure out which is best for them...
Hey Thorsten, I've been using a service called Scalarium which essentially is what OpsWorks has become for a number of years since we moved off of RightScale (I'm sure you remember). And essentially, believe it or not: what you call lack of features — that is all we required. Scalarium is/was fully customizable through Chef. Something you guys are offering as well nowadays. And at the same time it comes with the benefit of not having to run a Chef server setup yourself. It also makes a few assumptions/choices for the user as to how the deployment should run, and we welcome these choices. Chef (specifically chef-solo) enables us not just to deploy on Scalarium or OpsWorks. We also use the same recipes to bootstrap developer VMs (Vagrant) or bootstrap a couple servers which are not on AWS. So there's no real vendor login or similar either. Add to that, if I decided to move to a full chef server setup, I'm almost there. I am sure OpsWorks will integrate with other services down the road — they already do a great deal with IAM. I also think they will keep this tool as open as possible: in case you noticed it comes with a haproxy role when technically there is a service (ELB) for that? With OpsWorks I can also run my own Memcached servers if I don't want to use ElastiCache. I can install my own MySQL server if I don't want to use RDS and the list goes on. As for adoption — I'm pretty sure their pricetag will be convincing for people who are running on top of AWS already. And yeah, point taken, AWS will not support Rackspace and whatever else is out there. But that wasn't a problem for us either. AWS is still the leader in cloud computing and nothing right now comes even close. I personally welcome this tighter integration (of Scalarium) into the company which owns and runs the PaaS. Looking forward to the service and stability and wish them overall best of luck.

Post a comment