Four years ago at EuroFoo 2004, I talked about two subjects. One was fabrication technologies and 3D printing. The other topic covered why much of IT was little more than a cost of doing business. Both subjects were in fact about commoditisation.
For me this has been an ongoing discussion for the last decade, a fair chunk of which has been with a good friend of mine, James Duncan.
In 2005, we started to build a service oriented business known as libapi, consisting of utility computing web services. As this concept developed it changed (a normal activity of any innovation) and became a utility computing cloud with an application framework known as Zimki. It's what we called a Framework as a Service (FaaS), just write your application and then release.
All that Yak shaving stuff from scaling to configuration to infrastructure was taken care of for you. Zimki even ran on our own private HaaS (Hardware as a Service) known as Borg, something we had started building in 2003. But as a user of Zimki you just worried about code and data, everything else was taken care of, all the yaks came pre-shaved and the shaving was hidden away.
At the heart of the system was the concept of a portable environment. There were many amazing moments along this journey, including :-
- Tom writing and releasing a new form of wiki from scratch to live on web in under 25 mins (2006).
- James demonstrating true portability of a running application between multiple Zimki installations (2007).
The important part of this tale is that we showed that building an ecosystem of utility computing providers, with simple portability of applications and code between those providers, was technically feasible. Such an ecosystem is what I call a competitive utility computing market.
Whilst, "open" standards (as in APIs & data formats) are necessary to achieve portability, they are not sufficient to achieve this. You need to have not only common APIs, but multiple providers and assurance that portability is possible i.e. semantic interoperability. Open source provides the fastest means of operationally achieving this and gaining adoption. The provision of an open sourced environment at any level of the stack (from SaaS to FaaS to HaaS, or any of the other aaS's) is what I refer to as an open sourced standard.
With an open sourced standard you can become a provider by either installing the standard (it is by definition a fully working stand alone environment) or by creating your own version which complies with all the primitives of the standard.
The standard provides a means of ensuring compliance between environments through monitoring.
The open SDK of GoogleAppEngine (GAE) is the potential beginning of an open sourced standard, assuming someone turns it into a fully functioning and scaleable open source system. Any application built to work in the open SDK of GAE will work on any provider's environment which complies with the open SDK of GAE.
This is not about this language (python) or that (ruby) or whether it's ready for the enterprise or whether it's EC2. In my view, it should all be about creating an open sourced standard and then Google seeding an ecosystem with its own implementation of that standard. Now obviously this is not enough to ensure portability as you still need monitoring and assurance but it's an essential element for any utility computing market which is going to be a free market i.e. it is not going to be based on some proprietary technology and hence a nightmare of control and constraint.
Hold on, isn't Google's implementation of the open SDK proprietary? Yes, but the open SDK is, as it says, open. You should look at this as though the open SDK is the beginning of an emerging standard and GAE is simply Google's implementation of this. Personally, Google should have started with an open source GAE because they run the risk of someone building an open source play against them.
This is just the beginning of what I discussed at OSCON in 2007. Ok, there are a lot of ifs and buts, however it certainly has exciting potential. If other providers create environments that are compliant to this open SDK, then we will have the beginnings of such a market. In my book, these changes have the potential to disrupt the entire enterprise IT and hosting market because they're ill prepared for the inevitable.
Like it or not, most ISPs are facing a bleak future at the hands of either huge new service providers or possible lock-in to a proprietary mesh. The only way that such ISPs can fight against this is to create a marketplace based upon open sourced standards. As a marketplace they can fight; as lone providers, their days are numbered.
Both barrels of change - innovation & adaptation - are pointing firmly in their direction. They need to be seriously thinking about creating open sourced standards, a monitoring body and a competitive marketplace. The time to do so is rapidly approaching; you can't hide forever and creative destruction has you firmly in its sights.
P.S. If you want to keep up with the latest developments in this field, I personally read James Urquhart's and Rich Miller's blog.
P.P.S. Yep, I know I'm repeating again a lot of stuff I talked about last year, but I thought it was timely.
-- Update 19th July 2013
Gosh, this is over five years old. Since that time -
- Google App Engine now has AppScale and a development effort with RedHat but is also has serious competition with Cloud Foundry which is playing a fully open source game. Never quite understood why they didn't start the game with an open source GAE, way back when.
- All the terms are wrong. HaaS became IaaS, FaaS became PaaS etc. Don't ask why, I never understood.
- I finally gave up using the term 'innovation' for the novel and new because that word is used for pretty much everything these days. "The bus went a different route today - it's an innovation!" etc.