Is it time to reset?

Our economy faces unusual challenges due to the exceptionally high debt burden. In terms of Government debt this is represented through Gilts (Government backed securities of debt). The recommended solutions to our problems usually involved manipulation of the money supply in the hopes that somehow this will correct the underlying problems.

For example, in the UK the Government sells debt with Gilts then, through a wheeze known as Quantitative Easing, it prints money to buy back the Gilts it has sold. The net effect is that GBP is devalued (leading to commodity price inflation), the delta between buy and sell price is absorbed as profits by the counter party (normally a bank) and the entire distribution of wealth becomes further concentrated to the advantage of the counter party.

It would in effect be more cost effective (and honest) if Government's didn't sell and buy back Gilts but simply printed money to counter their shortfall. You'd still however be left with the issue of devaluation.

Now in an export led economy devaluation can help boost exports at the same time as increasing inflation. However, we're not an export led economy, so devaluation without direct investment leads to higher material costs, less profitability in internal markets and correspondingly cost reduction, weakening of the internal market, higher inflation and stagnation i.e. what the media call stagflation.

All of these problems are exacerbated by debt, inequality of wealth distribution etc. In the Eurozone we're seeing this shake out with Greece which faces either a decade or more of misery or default on the Government debt (i.e. gilts)

Now, a Greece default would be a disaster because it would be difficult to raise further debt and investors would be wary of trading with Greece. But wait, it's part of Europe ... the EU could always raise debt for it. I suspect this is why people are so keen for Greece to leave the Euro if it defaults. A country that defaults but then continues is not a message the market wants to hear.

Why?

Well despite media opinion, Government shouldn't operate for the benefit of investors but society as a whole and Gilts come with risk (albiet relatively small). Now if a country default and continued to operate, then the problem for the market becomes what if this idea extends? So let us extend this Greek idea a bit more. What if every country in Europe and ideally add in the US as well, simultaneously defaults on Government Debt i.e. Gilts and resets the debt to zero?

Well for investors it would cause one hell of a haircut and some banks would probably fail. However, those can be nationalised where necessary and measures taken to limit the damage. You'd certainly need some form of protective measures for those at the bottom end of society - hence tax raises would be necessary - and Government would need to co-operate to smooth out some of the fall-out.

There'd be lots of nashing of teeth, the markets would suffer turmoil whilst they reset but investment (in the case of shares, gilts etc) is always shorter term gambling and despite the losses the size of the EU & US means investment will still continue, possibly even flourish. It's worth remembering that market indices (FTSE etc) are also not a good indicator of the underlying economy despite the media's fixation on them.

I can't see there are actually any real downsides to a Europe and US default (bar the temporary turmoil etc) except for investors but such gambling inherently occurs risk and these are fairly unique circumstances. The Governments could always shore up the economy by direct Keynesian style investment as well.

Naturally, some would argue that this might collapse the USD / EURO / GBP against other currencies such as the Yuan. But the above approach wouldn't significantly increase money supply (other than investors dumping) and the Yuan isn't a free floating currency. Certainly against other countries they'd be possible devaluation but then given the size of the trading blocks the effect should be minimal over time. What about sanctions? Against Europe & the US - don't make me laugh.

Of course, some will argue it would spook investors so much that there'd be a collapse of investment. However, if the money was invested in Government debt it wasn't invested in longer term infrastructural goals which is what we actually need. Any investors sent to the wall would be quickly replaced by others - that's capitalism for you - and as for pension funds, well it's true that we'd need decent protective measures put in place to protect the poorest but beyond that not a great deal more.

I'm writing this because the UK Government is planning to give more taxpayers' money to the IMF who may contribute to the Eurozone bail-out (something which our Gov. said they wouldn't do) or in other words piling on more debt to help solve problems caused by having too much debt.

This is a cycle we need to break. Can I suggest we reset the market economy by resetting Government debt. A simultaneous default by Europe and US on all Government debt should do the trick.

Does this post mean I believe this is the right course of action? Well, unfortunately whilst the idea is interesting, the practice is virtually impossible. In order to exact such a change, the various Governments would need to agree and execute almost instantly to avoid investors dumping Government bonds on the unsuspecting public (or wrapping them up in some other complex instrument). I have doubts that our leaders are capable of such consolidated action. All it would take is one party to phone a friend and warn them to get out of Government bonds and the entire scheme would unravel quickly.

So, overall ... I agree with the concept but the practice is probably too difficult and it's much more likely that we'll settle for many years (or decades in the case of Greece) of austerity

More QE madness ...

In the last five years, GBP has dropped in value by between 23-47% against the USD, EUR and CNY when Gold is used as the standard. GBP has taken a pasting. Our UK inflation during that time has been around 18% (based on CPI) but that's a basket of goods approach, as we've all seen basic commodity inflation has been much higher. You can pretty much put the entire inflation down to GBP devaluation.

One might argue that devaluing GBP is good for exports, however the UK has a huge balance of trade deficit managing to clock up a record breaking £9.2 bn in Dec'10. Whilst exporters have raised some recent cheer, what has to be remembered is that the UK imports almost all its copper, ferrous metals, lead, zinc, rubber, and raw cotton and about one-third of its food, along with a whole range of finished goods. With the GBP down the toilet, the cost of these goods has risen dramatically and certain items just aren't luxuries.

So, who has made good with the collapse of the GBP and where did it come from? Well, the reason why GBP has been hit hard is basically because of monetarist policies such as quantitative easing and keeping interest rates low. Quantitative easing (QE) is the best wheeze of the two and consists basically of buying back debt we're constantly selling, at an obvious premium, and hence simply amounts to printing money and handing it over to banks. The monetarist delusion is that those banks will lend it out, increasing money supply, and hence magically all our problems will be solved. In reality it takes no consideration of capitalisation requirements, debt exposure, weakness of infrastructure, business cycle etc. The net effect is always bad for GBP.

Through financial engineering we've created a situation of increasing inflation (due to GBP devaluation through money supply manipulation) combined with a weakness in the economy as a whole since we're not bothering to directly investing in it and trying to combat the economic cycle. This combination gives us stagflation = stagnation of industry + inflation.

So who benefits? Well, a depressed GBP makes the stock market and housing more attractive to foreign investors. Hence the FTSE, though fluctuating, remains artificially high and London housing is undergoing a mini-boom. Hence some people in the city think we're doing well, when in reality they might be doing ok but the rest of country is sinking fast.

Of course, viable solutions to this problem which include increasing interest rates, direct investment in industry (rather than QE) etc will cause lots of short term pain for those with debts and exposure combined with haircuts for banks and investors. Rather than face this, we continue on a path of devaluing our future in the belief that somehow this can correct problems caused by borrowing too much from the future. It's like a drunk reasoning that the way to deal with their drinking debts and find the path to happiness is through selling a kidney and only buying methylated spirits.

So, does our current policy help us? Not a jot. The increasing focus on money supply will probably mean more QE. At the same time, the overall economy will continue to weaken, unemployment rise, tax receipts reduce creating a need for more cost cutting, cost of basic goods will continue to increase, export led business (without direct investment) will continue to flounder but at least the FTSE will look somewhat rosy until reality catches up with it and graphically demonstrates the error of its ways.

Eventually, if we keep on this route we will finally reach a tipping point and enter the world of hyper inflation combined with extensive contraction of industry. I can't think of a nifty combination of these terms, so I'll resort to, Hyper inflation + Contraction = "Zimbabwe" Economics. Of course, I use the phrase loosely here because to actually achieve the stunning results of Zimbabwe requires a very rare kind of recklessness (or more appropriately "wrecklessness") which is unlikely to be repeated.

I'm writing this so as we enter these more troubled times, can we please, please, please remember to round up all the monetarists and either lock them up in the Tower of London or ask them to provide the data which demonstrates why what they're doing makes sense.

Hosting Con Keynote

I was very fortunate to be asked to give the opening keynote at Hosting Con 2011 covering commoditisation, business evolution, leadership and what the various tactical plays in the cloud computing space mean to hosting companies. The audience was fantastic, I had a great time and despite using excessive numbers of slides, no-one was hurt in the process.

Continuing on the theme from my OSCON tutorial, I've uploaded a summary set of slides which are highly condensed but give a taster to what we covered.

Alas, there's no video and as per usual I'm six years into writing my book and around 30% of the way there. The subject matter keeps on giving me more areas of interest to explore, so don't hold your breath for me to finish any time soon.

Summary of Hosting Con 2011 keynote

View more presentations from swardley

A run on your cloud?

When I use a bank, I'm fully aware that the statement I receive is just a set of digits outlining an agreement of how much money I have or owe. In the case of savings, this doesn't mean the bank has my money in a vault somewhere as in all likelihood it's been lent out or used elsewhere. The system works because a certain amount of reserve is kept in order to cover financial transactions and an assumption is made that most of my money will stay put.

Of course, as soon as large numbers of people try to get their money out, it causes a run on the bank and we discover just how little the reserves are. Fortunately, in the UK we have an FSA scheme to guarantee a minimum amount that will be returned.

So, what's this got to do with cloud? Well, cloud (as with banking) works on a utility model, though in the case of banking we get paid on both the amount we consume and provide (i.e interest) and in the cloud world we normally only have the option to consume.

In the case of infrastructure service providers, there are no standard units (i.e. there is no common cloud currency) but instead each provider offers it own range of units. Hence if I rent a thousand computer resource units, those units are defined by that provider as offering a certain amount of storage and CPU for a given level of quality at specified rate (often an hourly fee).

As with any utility there is no guarantee that when I want more, the provider is willing to offer this or has the capacity to do so. This is why the claims of infinite availability are no more than an illusion.

However, hidden in the depths of this is a problem with transparency which could cause a run on your cloud in much the same way that Credit Default Swaps hit many financial institutions as debt exceeded our capacity to service it.

When I rent a compute resource unit from a provider, I'm working on the assumption that what I'm getting is that compute resource unit and not some part of it. For example, if I'm renting on an hourly basis a 1Ghz core with 100Gb storage and 2Gb memory - I'm expecting exactly that.

However, I might not use the whole of this compute resource. This offers the service provider, if they were inclined, an opportunity to sell the excess to another user. In this way, a service provider running on a utility basis could be actively selling 200 of their self defined compute units to customers whilst it only has the capacity to provide for 100 of those units when fully used. This is quaintly given terms like improving utilisation or overbooking or oversubscription but fundamentally it's all about maximising service provider margin.

The problem occurs when everyone tries to use their compute resources fully with an overbooked provider, just like everyone trying to get their money out of a bank. The provider is unable to meet its obligations and partially collapses. The likely effect will be compute units being vastly below their specification or some units which have been sold are thrown off the service to make up for the shortfall (i.e. customers are bumped).

It's worth remembering that a key part of cloud computing is a componentisation effect which is likely to lead to massively increased usage of computer infrastructure in ever more ephemeral infrastructures and as a result our dependency on this commodity provision will increase. It's all worth remembering that black swan events, like bank runs do occur.

If one overbooked provider collapses, then this is likely to create increased strain on other providers as users seek alternative sources of computer resource. Due to such an event and unexpected demand, this might lead to a temporary condition where some providers are not able to hand out additional capacity (i.e. new compute units) - the banking equivalent of closing the doors or localised brown-outs in the electricity industry.

However, people being people will tend to maximise the use of what they already have. Hence, if I'm renting 100 units with one provider who is collapsing, 100 units with another who isn't and a situation where many providers are closing their doors temporarily, then I'll tend to double up the workload where possible on my fully working 100 units (i.e where I believe I have spare capacity).

Unfortunately, I won't be the only one doing this and if that provider has overbooked then it'll collapse to some degree. The net effect is a potential cascade failure.

Now, this failure would not be the result of poor utility planning but instead the overbooking and hence overselling of capacity which does not exist, in much the same way that debt was sold beyond our capacity to service it. The providers have no way of predicting black swan events, nor can they estimate the uncertainty with user consumption (users, however, are more capable of predicting there own likely demands).

There are several solutions to this, however all require clear transparency on the level of overbooking. In the case of Amazon, Werner has made a clear statement that they don't overbook and sell your unused capacity i.e. you get exactly what you paid for.

Rackspace also states that they offer guaranteed and reserved levels of CPU, RAM and Storage with no over subscription (i.e. overbooking).

In this case of VMWare's vCloud Director, then according to James Watters they provide a mechanism for buying a hard reservation from a provider (i.e. a defined unit), with any over commitment being done by the user and under their control.

When it comes to choosing an infrastructure cloud provider, I can only recommend that you first start by asking them what units of compute resource they sell? Then afterwords, ask them whether you actually get that unit or merely a capacity for such depending upon what others are doing? In short, does a compute unit of 1Ghz core with 100Gb storage and 2Gb memory actually mean that or could it mean a lot less?

It's worth knowing exactly what you're getting for your buck.

Arguably, the best cloud conference in the world?

For those of you who missed the OSCON Cloud Summit, I've put together a list of the videos and speakers. Obviously this doesn't recreate the event, which was an absolute blast, but at least it'll give you a flavour of what was missed.

Welcome to Cloud Summit [Video 14:28]
Very light introduction into cloud computing with an introduction to the speakers and the conference itself. This section is only really relevant for laying out the conference, so can easily be skipped.
With John Willis (@botchagalupe) of opscode and myself (@swardley) of Leading Edge Forum.

Scene Setting
In these opening sessions we looked at some of the practical issues that cloud creates.

Is the Enterprise Ready for the Cloud? [Video 16:39]
This session examines the challenges that face enterprises in adopting cloud computing. Is it just a technology problem or are there management considerations? Are enterprises adopted cloud, is the cloud ready for them and are they ready for it?
With Mark Masterson (@mastermark) of CSC.

Security, Identity – Back to the Drawing Board? [Video 25:12]
Is much of the cloud security debate simply FUD or are there some real consequences of this change?
With Subra Kumaraswamy(@subrak) of Ebay.

Cloudy Operations [Video 22:10]
In the cloud world new paradigms and memes are appearing :- the rise of the “DevOps”, “Infrastructure == Code” and “Design for Failure”. Given that cloud is fundamentally about volume operations of a commoditized activity, operations become a key battleground for competitive efficiency. Automation and orchestration appear key areas for the future development of the cloud. We review current thinking and who is leading this change.
With John Willis (@botchagalupe) of opscode.

The Cloud Myths, Schemes and Dirty Little Secrets [Video 17:38]
The cloud is surrounded by many claims but how many of these stand up to scrutiny. How many are based on fact or are simply wishful thinking? Is cloud computing green, will it save you money, will it lead to faster rates of innovation? We explore this subject and look at the dirty little secrets that no-one wants to tell you.
With Patrick Kerpan (@pjktech) of CohesiveFT.

Curing Addiction is Easier [Video 18:41]
Since Douglas Parkhill first introduced us to the idea of competitive markets of compute utilities back in the 1960s, the question has always been when would this occur? However, is a competitive marketplace in the interests of everyone and do providers want easy switching? We examine the issue of standards and portability in the cloud.
With Stephen O’Grady (@sogrady) of Redmonk.

Future Setting
In this section we heard from leading visionaries on the trends they see occurring in the cloud and the connection and relationships to other changes in our industry.

The Future of the Cloud [Video 29:00]
Cloud seems to be happening now but where is it going and where are we heading?
With J.P. Rangaswami (@jobsworth) of BT.

Cloud, E2.0 – Joining the Dots [Video 30:04]
Is cloud just an isolated phenomenon, or is it connected to many of the other changes in our industries.
With Dion Hinchcliffe (@dhinchcliffe) of Dachis.

The Questions
The next section was a Trial by Jury where we examined some of the key questions around cloud and open source.

What We Need are Standards in the Cloud [Video 45:17]
We put this question to the test, with prosecution Benjamin Black (@b6n) of FastIP, defence Sam Johnston (@samj) of Google and trial by a Jury of John Willis, Mark Masterson, Patrick Kerpan & Stephen O’Grady

Are Open APIs Enough to Prevent Lock-in? [Video 43:21]
We put this question to the test, with prosecution James Duncan (@jamesaduncan) of Joyent, defence George Reese (@georgereese) of Enstratus and trial by a Jury of John Willis, Mark Masterson, Patrick Kerpan & Stephen O’Grady

The Debates
Following the introductory sessions, the conference focused on two major debates. The first of these covered the “cloud computing and open source question”. To introduce the subject and the panelists, there were a number of short talks before the panel debates the impact of open source to cloud and vice versa.

The Journey So Far [Video 10:59]
An overview of how “cloud” has changed in the last five years.
With James Urquhart (@jamesurquhart) of CISCO.

Cloud and Open Source – A Natural Fit or Mortal Enemies? [Video 8:44]
Does open source matter in the cloud? Are they complimentary or antagonistic?
With Marten Mickos (@martenmickos) of Eucalyptus.

Cloudy Futures? The Role of Open Source in Creating Competitive Markets [Video 8:43]
How will open source help create competitive markets? Do “bits” have value in the future and will there be a place for proprietary technology?
With Rick Clark (@dendrobates) of OpenStack.

The Future of Open Source [Video 9:34]
What will cloud mean to open source development and to linux distributions. Will anyone care about the distro anymore?
With Neil Levine (@neilwlevine) of Canonical.

The Debate – Open Source and the Cloud
 [Video 36:24]
Our panel of experts examined the relationship between open source and cloud computing.
With Rick Clark, Neil Levine, Marten Mickos & James Urquhart

The Future Panel followed the same format with first an introduction to the experts who will debate where cloud is going to take us.

The Government and Cloud [Video 10:27]
The role of cloud computing in government IT – an introduction to the large G-Cloud and App Store project under way in the UK; what the UK public sector hopes to gain from a cloud approach, an overview of the proposed technical architecture, and how to deliver the benefits of cloud while still meeting government’s stringent security requirements.
With Kate Craig-Wood (@memset_kate) of Memset.

Infoware + 10 Years [Video 10:38]
Ten years after Tim created the term infoware, how have things turned out and what is the cloud’s role in this?
With Tim O'Reilly (@timoreilly) of O'Reilly Media.

The Debate – A Cloudy Future or Can We See Trends? [Video 50:12]
The panel of experts examine what’s next for cloud computing, what trends can they forsee.
With Kate Craig-Wood, Dion Hinchcliffe, Tim O’Reilly & JP Rangaswami

So, why "arguably the best cloud conference in the world?"

As a general conference on cloud, then the standard and quality of the speakers was outstanding. The speakers made the conference, they gave their time freely and were selected from a wide group of opinion leaders in this space. There was no vendor pitches, no paid for conference speaking slots and hence the discussion was frank and open. The audience themselves responded marvelously with a range of demanding questions.

It is almost impossible to pick a best talk from the conference because they were all great talks. There are real gems of insight to be found in each and every one and each could easily be the keynote for most conferences. In my opinion, if there is a TED of cloud, then this was it.

Overall, the blend of speakers and audience made it the best cloud conference that I've ever attended (and I've been to 50+). This also made my job as a moderator simple.

I'm very grateful to have been part of this and so my thanks goes to the speakers, the audience, the A/V crew who made life so easy and also Edd Dumbill (@edd), Allison Randal (@allisonrandal), Gina Blaber (@ginablaber) and Shirley Bailes (@shirleybailes) for making it happen.

Finally, huge thanks to Edd and Allison for letting me give a version of my Situation Normal, Everything Must Change talk covering cloud, innovation, commoditisation and my work at LEF.

Islands in the sky

I'm often asked how will the cloud develop to which I'll answer -"imperfectly, very imperfectly".

I was reminded of this through a long discussion with Benjamin Black, hence I thought I'd write something to explain my general thoughts on the problem. First, let me apologise as this will be a long post. Second, we need to start by recaping some basic concepts about risks. The barriers to adoption in cloud cover three basic forms of risk :-

Disruption Risks : Change to existing business relationships combined with issues around political capital and previous enterprise investment. It's often difficult to let go of that which we have previously invested in.

Transitional Risks: These risks are related to the shift from a world of products to a world of services and they include confusion over the models, trust in the service providers, governance of this service world, transparency from the providers and security of supply. Many of the transitional risks can be mitigated with a hybrid (private + public) cloud approach, a standard supply chain management technique. This approach has been used in many industries which have undergone a similar change, for example in the early decades of power generation it was common to combine public generation with private generators. Even today most data centres mix a variety of public suppliers with backup generators and UPS systems. Fortunately, these transitional risks are relatively short lived.

Outsourcing Risks: These cover lack of pricing competition between the new providers , lack of second sourcing options between providers, loss of strategic control to a specific technology vendor, lock-in and unsuitability of the activity for such service provision (i.e. it's not ubiquitous or well defined enough for such volume operations based service provision). The outsourcing risks can be reduced through the formation of a competitive marketplace of providers with easy switching between them and ideally the option to in-house service provision. The outsourcing risks are long term.

For a competitive market to form, you need easy switching which means portability. The basic ingredients of portability include a choice of providers, access to your code and data from any provider and semantic interoperability between providers i.e. both the origin and destination providers need to understand your code and data in the same way. There is limited value in having access to your code and data if no other provider understands it and operates to provide the same functionality e.g. getting access to your data in salesforce is great but what do you do with it?

In such circumstances, there does exist a weaker form of syntactic interoperability, which means both providers can exchange data but the end result may not function in the same way and your data may not retain its original meaning. Often, this is where we see translation systems to convert from one system to another with the usual abundance of translation and semantic errors.

The ideal situation is therefore semantic interoperability, which generally means a common reference model (i.e. running code) which providers either operate or conform to. Unfortunately, common reference models come with their own risks.

Let us suppose you have a marketplace of providers offering some level of service at a specific level of the computing stack (SPI Model) and these providers operate to a common reference model. The model provides APIs and open data formats, giving you access to your code and data. You therefore have a choice in providers, access to your data and semantic interoperability between them. You have portability. BUT, if that common reference model is owned by a vendor (i.e. it's proprietary code) then that market is not free of constrant but instead controlled by the vendor. All the providers & consumers in that marketplace hand over a significant chunk of strategic control and technology direction to the vendor, who is also able to exert a tax on the market through license fees.

To reduce this loss of strategic control and provide a free market (as in free of constraints), then that common reference model must not be controlled by one party. It has to be open sourced. In such an environment, competition is all about operational efficiency and price vs QoS rather than bits. This makes intuitive sense for a service world, which is why I'm pleased openstack is following that route and I hope it will become the heart of a market of AWS clones. Obviously, you'll need different common reference models at different layers of the computing stack. Whilst only one is probably needed for infrastructure, you will need as many as there are competitive application marketplaces (CRM, ERP etc) in the software later of the SPI model.

Before anyone cries the old lie of standardisation hampers innovation, it's worth remembering that utility service provision (which is what cloud is really about) requires volume operations which in turn requires a ubiquitous and well defined activity. Whilst the common reference models certainly won't be perfect in the beginning, they don't need to be, they only have to create "good enough" components (such as a defined virtual machine). They will improve and evolve over time but the real focus of innovation won't be on how good these "good enough" components are but instead what is built with them. This concept, known as componentisation, is prevalent throughout our industrial history and shows one consistent theme - standardisation accelerates innovation.

So everything looks rosy … we'll have the economics benefits of cloud (economies of scale, increased agility, ability to focus on what matters), competitive marketplace based around multiple providers competing on price vs QoS, the options to use providers or install ourselves or to mitigate risks with a hybrid option, "open" API & data formats giving us access to our code and data, open sourced common reference models providing semantic interoperability, "good enough" components for ubiquitous and well defined activities which will cause an acceleration of innovation of new activities based upon these components … and so on.

Think again.

In all likelihood, we're going to end up with islands in the cloud, marketplaces built around specific ways of implementing a ubiquitous and well defined activity. Don't think of "good enough" components but instead a range of different "good enough" components all doing roughly the same thing. Nuts? It is.

Hence, in the infrastructure layer you're likely to see islands develop around :-

• EC2/S3 (e.g. core of AWS) including the open source implementations such as Open Stack, Eucalyptus and Open Nebula.
• vCloud principally provided through VMWare technology.
• a Microsoft infrastructure based environment.
• any Openstack APIs, particularly if Rackspace implements this.

All of these will be providing their own versions of "good enough" units of virtual infrastructure. Within those islands you'll head towards multiple service providers or installations, a competitive marketplace with switching between installation and semantic interoperability based upon a common reference model. The open source projects such as OpenStack are likely to form assurance industries (think moody's rating agencies, compliance bodies) to ensure portability between providers by comparison to the common reference model whereas the proprietary technologies are likely to develop certification bodies (e.g. VMWare Express).

Between islands there will be only syntactic interoperability (with exceptions such as OpenStack which will try to span multiple Islands), which will mean that you'll require translation of systems from one island to another. Whilst management tools will develop (and already have started) to cover multiple islands and translation between them, this process is imperfect and a constant exercise in chasing different APIs and creating a lowest common denominator (as per libcloud). Of course, I wouldn't be surprised if the libcloud folk were hoping that as a community develops around them, then the providers will offer libcloud as a native API. Such command & conquer strategies rarely succeed.

Given this complexity and since there will be multiple service providers within an island, it's likely that consumers will tend to stick within one island. If we're lucky, some of these Islands might die off before the problem becomes too bad.

Of course, these base components could effect the development of higher order layers of the computing stack and you are likely to see increasing divergence between these islands as you move up the stack. Hence, the platform space on the vCloud island will differ from the platform space on the EC2 / S3 island. We will see various efforts to provide common platforms across both, but each will tend towards the lowest common denominator between the islands and never fully exploit the potential of any. Such an approach will generally fail compared to platforms dedicated to that island, especially if each island consists of multiple providers hence overcoming those general outsourcing risks (lack of second sourcing options etc). Maybe we'll be lucky.

So, the future looks like multiple cloud islands, each consisting of many service providers complying to the standard of that island - either vCloud, EC2/S3 or whatever. Increasing divergence in higher order systems (platforms, applications) between the islands and whilst easy switching between providers on an island is straightforward, shifting between islands requires translation. This is not dissimilar to the linux vs windows worlds with applications and platforms tailored to each. The old style of division will just continue with a new set of dividing lines in the cloud. Is that a problem?

Yes, it's huge if you're a customer.

Whilst cloud provides more efficient resources, consumption will go through the roof due to effects such as componentisation, long tail of unmet business demand, co-evolution and increased innovation (Jevons' paradox). Invariably one of the islands will become more price efficient i.e. there is no tax to a technology vendor who collects their annual license and upgrade fee through a drip feed process. It's this increased dependency combined with price variance which will result in operational inefficiencies for one competitor when compared to another who has chosen the more efficient island. The problem for the inefficient competitor will be the translation costs of moving wholesale from one island to another. This is likely to make today's translations look trivial and in all probability will be prohibitive. The inefficient competitor will be forced therefore to compete on a continual disadvantage or attempt to drive the technology vendor to reduce their taxation on the market.

The choices being made today (many are choosing islands based upon existing investment and political choices) will have significant long term impacts and my come to haunt many companies.

It's for these reasons, that I've recommended to anyone getting involved in cloud to look for :-

1. aggressively commoditised environments with a strong public ecosystem.
2. signals that multiple providers will exist in the space.
3. signals that providers in the space are focused on services and not bits.
4. an open source reference implementation which provides a fully functioning and operating environment.

In my simple world, VMWare is over-engineered and focuses on resilient virtual machines rather than commodity provision. It's ideal for a virtual data centre but we're talking about computing utilities and it also suffers from being a proprietary stack. Many of the other providers offer "open" APIs but as a point of interest APIs can always be reverse engineered for interoperability reasons and hence there is no such thing as "closed" API.

The strongest and most viable island currently resides around EC2 / S3 with the various open source implementations (such as UEC), especially since the introduction of Rackspace & Nasa's service focused openstack effort.

I don't happen to agree with Simon Crosby that VMWare's latest cloud effort Redwood == Deadwood. I agree with his reasoning for why it should be, I agree that they're on shaky grounds in the longer term but unfortunately, I think many companies will go down the Redwood route for reasons of political capital and previous investment. IMHO I'm pretty sure they'll eventually regret that decision.

If you want my recommendation, then at the infrastructure layer get involved with open stack. At the platform layer, we're going to need the same sort of approach. I have high hopes for SSJS (having been part of Zimki all those years back), so something like Joyent's Smart platform would be in the right direction.

---  Added 19th August 2013

Gosh, this is depressing. 

Three years and 15 days later Ben Kepes (a decent chap) writes a post on how we're coming to terms with what are basically "islands in the clouds".

OpenStack followed a differentiation road (which James Duncan and I raised as a highly dubious play to the Rackspace Execs at the "OpenStack" party in July at OSCON 2010). They didn't listen and we didn't get the market of AWS clones. In all probability if AWS compatibility had been the focus back in 2010 then the entire market around OpenStack could have possibly been much larger than AWS by now. But, we will never know and today, OpenStack looks like it has almost given up the public race and is heading for a niche private role.

In his article, Ben states that companies never wanted "cloud bursting" - a term which seems to be a mix of 'live' migration (a highly dubious and somewhat fanciful goal to aim for which is more easily managed by other means) combined with the ability to expand a system into multiple environments.

Dropping the 'live' term, then both can be achieved easily enough with deployment and configuration management tools. One of the reasons why I became a big fan of Chef in '08/'09 (and not just because of my friend Jesse Robbins). This sort of approach is simple if you have multiple providers demonstrating semantic interoperability (i.e. providing the same API and the same behaviour) as your cost of re-tooling and management is small. It becomes unnecessarily more complex with more Islands.

Anyway, that aside the one comment I'll make on Ben's post is the goal was never "cloud bursting" but instead second sourcing options and balancing of buyer / supplier relationship. Other than that, a good but depressing post.

Old yet new ...

I'm just comparing two of my talks, both on cloud computing and if anyone has time, I'd like some feedback.

The first is my recent talk from OSCON in 2009 covering "What is cloud computing and why IT matters", the second is my talk from OSCON in 2007 covering "Commoditisation of IT"

They both cover the same topic matter but with a different viewpoint (N.B. terms have changed since the 2007 talk but I'd like some feedback on style & content.)

Both are 15 minutes long but which was better and more importantly, why?

OSCON 2009: What is cloud computing and why IT matters

OSCON 2007: Commoditisation of IT

Capital...

Over the years, I've often discussed the ideas of physical and human (intellectual and social) capital within organisations. I thought I'd cover some old ground again.

Organisations simply exist between the intersection of a network of people and a mass of activities undertaken. Remove this and you're left with what an organisation really is, nothing bar any remaining residual capital.

The act of people interacting with activities creates several forms of capital, three of the most interesting are physical, intellectual and social. All of these forms of capital are susceptible to the ravages of commoditisation.

We've already experienced the effects of commoditisation on physical assets. For example, the news industry was once able to use physical assets (large and expensive printing machinery) to control the activity of publishing - not only what was published but whom. In days of past if you wanted to be a journalist your options were limited.

Today, the digitisation of content and the spread of the means of mass communication have changed the rules and commoditised this activity. The barriers to entry have been severely diminished and anyone can publish, This means news organisations have been forced to seek other means of differentiation, value and ultimately control.

Equally, many forms of intellectual capital has slowly been commoditised. Whereas in the past you needed direct access to a lawyer to help with the arcane knowledge of how to write a will, today you can download forms online.

All manner of knowledge has been neatly codified, commodified (given a value for access) and ultimately commoditised (become standardised, commonly available, relentlessly driven to a lower cost) through market forces.

Access to knowledge can (and has been) an important mechanism of control for some organisations. The commoditisation of such knowledge diminishes this means of control. As a journalist may find they are less dependent on a news company in order to publish, a budding lawyer may find it easier to access the knowledge they need without a law firm.

Obviously both types of organisations still provide the benefits created by the internal ecosystem of a network of people and a mass of different activities (i.e. rapid access to certain skills, specialists and supporting structures). However, both types of organisation will also have social capital - interactions, reputation and relationships with others.

Hence a journalist or lawyer my choose to work with one particular organisation because it can offer access to the right people, provides a prestigious network and has a high amount of social capital.

I mention this because many social network tools are currently busy codifying relationships between people. Furthermore, some are also trying to identify and provide measurable value in those networks (the act of commodification). Could this onslaught also lead to the commoditisation of business networks?

Will we see a future where we can buy and sell access to a social network? How will this impact organisations who depend upon their networks and use access as a means of control? Will companies also attempt to control and own this network more tightly?

These are just some of the questions I suspect we will be facing over the next few years.

Lifecycle

For many many years, I've talked about the evolution of activities (from innovation to commodity), how this enables further innovation (componentisation) and why organisations compete in ecosystems (Red Queen Hypothesis). I've also hypothesised an S-Curve of ubiquity vs certainty to describe this evolutionary change, demonstrated techniques to manage such activity life-cycle, shown how Gartner's Hype Cycle can be derived and catalogued the underlying interconnection between Enterprise 2.0, cloud, SOA and web 2.0.

Rather than bore you with the details again, I thought I'd concentrate on a couple of diagrams to explain many of the structural aspects of this.

Figure 1, provides an overview of how activities changes from innovation to commodity, and more importantly how techniques, focus and strategy changes.

Figure 1 - Lifecycle (click on image for higher resolution)

All business activities exists somewhere on this S-Curve and all of them are moving from innovation to commodity. Hence any organisation can be characterised as a network of people interacting with a network of constantly evolving activities, with the organisation itself simply being the intersection between activities and people. You can actually visualise this, though I tend to focus on the network of activities rather than people. By mapping out lines of business against state of evolution, I've found useful tricks for managing activties along with patterns for competing with others.

Learning how to manage activities at their different life-cycle stages and hence knowing how to drive innovation, leverage emerging activities and commoditise that which is cost of doing business is essential for any company. This act is one of balancing the old innovation paradox between survival today (efficiency through co-ordination, coherence & hence order) and survival tomorrow (innovation of new activities, hence deviation, serendipity & disorder).

Since I've often talked about the organisational details of managing life-cycle (the use of pioneers, colonisers and town planners), I thought I'd instead just concentrate on the basic structure. Figure 2 provides the structural elements that are important:-

• Core services : these are core services that the organisation provides, in the I.T. world this is the area where SOA, cloud and other "service" concepts are most relevant.
• Ecosystem : this is the ecosystem that an organisation creates around its core services including workforce, partners, community, channels, customers etc.
• Innovation at "the edge": in general, the larger the ecosystem then the greater the potential for innovation to occur. The concept of innovation at the edge simply refers to expanding the ecosystem as wide as possible.

Figure 2 - Ecosystem (click on image for higher resolution)

In a typical example (e.g. Salesforce & Amazon), the company providing the core services enables and encourages a wider ecosystem to develop around it.

By monitoring new activities (i.e. innovations), and the early adoption of new but similar activities (copying is one of the many signals of success), the company can look to leverage any innovation for the benefit of the wider ecosystem. Methods which can help enable this vary from the provision of an application store to increasing awareness of innovations through the use of Enterprise 2.0 techniques.

By monitoring signals of wider adoption (i.e ubiquity) and early formation of standards (increased definition and certainty of the activity), the company can elect to drive an activity towards commoditisation and provision as a core service. This correspondingly completes the circle and encourages further innovation in the ecosystem through componentisation.

Quite simply put, the structure is simply designed to feed off and accelerate the normal process of evolution of activities (technical or otherwise). This results in a situation where apparent innovation (others are innovating for you), customer focus (leveraging of consumption data to deliver what people want) and efficiency (economies of scale) can all increase with the size of the ecosystem.

I mention this because the centralist approach is to provide all activities at the centre as opposed to "crowdsourcing" both creation and identification of innovation to a wider ecosystem built around a core of common services. Whilst centralisation is not an invalid approach, it is generally highly ineffective when competing against a company which creates a broad ecosystem. This is shown in figure 3.

Figure 3 - Competitive Landscape (click on image for higher resolution)

So with this in mind, I turn to the U.K. Government cloud efforts. It's worth remembering that the U.K. Gov I.T. currently employs over 35,000 people and outsources nearly 65% of its budget (from a total figure of £16bn+). This pretty much makes the internal part of U.K. Gov I.T. equivalent to Google PLUS Amazon whist the outsourcing part is far bigger.

The approach of providing standardised & centralised core services for commodity activities (such as computing infrastructure) is fine. However, as there is no actual competitive utility computing market, an approach of outsourcing to a group of vendors would be unwise (it's worth noting that both Google & Amazon adopted to build in-house). Fortunately, one set of standards - EC2 & S3 - are emerging.

Given this, a sensible strategy would be to adopt these emerging standards, consume conforming external services and where needed build using an open sourced technology (there are several to choose from, Ubuntu Enterprise Cloud would be one). Design for a mix of private / public (hybrid) with a near future view of using multiple public providers.  Develop any needed new elements in-house whilst outsourcing standard components i.e. data centre floor space, power provision etc.

The second area of concern is the Government Application Store. Whilst providing a centralised mechanism of application fulfillment is a sensible approach, the concern should be how those application are developed and provided to the store. Whilst some applications have become commoditised enough to be provided as centrally managed applications or services, it is absolutely essential that the application store should encourage a wider ecosystem (especially at local government level and within communities) for the development of new applications.

A fairly sound approach would be to combine the above with mechanisms of ecosystem monitoring and encouragement for the wider adoption of successful activities. An alternative centralist nightmare, would be where the core (i.e. some form of centralised council) attempts to predict the future whilst defining and developing activities to be adopted (a dis-functional programme management approach). This will lead to the normal flurry of massive development costs, vendor dependency and lock-in.

So why should I care? Well, I live in the U.K. and our Government exists in a wider competitive ecosystem of national governments. The role of U.K. Gov I.T. is to get this stuff right, the same with any other Government.

Trading Amazon Instances.

The problem with predictions is not the knowing of what but the knowing of when.

I spectacularly failed to predict the current financial crisis having expected it to occur several years earlier. I'm also expecting that my 2007 prediction of when cloud computing brokers will appear (along with exchanges in computing resources, futures and swaps in resources) will also fail.

This became clear as soon as Amazon introduced reserved instances. The only thing preventing the formation of a trading market in EC2 instances, is that reserved instances are not transferable. As soon as that changes, we will quickly move from reserved instances and the spot price to a commodity exchange and the usual paraphernalia of derivatives to spread betting.

Whilst I predicted that "six years from now, you'll be seeing job adverts for computer resource brokers", it now seems likely to be earlier.

Is the enterprise ready for the cloud?

There are many known risks associated with the cloud, some are transitional in nature (i.e. related to the transformation of an industry from a product to a service based economy) whilst others are general to the outsourcing of any activity. These always have to be balanced against the risk of doing nothing and the loss of competitive effectiveness and/or efficiency.

You'll find discussion of these risks in various posts and presentations I've made over the years. The forces behind this change are not specific to I.T. but generic and have (and will) effect many industries.

In this post, I want to turn the clock back and discuss again the organisational pressures that cloud creates because for some reason it doesn't get mentioned enough.

The tactics and methodologies needed to be used with any activity depend not upon the type of activity but it's lifecycle. For example, there is no project management method applicable to all types of activities despite the desire of many organisations to try and simplify this complex problem to a unified approach. Using agile everywhere is about as daft as using prince 2 everywhere, single policies simply aren't effective.

The shift towards cloud and the further commoditisation of I.T. will actually exacerbate this problem of single policies by highlighting the extremes and differences between managing an innovation and a commodity. Many organisations are simply not geared upto dealing with the realisation that they are complex adaptive systems rather than linear like machines.

People often ask the question whether "the cloud is ready for the enterprise" but the bigger question which is missed is whether "the enterprise is ready for the cloud". In many cases, the answer is no.

An example of the problems that the cloud can create is the shift to a variable model of charging and the move away from capital expenditure. Whilst it makes intuitive and obvious sense to pay for what you use, I'll use the example of worth based development to show where it goes wrong.

Back in 2003, I was extensively using agile development techniques for new projects to overcome the normal conflict between the client and the developers over what was in or not in the specification. It should never be forgotten that the process of developing a new project is also a process of discovery for the client. Requirements change continuously as more is discovered and agile is specifically designed to cope with a dynamic environment. However, it does have a weakness.

Whilst the client gets more involved in the project, the cost of change reduces (due to test driven development) and the client gets more of what they wanted, the weakness is that in most cases the client has little or no understanding of what the value of the system is going to be other than the amount they have to spend on it. In response to this, I introduced a concept known as worth based development.

The first step was to sit down with the client and work out a measure of worth for the system (i.e. machines sold, leads created, new customers found, improved forecasting etc). Once we had an agreed measure of worth, we used models to calculate the likely range of potential values that such a system would create.

If we calculated that the potential was high enough and the risks acceptable then we would offer to build and operate the system in return for an element of the measurable value created. This was a no-win, no-fee mechanism of development and goes far beyond "pay for what you use" and into "pay a fraction of what you get out".

The effect of this approach was several fold :-

1. If we didn't believe the project was likely to succeed then we wouldn't work on this basis and instead charge on a more traditional model (hours billed etc). This told the client valuable information about their project.


2. If we both agreed then immediately both parties were now focused on maximising the value of system rather than developing an arbritary set of capabilities. If an opportunity arose that could maximise value, then it was easy for both parties to accept it.

Charging based upon a measure of the value created sounds obvious but it was a spectacular fail.

In one case, we built a system which created leads for highly expensive equipment. The measure of value here was leads (i.e we didn't control the sales process which was entirely separate). We worked with the client, built the system and switched it on - it was a massive success.

In a few months, we had created tens of thousands of leads. Our charge was around 10 euros per lead and the client had racked up a sizeable bill. At this point I received a phone call.

The client asked me to switch the service off. I asked why and whether they were happy with all the leads. The answer came back that they were delighted with the leads, lots of which were turning into sales but could we still switch the system off because they had run out of budget.

Now this perplexed me because a single unit of the equipment sold for thousands of euros and the client was selling to a good percentage of the leads (often with multiple units). Working with the client, we quickly showed them how the additional revenue vastly outstripped the cost, the system was simply generating profit and we had the figures to prove it.

The problem however wasn't profit, they could see it was creating it. The problem was that the cost had exceeded the allocated budget and the client would have to go through either another planning cycle or an approval board to get more funds. Both options would take months.

I was stunned, the client was asking me switch off a profit making system because it had been too successful and the cost had surpassed some arbritary budget figure. They answered "yes" and stated that they had no choice.

Even in a case where direct additional revenue and profit could be proved, the budgetary mechanisms of the organisation were not capable of dealing with variable costs because they'd never been designed that way. The situation is worse in the case of the utility charging model of cloud providers because a direct measure of worth cannot always be shown. This problem of variable costs vs fixed budgeting & long planning cycles is going to re-occur for some organisations.

Not all enterprise are ready for the cloud.

Happy days are here again ...

Having arrived back from Dublin, I discover the local media is all a flutter with the tales of huge banking bonuses. In my view this is great news as it means the banks must be doing well and so we can finally stop the continued bail-out.

There is no need for any more of the £125 billion quantitative easing scheme and the purchase of gilts at hyper inflated prices. Obviously some banks have been making a nice little earner on this but they've got cash now, they're loaded and so they don't need it.

We can stop the planned £600 billion buy-out and insurance of toxic debt - the unfortunately named asset protection scheme. The one asset it won't protect is taxpayer funds and so with the banks awash with cash it's time to end this idea.

Obviously the $400bn black hole heading towards the private equity industry won't need any government funds because the banks have cash and they funded most of these shenanigans.

The generous lines of credit, the chunky loans - well this can all stop. With the banks in such good shape then I'd expect to see a wholesale reversal on the flow of funds as taxpayers want every penny back with a decent return to boot.

Trebles all around in my view.

Unfortunately I suspect that the trebles have already been drunk by a select few who are playing a lavish game of financial roulette insured by the average person on the street. From what I understand, most of the profits are coming from the investment banking operations rather than any meaningful growth in the lending industry to the business sector. As the Fed has been discovering, its recent use of taxpayers funds to improve liquidity has been gamed to generate handsome profits in these investment operations.

The taxpayer can only fund such an illusion of recovery for so long. Eventually we'll have to wake up and face the horrid truth especially as the abyss that it is the OTC market starts to swallow up what's left of yesteryear's fortunes.

I suspect we'll once again see that last bastion of the financial industry, a shabby bunch of fortune tellers who'll be wheeled out to explain that no-one saw it coming.

Actions speak louder ...

Today, the chancellor presented an excellent budget.

The budget contained investment in building & green technology, measures for the protection of society's most vulnerable, focus on training & jobs, benefits to savers, introduction of a higher tax rate and increased government borrowing in order to maintain public spending. Unfortunately whilst it's an excellent step in the right direction, it's just a step and we've got an enormous mountain to climb. That said, combined with Brown's recent lambasting of snout troughing MP's, this has been a good few days.

It's still a great shame we purchased all those gilts in the "quantitative easing" fiasco, that interest rates have remained too low, we've been foolishly generous regarding re-insurance of bad debts, the excessive bonus culture remains intact and the for the wealthiest it is all too easy to avoid tax. However, at least this we're heading in the right direction.

Naturally, a few of the most advantaged made the usual hollow threats to leave the country. Such words not only demonstrate arrogant beliefs of self-importance but also a delusion that anyone else cares or that somehow they won't be replaced in a heartbeat. Please don't threaten to leave - just leave, go on, sod off ... and don't come back.

Inflation still rampant

Depressingly, inflation still continues to remain well above the government 2% target at 2.9%. Sterling has also gone through a sustained period of depreciation and nothing is being done.

What I'm bemused about is how some are calling "quantitative easing" a success and stating that we need more of it. What we need to do is raise taxes, nationalise the building industry, increases interest rates and start building social housing. But don't worry, we're going to get a £5,000 voucher to buy a green car instead.

They've all gone quackers.

Help needed with the Cloud ...

I'm writing a piece on cloud computing and I'm stuck on a particular analogy. I need to know who invented the "industrial revolution" and who actually first coined the phrase?

Also, I'm still looking for a short and catchy definition for the "industrial revolution" which explains everything in a single sentence rather than requiring me to read several volumes of enlightened historical writings.

Come on people, it has been over two hundred years now. Surely we've got this one nailed down to 140 characters or less.

When the going gets rough ...

I was recently asked what legislation do we need to control the shenanigans in the financial community. As far as I'm concerned we've got plenty.

Over the last decade much has been done to push forward the ideologies of monetarism with numerous threats made that excessive regulation would force Banks and certain industries to leave our shores. The reckless continuation of monetarist dogma has led to this debt fuelled society and the resultant serious damage to property and harm caused to the public.

The act of threatening or actual harm in order to further an ideology is amply covered by the anti-terrorism laws of 2000 & 2001. Under these laws the Government has the right to seize any cash or assets which are either connected to or have been obtained through threats and acts related to the pursuit of such an ideology.

As far I can see, this includes Sir Fred's pension.

Well, that's what the pirate in me says we should be doing.

Wide of the mark ...

There has been some excellent analysis about the recent announcement by Canonical of Karmic Koala. I'd like to take some time to respond to some of the questions raised in Matt Asay's post and by the comments left.

Can someone point me to a dumbed down explanation of the cloud?
Certain activities at various layers of the computing stack (application, platform and infrastructure) have become so ubiquitous and well defined that they are suitable for service provision through volume operations.

This transition from a product to a service based economy is behind the growth of the various "as a Service" industries. This is a disruptive shift which offers numerous benefit from economies of scale (through volume operations), focus on core activities (outsourcing), acceleration in innovation (componentisation) and pay per use (utility charging).

It also creates various risks (management, security and trust) related to the transitional nature of this shift, along with all the normal concerns around the outsourcing of a common activity (second sourcing options, competitive pricing pressures & lock-in).

Twenty years ago, this change was first described as utility computing. Today, the concepts of utility computing, this disruptive transition of the computing stack from a product to a service based economy, the growth of a new breed of volume operation specialists (the as a Service industry) and the underlying technologies supporting this change have been grouped together under the heading of cloud computing.

Open source strategy must be subordinated to a successful proprietary software strategy.
As ubiquitous and well defined activities in IT head towards service provision, i.e. "the cloud", the potential outcomes include regulated large scale monopolies or the formation of competitive marketplaces.

The advantages of creating a functioning marketplace are numerous. For consumers there exists freedom, choice and competitive pricing. For providers there exists reduction in adoption barriers and competitive advantage through operations. The formation of markets also creates other service related revenues such as brokerages, exchanges, support, assurance and insurance.

The full list of benefits are many and wide however competition in these markets will require standards and easy switching between providers, just as you have within the electricity industry.

Unfortunately the often cited analogy of electricity contains one major flaw. We are not neutral to our provider as we have a relationship with them (our data, code, meta data etc). For easy switching between providers we need the ability to move our relationships between providers, a choice in destinations and each provider to offer the same output. Whilst the output in the electricity industry is a standard provision of electricity, the cloud computing industry needs to standardise the output of various layers of the computing stack.

Naturally there will be more standard outputs in the application space (i.e. there are more types of applications) than in the infrastructure space. However, the only practical way of achieving this is for those standards to be open source reference models, i.e. complete functioning and running open source code.

I discussed this at length at OSCON in 2007 and at much earlier talks.

Furthermore, for a ubiquitous and well defined activity, open source fundamentally makes more sense as any value relates to service provision rather than the marginal feature differentiation of an common application. The premise that open source must be sub-ordinated to proprietary technology is faulty in this case.

That strategy increasingly points to tethering an open server (and desktop) with closed cloud services. That's not a critique. It's a fact.
The move towards competitive marketplaces based upon open sourced standards should benefit consumers (choice and freedom), providers (removal of adoption barriers) and society overall (acceleration in innovation).

This will require standardisation around open source reference models and easy switching between providers. I trivialised these concepts with my post on the three rules happy of cloud computing.

Rule 1: I want to run the service on my own machine.

Rule 2: I want to easily migrate the service from my machine to a cloud provider and vice versa with a few clicks of a button.

Rule 3: I want to easily migrate the service from one cloud provider to another with a few clicks of a button.

At the infrastructure layer of the stack, Canonical's approach to cloud computing can be clearly seen as helping support the development of standards, to promote open source in the cloud computing space, to build an ecosystem and to make users Rule 1 happy. This however is not the end but the beginning of a journey.

Mark made the comment that it would be apt to make it easier to navigate the jungle. Navigation is inherently all about movement and freedom of choice.

I firmly and absolutely believe in choice for users and the creation of competitive markets and ecosystems. Users and providers should not be limited to a proprietary framework or any single source.

Whilst Matt is obviously not taking pot shots at Karmic Koala and his blog is an excellent read, his reasoning here is somewhat wide of the mark. Of all the trees in the forest, the Koala loves Eucalyptus.

National Savers Day ...

At a time when inflation exceeds the national target of 2%, the Bank of England is introducing quantitative easing to solve our economic mess. This is akin to pouring oil onto a road in order to slow down a speeding car. 

Whilst the long term effect of high (and hopefully not hyper) inflation compared to savings returns will eventually resolve the crisis it won't be until a combination of a weakening internal economy, weakening currency and core inflation has helped dig a deeper hole. We should therefore at least spend a moments thought for the ordinary folks whose life savings will become worth a lot less (hopefully not worthless) in the process.

Rather than raising taxes, the savings of common people will be used to bail us out of an economic abyss created by some of our wealthiest citizens combined with some very dogmatic and rather foolish economic policies. Of course, the very approach of quantitative easing will help support stock and house prices (temporarily) which bizarrely enough are things that those people who will be out of work and the most careful of savers don't tend to own a lot of. 

So trebles all around for wealthy gamblers and as for your common ordinary savers ... well, the least we should do is to have a national holiday to say thanks.

Thank you savers for keeping within your means, being careful with money, saving up for a rainy day and then bailing out the rest of us when we've blown all the future cash. Whilst your savings might crumble on the bright side it will maintain house prices you can't afford and stocks you didn't buy. So, thank you.

Lastly, a friend asked me to provide a short definition for quantitative easing.

"Quantitative easing is a fiscal laxative best avoided when your economy is already in the toilet."

Or in other words, when you're in a hole ... stop digging! And no, by digging a deeper hole you won't be able to magically back fill the hole you've already created with the new earth you've just dug. It doesn't work like that.

Update 9th May 2013

Warren Buffet says he feels sorry for savers - ah, what kind words. That must warm the heart of the savers out there as they're looking at the cat food tins and asking "is it edible?"

Update 5th August 2013

I do think the Government should bring in a range of issues for the five year old "granny bonds" (NS&I Inflation Linked Certificates) even with a low maximum capital (i.e. £100K) so that some of the least well off savers don't get utterly mutilated by what is about to start to unfold.

When in a hole ...

Once again we approach the cataclysm that is quantitative easing, otherwise known as printing money (but without the direct investment of a Keynesian type approach).

The whole approach of reducing interest rates led to savers having less money to spend whilst those in serious debt just tried to hang on. The net effect might be to slow the creeping expansion of toxic debt (good for banks), reduce currency value and cause an influx of cheap foreign capital (good for stock market and house owners but bad for inflation) but this is at the cost of shrinking and weakening our overall economy (bad for people).

A large number of souls are out of work for no particularly good reason. With inflation running at 3.1%, we need to be restoring confidence to our savers and our currency. Printing more money through such a scheme will either cause an exodus that'll lead us into a tailspin or more likely drag out the recession for many years.

Despite beliefs that we can dig our way out of this mess by applying the same sort of techniques which got us here in the first place, we just seem to be getting in deeper.

By the way, if the banks have so many toxic assets they would like to get rid of, can't they at the very least pay bonuses in them?

It's all about new technology .... NOT!

I was recently asked to explain the difference between "cloud" computing and the earlier attempts to create an ASP (application service provider) industry. Is it just down to new technology? To understand the difference, we first need to get to grips with some of the fundamentals of change and what cloud computing is.

The fundamental forces behind change

Back in the 1990s, Paul Strassmann demonstrated that there was no link between IT spending and business value. Whilst there has been some argument over the validity of the research, Strassmann’s work created an idea which rapidly spread. This idea was that not all IT is the same, not all IT has value and some IT has commoditised.

However, what is commoditisation?

In its simplest terms, commoditisation (as opposed to commodification) is a neologism which describes how a rare and poorly understood innovation becomes well defined and ubiquitous in the eyes of the consumer. In other words, it’s a transition that describes how a once rare, exciting and new activity (an innovation) becomes commonplace, bland and standardised (more of a commodity).

The most often quoted example of commoditisation is the electricity industry and how this innovation led to the formation of national grids in the 1930s. Today, to most consumers, electricity is something you get from a plug and few companies describe their use of electricity as a source of innovation or a competitive advantage.

Whilst the journey from innovation to commodity has numerous stages (for example bespoke, product and services), this represents a continuous but hazardous transition of an activity to more ubiquity and better definition. There are numerous factors controlling the transition but for brevity I'll simply state that not all activities will commoditise, some have physical, social and other constraints. In figure 1, I've plotted business activities against axis of ubiquity (how common something is) and certainty (how well defined and understood something is).

Ubiquity vs Certainty for TVs, Telephones and VCRs.
(click on image for larger size)

The data is derived from the TV, Radio and Phone industries however it suggests that an S-Curve relationship between the ubiquity and certainty of an activity exists. The graph shows a path for how a rare and poorly understood innovation becomes a common and well defined commodity.

All business activities are somewhere on that curve and all of them are moving, commoditisation never stops and IT activities are no exception. Figure 2 provides a hypothetical example of the activities within a business.

Representation of activities in a business
(click on image for larger size)

This graph is a representation and the highlighted points are not real data. The real path can only be determined after an activity has reached a certain level of commoditisation (in other words, I can't predict the future). You can however use pretty good expert reviews but that's another topic for another day. Since all the activities are connected, you can also expand this graph by looking at the linkages between components and how commoditised they are but that's also another topic for another day. I do however want to note that the journey of an innovation to ubiquity is not an easy one and some of the changes can be disruptive to an existing industry. This is especially true as any activity moves from the product to services stage of its journey.

Such a disruptive change is occurring in IT today. A quick glance at the current list of hot terms brings up subjects such as service oriented architecture, web services and mashing up services. All of these contain a strong service theme. The computing stack, which again for brevity I’ll characterise into three layers of application, platform and infrastructure is slowly shifting away from products towards standard components provided as internet services.

The last thing to note is that you have no choice when it comes to commoditisation. If you treat an activity as an innovation whilst everyone else uses standard services, then the only thing you are likely to create is a competitive disadvantage for yourself. This is why any company needs to continuously adapt to changes in the surrounding market just in order to retain its competitive position (the Red Queen Hypothesis).

In general, commoditisation is a continual process that can be be highly disruptive. You have to continuously adapt to this change and it is happening in IT today.

What is cloud computing?

Certain IT activities have become so common and so well defined that they are now suitable for service provision through volume operations. This is not confined to one particular layer of the computing stack but across all layers. This transition has given rises to the “as a Service” industry which includes :-

• Infrastructure (or Hardware) as a Service providers such as Amazon and FlexiScale.
• Platform (or Framework) as a Service providers like Ning, BungeeLabs and CogHead.
• Application (or Software) as Service providers like Salesforce, Zoho and Google Apps.

Supporting this transition is a range of technologies from clustering to virtualisation. In essence these have provided effective means of balancing the supply of computing resources to match the demand, a necessity for volume operations.

Whilst the concept of providing of computing resources through utility-like service providers dates back to John McCarthy in the 1960s, this idea began to sink into the fog of history shortly after. It resurfaced in the 1990s as it became the fashion to think of IT development as a factory-like process with standard components which could be plugged together to create new applications. With the development of  the internet,  a resurgence of interest in the concepts of utility-like service provision began. Unfortunately, many early attempts  were unsuccessful as they tried to apply such methods to activities that lacked both ubiquity and definition.  Increasingly as areas of IT have become common they have become more suitable for outsourcing to such providers. Managed hosting providers led this second wave of change and the new breed of volume operations specialists such as Amazon are leading this third wave.

In general the concepts of utility computing, this disruptive transition of the computing stack from a product to a service based economy, the growth of a new breed of volume operation specialists (the as a Service industry) and the underlying technologies supporting this change have been grouped together under the heading of cloud computing.

So how about ASP?

Well, ASP is part of the same overall process but as I said earlier many of the attempts focused on activities that were neither ubiquitous nor defined enough for such a volume operations approach. Others were more a a rental model for products. Today, this has changed. Cloud computing has less to do with a technological change and more to do with an environmental change in the wider IT economy.