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 (it even changed its name). 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 wiki from scratch in under 25 mins (2006).
- James demonstrating true portability between multiple 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 open standards, but multiple providers and assurance that portability is possible. 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.
The open SDK of GoogleAppEngine (GAE) is a potential open sourced standard. 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 (HaaS) or Facebook (Faas). In my view, it is all 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, but it's an essential element for any competitive utility computing market that is not going to be based on some proprietary technology and hence an interoperability nightmare.
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.
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, this has the long term potential to disrupt the entire enterprise IT and hosting market.
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.
No comments:
Post a Comment