This month Amazon announced AWS OpsWorks, which is the result of their acquisition of Peritor and the embedding of its Scalarium platform within AWS. OpsWorks is a new framework for simplifying the deployment of applications on the cloud.
Given that Amazon already has a few frameworks automating application deployment, such as CloudFormation and Elastic Beanstalk, I find the addition of OpsWorks to the mix to be an important recognition of the void that exists between the existing PaaS and Automation frameworks.
In this post I'll try to zoom in to that void between PaaS and DevOps.
I'll start with a post that I wrote a few months back - PaaS Jailbreaker, in which I pointed out the two models for delivering applications in the cloud, from PaaS to DevOps. In this post I suggested that rather than thinking of the two models as separate entities, it would make sense to combine the two.
James Urquhart wrote an excellent article on GigaOM - Is your PaaS composable or contextual? In his article, Urquhart refers to the differences between the two approaches to PaaS as composable vs contextual. A good example for a contextual approach is the plugin-based approach implemented by Heroku or Force.com. Plugins provide a flexible way to extend the platform, but the extension needs to fit into a certain model. For example, in the case of Heroku you don't control the actual VM or underlying cloud infrastructure, nor the network that is provided for that infrastructure. A composable approach, on the other hand, is focused on the composition of the different application components and, as such, doesn't need to assume anything about the underlying infrastructure that runs the components of our application. Amazon OpsWorks fits into that second category.
Urquhart specifically pointed out Dietzler’s Law for Access as a way to illustrate the limitation of the contextual approach. While the contextual approach (customization via plugins) provides some degree of flexibility, it is the 10% of the things that you can't control that matters most, as they define whether you'll be able to be deliver your application the way you want to:
Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create, and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions, and users always want 100% of what they want.
Interestingly enough, Amazon launched OpsWorks a week later.
The introduction of OpsWorks was quite interesting as it came two years after Amazon launched its Heroku/GAE equivalent - Elastic Beanstalk. I found the announcement by Amazon quite interesting. The fact that they had a PaaS offering already and still found it necessary to launch a new platform for delivering applications is:- Acknowledgement that the current PaaS offering isn't a one-size-fits-all solution, and despite the various extensions that Amazon delivered to support other languages within the platform, there are still many applications, and consequently organizations, that do not fit into the Elastic Beanstalk model.
- Recognition of the fact that within the realm of the application delivery, there is a need for a more open framework for delivering applications, and that realm needs to take a more "composable" approach. In the case of OpsWorks, the composable approach happens to rely on Chef and the OpsWorks orchestration layer on top of it.
Werner Vogels uses the control vs convenience tradeoff as a way to position the various AWS offerings, as he pointed out in his post: Expanding the Cloud - Introducing AWS OpsWorks, a Powerful Application Management Solution:
With the launch of AWS OpsWorks customers now have a very powerful solution that allows them to manage their application easily without giving up control.
In other words, OpsWorks is aimed at filling a void between the Beanstalk model and the DIY (do it yourself) model.
Interestingly enough, I used to describe the various solutions in the cloud stack in very similar terms to the way Vogels does, with the slight difference that I used the term Control vs Productivity and looked at a broader scope between IaaS and PaaS.
OpsWorks vs Other Kinds of PaaS
In a discussion I had on that subject last week with Ran Tavory and Ori
Lahav as part of the Reversim podcast, we seemed to agree that currently, there
is space for both models of PaaS - the OpsWorks model (composable) and the Beanstalk
model (contextual). Having said that, when I framed the question "which of
the frameworks/approaches will run 80% of the cloud workload in the future?"
we all seemed to agree that the answer would more likely be OpsWorks. The last
point led me to believe that while there is space for the two models right now,
this may be only a transition stage, while over time we’ll see that first
generation PaaS and the likes of Beanstalk will be replaced with second generation
PaaS offerings, as in the case of OpsWorks.
OpsWorks and the blurring line between PaaS and IaaS
The fact that OpsWorks runs on Chef, as do many of the IaaS services in many cloud infrastructures, also raises the question whether it is right to draw a line between our IaaS services and applications, as I pointed out here: The blurring line between PaaS and IaaS.
OpsWorks and Cloudify
OpsWorks and Cloudify follow the same foundational concepts from an architecture perspective - both frameworks integrate with DevOps tools like Chef and add an orchestration layer on top of it, making it easier to compose various parts of the application stack. In many ways you can think of Cloudify as a framework for building your own OpsWorks.
PaaS, DevOps and Everything in Between
Vogels seems to avoid labeling either Beanstalk or OpsWorks as belonging to the PaaS category. Urquhart, on the other hand, looked at the two as two kinds of PaaS solutions - Contextual (Beanstalk) vs Composable (OpsWorks).
One thing that is clear to me is that the current PaaS category is too narrow to fit all the different kinds of PaaS.
Looking at the definition of PaaS in a broader context, I would frame it as a "Platform for running and managing applications on the Cloud." In that context, the way we choose to run those apps becomes an implementation detail. Having that context in mind, I tend to look at both Beanstalk and OpsWorks as two kinds of PaaS offerings. What we’re missing at this point is a simple way to label those different categories.
One approach would be to use Urquhart’s definition (“Contextual vs Composable) which categorizes the different PaaS solutions based on the approach through which they choose to deliver the apps. We can also look at CloudFoundry vs GAE as open vs closed. Another possible category is PaaS frameworks (i.e. frameworks that provide middleware to build your own PaaS), vs PaaS as a self-service solution.
RightScale, on the other hand, uses the term Cloud Application Management to define a similar category and looks at PaaS as a private use-case for using the Cloud Application Management framework. We also had internal debate on that subject at GigaSpaces and couldn't come to a final agreement on where to draw the line between the different categories.
What do you think? Is OpsWorks a new kind of (Composable) PaaS or Cloud Application Management Platform?
Does it really matter?
References:
- GigaSpaces Cloudify & VMware Cloud Foundry the new PaaS Jailbreaker
- Is your PaaS composable or contextual? (Hint: the answer matters)
- Mapping the Cloud/PaaS Stack
- The blurring line between PaaS and IaaS
- Expanding the Cloud - Introducing AWS OpsWorks, a Powerful Application Management Solution
- Amazon adds OpsWorks application life cycle
management to AWS cloud
