PaaS offers the potential to democratize web development by enabling anyone who can use a browser to assemble and extend web-based applications. Yet early PaaS players, including Force.com, Bungee Labs, Google AppEngine and Microsoft's Azure, have introduced PaaS solutions that are remarkably proprietary.
A proprietary PaaS solution introduces high switching costs to move data or logic from one PaaS provider to another. For example, moving an application from the recently deceased Coghead to AppEngine would require a wholesale rewrite of an application written on one proprietary framework to another.
In short, customers adopting PaaS gain access to powerful new technical capabilities but at the cost of stepping back to the proprietary business models of 20 years ago. Surely the same market forces that have driven greater transparency in the enterprise software world will also prevail in the brave new world of cloud computing!
In talking with customers and analysts, WaveMaker has introduced the term Open PaaS to describe what the next generation of cloud development tools should look like. In our definition, Open PaaS solutions have four characteristics:
- Portable - customers must be able to run applications built using PaaS tools on multiple cloud offerings. PaaS offerings based on proprietary languages (e.g., SalesForce, Bungee, Coghead) lock customers into a single cloud provider.
- Available as open source - customers must be able to run applications created with PaaS in their own data center in an open source environment . SugarCRM pioneered the attractive concept of letting the customer "take their ball and go home." For PaaS vendors, it is even more important that customers be able to move a cloud app from the cloud to behind their firewall.
- Mobile-aware - increasingly, web enablement reaches beyond the desktop browser to smartphones from companies like Apple, RIM and Palm. Customers need PaaS tools that can deliver device-appropriate content and functionality. Effectively, this is an update of the old Java "write once run anywhere" mantra.
You can read the Open Cloud Manifesto here, but here is my take on the 6 principles of the Open Cloud Manifesto (the bold titles and italic comments are mine):
- Commit to cloud interoperability: Cloud providers should collaborate to solve standard problems (e.g., security, interoperability) in a standard way. At a minimum, this requires publishing the APIs needed to build interoperable security and other services across cloud providers.
- Eschew vendor lockin: Cloud providers must not use their market position to lock customers into their particular platforms. This goes to the heart of the problem. If you are at the head of the pack, why slow down and let others catch you? The answer can only be because doing so gives you access to a much bigger market, of which you are still at the head of the pack but with a smaller lead!
- Adopt existing standards aggressively: Cloud providers must use and adopt existing standards wherever appropriate. This will be much easier for new cloud vendors, who are starting from scratch, than existing cloud vendors, who built out their infrastructure before many of these standards existed.
- Minimize proliferation of new standards: When new standards are needed, Cloud vendors must be judicious to avoid creating too many standards. We must ensure that standards promote innovation and do not inhibit it. This shows great wisdom in the ways of the world. What are most standards bodies anyway but the effect to gain or preserve market share by non-market driven means?
- Focus new standards on actual customer needs: Any community effort around the open cloud should be driven by customer needs. This is another swipe at the self-serving approaches of many standards bodies. From a cynical perspective, we will know cloud computing is successful when its standards bodies become just as opaque and non-customer focused as other entrenched standards like Java ;-)
- Cooperate between standards groups: Cloud computing standards organizations, advocacy groups, and communities should work together and stay coordinated, making sure that efforts do not conflict or overlap. This is well-intentioned, but also seems to be saying "thou shalt have no cloud advocacy groups before me" (shouldn't that be commandment I?)