Cloud Attributes Apply Across the Stack

My “aha” moment here at EMC came during my first week when I was asked to describe the generic attributes of cloud infrastructure. Here I was, in an organization that’s made billions on storage, and I was about to talk about cloud attributes solely from a compute perspective.Was I missing something?

I then realized that I’d always related to storage as a “big, fat, dumb disk in the sky”, and assumed that it was merely subservient to the compute stack.

Well, not exactly.

My re-think was that attributes of Compute, Storage, and yes, Network, all had to be reconsidered in the context of a holistic cloud-based infrastructure.

Cloud Attributes:

Most will agree that the following attributes describe the operational profile of a generic cloud: (HT to IDC)

• Shared, standard service. Built for a market (public), not a single customer
• Solution packaged. A “turnkey” offering, integrates required resources
• Self-service. Admin, provisioning; may require some “onboarding” support
• Elastic scaling. Dynamic and fine grained
• Usage-based pricing. Supported by service metering
• Accessible via the Internet. Ubiquitous (authorized) network access
• Standard UI technologies. Browsers, RIA clients, and underlying technologies
• Published service interface/API. Web services and other common Internet APIs

 I’ll add a few functional attributes as well:

• Consolidation: ability to make optimal use of lower-level resources
• Automation: ability to self-configure to provide the required service
• Self-healing/failover: ability to correct for failure with little or no service interruption
• Multi-tenancy, Multi-tiered-SLA: ability of resources to securely house individual services & service-levels across a shared infrastructure
• Global availability: ability to provide a shared service across multiple availability zones

Attributes in a Storage Context

The first assumption most make is that these traits apply exclusively to the compute layer (physical servers, VMs and the like). But pause and consider the storage (and network) facilities need to embody most, too.

But consider this: In a virtualized world, servers are files, and files are just data.

So, when we talk about cloud-related scaling, service migration, server fail-over etc., we must also implicitly speak of managing data dynamics, data replication and data mobility. When we talk about automation, self-service provisioning and service elasticity, we’re implicitly talking about dynamic data/storage provisioning and expansion. When speaking of multi-tenancy and tiered SLAs, we’re also speaking of shared storage facilities performing identical functions in lock-step with the compute facilities.

From a broader perspective , begin to consider implications of global availability and hyper-scale. The terabytes of data that embody virtual servers and their data might need to be migrated to (or duplicated in) multiple hemispheres- not a trivial task from an integrity and latency perspective. We can know (or hope) that the physical servers will be there… but it’s the bits that still have to travel.

The next idea these observations triggered was the need to keep compute, network and storage stacks in lock-step when rolling-out cloud services. The answer (not surprisingly) is converged infrastructure... An approach where the desired cloud attributes are assigned to the 3 stacks simultaneously. More about that in a future Blog.

But I'm now encouraging everyone to view storage of bits in a completely different light – one where the functional and operational attributes of storage must be architected to embrace the core attributes of cloud computing. For without the bits, there can be no servers, no data, and no services. More about that in a future post as well :)

IO Virtualization: The “Hypervisor” for Your Infrastructure

An Explosive Technology, But Don't Treat as a Standalone Product
  
More than ever in 2010, IO Virtualization (IOV) has been showing-up in products, written about, spoken about. Because I’ve had a few years’ experience with this technology, I wanted to give a very brief explanation of the concept, and focus more on why it will be increasingly important.
 
In particular, I want to draw an analogy where you should view IOV as a critical enabling feature of future IT Management…  but not as a stand-alone product. Why? It's similar in concept to how the hypervisor is an enabler (but usually not used as a stand-alone product) of data center management services. 

This blog is related to my 2009 installment on Fabric as an IT Enabler.

What is IOV?

Today's Physical Infrastructure

IO Virtualization is an approach whereby physical IO components such as Network Interface Cards (NICs) Host Bus Adaptors (HBAs) and Keyboard/video/Mouse ports (KVM) are reproduced logically rather than physically.  In other words, a physical IO port (Ethernet, Infiniband, PCI, etc.) might logically represent itself to the O/S as different configurations.

Clearly this is convenient because it (a) eliminates multiple costly IO devices that also consume power and installation time. But it’s also convenient because IO – and it’s associated addressing such as IPs, MACs, Worldwide Names, etc. – can be instantly configured with a mouse.


The other consequence of IOV is that a single physical port means a single physical cable.  In essence, a server’s logical IO is consolidated down to a single (physical) converged network which carries data, storage and KVM traffic.   So this means that no matter how many logical IO devices you configure for a server, there is still only a single cable out the back.  So IOV yields the ideal “wire-once” server environment that’s still infinitely re-configurable.

The overall value of IOV becomes clear fast:  Fewer physical IO devices to buy, fewer cables to install, zero re-cabling, fewer physical ports to buy, and instantly re-configurable IO. 

Differing Implementation Approaches

Infrastructure With
IO Virtualization

In brief, there are a few differing approaches to IO virtualization:

• Existing on-board Ethernet with new IO drivers: (e.g. Egenera)
• Converged Networking Adapters (e.g. Qlogic, Emulex)
• Appliances + high-throughput IO devices (e.g. Xsigo)
• Existing physical IO but with address hardware-based mapping/virtualization (e.g. HP VirtualConnect)

Putting IOV in Perspective

You should think of IOV using the following analogy: The way in which the hypervisor abstracts software in the application domain, IOV abstracts IO and networking in the infrastructure domain.  (However, to be clear, IOV is not a software layer as-is the hypervisor)

This analogy leads to a few more observations:

1. Where the hypervisor added software portability in the software domain IOV will do the same for the infrastructure domain.  Higher-order services like HA and consolidation were made possibly by the hypervisor.  Similarly, HA, DR and migration can be accomplished with IOV. And what’s more, a hypervisor is not required for IOV, so you can use IOV with native applications too.
2. The hypervisor used to be the focus, but now it’s merely an enabling feature embedded within higher-level IT management products. Those products leverage the hypervisor to perform tasks such as migration, fail-over and consolidation. You should view IOV similarly: it is an enabling feature that will allow for analogous IO consolidation, migration and fail-over.
3. Where hypervisor implementations and performance used to be hotly-debated, nobody really cares anymore.  Today the real *value* is not in the hypervisor, but in the management tools surrounding it.  Similarly, IOV should be judged less on how it is implemented, and more on the management tools and automation which manage it.

Forrester analyst Galen Schreck made a similar observation recently:

….Aside from benefits like reducing cabling and switch ports, I think the most interesting aspect of virtualized IO is the ability of a physical server's personality to be moved to any other server in the data center. In addition to the underlying network technology, the thing that makes this possible is integrated management of the server and data center fabric. In most cases, this won't be a stand-alone product that you acquire (though you can build your own solution from InfiniBand and PCI Express products on the market). This capability will most likely be an integrated part of whatever server and network environments you select, but now is the time to begin planning how you'll tie it in with the rest of your system management environment.

IO Virtualization in the IT Management Landscape

How might IO virtualization be used as part of the IT ecosystem in an integrated manner?

In much the same way that the hypervisor has since been embedded in tools like VMware’s vCenter, IOV can (and has been) embedded with higher-level management tools.

Taking an example I’m rather familiar with, Egenera’s PAN Manager Software surrounds IOV technology with facilities such as integrated with converged fabric networking, server boot control and storage connectivity.  When used alongside these and other services, IOV enables:

• Server High Availability– In the case of hardware failure, a server’s infrastructure state (IO addressing, storage naming, network topology and workload) can be re-instantiated on another bare-metal server. This provides a ‘universal’ style of failover that doesn’t require clustering software. And what’s more, the failed-over server workload could be a native OS, or a VM host.  IOV is agnostic to the workload!
• Disaster Recovery – expanding on the example above, if an entire domain of servers fails, the entire group of server IO states, networking states, etc. can be recovered onto another domain (assuming shared/replicated storage).  This approach to DR is elegant because it fails-over not just workloads but  the entire logical server/environment configuration as well.
• Scaling-Out – where a series of server profiles can be instantly replicated into an instant cluster. Workloads, NICs, HBAs, networking addressing and storage connections (complete with fabric-based load balancing) can all be cloned… starting with the IO and networking profiles, made possible through IOV.

In future blogs I’ll dive more deeply into how software-based IOV operates as part of the IT management ecosystem, and why it is a popular approach because of its cross-platform compatibility in a heterogeneous data center.

Converged Infrastructure, Part 3

Converged Infrastructure: What it Is, and What it Isn't

In my two earlier posts, I first took a stab at an overview of converged infrastructure and how it will change IT management, and in the second installment, I looked a bit closer at converged infrastructure's cost advantages. But one thing that I sense I neglected was to define what's meant by converged infrastructure (BTW, Cisco terms it Unified Computing). Even more important, I also feel the need to highlight what converged infrastructure is not. Plus, there are vendor instances where The Emperor Has No Clothing -- e.g. where some marketers have claimed that they suddenly have converged infrastructure where the fact remains that they are vending the same old products.

Why splitting hairs in defining terms? Because true converged infrastructure / unified computing has architectural, operational, and capital cost advantages over traditional IT approaches. (AKA Don't buy the used car just because the paint is nice)


Defining terms - in the public domain
Obviously, it can't hurt to see how the vendors self-describe the offerings... here goes:
 
Cisco's Definition (via webopedia)

"...simplifies traditional architectures and dramatically reduce the number of devices that must be purchased, cabled, configured, powered, cooled, and secured in the data center.  The Cisco Unified Computing System is a next-generation data center platform that unites compute, network, storage access, and virtualization into a cohesive system..."

Egenera's Definition

"A technology where CPU allocation, data I/O, storage I/O, network configurations, and storage connections are all logically defined and configured in software. This approach allows IT operators to rapidly re-purpose CPUs without having to physically reconfigure each of the I/O components and associated network by hand—and without needing a hypervisor."

HP's Definition

"HP Converged Infrastructure is built on a next-generation IT architecture – based on standards – that combines virtualized compute, storage and networks with facilities into a single shared-services environment optimized for any workload."

Defining terms - by using attributes
Empirically, converged infrastructure needs to have two main attributes (to live up to its name): It should reduce the quantity and complexity of physical IT infrastructure, and it should reduce the quantity and complexity of IT operations management tools. So let's be specific:

Ability to reduce quantity and complexity of physical infrastructure:

• virtualize I/O, reducing physical I/O components (e.g. eliminate NICs and HBAs)
• leverage converged networking, reducing physical cabling and eliminating re-cabling
• reduce overall quantity of servers, (e.g. ability to use free pools of servers to re-purpose for scaling, failure, disaster recovery, etc.)

Ability to reduce quantity and complexity of operations/management tools:

• be agnostic with respect to the software payload (e.g. O/S independent)
• fewer point-products, less paging between tool windows (BTW, this is possible because so much of the infrastructure become virtual and therefore more easily logically manipulated)
• reduce/eliminate the silos of visualizing & managing physical vs virtual servers, physical networks vs virtual networks
• simplified higher-level services, such as providing fail-over, scaling-out, replication, disaster recovery, etc.

To sum-up so far, if you're shopping for this stuff, you need to
a) Look for the ability to virtualize infrastructure as well as software
b) Look for fewer point products and less windowing
c) Look for more services (e.g. HA, DR) baked-into the product.

Beware.... when the Emperor Has No Clothes...
In closing, I'll also share my pet peeve: When vendors whitewash their products to fit the latest trend. I'll not name-names, but beware of the following stuff labeled "converged infrastructure":

• If the vendor says "Heterogeneous Automation" - that's different. For example, it could easily be scripted run-book automation.  This doesn't reduce physical complexity in the least.
• If the vendor says "Product Bundle, single SKU" - Same as above. "Shrink wrapped" does not equal "converged"
• If the vendor says "Pre-Integrated" - This may simplify installation, but does not guarantee physical simplicity nor operational simplicity

 Thanks for reading the series so far.  I'm pondering a fourth-and-final installment on where this whole virtualization and converged infrastructure thing is taking us - a look at possible future directions.
 

Converged Infrastructure Part 2.

Part 2. Converged Infrastructure’s Cost Advantages

In my first installment about converged Infrastructure, I  gave an outline of what it is, and how it will change the way in which IT infrastructure is managed.

In this installment, I’ll go a bit deeper and explain the source of capital and operational improvements converged Infrastructure offers – and why it’s such a compelling opportunity to pursue.

But first, the most important distinction to make between converged infrastructure and “the old way of doing business” is that management – as well as the technology – is also converged.  Consider how many point-products you currently use for infrastructure management (i.e. other than managing your software stack). 

This diagram at right  has resonated with customers and analysts alike. It highlights, albeit in a stylized fashion, just how many point-products an average-sized IT department is using.  This results in clear impact in

• Operational complexity – coordinating tool use, procedures, interdependencies and fault-tracking
• Operational cost – the raw expense it costs to acquire and then annually maintain them
• Capital cost – if you count all of the separate hardware components they’re trying to manage

That last bullet, the thing about hardware components, is also something to drill down into.  Because every physical infrastructure component in the “old” way of doing things has a cost.  And I mean I/O components like NICs and HBAs, not to mention switches, load balancers and cables.

What might be possible if you could virtualize all of the physical infrastructure components, and then have a single tool to manipulate them logically?

Well, then you’d be able to throw-out roughly 80% of the physical components (and associated costs) and reduce the operational complexity roughly the same amount.

In the same way that the software domain has been virtualized by the hypervisor, the infrastructure world can be virtualized with I/O virtualization and converged networking. And, once the I/O and network are now virtualized, they can be composed/recomposed on demand.  This eliminates a large number of components needed for infrastructure provisioning, scaling, and even failover/clustering (more on this later).  And, if you can now logically re-define server and infrastructure profiles, you can also create simplified Disaster recovery tools too.

In all, we can go from roughly a dozen point-products down to just 2-3 (see diagram above).  Now: What’s the impact on costs?

On the capital cost side, since I/O is consolidated, it literally means fewer NICs and elimination of most HBAs since they can be virtualized too.  Consolidating I/O also implies converged transport, meaning fewer cables (typically only 1 per server, 2 if teamed/redundant). And a converged transport also allows for fewer switches needed on the network.  Also remember that with few moving (physical) parts, you also have to purchase few software tools and licenses. See diagram below.

On the operational cost side, there are the benefits of simpler management, less on-the-floor maintenance, and even less power consumption. With fewer physical components and a more virtual infrastructure, entire server configurations can be created more simply, often with only a single management tool. That means creating and assigning NICs, HBAs, ports, addresses and world-wide names. It means creating segregated VLAN networks, creating and assigning data and storage switches. And it means automatically creating and assigning boot LUNs. The server configuration is just what you’re used to – except it’s defined in software. And all from a single unified management console.   The result: Buying, integrating and maintaining less software.

Referencing the diagram at right, here's what this looks like on a physical level is fewer components: Costly NIC and HBA cards are virtualized, with their physical transport now consolidated over Ethernet ports, and switches/cables now replaced by a logically-configured switch.

Ever wonder why converged infrastructure is developing such a following? It’s because physical simplicity breeds operational efficiency. And that means much less sustained cost and effort. And an easier time at your job.

Next installment: What Converged Infrastructure is not.

Converged Infrastructure. Part 1

Since joining Egenera, I've been championing what's now being termed Converged Infrastructure (aka unified computing). It's an exciting and important part of IT management, demonstrated by the fact that all major vendors are offering some form of the technology. But it sometimes takes a while for folks (my analyst friends included) to get their heads around understanding it.  So I'm going to take a stab at a multi-part Primer on the topic.
 
Part 1: What is Converged Infrastructure, and how it will change data center management

Converged Infrastructure and Unified Computing are both terms referring to technology where the complete server profile, including I/O (NICs, HBAs, KVM), networking (VLANs, IP load balancing, etc.), and storage connectivity (LUN mapping, switch control) are all abstracted and defined/configured in software. The result is a pooling of physical servers, network resources and storage resources that can be assigned on-demand.

This approach lets IT operators rapidly repurpose servers – or entire environments – without having to physically reconfigure I/O components by hand—and without the requirement of hypervisors.  It massively reduces the quantity and expense of the physical I/O and networking components as well as the time required to configure them. A converged infrastructure approach offers an elegant, simple-to-manage approach to data center infrastructure administration. 

From an architectural perspective, this approach may also be referred to as a compute fabric or Processing Area Network. Because the physical CPU state (i.e. naming and configuration of I/O, networking and storage naming) is completely abstracted away, the CPUs become stateless and therefore can be reassigned extremely easily creating a “fabric” of components, analogous to how SANs assign logical storage LUNs.  And, through I/O virtualization, both data and storage transports can also be converged, further simplifying the physical network infrastructure down to a single wire.

 The result is a “wire-once” set of pooled bare-metal CPUs and network resources that can be assigned on demand, defining their logical configurations and network connections instantly.

BTW, there is another nice resource -- a white paper commissioned by HP (!) executed by Michelle Bailey at IDC. In it she defines what is a converged system:

"The term converged system refers to a new set of enterprise products that package server, storage, and networking architectures together as a single unit and utilize built-in service-oriented management tools for the purpose of driving efficiencies in time to deployment and simplifying ongoing operations. Within a converged system, each of the compute, storage, and network devices are aware of each other and are tuned for higher performance than if constructed in a purely modular architecture. While a converged system may be constructed of modular components that can be swapped in and out as scaling requires, ultimately the entire system is integrated at either the hardware layer or the software layer.

Converged Infrastructure and Software Virtualization

A Converged Infrastructure is different from—but analogous to—hypervisor-based server virtualization.  Think of hypervisors as operating “above” the CPU, abstracting software (applications and O/S) from the CPU; think of a Converged Infrastructure as operating “below” the CPU, abstracting network and storage connections. However, note that converged Infrastructure doesn't operate via a software layer the way that a hypervisor does. And converged Infrastructure is possible whether or not server virtualization is present.

Converged Infrastructure and server virtualization can complement each other producing significant cost and operational benefits. For example, consider a physical host failure where the entire machine, network and storage configuration needs to be replicated on a new physical server. Using Converged Infrastructure, IT Ops can quickly replace the physical server using a spare “bare metal” server.  A new host can be created on the fly, all the way down to the same NIC, HBA and networking configurations of the original server.

A Converged Infrastructure can re-create a physical server (or virtual host) as well as its networking and storage configuration on any “cold” bare-metal server.  And in addition, it can re-create an entire environment of servers using bare-metal infrastructure at a different location as well. Thus it is particularly well-suited to provide both high-availability (HA) as well as Disaster Recovery (DR) in mixed physical/virtual environments – eliminating the need for complex clustering solutions. And in doing so, a single Converged Infrastructure system can replace numerous point-products for physical/virtual server management, network management, I/O management, configuration management, HA and DR.

Converged Infrastructure - Simplifying Management for “The other half” of the Data Center

In the manner that server virtualization has grown to become the dominant data center management approach for software, converged infrastructure is poised to become the dominant management approach for “the other 50%” of the data center – its infrastructure.

However adoption will take place gradually, for a few reasons:

• IT can only absorb so much at once. Most often, converged infrastructure is consumed after IT has come up the maturity curve after having cut their teeth on OS virtualization. Once that initiative is under way, IT then begins looking for other sources of cost take-out.... and the data center infrastructure is the logical next step.
• Converged infrastructure is still relatively new. While the market considers OS virtualization to be relatively mature, converging infrastructure is less-well understood.

But there is one universal approach that can overcome these hesitations -- money.  So, in my next installment, I'll do a deeper dive into the really fantastic economics and cost take-out opportunities of converging infrastructure...

If you think Converged Infrastructure & Fabrics are niche, guess again

A few weeks ago, I Tweeted about an analyst conversation where it was looking like the market for Fabric Computing / Unified Computing would be growing rapidly in the foreseeable future.

Another analyst friend of mine quickly commented back – sarcastically – that the market was sure to be in the billions of dollars.

I was feeling a little unsure about this market until a few weeks later when I was shown a technology report from Thomas Weisel Partners. Although the market definition for converged infrastructure (also known as Unified Computing) was still forming, TWP felt that sales of Converged Infrastructure solutions could rise as high as $15 billion by the end of 2014.  Billion with a “b”?  Right-on…

Then there is a report by Gartner Research on fabric-based computing… which estimated that by the end of 2012, roughly 30% of the world’s top 2000 companies would have some form of fabric-based computing architecture. (Under the heading of “fabric” falls Unified Computing as well as Converged Infrastructure).

So, why is the market (for fabric computing, converged infrastructure, unified computing) still considered so new in the market, yet forecast to be so booming in 2-4 years?

First of all, what we’re talking about here are systems like Cisco UCS, Egenera PAN Manager, HP VirtualConnect, IBM Open Fabric Manager, and a few others. At the heart of each system is technology (sometimes HW, sometimes SW, sometimes mixed) that virtualizes I/O and leverages converged networking.

And why are vendors all chasing this approach? For a number of reasons --

1. It’s incredibly complementary to virtualization: in the same way that the hypervisor changed how SW is abstracted, provisioned, managed and migrated, Converged Infrastructure changes how IO/networking/connectivity is assembled and managed. This gives vendors a valuable set of new offerings, and can tie management of infrastructure to management of VMs – yielding end-to-end abstraction of the entire data center. Roughly as much $ is spent managing infrastructure as it is managing software… to the TAM is huge here.
2. It changes how availability is delivered: By manipulating IO addressing, networking and connectivity, Converged Infrastructure Management can re-provision failed hardware – either in the form of physical servers, or indeed, entire environments. Thus, Converged Infrastructure has the potential to displace a big chunk of traditional clustering software… (nearly a $ billion, if you follow IDC’s estimates)
3. It changes how networks are physically wired and managed: Converged Infrastructure uses fewer IO components (either a single LOM or a single CNA), converged network protocols, fewer cables, and generally fewer switches. This yields a lower CapEx investment, and a commensurate lower OpEx to manage. The opportunity to sell alternative approaches to each of these technologies is immense.
4. Converged Infrastructure is highly complementary to shared storage: the pervasiveness of SAN storage is a major enabler of a more virtual/flexible data center. As physical/virtual servers move, migrate and scale, storage simply follows.  An increasing ratio of servers – especially blades – are being shipped with HBAs, indicating that SAN use is on the upswing.
   

As to evidence that this market is shaping-up, we need only look to the magnitude of investment that Cisco, Egenera, HP, IBM – and even Emulex and Qlogic – are pouring into this market. Methinks we’ll see the hockey-stick shortly.

Emergence of Fabric as an IT Management Enabler

Last week I attended Gartner's annual Data Center Conference in Las Vegas. Four days packed with presentations and networking (of the social kind). Lots of talk about cloud computing, IT operations, virtualization and more.

Surprisingly a number of sessions directly referenced compute Fabrics -- including "The Future of Server Platforms" (Andy Butler), "Blade Servers and Fabrics - Evolution or Revolution" (Jeff Hewitt), and "Integrated Infrastructure Strengths and Challenges" (Paquet, Dawson, Haight, Zaffros). All very substantive analyses of what fabrics _are_... but very little discussion of why they're _important_. In fact, Compute fabrics might just be the next big thing after OS virtualization.

Think of it this way: Fabric Computing is the componentization and abstraction of infrastructure (such as CPU, Memory, Network and Storage). These components can then be logically re-configured as-needed. This is very much analogous to how OS virtualization componentizes and abstracts OS and application software stacks.

However, the focus by most fabric-related vendors thus far is simply on the most fundamental level of fabric computing, which is simply virtualizing I/O and using a converged network. This is the same initial level of sophistication when the industry believed that OS visualization was only about the hypervisor. Rather, we need to take a longer view of fabric computing and think about higher-level value we create by manipulating the infrastructure similar to how we manipulate VMs. A number of heady thinkers supporting the concept of Infrastructure 2.0 are already beginning to crack some of these revolutionary issues.

Enter: Fabric as an Enabler

If we think of "fabric computing" as abstraction and orchestration of IT components, then there is a logical progression of what gets abstracted, and then, what services can be constructed via logically manipulating the pieces:

1. Virtualizing I/O and converging the transport

This is just the first step, not the destination. Virtualizing I/O means no more stateful NICs and HBAs on the server; rather, the I/O presents itself to the OS as any number of configurable devices/ports, and I/O + data flow over a single physical wire. Transport can be Ethernet, FCoE, Infiniband, or others. In this manner, the network connectivity state of the physical server can be simplified and changed nearly instantaneously.

2. Virtual networking

The next step is to define in software the converged network, its switching, and even network devices such as load balancers. The result is a "wire-once" physical network topology, but with an infinitely reconfigurable logical topology. This permits physically flatter networks. Provisioning of the network, VLANs, IP load balancing, etc. can all be simplified and accomplished via software as well.

3. Unified (or Converged) Computing

Now things get interesting: Now that we can manipulate the server's I/O state and its network connections, we can couple that with creating software-based profiles of complete server configurations -- literally defining the server, its I/O, networking, storage connections, and even what software boots on it. (Software being either a virtual host, or a traditional native OS). Having defined the entire server profile in software, we can even define the entire environment's profile.

Defining servers and environments in software allows us to provide (1) High Availability: With a hardware failure, we can simply re-provision a server configuration to another server in seconds -- whether or not that server was running a VM host, or a native OS. (2) Disaster Recovery: we can re-constitute an environment of server profiles, including all of their networking, ports, addresses, etc., even if that environment hosts VMs and native OS's.

 4. Unified Management

To achieve the ultimate in an agile IT environment, there's one remaining step: To orchestrate the management of infrastructure with the management of workloads. I think of this as an ideal Infrastructure-as-a-Service -- physical infrastructure that adapts to the needs of workloads, scaling up/out as conditions warrant, and providing workload-agnostic HA and DR.  From an IT agility perspective, we would now be able to abstract nearly all components of a modern data center, and logically combine them on-the-fly as business demands require.

Getting back to the Gartner conference, I now realize one very big missing link -- while Gartner has been promoting their Real-Time Infrastructure (RTI) model now for some time, they have yet to link it to the coming revolution that will be enabled by fabric computing.  Maybe we'll see some hint of this next year.

Infrastructure Virtualization: The Next Logical Step

2010 will be an interesting year for virtualization - but not from the perspective you're probably thinking. It will be the year of the virtual infrastructure, not of the virtual machine.
Yes, the O/S virtualization market is maturing as it transforms how servers and applications are managed. The major vendors all offer hypervisors and management to accomplish server consolidation, live migration, HA, lifecycle management, lab management, and more. And they're even offering higher-level tools for DR and cloud computing... Read more on VMBlog.com

Infrastructure 2.0 – A Virtual Analogy

Is OS virtualization an end in itself? Is it both necessary and sufficient for all things Cloud and IaaS? Is it the panacea IT Operations has been looking for? From where I see it, abstracting the OS is certainly a great start, but it’s actually only 50% of the goal.

To a degree, OS virtualization is the “shiny metal object” de jure in that it’s captivating everyone’s attention. It is of course very valuable, and is causing an important inflection point in datacenter operations and economics. But there is a less-visible, less sexy side to datacenter operations and economics that lies “below” the CPU in the stack...

Read more on the Infrastructure 2.0 Blog

Differing Target Uses for IT Automation Types

One of the most oft-repeated themes at this year's VMworld was that of "automation." Everybody claimed they had it, but on closer investigation it had any number of poorly-defined meanings.

A specific angle I want to address here is that of infrastructure automation; that is, the dynamic manipulation of physical resources (virtualized or not) such as I/O, networking, load balancing, and storage connections - Sometimes referred to as "Infrastructure 2.0". Why is this important? Although automation of software (such as provisioning & manipulation of VMs/applications) usually captures attention, remember that there is a whole set of physical datacenter infrastructure layers that IT Ops 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.

There are 2 fundamental approaches to automation I'll compare/contrast: Let's loosely call them "In-Place" Infrastructure Automation, and Virtualized Infrastructure Automation.

Confession: I am a champion of IT automation. The industry has evolved into a morass of technologies and resulting complexity; the way applications (and datacenters) are constructed today is not the way a greenfield thinker would do it. Datacenters are stove-piped, hand-crafted, tightly-controlled and reasonably delicate. Automating how IT operates is the only way out -- hence the excitement over cloud computing, utility infrastructure, and the "everything-as-a-Service" movement. These technology initiatives are clear indications that IT operations desires a way to "escape" having to manage its mess.

At a high-level, automation has major top-level advantages: Lower steady-state OpEx, greater capital efficiency, and greater energy efficiency. And, automation also presents challenges typical of paradigm changes: distrust, organizational upheaval, financial and business changes. The art/science of introducing automation into an existing organization is to reap the benefits, and mitigate the challenges.

As infrastructure automation moves forward, it appears to be bifurcating along two different philosophies. Each is valid, but appropriate for differing types of uses:

• "In-place" infrastructure automation: (distinct from run-book automation) Seeks to automate existing physical assets, deriving its value from masking the operational and physical complexity via orchestrating in-place resources. That is, it takes the physical topology (servers, I/O, ports, addressing, cabling, switches, VMs etc.) and orchestrate things to optimize a variable such as an SLA, energy consumption, etc.
• Virtualized Infrastructure automation: Seeks to first virtualize the infrastructure (the assets as above) and then automate their creation, configuration and retirement. That is, I/O is virtualized, networking is frequently converged (i.e. a Fabric), and network switches, load balancers, etc. are virtualized as well.

Each of these two approaches has properties with pros and cons with which I'm familiar -- having worked for companies in each space. I'll try to elucidate a few of the "high points" for each:

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

• Automates existing assets: Usually, there is no need to acquire 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 largest value propositions for this approach - automate what you already own.
  
• Masking underlying complexity: A double-edged sword, I suppose, is that while "in-place" automation simplifies operation and streamlines efficiency, the datacenter's underlying complexity is still there - e.g. the same redundant (and sometimes sub-optimal) assets to maintain, same cabling, same multi-layer switching, same physical limitations, etc.
  
• Alters security hierarchy: Since assets such as switches will now be controlled by machine (i.e. the automation SW automatically manipulates addresses and ports) 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 datacenter. 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...or, if physical load balancers aren't available, servers/ports won't have access to them. Nonetheless, if properly architected, some of these limitations can be mitigated.
• Use with OS virtualization: This approach usually takes control of the VMM as well, e.g. takes control of the 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/maintain because all assets, versions, and physical topography necessarily need to be discovered and cataloged. But once running, the system will essentially maintain its own CMDB.
  

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

• Reduction/elimination of IT components: The good news here is that through virtualizing 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 virtualized/presented to the CPU as any number of virtual connections and networks. And, a single virtualized 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/retired/repurposed on-demand. e.g. networking, load balancing, etc. can be created at-will with essentially arbitrary topologies.
  
• Consistent/complementary to OS Virtualization models: If you think about it, virtualized infrastructure control is pretty complementary to OS virtualization. While OS virtualization logically defines servers (which can be consolidated, moved, duplicated, etc.), infrastructure virtualization similarly defines the "plumbing" and allows I/O and network consolidation, as well as movement/duplication of physical server properties to other locations.
• New networking model: One thing to keep in mind is that with a completely virtualized/converged network, the way the network (and its security) is operationally managed changes. Organizations may have to re-think how (and who) creates and repurposes network assets. (Somewhat similar to coping with "VM Sprawl" in the software virtualization domain)
  
• Use with OS virtualization: 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 'green field' 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 datacenter assets - especially in a Dev/Test environment. 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/cabling/networking can be designed-in from the ground up. Most of these products are designed for production data centers, as well as cloud/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. Virtualized Infrastructure Automation adoption, on the other hand, will tend to ride the technology wave driven both by networking vendors and OS virtualization vendors.

Stay tuned for additional product analyses in this space...