- March 18, 2013
- Posted by: Nati Shalom
- Category: Uncategorized
this post I’ll try to zoom in to that void between PaaS and DevOps.
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.
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
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
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
In other words, OpsWorks is aimed at filling a void between the Beanstalk
model and the DIY (do it yourself) model.
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
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.
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.
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.
do you think? Is OpsWorks a new kind of (Composable) PaaS or Cloud Application
it really matter?
- GigaSpaces Cloudify & VMware Cloud Foundry the new
- 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