Alex Freedland, Co-Founder and Chairman at Mirantis, wrote a controversial post in which he basically marks the breakup between some existing PaaS frameworks and OpenStack - CloudFoundry specifically.
Personally, I think that Freedland highlights a growing sentiment in the OpenStack community. The fact that OpenStack is open source should change the way we think of the PaaS and IaaS layers, as I noted in one of my earlier posts, The Blurring Line Between the IaaS and PaaS Layers.
In the case of CloudFoundry and OpenShift specifically, PaaS was built with the assumption that the IaaS layer provides basic compute, storage and network services and all the rest should be handled at the layers above. The reality, though, is that the IaaS layer is continuously moving up the stack in a very similar way to which Amazon has grown its stack.
This shift up the stack changes many of the built-in design assumptions of many existing PaaS products, CloudFoundry and OpenShift specifically. For example, the way we handle user-security, metering and scheduling is often in a completely parallel stack that exists in both the IaaS and PaaS layers. This leads to a lot of unnecessary redundancy and therefore complexity and inconsistency. On top of that, the middleware stack (Ruby vs Python) also leads to another layer of redundancy and complexity, especially for organizations looking to deploy the end-to-end stack. For example, why would we need two different models to handle database availability? Why do we need different agent systems to monitor our instances? If we already have a model to detect and monitor device failure, why do we need to add another failure detection mechanism on top to detect the same failure? In many of these cases, we already built solutions at the IaaS layer and we only need to make the right use of them.
Now there is nothing wrong with CloudFoundry or OpenShift; they do exactly what they were designed to do. That being said, on OpenStack we can do things differently than we can on other closed IaaSs, creating a great opportunity to not just simplify things, but do do things that are much harder otherwise. Let me explain.
The Need for a Native Open PaaS
A native open PaaS is a PaaS that comes with a much thinner stack and relies more heavily on a common set of services provided by the IaaS layer for user management, metering, etc.
Its main focus is to provide a higher level abstraction that would simplify the deployment and management of applications on OpenStack.
Another area that a native open PaaS differs from its existing predecessors is the native DevOps support. Many of the existing PaaS platforms were built with the assumption that developers only worry about their code. However, in real life, continuous delivery or deployment can expose changes at all layers, including the configuration of the application and PaaS stack, and should therefore be consistent with the way updates and configuration management takes place in the IaaS layer.
A native open PaaS should leverage the same DevOps tools used by the IaaS layers to push updates to the application layer.
The Missing Piece in the Puzzle - Open DevOps Automation
Earlier this year, Amazon launched a new piece in their stack - OpsWorks, which basically filled a gap between their existing IaaS and PaaS layers. They refer to it as DevOps automation.
AWS Stack
AWS OpsWorks provides an orchestration and workflow service that currently runs on top of Chef and provides users with the ability to build their own custom stacks on top of AWS, as I noted in my earlier post DevOps, PaaS and Everything in Between.
The OpenStack Heat project fills the AWS CloudFormation box in the above image, providing a basic templating model for orchestrating and automating the deployment of software stacks on OpenStack.
I believe that OpenStack also needs to fill in the OpsWorks box as higher level abstraction for application deployment. Given the open nature of OpenStack and the private cloud focus I think that this piece should be more open and support not just Chef, but also other configuration management frameworks such as Puppet, Ansible and Salt through Heat. There should also be a much stronger emphasis on the application orchestration piece to enable automation of complex application related processes, such as continuous delivery, deployment automation, recovery and scaling and for that we need a more advanced rule engine to support those advanced flows.
If done right, tools like OpsWorks in conjunction with Heat can serve as a great foundation for PaaS. At the same time, I can see many cases in which users would simply use something like OpsWorks directly without needing another layer of abstraction on top of it, hence why it makes sense to keep those boxes also as independent services.
Consolidating the Efforts
There are currently many projects and initiatives in the OpenStack community, each trying to address different aspects of the application deployment and management complexity. Let me name a few:
Adrian Otto, Principal Architect at Rackspace, announced Project Solum support from Rackspace, eBay, Red Hat, Ubuntu / Canonical, dotCloud as well as GigaSpaces.
Some of the guys from my team at GigaSpaces are also going to give a talk during the OpenStack Hong Kong event about delivering the equivalent of Amazon OpsWorks on OpenStack - See the details here.
There are many other related projects and initiatives that I haven’t listed here and many others that are probably being worked on as we speak - it is beyond the scope of this post to list them all.
Looking Into the Future
I think that this is a great and an exciting opportunity for the OpenStack community to deliver on its promise and really push the open source cloud forward. It can do so by breaking the traditional barriers between IaaS and PaaS, and go above and beyond what we've seen normally in closed source clouds. There are many areas in which such an approach can lead to an even greater degree of innovation. For example, think about bringing the network and the application together, making multi-site deployment a breeze.
I look forward to meeting everyone on the Solum team next week during OpenStack Hong Kong and to being a part of this next wave of the revolution.
References
-
Project Solum announcement
-
Mirantis To PaaS Vendors: Stop Fighting OpenStack Gravity
-
Rackspace jumps on bandwagon with open source PaaS project
- DevOps, PaaS and Everything in Between
