Infrastructure 2.0 is, at its core, about evolving to a new level of interconnectedness, one in which the underlying infrastructure becomes as flexible and adaptable as the applications and virtualization infrastructure it is responsible for managing and delivering. In order to be connected, however, you need a way in which disparate infrastructure components can communicate, either directly or via a third party (coordination | management | orchestration) server.

That communication is almost certainly going to take (and in many cases has already taken) the form of service-enabled control planes. These "services" are necessary in order to provide the foundation through which previously static infrastructure becomes a dynamic, integrated component in the great infrastructure mashup that will drive the success of the next generation data center.

Just how important are service-enabled control planes and interconnectedness? Consider the abstraction and automation stages of maturation as described by James Urquhart's in a recent post describing a Cloud Maturity Model. James' model is tied closely to the cloud, but it is just as applicable to dynamic environments in general, whether they are based on the cloud or simply virtualized.

Without service-enabled control planes dynamic environments cannot mature past the consolidation stage. Enabling the ability to decouple (abstract) infrastructure from physical implementations to achieve a dynamic infrastructure requires these aforementioned control planes or interfaces. That these abstractions should be (but are not currently) based on a common standard will inhibit the maturation of the cloud into the utility and market stages, but provides the means by which dynamic environments can mature into the automation stage.

Decoupling can enable greater levels of integration between the disparate layers of infrastructure: network, application, the endpoint, and IP address management, necessary to achieve interconnectedness.

The abstraction required already exists, but today they are product-vendor specific: Cisco has SONA for network infrastructure, F5 has iControl for application delivery infrastructure, and InfoBlox supports IF-MAP for IP address management. What doesn't exist is the collaboration and orchestration capabilities necessary to achieve automation in an efficient, reusable way; it's missing a BPEL for network infrastructure, if you will: a way to neatly exploit the automation capabilities available to manage existing service-enabled infrastructure. We're missing the glue that holds the pieces together, that loosely couples all the moving parts.

The ability of network and application delivery infrastructure to enable dynamic environments to mature past the pilot and early adoption stages exists today; it's just rarely been exploited until the recent explosion of cloud computing and virtualization initiatives. Today we're essentially building infrastructure mashups (informal, lacks standards) instead of composite applications (formal, standards-based). It works, but the result is neither portable nor easily reused for other applications.

The cloud, both private and public, as well as dynamic environments in general will leverage these service-enabled control planes to move past the automation stages and into the utility stage. It could be argued, in fact, that providers such as Amazon, BlueLock, and Joyent have already reached this stage by taking advantage of existing capabilities, albeit not easily.

But we won't see inter-cloud portability and integration until we have a more viable, standards-based mechanism for orchestrating and integrating dynamic infrastructure.

IMAGE COURTESTY GREG NESS/INFOBLOX

Related articles by Zemanta

• The death of SOA has been greatly exaggerated
• Infrastructure 2.0: The Diseconomy of Scale Virus
• Cloud Computing need not wait for Infrastructure 2.0
• Cloud Computing: Achieving full interconnectedness
• The Great Infrastructure Initiative Canard
• Rethinking out loud about infrastructure