JSOPs .... buy, buy, buy.

Carrying on from my last post, I want to breakdown the terms SaaS, FaaS and HaaS.

SaaS (Software as a Service) is simply where your data resides in an application from a SaaS provider.

Ideally you want to be able to move your data from one provider of that application to another and know that service will continue to work - you're just switching provider after all. This means the application has to conform to a standard - whether it's a standard for a CRM app or a standard for ERP app or whatever type of app it is.

Before anyone argues that you cannot create standards for such apps, Salesforce supports the case that you can. Where an app is ubiquitous in an industry, it's just a cost of doing business and not a form of competitive advantage. You may want your own special flavour of electricity - I want mine standard, bland, reliable, competitively priced and to come out of a plug.

The common service providers of a standard app worry about how this app is delivered, the infrastructure, how it works and the service. As a user, I care that my data works here with this CSP of CRM and that I can swap to this CSP of CRM because of price or better service or whatever. No lock-in, no exit fees and no hidden surprises.

FaaS (Framework as a Service) is simply where your data and your application resides in a framework from a FaaS provider. Early examples of this include Zimki and BungeeLabs but neither are open sourced yet. [Dec'2009 - this is now known as PaaS or Platform as a Service]

The same is true with FaaS as it is with SaaS. I want multiple providers competing to give me the best price and service, a competitive utility market, with no lock-in, no exit fees and an easy swap from one provider to another.

HaaS (Hardware as a Service) is simply where your data, your application and your framework resides in a machine environment (virtual or otherwise) from a HaaS provider. Again the same rules apply, I want no lock-in, no exit fee and an easy swap - hence open source standards are again the order of the day.

I met Jeff Barr some time ago. I told him that in my opinion the smart thing would be for Amazon to open source EC2 & S3, encourage competitors and compete on price and service - take first leader advantage, establish the market. If they don't, someone else could disrupt their market by doing this to them. I asked Werner the same thing at FOWA and he talked about their "secret sauce". I reckon all that is needed is an open sourced utility computing engine being adopted by small ISPs and they are going to have a fight on their hands.

Monopoly vs Market - who do you think is going to win?

Of course, once this starts to happen, and it is fairly inevitable it will for infra-structural like services, there are whole new opportunities that appear. From exchanges to brokers.

Why bother dealing with a H/F/SaaS provider directly if portability exists, just get a broker to manage the service on your behalf to constantly get you the best price at the quality you need.

Think I'm kidding? Nope, this is where it is going. Which is great for business, the open source world and the new markets which will establish but a complete nightmare for those still selling an ERP app (as opposed to the manner of its use) as a source of strategic value.

If you don't like change, you're really going to hate the future.

All of this stuff has been obvious for about a decade, we waxed on about it at EuroFoo '04 and many of us were delighted that Carr had firmly put the subject on the map.

The first shoots of this have only just started to appear over the last eighteen months and sometimes these things take time.

A future exchange in computing resources? A futures market? Swaps on JSOPs (JavaScript Operations).

You betch'a.

Six years from now, you'll be seeing job adverts for computer resource brokers.

[Update July 2013 - I originally thought the smart play with Amazon would be to open source the technology to prevent themselves being disrupted by an open source play combined with exploitation of constraints e.g. increase demand through a price war beyond ability of Amazon to build. In this I was utterly wrong. 

What I hadn't factored in was the CEOs / CIOs of their competitors being so completely dozy and dopey that they would allow Amazon to walk away with the market right under their noses. You live and learn. Never underestimate the blindness of competitors.]

All you need is choice ...

Following on from Artur's post on Amazon's SLA - I've picked up Scott Hanselman's questioning of the Skynet compute cloud.

Balancing supply and demand for computer resources over a few large scale common resource providers enables efficiency gains (in terms of money, people and energy) which are not achievable with today's fragmented infrastructure. However there are barriers to its adoption, whether it's legal issues or concerns over lock-in to a specific vendor and the resultant exit cost.

I've long believed the key to this is establishing a competitive utility computing market, but this requires portability of applications from one cloud to another and hence an open and free standard (implemented through an open source reference model).

As I've commented before the issue is not the lack of an SLA with Amazon EC2 but that there is no Google EC2 or Microsoft EC2 or etc.

Creating such portability is one of the key ideas behind Zimki, though obviously slightly higher up the stack than raw machine images. This is one of the reasons why the open sourcing of the Zimki engine is so key to us and hence my disappointment in our delay.

On an aside, it is good to note that other frameworks are being developed in JavaScript. I was pleased to hear about Steve Yegge's port of Rails to JavaScript.

You can read more about this on Steve's blog. It's a shame they don't seem to be open sourcing it yet.

One thing worth noting is Steve's reference to "NBE", I just hope that the "E" stands for engine.

Google has the infrastructure and brand to make such a move into the NBT (Next Big Thing) and we would all benefit from an open sourced standard engine providing portability between clouds.

The original but very sucky name of Zimki, was libapi - as in liberty, liberal and liberation API.

It's always been about freedom from "Yak shaving" but that freedom also requires choice.

Milk and two sugars ...

I have three personal rules of business.

The first is: -

"if you don't like change, you're going to really hate the future"

or as Joseph A. Schumpeter put it

"Capitalism, then, is by nature a form or method of economic change and not only never is but never can be stationary"

The second is :-

"products or technology don't make great businesses, people do."

Your products are going to change, your markets are going to change - if you want to survive you are going to depend upon people. Now, I've been through this a number of times with Fotango; from a photo service to a software house and now to utility computing services.

The trick is transformation. You need to maintain one existing business whilst building an entirely new future. It's not an easy challenge, it takes a lot of time and energy.

I'm lucky though to have a wonderful team of skilled, passionate and talented individuals. I'm very proud of them and their achievements.

Zimki is a cool piece of software backed up with good ideas, a strong movement towards utility computing grids and viable new businesses to be created. There is still a lot more to be done, and then we need to build a community around it.

Transformation is not always a smooth process, sometimes there is too much to be done and sometimes that next step is just too high or you are not quite ready yet. At moments like this, you need to take stock, regroup and try another way.

There's no shame in that, it's life, it happens.

It was one of those moments, which led to the recent change to the open sourcing of Zimki.

Obviously we are disappointed to miss our target and some of the reaction has been negative. I do understand this, I understand the frustration and concern. I'm deeply sorry for this.

As I said "we'd rather do it right rather than just right now" of course given the choice "I'd rather do it right and right now" but sometimes that's just not going to happen.

My talk at OSCON will be on the impact of commoditisation in both manufacturing and IT and how open sourcing is driving the acceleration of innovation. I'll have to leave the announcements on Zimki to a later day.

So what's the third rule? Well that one I'll keep to myself. I can't give away all my secrets! That one is worth at least a cup of coffee.

Federation ...

I've waxed lyrically for a very long time about the distinction between CODB (cost of doing business) vs CA (competitive advantage) in IT, commoditisation of IT and the need for a "national" grid of utility computing resources.

We covered many of these subject in detail, along with 3D printing & worth based development back in Euro 2004.

So it is interesting to see how things have developed since that time and a lot of the new companies arriving on the scene.

There are so many it is difficult to keep track, but I noticed recently this announcement of a SaaSGrid. The concepts seem similar to our Borg system (which we've been using internally since about 2003) and Zimki (which previously was called libapi and internally is known as fish - more on the naming of Zimki.).

A platform you can build another application on, you charge for it with a utility pricing model and you sell it forward with a utility pricing model. Excellent.

Though they don't seem to have launched yet, it is interesting. However, there is one disappointment for me - "do it all without technological lock-in" and "host it with patent pending scaling and reliability technology ...".

The key to generating a true federated grid and avoiding any lock-in, is and has always been an open and free standard (i.e. running code, an open source reference model for implementation which defines the standard). I'm talking at OSCON this year and most of my talk will be on this matter.

The people behind SaaSGrid seem to be Matt and Sinclair from SaaSBlogs. They seem smart enough cookies, and I wish them best of success.

I hope they consider the whole open standards issue of a federated grid, because this is where the real battle will be fought and is it really to everyones interest to create multiple competing standards?

The right tool for the job?

I was reading SaaS blog and Matt Ammerman's article on online IDEs, it's worth a look.

Now there is nothing revolutionary about providing a utility computing cloud through an online development environment - it's just a common sense application of previous ideas.

Since we launched Zimki back in early 2006, we've talked constantly about "yak-shaving", the benefits of simplifying the process of development and for only paying for what you consume etc. We've haven't just been handing out the T-Shirts though, we've been doing this for real. There are some really decent ideas behind it.

Firstly,"it is more efficient to have multiple network services share a common infrastructure that can absorb failures and bursts in client demand than it is to have every service over provision resources to accommodate peak requirements" - see Chaki Ng et al.

Secondly, assuming that every provider uses a common standard or engine then resilience can be achieved through a network of providers greater than any single provider.

The key to this all, is creating the federated grid of common service providers (think of a national grid of electricity providers), an exchange of computing resources and eventual virtualisation over multiple providers and even P2P. The problem has always been, how do you achieve this? You can't just move from one environment to another and expect it to work, there's usually installation, set-up etc, limitations involved.

Hence the reason why open source is such an important part of this puzzle. It's all about building that free and open standard to allow this to happen.

This has been a personal mission for me, as I hate all the stuff which gets in the way of me building something new. I want the freedom to build my application and it's data and release it into a cloud, knowing that it will work. I want my application to move from one cloud to another either because of demand or because I tell it to or because some fault happened somewhere. I want to know that it will still work. I don't want to be shackled with building infrastructure, worrying about capacity planning, demand spikes, disaster recovery, load balancing, test and staging environments and worst of all the cost of it all. All this stuff gets in the way of me building - I want freedom from this "yak shaving" - I just want to build new and interesting things.

Undoubtedly, at the beginning, any standard will come with limitations.

With Zimki you can build whatever you want but you need to write it in JavaScript, which runs on our servers. We chose JavaScript because of web services (XML, JSON etc) and all the other stuff happening on the web - it just seems logical to run the same language on the client that you run in the cloud and relatively straightforward to add persistence to JavaScript on the server.

The plan has always been to open source Zimki to try and create that first standard. Even if it is adopted, Zimki would be just a starting point on this journey. We are going to need others to join us, provide infrastructure clouds which fit with the standard and help develop the standard. Everyone competing and sharing in this federated grid.

But won't that "alienate one crowd that, well, we owe pretty much everything to - software developers and engineers" as Matt says?

That depends upon whom you're talking about - certainly you are going to upset some people because fundamentally it's about commoditisation and turning an often customised but commonly needed item (like a computing environment with CPU resources, storage and bandwidth) into a standard. Commoditisation does means less customisation, but is that a bad thing? Users of a web application have no idea about your infrastructure, they only care that your applications works. In developing an application, I don't care about the infrastructure only that it works reliably, provides my application with the resources it needs, doesn't cost the earth and that if I'm not happy I can move to another environment quickly and easily.

I don't mind if it's two boxes or ten thousand, I'm not interested in how many disks or blue lights there are - I'd rather that this was someone else's problem to solve. I just care that my app works, runs well, cheaply and simply. Of course, some people earn a decent living out of making life complex - I'm sure there were a lot of upset people when the national grid formed, or railway gauges were standardised or TCP/IP became the standard network protocol or when HTTP appeared on the scene.

This always happens whenever you deal with infra-structural goods. There are always some losers, but overall such standardisation is to the greater common good. The upside of commoditisation (forgetting the massive reductions in waste and so forth) is that it allows for new opportunities to develop. It allows for progress.

So yes, it will alienate some people - but for most it will hopefully be liberating, allow for more creativity and free us from the shackles of the old way. All that's needed is an adopted open and free standard. An open sourced Zimki might help us on that road, maybe something better will come along.

I hope so, I've shaved enough yaks in my time.

My ignite talk

Mark Fowler has very kindly put my Ignite talk about commoditisation concepts onto Viddler.

This is a general light hearted overview of the ideas. If you want to get more details about what we are doing in this field, or find out about the open sourcing of Zimki then check the Zimki blog or come and see us at OSCON '07.

Now this was a talk prepared whilst jet lagged, with short notice (i.e that afternoon) and with the rule of 70 slides in 5 minutes. I was still writing it just before presenting.

Scary stuff....

I didn't quite make the 70 slides in 5 minutes, just over, but it was sooooo close.

70 slides in 5 mins.

Just added my talk, for anyone who likes commoditisation, ducks and kittens with guns.

You suck ... thank you.

Neil McGovern posted some very valid comments about Zimki. Now, we're a small company and we know about the shortfalls in documentation with Zimki.

We're trying to improve it, all the time.

I hope that when we open source Zimki, we might be able to gain the support of others in the wider community in creating a utility computing market based upon an outstanding product. We will of course push it as far as we can.

So Neil's comments are fair, but they are also very much appreciated. Why? Because Neil has taken the time to tell us what he thinks sucks with Zimki. This is positive and helps us improve things.

So thank you and we'll get it fixed as fast as we can.

Web 2.0 catchup

The Web 2.0 Expo was fantastic, we had an excellent outing with Zimki as per Koby's post on our blog, overall great fun.

I gave two talks - one for Ignite, one at the Web 2.0 Expo itself - both seemed to go ok. I also met a large number of interesting people and listened to some very interesting ideas, you just can't ask for more than that.

We didn't get much take up on the carbon offset idea. We'll try that again at OSCON as I'm keen to encourage people to think about such things.

I saw many exciting ideas, talks, companies and products but I'll mention one in particular - BungeeLabs.

We launched Zimki, well its predecessor called LibApi, back in early 2006 with the service going public in Mar 2006. The idea was based around :-

• an online development environment which took care of all the "Yak shaving" which normally occurs with software development

• a "pay as you consume" model for charging for the use of our computing cloud

• the creation of a competitive utility computing market through the open sourcing of Zimki

Later that year Amazon's EC2 launched, we knew we had competition - so it's good to see another company enter the same market space. Why good? Well, it validates the market, it creates competition and I have to agree with Sha Agassi's sentiment that utility computing clouds are the most important developments in the software industry for the last ten years.

Agassi however refers to Amazon's EC2 directly whereas my view is the really important step is the establishment of a competitive utility computing market - not just one provider - hence the reason for open sourcing Zimki to try and kick-start this process (see my earlier posts on open sourcing Zimki, large scale disruption, utility based grids etc)

So how about the new kids on the block with their next-generation on-demand environment? What do they provide? A web-based IDE, on-demand scalable deployment, highly instrumented infrastructure and utility computations that combine computing, storage and network interaction - hey it sounds like another Zimki like concept.

Unfortunately they are not going to be into beta phase until May apparently - so it's not out yet, but it is direct competition at the same level of the stack - this is good news.

The IDE they demonstrated looks good, didn't get a chance to play with it myself and from Alex Barnett's blog they've got the concepts right - utility computing and removing "yak shaving" (note, must buy shares in the little company that makes our Yaks for us). Of course, I'd have to agree since we've been doing and talking about this for over a year, I wouldn't exactly call it revolutionary though. We didn't even think it was revolutionary back when we started and that was some time ago.

However a couple of disappointments for me. First they seem to have created a new language - BungeeLogic. I wish they hadn't, there is enough of them out there, that's why we chose JavaScript.

Secondly from what I was told by them, they are only open sourcing the connection component not the entire environment and engine. This is a shame, as the real value is to have many providers in the same space with developers freely able to move between providers.

Still, it's exciting though

My voice, your voice ... our voice.

The market is changing, and conversation is becoming as or if not more important than product. It's all about our experience or relationship with something and that isn't just the thing itself.

This is one of the reasons why I believe that the adoption of Enterprise 2.0 like technologies is inevitable. As a company you need to become the canonical source of information about your product, warts and all, otherwise you run the risk of someone else becoming that voice.

Then again, why not allow someone else to become that voice? If you can build a community around your product, why not let that community set your direction?

With Zimki we wanted to build a forum, but we also have to get ready for the open sourcing of Zimki, there is also the documentation to get written, and this feature and that feature and so on, oh yes - we also need to provide more tools, improve the IDE etc.

We're only a small company, the team are doing an amazing job but we have a huge number of projects to manage and many things we need to improve.

So, I am very grateful to Joel for creating the unofficial Zimki forum

Thank you Joel.

Hopefully when we get to OSCON and the open sourcing of Zimki, we will find others willing to help create this idea of an open utility computing environment with much less Yak-shaving and moveable applications.

So it is truly encouraging that people are already starting to help.

E-Tech was fab.

As usual E-Tech was an outstanding event - there were some excellent speakers, an interesting crowd and good conversations all round.

I'd like to have seen more, but there is never enough time. The talks I really enjoyed were :-

• Body Hacking, Quinn Norton. This is a really interesting subject matter, enhancing the human body and the potential social impacts of this. Wonderful.

• The Making of Virtual Earth, John Curlander. Captivating stuff on how to go about creating entire 3D images of the environment from a mass of 2D pictures. This is definitely one to watch.

• From Pixels to Plastic, Matt Webb. Well it's Matt and I couldn't miss one of his talks.

• JavaScript: It's Happening All Over Again! James Duncan. I work with James and so I know the talk, but I do enjoy his presentations and yes JavaScript is very cool.

• Spintronics, Kevin Roche. Harnessing quantum spin in modern electronics and methods of creating streams of electrons with the same spin. I was stunned by this.

• Haml: A Semantic Rebellion in Template Land, Hampton Catlin. It's always dangerous to use live demos but building your presentation in your own tool - crazy. It worked, it was great fun and Hampton presents with flair. Shame the room was pitch black.

The list could and should go on, but all I'll say is that if you've not been to E-Tech I would strongly recommend it for next year.

I also gave a talk on commoditisation (with ducks, Zimki and fabbing as usual).

Unfortunately there was a mini gale at the time, so the doors were blasted in on several occasions and also the room was located outside the main area, down a small track, through the woods and past the signs which said "beware of the dragons".

I'm very grateful and extremely surpised that people made the trek. Unfortunately we didn't get many people to sign up for our carbon offset site in Zimki . We'll have to try again later in the year.

Now this is fairly old, but I'd never seen it before until Craig Dwyer pointed it out to me. If you like Lego, you have to watch this.

Large Scale Disruption

I had a long discussion yesterday with a friend about the open sourcing of Zimki. The plan is to open source the entire environment later this year (probably GPLv3 for the engine and LGPL around the interfaces - though we are finalising this at the moment).

Now Zimki (which we first alpha'd in early'06) is a JavaScript application development and hosting environment on a "pay as you go" model.

So it has :-

• Application framework - comparison is Rails
• Cloneable applications - comparison is Ning
• Utility computing - comparison is EC2
• Federated services - comparison is ... (no-one else does this yet)
• A JavaScript development environment.

It's not a direct competitor to any of these which have their own specialisations and focus but you can sort of think of it as EC2 + Rails + Ning + other useful "Yak Shaving" bits taken care of.

However what happens when we open source Zimk?

Well as posted before and also by James, the reason for open sourcing Zimki is to help establish a competitive utility computing market made from a large number of providers competing in the same space with customers freely & simply able to move applications and data between providers with no exit costs.

Now this marketplace could become a direct competitor to any singular large scale utility computing provider based upon propriatory services.

Yep. I know.

But then again, an open source based competitive market place avoids the dangers of anyone in the future providing a pipe like argument to infrastructure.

So I'm happy.

Oh you shouldn't ....

Whilst trawling the web I came across an example of your average Zimki geek

This got me wondering, ignoring my own stunning looks (not in the positive sense) - does your application framework & language say something about you?

Is there a difference between say a JavaScript & Zimki geek against say a Ruby on Rails geek, ignoring the minor technical issue of Ruby not running in the browser, so you have to use JavaScript anyway.

Hmmmm ....

For a more sensible discussion of languages - it's worth looking at Tim's "naughty but nice" post on programming wars

Give credit where credit is due ...

I've received a number of emails recently as well as very kind comments on the presentation I gave at FOWA. These things mean an awful lot to me, as it such an honour to speak to my peers.

Most of the team at Fotango (to name but a few ... James Duncan, Greg McCarroll, Mark Fowler, Tom Insam, Bruce Richardson etc) are outstanding natural speakers and have given me help and useful comments.

Many of my friends in the world of technology (Jonathan Laventhol, Greg Stein, Matt Webb, Nat Torkington, Nick Stone, Suw Charman, Jim Purbrick (aka Babbage), Artur Bergman, James Larson and others) have given me help and support in refining my ideas.

I do however have a "secret sauce", and in light of my conviction for openness I have to share this. I was very fortunate at Euro Oscon to spend an hour or two with Damian Conway, a master of the art of public speaking. The time I spent with Damian had a dramatic impact on me, how I approached the art of speaking and the information I presented.

If you ever have the chance to hear Damian speak I would recommend it wholeheartedly, he is an outstandingly gifted. If you ever get the chance to spend time with Damian, then grab it.

I owe him a great deal of thanks.

News on Zimki

I've read a wonderful post by Simon Bisson on The Register on our Yak Shaving theme at FOWA. I'm humbled by the kindness of it.

James has written two excellent articles about the article - understanding the cost of a line of code and FOWA Coverage - of course I believe they are both worth reading as I share the same views.

James and I have been talking about the concepts of commoditisation (both in terms of IT and Manufacturing) for a long time, a reasonable amount of the last six years that we have known each other.

It's good to be finally doing something about it with Zimki and to be in such good company at Fotango. Even if Tom is still annoyed at me about the "Free Tom" bit.

Maybe I should cheekily ask him to do a presentation entitled .... "I am Tom"

NBL maybe NBT.

I picked up this post by Steve Yegge on the NBL (next big language). He didn't say what the language was, but you should read the comments. I agree - JavaScript. When we started Zimki our intention was to remove all those unwanted yak-shaving tasks which got in the way of creating something. I called this campaign - Free Tom - much to Tom's annoyance.

We then built a JavaScript application development & hosting environment. One language front and backend (JavaScript), utility hosting environment (no capex) and persistence (not a relational database but instead a key/object store). Everything accessed through an API, even the client desktop tool for developing uses the same APIs.

A great moment for me was when Tom, during a break at D.Construct built and released a wiki with autopreview in under 25 minutes. Let us be clear here - from concept to development to live on the web as a running service within 25 minutes. I can't even get a hosting arrangement sorted out in that time usually.

So at FOWA I talked about Zimki & commoditisation, about building online in JavaScript without the need to worry about servers, hosting and databases. I talked about our plans to open source the entire technology later this year in order to create a fully competitive utility computing grid and to remove lock-in. So far, Zimki and the API services behind it have been blooming. We started with three applications consuming the services in Feb '06, by April '06 we had 600k API calls, by June '06 we had dozens of applications, over 2.8M API calls and 150 developer accounts. Today, we're into the many thousands of developer accounts.

The comments ranged from some real interest, to the very flattering (p.s. Thanks, I'm always nervous when speaking as I find it such a privilege to do so and very demanding to get it right, even if it is less than ten minutes) and the I don't get it, where's the business model? Sadly there's some old skool VCs & IT folk out there who just don't get how the IT world is moving to a utility basis.

Well you can't always get the message across clearly in eight minutes. Other than the trivial selling resources into the cloud there are further opportunities which are all fairly obvious. However, this got me thinking, maybe they are just obvious to us? This subject does seem to be something new to many people, you do need to change the way you think about IT.

Now, I've been talking about commoditisation for a long time, and I am also lucky to exist in a social environment surrounded by some very smart people. To find the money, you just need to ask yourself the questions of:-

1) Is there a distinction between the electricity generators and the electricity providers?

2) What was the impact of standardisation and the national grid?

Could commoditisation actually be the Next Big Thing? Well in my view, it's been the NBT for a very, very long time - it just doesn't get the same buzz as the "new" stuff. Until, of course, we start thinking it is "new".

-- 22nd Feb 2016

Tidied up some of the typos, paragraph structure and width adjusted. Well, it's almost a decade later and Javascript is still but not quite the NBT.

Alas, many of the links are now broken.

Eight minutes of commoditisation

It's late, I'm tired but today has been good. I was at the future of web apps conference in London which Ryan has done an excellent job in making happen.

There was a good range of speakers, with some outstanding corridor conversation (the sign of any excellent gathering).

There were so many interesting people that you may as well just publish the attendee list - however it was especially good to catch up with Suw Charman, Tom Armitage, Peter Ferne and Michael Cummins (AOL).

The guys from soocial topped the list of speakers with Stefain Fountain rocking the house with his amazing talk on mobile contacts. I just couldn't stop laughing - an outstanding showman.

I also gave a short talk on commoditisation - it was less than ten minutes and was pretty well received. The fear of speaking is over now, so I can just get on with the job of promoting Zimki and enjoying myself. The crew on the Zimki stand were fantastic as usual.

Sometime in the next few weeks, I need to find a few spare moments to shift my blog over to Zimki. Though I should sort out a proper domain name before I do so.

This is the biggest obstacle to overcome - choosing the right name. Suggestions are welcome as long as it's not grumbly_old_bugger.com (thanks Steve).

Well this won't happen before FOSDEM....

An open source utility based grid.

Zimki is growing - excellent.

These are my thoughts on why a grid of utility based providers of an open source platform is necessary and the CA / CODB divide in IT.

No service is ever 100%, hence the abundant use of the n+x model from stand alone (n+0), to the simple cluster (n+1) and further.

This extends not just to hardware but to providers. Hence the greater the number of providers in a cloud and the more distributed the application, the greater the resiliance. A case of n+1 would have one utility provider as the primary source, and another as the secondary.

By creating a utility IT environment where applications & data can simply switch from one provider to another, you enable two things to happen.

Firstly, you create a competitive utility IT environment - where price & quality of service (QoS) can be compared.

Secondly, you should be able to create a greater level of resilience at the same price.

As far as I am aware, it is estimated that 15% of company data centre capacity is utilised. If you accept this and assume a 100% markup then for the same price each company can access three equivalent utility data centres (n+2). Assuming perfect balancing of supply and demand, and discounting any economies of scale, an n+1 model will give more resilience at less cost on a utility basis.

This requires simple transfer between providers and open competition. If we spend over $2 trillion p.a. on IT and the majority of that IT is CODB and of little or no strategic value - then such cost savings will become critical.

This is why I believe there will be a shift towards a cloud of utility providers, competing on price & QoS with simple transfer of applications and data between providers. In the same way that it is likely that most CODB apps will become generic and exist somewhere on the cloud.

Price & competitiveness will force the issue. As the ubiquity of IT increases, so more of it will shift towards CODB.

Scarcity is the key to differentiation and a source of advantage, not ubiquity.

Everyone has ERP/CRM etc. The systems are not a source of differentiation and the focus should be "as cheap as chips".

In the long run, the utility model is most likely to be the only one standing, but the driving force will be a greater understanding that the majority of IT is CODB and price / QoS will become the critical issues.

The days of added business value are limited for the majority of systems.

The minority which is genuinely novel and new and therefore can be seen as a source of competitive advantage, will most likely shift to worth based development (WBD) methods - where reward is directly related to a metric of business value. This is all the more achievable when some of the risks are negated (such as hosting / operating costs) - however it still requires a change in mindset to distinguish CA from CODB.

Transitional (the movement from CA to CODB) is ripe for open sourcing, to avoid the cost of transition associated with being the non-standard product - however timing on this will always be critical.

So in general (and this is what we discussed back at Euro Foo'04, a rehash of a report I wrote back in 2002) - the ideal is roughly:-

Characteristics :-

• novel and new
• relevant
• potential & measurable fast return
• uncertain

possible source of CA

Approach: build using a WBD [minimise risk, share reward] method and if it becomes successful, and competitors appear to be building equivalents adopt the approach of open sourcing the entire service, allow all competitors to copy it and attempt to establish it as the standard product. [Avoidance of the cost of transition]

Characteristics :-

• you've heard of it or worked on before
• lots of companies have it
• a generic term exists to describe it
• often called "strategic"
• you believe you need
• considered as "best practice"

most likely CODB

Approach :"Cheap as chips" - use a generic product run on a utility service, avoid customisation.

This is based on my comments on Carr's blog about Google whacking the IT industry.

Hope ++

In our history we have had many protests (from Wat Tyler to the Jarrow marchers to the Chartists). Few have succeeded, most have failed - all have struggled for their cause.

However, other than the anti-war march, I can't think of any examples of two million people turning up in London to protest and then going home after nothing happens.

Had Wat Tyler led a march of two million peasants, do you think things would have turned out as they did?

Why do we accept this?

How many people do you need on a march before you are listened to? 10 million? 20 million?

Why do we allow ourselves to be ignored?

Is it that we have too much to lose? So to demonstrate is ok and if we are all ignored well c'est la vie; there is always the election!

The problem with waiting for the election is the declining turnout and that both parties are identical. I've even heard talk of boycotting the next election in order to make some sort of statement - I presume that statement is "please ignore us".

So what is behind this political emasculation of the populace?

I have an idea.

I've noticed a growing culture not just of fear but of vulnerability and powerlessness.

So, have you heard any of these:-

• one person can't make a difference
• what's the point in voting
• they don't listen anyway
• I'm worried about .... job, home, debt, children ...
• we're under the threat of terrorist attack
• the environment is collapsing

I'm hearing a surprising number of statements about human frailty recently and everyone seems to be a potential victim. (Where did that term come from anyway?)

In a spirit of inquiry, and to shed some light on the current zeitgeist, I've been running my mood map on Zimki which tracks photos and blogs tagged with certain emotional words. It's a simple demo app which took about an hour+ to write (this is for someone who didn't know JavaScript or HTML)

The result (obviously impacted by seasonal variation):-

Well since Nov '06,

Sadness has increased over Happiness (+2%)

But

Hope has increased over Fear (+7%)

So we're more miserable, but at least we're hopeful.

Of course this is all anecdotal, but the worrying thing is that we may be hoping for someone else to create a better future because we feel powerless to do so ourselves.

Commoditised web - how much? what next?

A few weeks ago the company I run, Fotango released our new utility billing model onto Zimki which is our commoditised web operating environment.

We are going to blog about this in detail on the Zimki Blog and also the Fotango Blog but I'll provide some information on here for those interested in the ideas behind commoditisation of IT and the stuff I talked about back at EuroFoo and EuroOscon.

As we run our own sites on Zimki, I can now reveal the cost of running our websites in terms of JavaScript Ops, Bandwidth, Storage etc. For simplicity our billing system converts all this to tokens (think electricity kw/h) which can be bought in batches of 100,000 for £1.

So let me be clear, this is a scaleable and robust environment where you can build and release entire applications online without ever needing to set-up a server, arrange a hosting environment, install and configure a database, install a web server etc. There is no initial capital investment for your service, as it is utility basis.

All you need is a browser and knowledge of JavaScript (which runs both front and back-end with an extended persistence layer). You can build an entire business online - or an application or even just expose parts of it through an API - with just a browser. So, how much does it cost to run your own online site? Well, let's get a sense of perspective first. Six years ago when we first created Fotango we spent a large amount on capital to install web servers, set up hosting etc. Setting up a web site could easily run into tens of housands of pounds, if not more.

So today, well :-

• The Fotango site costs 63 pence per day, or about £19 per month
• The Zimki Blog costs 19 pence per day or about £6 per month

Of course, we are not charging at the moment - i.e. it's free to use. The entire business is built around the capabilities of a scaleable cluster with some nifty financial models based on utility, which charge on the basis of how much of the cloud you consume. For a company web site and a blog - £25 per month seems reasonable - crikes I wished we had this a long time ago.

But that's progress.

However, when we open source the system (planning to do so, later this year) and release the grid elements, our customers will be able to switch their applications and data between different providers at the press of a button. (why? well price and QoS will very between providers - we intend to provide that information along with a number of market capabilities - think energy trading, and I'll comment on this in a moment.)

Or our customer could host Zimki themselves.

Or they could use multiple Zimki providers.

Or (and this is my favourite bit) our customer could even sell spare capacity in their own data centres back into the Zimki grid.

That's the plan - and slowly we are getting there! As for why open source - well see my earlier post about this.

Will I be shifting this blog to Zimki - of course! I'm just waiting for my friend James Duncan to finish writing his Zimki blog application, and then hopefully I'll be able to get the code from him and create my own! (several beers may well be in order)

So why the comment about energy trading?

Well you can build an application in Zimki (either in a realm or using multiple realms) which can have different end-users. So for example, I could build a CRM system for different companies using either seperate sandboxed realms or keeping the data separate with program logic in Zimki. This means I could build a SaaS application on Zimki (we are intending to release an example billing module for our Zimki customers in order to help them do this, but that's much later).

That means I can create a SaaS application, without investing in hardware, setup etc etc or being concerned about scaleability and such issues. The end-users of my SaaS application would then pay me (if it's any good!) for it's use and I would just pay the Zimki grid for consumption of resource. This reduces my risk and capital investment when creating a new business, enables me to expand easily with the business and makes it easier for me to get such services out there.

It also means that once my SaaS application is successful, then shifting from one provider of the Zimki grid to another could significantly reduce costs. That creates competition and enables price to be balanced against QoS. The world of commoditised IT is rapidly approaching, which is good because once all established we can get onto the business of commoditising something else - like the manufacturing process (think digital fabrication, most likely with inkjet, giving compositional and geometric freedom)

I look forward to a day when I'll get to read a book from Nicholas Carr on "Does it MATTER - Digital Fabrication and the corrosion of competitive advantage" as we all merrily inkjet print huge numbers of physical goods (as dissussed back at Euro Foo '04). That will cause even more nashing of teeth than this current round of commoditisation, but then biological manufacture (Drew Endy et al) isn't that far into the future either.

Still, from all accounts, the printing of object and electronics is happily jogging along. (Thanks to James for spotting the post)