Before discussing VMForce, I first want to remind people of the tale of Zimki.
Zimki was one of the first platform as a service offerings, initially built and released in 2005 under the name libapi (liberation API).
With Zimki, a user could sign onto this hosted service and create entire applications (including all client and server side components) in one language - JavaScript. You developed inside the platform consuming the services it provides through APIs and the user had no need to be aware of physical machines. The service was charged on a utility basis including JavaScript operations, storage and network and billing could be broken down to the Javascript function. Billing was calculated in a parallel mechanism (think network taps) and didn't interfere with any operations.
The use of JavaScript as the base language was made for several reasons. First, it was widely known. Second, it had been contained within the browser for almost a decade. Thirdly, with one common language there was a reduced potential for translation errors between client and server side code. Lastly ALL communication was AJAX (i.e. asynchronous) and objects were passed as JSON.
The platform provided additional primitives to the language for storage of objects (data) through a NoSQL object store, along with templating systems and simple conversion of functions to web services (APIs). Building a system in Zimki was simple with entire applications being written and released in a matter of hours. However, this wasn't some sort of magic but instead a normal consequence of componentisation and a standardised platform delivered as a service.
The entire platform had an extensive API set for its management, monitoring and development which was used both by the web based development tools and the local development environment. All user written functions could be exposed as an API by the addition of the zimki.publishPath([path], [function name]) to your code base. Since all code and data were stored as objects, moving entire applications from one hosted Zimki environment to another hosted Zimki environment was relatively trivial and was demonstrated several times in '06/'07. You could even move high load functions from one system to another.
The entire system had also been constructed to allow for the rapid development of shared code bases & components amongst its users. Zimki was far from perfect but it was highly useable and was rapidly growing.
During 2006, it was announced that Zimki would be entirely open sourced in 2007 to enable other companies to run their own Zimki installations and for other providers to set-up. The purpose of this action was to create a competitive marketplace of Zimki providers (multiple public sources) as well as enabling hybrid clouds (the use of public and private provision).
The system was going to be GPLv3'd precisely because of the "SaaS" loophole. The intention was to allow multiple providers to make operational improvements to the code base for reasons of service competition whilst ensuring portability through a separately established assurance authority with a trademarked compliance stamp. As part of this, an exchange was to be established.
The use of open source, extensive APIs (covering management, development and monitoring), all objects and code freely portable and an assurance authority was specifically designed to create a competitive marketplace.
Everything was looking good. Zimki was backed by a well resourced company, Fotango, for which I was the acting CEO. We'd recorded 16 highly profitable quarters, had significant cash reserves and were ready to take on this market. Unfortunately, the parent company Canon had reasonably decided that this utility computing world was not core to its objectives and it had a different focus. The consequence of this was that Zimki was never open sourced, the service was terminated and the company outsourced.
Had Canon taken another path then it could well have become one of the largest cloud providers in today's market, rivaling those of later entrants such as Google (with AppEngine), Microsoft (with Azure) and more recently VMForce. But that's innovation for you, it's a gamble and outcomes are uncertain. Bizarrely, the termination of Zimki reinforced the importance of portability and a choice of providers in the PaaS space.
Probably the most important lesson learned from Zimki was that lock-in can be created in multiple forms, including lack of access to code & data, high exit costs, additional services and management tools. The only viable way of preventing this and creating a marketplace with competition in service provision, is if the entire service is open sourced and built with the ideas of portability from the beginning.
So five years later, we have the announcement of VMForce providing a PaaS offering based around Java. Obviously it will provide a much faster rate of development and deployment (a normal consequence of componentisation) along with all the other benefits of a cloud service. This however, isn't anything new or pioneering, it's a consequence of a standardised platform which we showed back in 2006. Unfortunately the system won't be open sourced, it runs on a proprietary platform and there exists many additional services around it. These are all ample opportunities for lock-in.
So we get the standard benefits and we get lock-in, when we could just get the benefits. Unfortunately this won't happen and we won't see freely competitive marketplaces until the underlying reference models (i.e. the entire system) are open sourced and people realise that open standards are necessary for portability but not sufficient for it.
We knew this in 2005, nothing has altered my opinion since then.
Instead, I expect we will hear lots of open talk without the essential ingredient of actually being open sourced. So my thoughts on the VMForce announcement, nothing new and the same old problems. I'm unimpressed so far but at least it gives us another Java platform to play with.
For reference, this is an old Zimki Presentation from 2006, with the talk notes included as text. There are a couple of flaws in the concepts which were later refined, but the basics are all there.
