The premise that if you don’t have an infrastructure comprised solely of Infrastructure 2.0 components then you cannot realize an automated, on-demand data center is, in fact, wrong. While the capabilities of modern hardware that come with Infrastructure 2.0 such as a standards-based API able to be leveraged by automation systems certainly makes the task all the more simple, it is not the only way that components can be automated. In fact, “legacy” infrastructure has been automated for years using other mechanisms that can certainly be incorporated into the dynamic data center model.

When it’s time to upgrade or purchase new solutions, those components enabled with standards-based APIs should certainly be considered before those without, but there’s no reason that a hybrid data center replete with both legacy and dynamic infrastructure components cannot be automated in such a way as to form the basis for a “private cloud.” The thought that you must have a homogeneous infrastructure is not only unrealistic it’s also indicative of a too-narrow focus on the individual components rather than systems – and processes - that make up data center operations.

In “The Case Against Private Clouds” Bernard Golden blames the inability to automate legacy infrastructure for a yet-to-occur failure in private cloud implementation:

The key to automating the bottom half of the chart -- the infrastructure portion -- is to use equipment that can be configured remotely with automated measures. In other words, the equipment must be capable of exposing an API that an automated configuration system can interact with. This kind of functionality is the hallmark of up-to-date equipment. Unfortunately, most

data centers are full of equipment that does not have this functionality; instead they have a mishmosh of equipment of various vintages, much of which requires manual configuration. In other words, automating much of the existing infrastructure is a non-starter.

The claim that legacy infrastructure is going to require manual configuration and therefore automating most of the infrastructure is a “non-starter” is the problem here. In other words, if you have “legacy” infrastructure in your data center you can’t build a private cloud because there’s no way to automate its configuration and management.

Identity Management Systems (IDMS) focusing on provisioning and process management have long ago solved this particular problem as has a

plethora of automation and scripting-focused vendors that provide automation technology for network and systems management tasks. CMDB (Configuration Management Database) technology, too, has some capabilities around automating the configuration of network-focused devices that could easily be extended to include a wider variety of network and application network infrastructure.

Any network or systems’ administrator worth their salt can whip up a script (PowerShell, bash, korn, whatever) that can automatically SSH into a remote network device or system and launch another script to perform X or Y and Z. This is not rocket science, this isn’t even very hard. We’ve been doing this for as long as we’ve had networked systems that needed management.

What is hard, and what’s going to make “private” clouds difficult to implement is orchestration and management. That’s hard, and largely immature at this stage because you’re automating processes (i.e.  orchestration) not systems.

That’s really what’s key to a cloud implementation, not the automation of individual components in the network and application infrastructure.

AUTOMATION IS EASY. ORCHESTRATION IS WHAT’S HARD.

Anyone can automate a task on an individual data center component. But automating a series of tasks, i.e. a process, is much more difficult because it not only requires an understanding of the process but is also essentially “integration”. And integration of systems, whether on the software side of the data center or the network and application network side of the data center, is painful. It should be a four letter word – a curse – and though it isn’t considered one it’s often vocalized with the same tone and intention as one invoking some form of ancient curse.

But I digress. The point is not that integration is hard – everyone knows that – but that it’s the integration and collaboration of components that comprise the automation of processes, i.e. orchestration, that makes building a “private cloud” difficult.

Management and orchestration solutions that can easily integrate both legacy infrastructure and Infrastructure 2.0 via standards-based APIs and traditional “hacks” requiring secure remote access and remote execution of scripts is the “killer app” for “private cloud computing”.

It’s already been done in the identity management space (IDMS). It’s already been done in the business and application space (BPM). It should be no surprise that it will, eventually, be “done” in the infrastructure world. Folks watching the infrastructure and cloud computing space just have to stop looking at two layers of the stack and broaden their view a bit to realize that the answer isn’t going to be found solely within the confines of infrastructure. Like the model and applications it hosts, it’s going to be found in a collaborative effort involving components, systems, and people.

Related blogs & articles:

• Infrastructure 2.0: The Diseconomy of Scale Virus
• We’re Sorry. The IPv4 Address You Are Trying to Reach Has Been Disconnected
• The days of IP-based management are numbered
• Infrastructure 2.0: As a matter of fact that isn't what it means
• Cloud Computing: Will data integration be its Achilles Heel?
• Infrastructure 2.0 and the New Data Center Culture

Categories: Cloud Computing , Development and General , iControl , Monitoring/Management 

• Terracotta and Eucalyptus to Drive Scaling in Private Cloud Environments
• A Practical Framework for Successful Private Cloud Computing Design