Guest post by Yaron Parasol, Director of Product Management, GigaSpaces

I’d like to start with a brief overview of the evolution of the cloud – and why I think a new approach to PaaS solutions is needed – and the best scenarios for this to come into play.

First there was IaaS. Cloud was created with the notion of IT agility and cost-reduction. You need servers? No problem! Forget about red tape, forget about sys admins. You create an account and in few clicks you select the hardware profile and OS image you need, and voila, your server is out there, ready for you to use. No hassles, immediate gratitude.

Well, this is true as long as the images you get form your cloud provider match your needs. If you have custom needs, you will have to create and maintain your own image. So, you need the sys admin’s knowledge. However, we’re also seeing a change in methodology here – sys admins no longer need to install the servers once they’re up. Instead, they provide their expertise using approved and maintained images on the cloud. Application developers can choose the right image for them and from that point on, create virtual machines in the amount and hardware size they need for their applications.

Now let’s switch to PaaS. The idea of no-ops is the guideline for many of the existing PaaS offerings. Their use cases and features are all about developers. As Michael Cote put it:

“The point of PaaS is to make a developer’s life even easier: you don’t need to manage your cloud deployments at the the lower level of IaaS, or even wire together your Puppet/Chef scripts. The promise of PaaS is similar to that of Java application servers: just write your applications (your business logic) and do magic deployment into the platform, where everything else is taken care of.”

Developers need to deploy applications to the Cloud. They don’t want to care about the OS but they also don’t want to care about platforms, load balancers etc. They want to focus on what they know – writing code.

This is definitely a very productive approach for some developers and some applications. Reality shows that a big portion of Cloud users don’t find these solutions a good fit for their purposes. These users continue to deploy and manage their applications on infrastructure clouds, as if they were running on premise leveraging the good old Ops folks. Others have taken a more agile approach, using configuration management and automation tools such as Chef.

These users chose not to use PaaS because they need flexibility and control. PaaS doesn’t seem to answer a lot of the current IT challenges – see for example here and here.

Existing applications with a variety of platforms, some using extremely complex topologies (like Hadoop, or a sharded MongoDB setup) are some of the reasons why PaaS won’t cut it for many users.

They would like to install their chosen versions of their preferred platforms, use their OS image, with their configured security groups, tune them in a manner that fits their applications and deploy their applications with the topology they choose.

Chef, like other DevOps tools, go a long way here and helps to achieve the flexibility while re-establishing a new agile relationship between Dev and Ops. Ops bring in their knowledge and skillset, but they document it and maintain it as code in a more structured and configurable way. This in turn gives the application guys the agility they need, putting a complex application to work in a single click and eliminating the platform black box experience which they dislike so much.

Application vs. Separate Platforms

However, DevOps tools still fall short when it comes to managing applications. They are not aware of the application’s inner dependencies. They don’t know how to monitor the application, scale it or even run a complex multi-tier recovery process. Most of these tools can’t even provision an entire application on the cloud.

So what if you could extend the DevOps experience to apply to the entire application lifecycle?

What if you could use Chef and the likes for installation but not stop there – automate things like failover and recovery, and even monitoring and scaling? You will still have all the Ops wisdom tailored to each of your applications and be able to automate any of your existing applications without re-architecting them.

This is exactly our take on PaaS, a DevOps style process that can describe any application’s lifecycle on any runtime environment, providing full automation without taking away the control.  And this is exactly what we set out to do with our Open Source PaaS platform – Cloudify, borrowing the idea of recipes but extending it to be application-centric and not infrastructure-centric.

The recipe describes the application dependencies and lifecycle events externally without any code or architecture change.

lifecycle{

init "mongod_install.groovy"

start "mongod_start.groovy"

postStart "mongod_poststart.groovy"

}

view rawmongod.groovyThis Gist brought to you by GitHub.

See how to create your own recipes here.

Mapping events like installation, start, post-start and stop to scripts or Chef cookbooks, exposing groovy andREST interfaces for context sharing and dynamic configuration and even provide a way to describe monitoring techniques, scaling rules and process “liveness” detection.

So think about it this way: while most PaaS services come with a catalog of predefined application blueprints, allowing the user to control only the application code, this new kind of PaaS stack, allows the user to define the blueprint, that is – any blueprint!

So, the recipes combine the Ops expertise with the power of automation for the developers. They completely remove the lock-in risk from the application-stack perspective.

You can read more the recipes, download Cloudify and experience it yourself or even join the community and influence the roadmap at cloudifysource.org. Or you can come see more when we present at HP Discover next week in Las Vegas.