One of the most often repeated themes at this year's virtual conference VMworld was that of automation. Everybody claimed they had it, closer investigation suggested otherwise.

Now why is infrastructure automation or the dynamic manipulation of physical resources important? Although software automation usually captures attention, remember that there is a whole set of physical datacentre infrastructure layers that has to deal with as well. When a new server (physical or virtual) is created, much of this infrastructure also has to be provisioned to support it. The IT industry has evolved into a morass of technologies and resulting complexity; the way applications (and datacentres) are built today is not greenfield anymore. Datacentres are stove-piped, hand-crafted, tightly-controlled and reasonably delicate and automating IT is the only way out. Automation has its advantages: lower operating expenditure, greater capital efficiency, and greater energy efficiency. It also poses challenges typical of distrust, organisational upheaval, financial and business changes.

The art or science of introducing automation into an existing organisation is to reap the benefits, and mitigate the challenges. As infrastructure automation, also known as Infrastructure 2.0, moves forward, it appears to be bifurcating along two different philosophies. There are two fundamental approaches to automation in-place and virtualised infrastructure automation. Each approach is valid, but appropriate for differing types of uses:

• In-place infrastructure automation: (distinct from run-book automation) It seeks to automate existing physical assets,   derive its value from masking the operational by orchestrating in-place resources. That is, it takes the physical topology   (servers, I/O, ports, addressing, cabling, switches, VMs etc.) and orchestrates things to optimise a variable such as a   service level agreement, energy consumption, etc.

• Virtualised Infrastructure automation: It seeks to first virtualise the infrastructure and then automate their creation, configuration and retirement. That is, I/O is virtualised, networking is frequently converged, and network switches, load balancers, etc. are virtualised as well.

Each of these two approaches has its pros and cons. I'll try to elucidate a few of the high points in each of the case:

In-Place Infrastructure Automation:
Examples: Cassatt (now part of CA), Scalent

• Automates existing assets: Usually, there is no need to acquire a new network or server hardware (although not all hardware   will be compatible with the automation software). Thus in-place assets are generally re-purposed more efficiently than they would be in a manually-controlled scenario. Clearly this is one of the most significant value propositions for this approach - automate what you already own.

• Masking underlying complexity: While in-place automation simplifies operation and streamlines efficiency, the datacentre's underlying complexity is still there: redundant assets to maintain, suboptimal cabling, outmoded multi-layer switching and physical limitations.

• Alters security hierarchy: Since assets such as switches will now be controlled by machine, this architecture will necessarily modify the security hierarchy, single-point-of-failure risks, etc. All assets fall under the command of the automation software controller.

• Broad, but not complete, flexibility: Because this approach manipulates existing physical assets, certain physical   limitations must remain in the datacentre. For example, physical server NICs and HBAs are what they are, and can't be   altered. Or, for example, certain network topologies might not be able to be perfectly replicated if physical topologies don't closely match. Nonetheless, if properly architected, some of these limitations can be mitigated.

• Use with OS virtualisation: This approach usually takes control of the virtual machine (VM) management software, or directly controls the VMs itself. So, for example, you'd allow the automation manager to manipulate VMs, rather than vSphere.

• Installation: Usually more complex to set up or maintain because all assets, versions, and physical topography necessarily need to be discovered and catalogued. But once running, the system will essentially maintain its own configuration management database (CMDB).

Virtualised Infrastructure Automation:
Examples: Cisco UCS, Egenera, Xsigo

• Reduction or elimination of IT components: The good news here is that through virtualising infrastructure, redundant components can be completely eliminated. For example, only a single I/O card with a single cable is needed per server because they can be easily virtualised or presented to the CPU. And, a single virtualised switching node can present itself as any number of switches and load balancers for both storage and network data.

• Complete flexibility in configuration: By abstracting infrastructure assets, they can be built or retired or repurposed on-demand. e.g. networking and  load balancing can be created at will with essentially arbitrary topologies.

• Consistent or complementary to OS Virtualisation models: If you think about it, virtualised infrastructure control is pretty complementary to OS virtualisation. While OS virtualisation logically defines servers, infrastructure virtualisation similarly defines plumbing and allows I/O and network consolidation, as well as movement or duplication of physical server properties to other locations.

• New networking model: With a completely virtualised or converged network, network (and its security) management changes. Organisations may have to re-think how (and who) creates and repurposes network assets. (Somewhat similar to coping with  "VM Sprawl" in the software virtualisation domain)

• Use with OS virtualisation: This approach is usually 'agnostic' to the software payload of the physical server, and is therefore neutral/indifferent to the VMM in place. Frequently the two can be coordinated, however.

• Installation: Usually relatively simple. Few components per server, few cables, especially in a greenfield deployment. Installation of software/BIOS on physical servers is probably not what you're used to, though.

Ideal use of these two approaches differs too. Obviously, in-place infrastructure automation is probably best-suited for an existing set of complex datacentre assets. As you'd expect , a number of existing lab automation products out there target this market. On the other hand, virtual infrastructure automation can certainly be deployed on existing assets, but its real value is for new installations where minimal hardware or cabling or networking can be designed-in from the ground up. Most of these products are designed for production datacentres, as well as cloud or utility infrastructures.

My overall sense of the market is that adoption of in-place automation will be driven primarily by progressive IT staffs that want a taste of automation and service-level management. Virtualised Infrastructure Automation adoption, on the other hand, will tend to ride the technology wave driven both by networking vendors and OS virtualisation vendors.