Hoff’s Metastructure and the Intercloud

The intercloud is the most interesting development in cloud computing (and perhaps the data center) since the migration of hypervisors into production environments.  It’s a model for driving incredible scale and efficiency from IT systems and hardware, and it can be architected for both public and private clouds.

The intercloud turns a global network of clouds (or virtualized data centers) into a cohesive, elastic and flexible mesh of on-demand processing power.  It shifts the balance of IT power from centralized to distributed architectures by allowing enterprises a wider range of on demand IT service delivery choices. 

For example, services could be delivered from one location over another because of short term differentials in power and/or labor costs.  It would also give enterprises more viable options for dealing with localized tax or regulatory changes.

The intercloud doesn’t yet exist, however---It has at least one missing piece: the automation of manual tasks at the core of the network.  The intercloud requires automation of network services, the arcane collection of manual processes required today to keep networks and applications available.

Until there is network service automation, all intercloud bets are off.  This gap between the delivery of cloud services today (via higher VM density and centralization) and the arrival of the distributed intercloud is the next period of stability before the next IT disruption.   Because of the low margin/high service (and high CapEx investments) involved in building scalable, elastic cloud services, the size of this intermediate cloud period will make all the difference for service providers and startups.

The Intercloud’s Net Effect

The intercloud will shift IT service advantages from centralized to decentralized models.  Decentralized architectures will have more choices when it comes to cost factors of production as well as performance tradeoffs.

As cloud providers race to become more flexible, more scalable and more profitable by building more density/scale into more centralized facilities they risk “de-positioning” themselves for the higher impact intercloud.  While many of these centralized architecture facilities are being built in low cost areas (and likely based on log term contracts and guarantees) they will have fewer choices over the long term as conditions fluctuate.

Fewer choices will eventually mean higher costs.

The tradeoffs between centralized and decentralized clouds might seem like a rounding error to some, but in a slim margin, service intensive business even incremental (and ongoing) short term advantages in a line item like electricity expense could prove to be a decisive game changer.  The intercloud, for example, could be designed to chase (off peak) low cost electrical power around the world.  It could also be less vulnerable to short term adverse changes in regulatory or tax policies or localized network issues.

Those who hold onto their distributed data center architecture and fully leverage infrastructure 2.0 would gain the upper hand with the intercloud by simply having more choices over time.

The intercloud puts the network at the core of the cloud.  

It will shift enterprise IT architectures from today’s preoccupations with tactical VM density payoffs (confined flexibility/motion within VLANs) to strategic VMotion payoffs (movement between clouds to exploit lowest cost point of delivery).  VMotion would escape the confines of the VLAN and shift the advantage from the centralized to the distributed.

Two interesting blogs from cloud guru Chris Hoff point to this gap and set up some interesting potential speculation around the intercloud’s potential as a game changer.

Intercloud: A Missing Piece

Hoff calls out the metastructure, or the naming and network services infrastructure (IPAM, DNS, etc.) as a part of a compelling three tiered cloud anatomy.  Today most enterprises manage this infrastructure manually.  Yes, that means mouse clicks in one layer corresponding with manual reconfiguration, check lists and committees in another.  The motor boat is towing the row boat.

This is the weak link that causes inconsistencies, insecure task delegation and no auditing or reporting options today.  The metastructure is dependent on high risk, specialized manual labor, policies and ad hoc committees.  The metastructure needs to be automated for the intercloud to function properly and enable enterprise intercloud adoption.

Today’s outdated processes won’t scale as systems are automated and move between clouds (via a slow, antiquated infrastructure layer requiring constant human intervention) in pursuit of ever lower IT operating costs.  Benefits could be offset by increasing network labor costs and increasing unplanned outages.  Those management costs are already on the increase as networks grow, as mentioned in a 2008 Computerworld survey.

Hoff’s Cloudanatomy definition sets the stage for the intercloud by defining what is missing:

Metastructure* is the protocols and mechanisms that provide the interface between the infrastructure layer and the applications and information above it.

 - Chris Hoff, Cloudanatomy, June 19, 2009

Cloud expert and visionary Reuven Cohen blogged about Chris’ effort to “condense” the components of the cloud into three key layers and the “extensible bridge”:

The idea of a Metastructure provides an extensible bridge between the legacy world of hardware based deployments and the new world of virtualized / unified computing. (You can see why Hoff is working at Cisco, he get's the core concepts of unified computing -- one API to rule them all)

- Reuven Cohen, Life in the Cloud, June 20, 2009

If Hoff is right, the core of the network will become the core of the cloud.  It will be the dynamic bridge between networks applications and endpoints being called Infrastructure 2.0. Today that bridge needs plenty of work.  As mentioned, most enterprises are still relying upon 80s era manual labor for their network. 

Now read Hoff’s blog from last fall on Infrastructure 2.0 and DNS:

And that's where this gets interesting to me because in order to truly automate virtualized and cloud computing environments, this means one of three things as it relates to where core/critical infrastructure services live:

1. They  will continue to be separate as stand-alone applications/appliances or bundled atop an OS
2. They become absorbed by "the (traditional) network" and extend into the virtualization layer
3. They get delivered as part of the virtualization layer

- Chris Hoff, Rational Survivability, Infrastructure 2.0…  December 8, 2008

Let me add one more sound bite to the mix, from an email I received as a result of the recent Future in Review panel on Infrastructure 2.0.  It puts the intercloud model within a proper context.  (I don’t have permission from the author to credit him as he wants to avoid any notoriety; the statement stands on its own):

"I would suggest a model of the intercloud as a heterogeneous distributed system with multiple clocks, locally incompatible address spaces, locally diverse contexts, but some concept of transient global coherence (e.g. reachability and security given mobility)."

- Suggestion from confidential source

Hoff’s observations will ultimately be addressed by the networking industry.  There is too much upside for those who enable the intercloud and unleash VMotion to drive unprecedented energy / cost savings with unprecedented elasticity.  It is the future of IT services delivery once network services are automated and a dynamic, extensible bridge exists between mobile, automated systems and an automated network infrastructure.