Cloud Zone is brought to you in partnership with:

Ross founded the open source Mule® project in 2003. Frustrated by integration "donkey work," he set out to create a new platform that emphasized ease of development and re-use of components. He started the Mule project to bring a modern approach, one of assembly, rather than repetitive coding, to developers worldwide. He is now the Founder and CTO of Mulesoft. Ross is a DZone MVB and is not an employee of DZone and has posted 94 posts at DZone. You can read more from them at their website. View Full User Profile

What is PaaS (Platform as a Service)

04.01.2011
| 4310 views |
  • submit to reddit
With 2011 being touted as the year of the PaaS there are still many questions to be answered.  We entered the space earlier this year with Mule iON so I thought I’d offer up my $0.02.

Lets quickly go over the basics of where PaaS sits. There are 3 defined service layers to the cloud: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS).

Both IaaS and SaaS are easier concepts to understand and have been around longer. IaaS provides a virtualization layer of elastic compute resources that are available on demand, such as Amazon EC2 or Rackspace Cloud. SaaS offers applications consumable over the web with pay as you go pricing, numerous examples include Salesforce, SuccessFactors, WorkDay and Inuit.

You can think of these layers as a stack and PaaS sits in the middle, filling the void between IaaS and SaaS. PaaS is the least well defined because people have very vantage point of what a platform is. Yefim Natis for Gartner is quoted describing PaaS as “Anything that is not a business application or systems infrastructure is PaaS”. To me this is middleware and by this definition the PaaS is going to have a massive impact the way software is built.

Cloud Stack

 

It’s about the apps

PaaS changes the way we build applications. It provides a development platform for building and running applications in the cloud. Like enterprise software platforms, the PaaS universe is evolving to serve various development communities (e.g., languages) as well as serve different functions. We’ve already seen successful incarnations of PaaS with Heroku (Ruby) Google App Engine (Python, Java), Elastic Beanstalk (Java) and Azure (primarily .Net) with many more cropping up (such as PHPFog, AppHarbor, no.de). Most have been targeted at a specific language community, but I fully expect PaaS offerings to be launched over the next  year targeted at specific verticals and niche applications. In fact Force.com is the daddy of niche PaaS since it catered exclusively for SalesForce users and even has its own language. This is becoming a trend with YuppTV and WorkDay making PaaS announcements for their own offerings in the last couple of weeks.

Why PaaS?

Up to now the cloud movement has been more about the business and operations but PaaS is all about developers and building apps. With PaaS developers can now spin up their new applications in minutes without going through the usual rigmarole of installing database, application runtime and other 3rd party software, before writing a line of code. Also the PaaS provider manages scalability reliability, patches and upgrades. Freeing the developer to just think out one thing – their app.

I think the biggest gain is speed and agility to get new apps up faster, easier, and with less overall costs. Users gain from having a ready-made, scalable and reliable run-time. It is available immediately and can grow as your app grows or be switched off at anytime. Another positive is that applications should be managed purely on SLAs (Service Level Agreements) focusing the developer on managing their application not the architecture or infrastructure.



All sounds good but…

Of course there are always some trade-offs and with PaaS you lose is some freedom to customize (I’m not sure that’s a bad thing, but I know some developers that do).  Most PaaS’s are somewhat restricted environments, in terms of the ready-made environment that the PaaS vendors provide.  Your applications need to work within the bounds of the platform, which means that not all PaaS’s are suitable for all applications that we build. For example Google App Engine (GAE) puts many restrictions on what can be done to the dismay of some of its users. The good news is that there will be different flavours of PaaS offerings to serve different vertical needs. So for the user there will be trade-offs, they will need to think about the potential for PaaS proliferation, and how they will have applications talk to each other that may be running on different PaaS’s.

What about lock-in?

This is always a concern when selecting a platform. There is always going to be some lock-in: no matter what software you write you need to make some decisions about the platform and technology you use. One of the reasons open source has proliferated all areas of software development is that it gives you control over your decisions – you are not beholden to any one entity. Going with a PaaS based on open source software means you should have the option to move your applications from the cloud back behind your firewall.  With the exception of Force.cm many of the first round of PaaS offerings are based on open source software.  The successful ones allow users to easily move their applications between the cloud and on premise.

Mule iON

So far I have just been talking about PaaS in general, but there are different categories of PaaS.  We launched Mule iON this year, an integration PaaS (iPaaS) focusing squarely on integration applications and web service creation. Integration applications are becoming increasingly important with the proliferation of SaaS and APIs. The abundance of new services and publishing of APIs is making the holy grail of composite or integration applications possible. I will be talking more about this and introducing the what and why of iPaaS in a follow-up post.

References
Published at DZone with permission of Ross Mason, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)