Saturday, May 01, 2010

VMForce, Zimki and the cloud.

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.


Anonymous said...


It's easy to be critical of VMForce sitting on top of a closed platform, but this is clearly just the opening shot. VMForce will be useful to a small but significant set of users - those who have already decided (rightly or wrongly) that is the right place to put their precious CRM data. I expect that there will be approximately zero people that use VMForce that aren't already in some way committed to SFDC.

What's much more interesting is last week's Spring meets GAE meets GWT announcement. SpringRoo has many of the qualities that made Zimki so useful, but with a sprinkling of pragmatism around language and developer frameworks (and the benefit of an extra 5 years in the oven).

Steve Herrod talks about "Open PaaS", and in my view they're walking the line just about perfectly. Their form of 'lock in' is that it's just going to be easier to go with stuff that's pre-integrated with monitoring and operations and supported by a bunch of the smartest kids on the block. Of course the option is there for you to roll your own from the underlying open source pieces, but that comes with a substantial time vs money compromise.

I guess things get really interesting if/when a service provider (or platform provider) picks up the "Open PaaS" bag of bits and tries to compete at some different price point or quality of service. That's the sort of open that I think you wanted for Zimki, and the sort of exposure to competition that scared Canon away. What actually seems to be happening here is that the PaaS is it's own kind of lock in, but that there will be a choice of underlying IaaS, and differentiation on operational stuff. This makes sense as there's a limit to application portability, but people don't want to be reliant on a single service provider (unless that's where they've already made a concious choice to put all of their data).

The Qb Payroll said...

For further assistance in QuickBooks, just connect to our QuickBooks Support Phone Number Hawaii 1-833-325-0220 and receive immediate & efficient support from our QB experts with 24*7 aid.