From this I started thinking; “Is there a solution that comes closer to delivering the original marketing hype?”
When I refer to “the marketing hype”, I am referring to the general notion of a cloud as a place where you build and run your application without concern for servers, operating systems, operations, data centers, networks etc.. etc.. A place where developers can deploy without experience in infrastructure architecture.
From the outset, Platform as a Service has always existed. The slide presentations and articles that “demystified the cloud” repeatedly from 2008-present with endless definitions, included AppEngine (Google), Force.COM (Salesforce) and Heroku as examples of PaaS. The first two were really designed to be complementary to the relevant Software as a Service (SaaS) offering, a custom code capability, tightly integrated into the primary service. Heroku was a more independent offering and always receives good reviews and some reasonable customer successes. EngineYard, PHPFog and a number of others have also shown what can be done.
What has changed now, is some chinks in the armor of IaaS in the form of complexity, reliability and availability. People know that its not as easy as it looks, and begin look elsewhere for the greener pastures and the promises of simplicity.
Enter from stage left, Platform as a Service (PaaS). A couple of vendors with a traditional footprint in larger enterprises have entered the market. Redhats - OpenShift and VMwares - Cloud Foundry are good indications of a “coming of age” for PaaS platforms as a viable alternative.
So what does PaaS have to offer that is more cloudy?
The Infrastructure as a Service (IaaS) service paradigm still sits squarely in the gap between development and operations. Platform as a Service (PaaS) moves this boundary more firmly into the sphere of influence of the developer. To be clear, there is still a gap to be bridged. Developers traditionally don’t do production, but in the PaaS model developers only need to consider production in the context of the application design and not infrastructure. The issues of infrastructure reliability, scalability etc.. are more clearly the responsibility of service provider.
The potential to realize the hype of the cloud is clearly evident. The abstraction of developers from the physical world is fundamental to the purest visions (thinking hype as I write this) of cloud computing. It is not without its pitfalls. I see a few of largish hurdles;
- Common infrastructure architecture – SalesForce.COM has promoted the efficiency of a common infrastructure, but they do this with a uniform code base. Can you achieve the commonality of the architecture in a PaaS environment to deliver the simplicity and economies of scale required to allow developers to truly focus on code. Will we start to see PaaS becoming complex and therefore requiring specialist skills to manage deployment.
- Time line delays – The more you abstract from traditional infrastructure design, the farther away you are from addressing the needs of enterprise users. Enterprises users like to understand the physical, particularly for comfort in the area of assurance, security and compliance. This may delay the rate of adoption and the profitability of a service. VMware is playing the “private PaaS” card in this space and advocating the “hybrid” model.
- Fear of lock-in – In recent times there has been lots of discussion on PaaS lock-in and API Lock-in. The reality IaaS presents less lock-in because the boundary between infrastructure and application tier is historically well understood by IT management and professionals. We know what to look for.. There is however, a tendency for developers to maximize the features of the application layer for any given product, which creates a dependency on whatever value-add the PaaS provider chooses to provide. A historically well known strategy for “Java Reference Implementation” application servers or any other code deployment environment.
PaaS has its supporters, but also its skeptics. Adrian Cockcroft for instance, thinks PaaS has some work to do and recently classified Cloud Foundry as a toy for anything that requires scale.
What PaaS needs is a anchor customer with a large workload to get some credibility, validate the model, evangelize the capabilities, lead a community of like minded businesses. This will uncover real-world solutions to problems and give greater confidence in the platform.
Contributed by: Brad Vaughan