PaaS as Infrastructure

The blurring line between PaaS and IaaS 

The core of IaaS services is centered around  Compute, Storage Network however over the past years the infrastructure moved up the stack and includes more application services such as Database as a Service, Hadoop Map/Reduce, and application lifecycle services. 

On the other hand, PaaS services offer similar services through the PaaS platform itself with the main difference being that quite often those services were designed to fit only the application that runs on that particular PaaS.

So rather than the traditional view, where we draw a clear line between the IaaS and PaaS layer we need to view them differently, where the PaaS and IaaS layers overlap each other on the software services layer.

 

IaaS and PaaS share a similar technology stack

A close look into the OpenStack infrastructure shows that even on the infrastructure level running the compute, storage and network services relies on messaging services such as RabbitMQ, databases such as Postgress, a load balancer such as Nginx and other software services. Running these software services for our infrastructure is not much different than running our apps.  With both the infrastructure and application we would need to address the scalability and high availabilityof these services and manage them through our infrastructure.

If that is the case wouldn't it make sense to share the same underlying technology to run our infrastructure and our apps?

Sharing the software services between your IaaS and PaaS

A typical public PaaS platform is built out of two main parts - a self-service portal, and a backend system that runs our apps.

With many of the public PaaS solutions such as GAE, Heroku the backend that runs our PaaS is treated as a blackbox.

Amazon Elastic Beanstalk does things differently in that respect - as it took a bottom-up approach. It uses the same AWS infrastructure to run Elastic Beanstalk and the infrastructure - this provides a lot of flexibility to its users, and equally as important, consistency between the way they run and manage their app and infrastructure. VMware took even a bigger step in this regard with CloudFoundry and BOSH and made their entire PaaS backend open source which gives users even greater flexibility. With Cloudify we took this idea a step further by introducing the concept of recipes into the core of the Cloudify infrastructure, and recently introduced our integration with Chef in a way that will enable users to run their Chef cookbooks as part of Cloudify. Chef has already gained popularity as a configuration and automation framework for setting up many of the OpenStack cloud deployments. Having Chef tightly integrated into the PaaS layer, simply put, makes perfect sense.

Example - Building your own RDS with Cloudify

To illustrate the idea of how we can use share the same deployment framework between our IaaS and PaaS layer I'll pick one of these software services to demonstrate the idea with. In this particular case, I've chosen to use a database as a service. Database as a service is often a good reference for a service that fits in both our infrastructure and application. Here is how we can easily set a database as a service with Cloudify:

1. Directly through the use of Cloudify recipes

If you allready developed your scripts for setting your database you can use cloudify recipe to wrap those script into a service. 

 Here a snippet of how that would look like:

service {
	name "mysql"
	icon "mysql.png"
	type "DATABASE"
	elastic true
	numInstances 1
	minAllowedInstances 1
	maxAllowedInstances 3	
	compute {
		template "SMALL_LINUX"
	}	
	lifecycle{
 
		install "mysql_install.groovy"
		start "mysql_start.groovy"
		startDetectionTimeoutSecs 900
		startDetection "mysql_startDetection.groovy"
		stopDetection {	
			!ServiceUtils.isPortOccupied(jdbcPort)
		}
        }	

You can refer to the full MySQL recipe here.

2. Through the use of Chef cookbooks

If you are already using Chef you can plug-in to the Chef MySQL cookbook by extending the Cloudify recipe to use Chef, as you can see in the snippet below:

service {
    extend "../../../services/chef"
    name "mysql-vanilla"
    type "DATABASE"
    numInstances 1
…
}

In addition to that you could attach Chef attributes and run parameters into the Cloudify recipe that will tell Chef which cookbook and recipe to run:

runParams = [
  "mysql": [ "bind_address": "0.0.0.0",
             "tunable": ["query_cache_limit": "2M"]  
  ],
  "run_list": ["recipe[mysql::server]"]]

You can read the full details on how to run Chef with Cloudify in our documentation.

Running through bare metal environment

Even in the case where we share the same software services through our infrastructure and application, we tend to run them differently.

Quite often infrastructure services will run on bare-metal environments, as we don't want to create dependencies between our virtualiation layer and the underlying infrastructure that runs it.  

To enable this level of flexibility, we need to abstract the underlying compute layer from our service orchestration layer. In this way, we can use the same recipe and deploy it on either a bare-metal environment or a virtaulization layer. (Read: Configuring a Traditional Data Center [BYON])

Final notes

Up until recently, PaaS and IaaS were treated as two separate and closed entities and the integration between the two was done pretty much in a blackbox approach. The fact that both the IaaS and PaaS underlying infrastructure were closed was the primary reason behind this.

Now with the growing adoption of open source IaaS such as OpenStack and CloudStack, and similarly with PaaS such CloudFoundry and Cloudify we have the opportunity to change this paradigm. There isn't much of a reason why we shouldn't be able to share the same orchestration, and configuration layers between our IaaS and PaaS layers. Amazon Elastic Beanstalk is a good reference why this makes a lot of sense.

Special thanks

Special thanks to Boris Renski who was the main inspiration behind this post.

References:

• Presentation on the Chef Meetup Group
• Online presentation