In my previous post in this series Graduating Cloud to the Enterprise, I covered Infrastructure-as-a-Service and highlighted some of the key gating factors for mass adoption by large enterprises. In this post I will analyze the benefits and challenges of Platform-as-a-Service (PaaS).
To give you good sense of what Platform-as-a-Service would mean I will start with an analogy with a relevant topic.
Say you are FremantleMedia and you are in the business of producing and hosting American Idol. Since your core business is creating and delivering an entertainment programs, building and owning an auditorium/theater probably figures last in your list. Your other choice is to rent the Kodak Theater. With your rental comes all the necessary components you need to create and deliver the show – namely the studio, the podium, the green room, A/V system, the lighting, the chairs, the ticket booth, the tiered seating, the rest rooms, parking lot.. you get the idea. It even comes with accommodations for the different classes of audience (Think customer segments) children, aged, families, physically disabled audience. So you do what your core competency is around i.e, create, deliver the program in the theater. You did not have to go through the hassle of building a theater, owning it and incurring the overhead of managing and maintaining it. The theater by itself, might have turned to the electric utility, water district, security companies for delivering the various needs you might have needed. But all that came as a package as part of renting the theater.
Platform-as-a-Service seeks to deliver a similar experience to companies creating and running web based applications, to meet their business needs.
Platform-as-a-Service (PaaS) at its core comprises of a computing platform that facilitates the development and deployment of web application without requiring companies to build, configure and maintain the infrastructure that hosts it.
A best-in-class Platform-as-a-Service must include
- Application Development Technology Framework: A robust application development technology framework built on a technology that is widely used. Most widely used technology frameworks are built on J2EE, .NET, PHP. The framework must support the management of the entire application lifecycle of design, development, testing, delivery, change control and update of software applications.
- Ease-of-Use: One of the key selling points of Cloud Computing is that the complexity gets masked from the clients. So PaaS should be no different. A Platform-as-a-Service should come with easy to use WYSIWIG tools with pre-built widgets, canned UI components, drag-and-drop tools and support for some standard IDEs. It should facilitate rapid, iterative Application Development.
- Business Process Modeling: A strong business process modeling framework that allows you model your business process and build the application around it. Remember, the new age applications should be built using model-driven, agile methodologies to afford you the ability to quickly adapt to the rapidly changing dynamics in a global business. A good platform must support robust digital and human workflow capabilities and allow for rich collaboration as part of the business transactions that would be conducted in the application.
- Ubiquitous: Companies these days have extended workforce in the far extremes of the world and they operate round the clock. The platform of choice should be accessible and available (at acceptable service levels).
- Scalable: Businesses are dynamic and the workforce is elastic thanks to all the M&As, divestitures that are going on. The platform should be smart enough to leverage the elastic capacity from the underlying infrastructure, to handle the peaks/valleys of stress the application will be put under. In addition, it should also address the needs around State Management, Persistence, Caching, Localization, Accessibility, Cross Browser support while abstracting it from the application development team.
- Adaptive: Technologies change by the day. Mobile is increasingly becoming platform to deliver atomic services. A best-in-class PaaS should provide ability to develop an application and deliver it on multiple run time platforms besides web. Mobile and Rich Client capabilities are becoming increasingly the norm.
- Secure: Should I say more? The more things we push on the internet the more we offer to the hackers. To effectively combat the threats, the platform should address things like Cross-site scripting, SQL Injection, Denial of Service, Encryption of traffic and make it ingrained into the application development. Additionally the platform must support single sign-on capabilities for you to be able to integrate it with your remaining on-premise applications or any other cloud applications.
- Inclusive: The platform should provide the ability to include/embed/integrate other applications built on the same platform or others. In fact, support for integrating to third party services using REST, Web Services or any other RPCs should be built in should be a minimum requirement in evaluating Platforms.
- Portable: Business dynamics change and there is a distinct possibility that you might have to move your application from one Infrastructure-as-a-Service provider to another. The platform should be agnostic to the underlying infrastructure and allow companies to move the application to another infrastructure.
- On-boarding Tools: Considering that most companies transition existing applications to the platform, it is fair to assume that they would also like to bring a subset of data with them. To facilitate an easy and quick migration of data over from the legacy on-premise application to the application, based on the new Platform, – bulk import, transformation tools is a necessary part of the toolkit that comes with the platform.
I admit Platform-as-a-Service means different things to different people as I characterized in my post – different flavors of Platform-as-a-Service
If you look at the current landscape, you will find two sets of players – the big kahunas in Force.com, Microsoft Azure , Google App Engine and some niche nimble successful smaller ones like LongJump, Engine Yard and Apprenda.
Who needs it?
The two key consumers of Platform-as-a-Service would be
- Small ISVs/Startups who work under tight budgets and scant resources. They cannot afford to invest in a dedicated team building a platform. Since majority of them operate on a atomic idea and opportunity window, time to market is critical for them. PaaS provides them a quick way to get their product to market.
- IT shops laden with the inventory of fragmented legacy apps which are band-aided together. Invariably most of those applications will be written in some outdated technologies like ColdFusion, Foxpro or Visual Basic. The challenge companies would be facing would be the dwindling in-house knowledge about the application and not being able to retain that “special talent” who built that application and finally deciding to re-write them.
As I mentioned in my last post, specialized tasks are best done by a specialist. And it is more apt in the case of Platform-as-a-Service than others. Building a Application Technology Platform is highly complicated stuff and is not for the regular “Joe-the-cubicle-dweller” who might be able to hack some early version of an open source software and create a small bespoken app. It takes a lot of foresight and architectural skills to create an adaptive, scalable platform and support it.
So after establishing the virtues of PaaS, let us look at some of the hurdles that are preventing a wider adoption by companies.
- Transition: Companies have a lot of legacy applications that are currently in use. For better or for worse, they work and help run business. There is no way to migrate them as is to a Platform without rewriting them. Any new application creation requires new investment. With IT budgets no longer the same as the glory days, CIOs will have tough time wiggling out a slice of the budget for a new application. Any tools that will have Rapid Application Development and data migration tools, that can reduce the upfront work and cost, will surely help get past this hurdle.
- Portability: Each PaaS platform comes with a underlying IaaS platform that they have partnered with. Already finicky, companies that bet on a particular platform would definitely like their applications be portable to other Infrastructure that is either their corporate standard IaaS or internally hosted infrastructure. The PaaS platforms available today are not geared to be a-platform-to-go. Also of critical importance is ensuring that platform based on a widely used technology. Try getting a Ruby-on-Rails programmer or architect in a offshore country. They are expensive and scant.
- Viability: Outside of Force.com, there are not many successful PaaS platform companies that have established a track record. Coghead’s PaaSing is still fresh in memory. Google and Microsoft have announced me-too platforms but it remains to be seen if there is enough focus on it amidst the hundreds of other things they both try to do. The rest are small vendors who will f ind it difficult to get past the corporate attorneys and their terms.
- Credibility: While there are many vendors claiming their platform as the nirvana for all things application development in future, there are few that can provide case studies of real critical applications being built on their platforms. Without that, a pure-play PaaS vendor will have a tough time convincing the CIOs of expanding their technology footprint to yet another platform. In the case of Salesforce.com, their success can be attributed to the fact that they are a SaaS company, that owns a key business entity in companies – i.e., customer. With that under their management, it is easy to cajole companies to build extension applications around that key entity.
- Governance:As with all things cloud, the elephant in the room is governance. With SaaS, it is clear whose throat will get choked if things fell apart. With Platform-as-a-Service it gets a little trickier. If things fell apart, is the developer who built on the platform going to be blamed or the platform on which it is built or the third party infrastructure that it is built on going to take the blame. Here are three things that I think the should happen to allay those fears
- An independent body akin to Better Business Bureau model that grades the platforms for their reliability.
- Ownership of SLA by the Platform provider irrespective of who the infrastructure provider is.
- Disclosure of the underlying technologies used in the platform that corporate architects or third party reviewers can review to get comfortable. Under strict non-disclosure obviously.
If you are a startup
As Brian Jacobs (@brian_emcap), General Partner at Emergence Capital Partners, pointed out to me, one of the most important considerations for startups thinking of building their application on a standard Platform-as-a-Service is thinking about their eventual exit. Here are couple of things to get you thinking on that front, if you are a startup.
- You might limit of your chances of getting acquired based on the platform you decide to base your application on. For example: A company built on Force.com might not be appealing to a company that has its own platform like Microsoft or Google.
- The issue of Intellectual Property might get a little challenging. You will have to sort that out before derivative work on the platform is created. How does the ownership transfer happen? Case-in-Point: If SAP acquires a company built on Force.com does it get to take the application and customers to its own platform? or more importantly can it?
In conclusion, there are is a lot of value to be derived from a platform-as-a-service but more questions need to be answered.
Update: Check out a new post on the different kinds of Platform-as-a-Service variants.