I wrote the below blog entry in Sept 2005 around the incarnation of enterprise virtualization and the natural evolution from centraliztion to decentralized and back to centralized again.

It's not to be taken too seriously  but the key message at the time I saw was around the increased utilization, the piece I glanced at but is now every more apparent is just how important the promise of flexibility and agility play in building a fluid self provisioned infrastructure.

Anyhow, I was in the process of collapsing a couple of web personas, found this doc hanging around so thought I'd place it so I didn't lose it. The other thing interesting to note I I figured by the end of 2006 we would be complete and I 'believe' if I try and translate my old abstract mumbles we are still not quite there.

.........................clip................................

Once upon a time in a not too distant kingdom resided a king with a particularly cumbersome problem, a big tin dragon that had a special talent for counting the kings taxes but with bad habits around being very stubborn, inflexible and rather costly with regular peasant sacrifices.

The king traveled to the local wizard to seek advise on this quandary, the wizard waved his hands mysteriously over his crystal ball and showed the king the possibility of a new life of smaller cheaper counters called an ‘abacus’, that can be used directly by the villagers without risk of accidental ingestion and offer the ability to not only count the kings taxes but also perform tasks that are most pertinent to local interest such as swamp algae cultivation or micro deforestation, thus distributed computing was born.

The King was thrilled by the change, gone were the days he had to answer to the dragon keeper Ivan Braun Munches, gone the inflexibility of the Tin dragon, the accidental reductions in workforce and the high price paid for specialist dragon dietitians.

A few years later, whilst gliding through the silky glades of his kingdom, the King was perplexed because, that although the Tin dragon had been replaced by sleek smaller cheaper counters, the cost of managing this distributed abacus network had escalated quite dramatically and once a year when the peasants were required to provide their ‘king appreciation tax’, the larger villages required more power than a single abacus which led to inaccurate calculations and in some case false imprisonment for tax evasion.

The King once again traveled to seek advice from the wizard, who pondered and thought thought and pondered until he revealed a cunning plan to split up the larger taxation tasks from the challenged villages and apportion part of the counting to villages that had spare cycles to allow the counting to happen faster.

The King implemented such a plan, he managed to accelerate the taxation process and immediately showed that with a distributed network of abacus devices, you could use available cycles to act as ‘tin dragon’, thus the birth of grid.

Over the next few years, at the same time each year, the King’s specially trained carrier pigeons, a special albino breed (White throated schedulers) who would fly to the Abacus workers to see if they have spare capacity and use them for counting his taxes. In most cases this worked just fine, but as the abacus workers became more established in the village, the workers locked the abacus away in fear of contamination which started to make the grid sporadic and unreliable in its efficiency.

This left the King in a taxing situation, although there was potential to use the distribution of such devices, without a predictable measure it was impossible to provide a guaranteed level of service which was exacerbated by the spiraling costs of managing a distributed network of abacus devices.

The king once again returned to the wizard and asked for his wisdom, the wizard thought and pondered, pondered and thought and in a puff of smoke, came up with an idea to centralize the abacuses in a specially designed abacus building to ‘pool resources’ and create the ability to further partition each abacus, so instead of using three rows of beads you can actually allow three people to work on one row each at the same time as many of the abacus workers traditionally used only one row. The partitioning was called isolation and the special stool to accommodate three different people at the same time was called a hyper-visitor which was latterly shortened to hypervisor.

The king was once again happy; he did suffer a little from hot working conditions and had to install fans on the ceiling to help with heat dissipation through having such a dense utilized abacus facility.

This new model had virtually the same abilities as the tin dragon and virtually the same cost as the distributed cheap abacus's but also allowed a high level of utilization and a higher capability to schedule guaranteed results. The king decided to call this virtualization for a liquid infrastructure.

So Grid had in a strange quirk of fate been the first use case for virtualization.

Once the king had this facility running smoothly he started to offer capacity as a service to other kingdoms and charged them on a result basis, he decided to call this on demand utility bartering. The lords of course wanted to ensure their taxes were done on time so insisted that the king signed a legal agreement or SLA to make sure their workload was executed at a previously agreed rate.

Before long, the king had created the most efficient cost effective way to execute taxation, he also discovered that other kings had followed suit and created a similar utility but for poultry management, guard payroll, security from Trojans, single guard sign in etc. The king thought if there was a way to harness each of these assets in some reusable way, you could offer them to other states or countries as a service orientated asset base or architecture.

This completed the final piece in the puzzle, before long they provided service orientated activities across the land and across the globe, the model started centralized with a high cost, went low cost and distributed, gained efficiency through grid, centralized to provide controls and virtualization, sourced through a utility model and then offered out in a service orientated manner.

So the moral of this story is, some fairy tales aren’t fiction.

Abridged as my memory is not what it used to be

To-morrow, and to-morrow, and to-morrow,

Creeps in this petty pace from day to day,

Life's but a walking shadow, a poor player

That struts and frets his hour upon the stage

And then is heard no more. It is a tale

Told by an idiot, full of sound and fury

signifying nothing." — Macbeth (Act 5, Scene 5, lines 17-28)

As a recent transplant from BEA Systems (AKA Oracle), I was struck with the overriding fear that my opening keynotes from last year’s BEAworld’s (see above), where I suggested that the idiots Macbeth referred to were people who tried to deploy SOA (service orientated architecture) in scale without using a virtual infrastructure, was perhaps misrepresented. Sadly, I’m now of the opinion it was me for not realizing that to enable a truly dynamic or agile applications infrastructure you need dynamic/agile storage.

Fast rewind…

I was asked to keynote at BEAworld on the topic of Virtualization and SOA. I hate the opening moments where you step up on stage and awkwardly introduce yourself, so I had a cunning plan to recite the above soliloquy from Macbeth, and then assert that he was the first SOA architect pointing out that ‘situational applications’ wouldn’t be built and discarded but would stick around and have a life of their own, so it’s a smart thing to plan for the unplanned.

I fundamentally believe we’ve redefined what both an application is and what a developer does, with mash-up, compositions and situational applications. Every employee of a business can construct an application or service and create unforeseen computer load on a data centre - a growing phenomenon as the expedient execution of data to knowledge drives a competitive edge and there’s nobody better than the consumers to know what and how they need this delivered.

This does however create volatility in the applications infrastructure, and I’d assert that to be successful you’d better deploy in a virtualized environment to handle the peek workloads without over provisioning or limiting their potential.

So why do I now see myself as the idiot? Because I glossed over the storage aspects by waving a couple of glib acronyms (NAS or SAN), yet didn’t understand that the majority of alternatives would be like creating the world’s fastest boat, where the anchor’s always deployed.

Now don’t get me wrong, I started my professional career as a backup admin in Fleet Street London for a chartered accountants running up and down stairs with arms covered in reel tapes, so I’m no stranger to this world.

Guess what systems I started on?

However, it’s easy to be mono focused and to not take into account the holistic challenges which I fell prey to.

The last few months have been a cathartic experience. I’ve been immersed in NetApp’s data protection offerings and their platform innovations. What’s washed over me is the foresight of the architecture to handle the flexible workloads that the emerged application demands will place.

What excites me is not only how NetApp’s addressed storage flexibility inside the systems (Snapshots, FlexClones, thin provisioning and even hetero consistency groups for those pesky portal composite apps using WSRP), but what really gets me going What’s got me cycling is the ONTAP architecture. ONTAP is so flexible, and yet connected that you could potentially re-factor a primary to a secondary, a primary to a VTL, a Vault, a mirror and so on.

Why is this great? ROA (return on assets), I just love the tangibility of buying something for a specific purpose, yet having the faith that if I want to re-use it, it’s flexible enough to morph to my changing needs.

The subtle marriage of software and hardware yet abstracting to a flexible model allows your assets to be as dynamic as your requirements. I’m sure the adages, ‘do more with less’ and ‘evolutions win over revolutions’ resonate well to ROA.

At this point I’d refer to some obvious candidates as examples: your iPod or iPhone as its features morph and extend, and my personal favorite, the Sonos music systems. OMG, I can’t tell you how excited I get when a new software version is automatically downloaded!

http://www.sonos.com/

If you peruse the successful innovations in today’s technology consumer market, there’s clearly a bias towards data and hardware, somewhat abstracted, architected for change and forming a truly symbiotic relationship.

There’s for sure some road still to travel, but I can’t help but feel NetApp’s closer to the end than the start. Kostadis, my ever passionate and vocal associate, has called this a ‘fantastical journey’, but one I’m sure we’re all embarked on, and one that’s easier if we’re cognoscente of the needs and demands of all the passengers.

I’m very excited to be part of this emergence. I don’t believe there’s an alternative anywhere close to such comprehension of bridging the storage and applications divide and with what’s in the hopper it’s only going to get better.

So to this inaugural blog, I confess and therefore absolve myself of my blinkered optics and cast myself towards the shameless abandon of the new order