What We Can Learn about Scale from Virtualization

As virtualization began to take hold there were a variety of metrics proposed for measuring success. Consolidation ratios, admins to virtual machine ratios, time to provision, and percentage of servers virtualized were among the most commonly used to measure and rate the success of virtualization projects.

Today we’re watching as DevOps begins its ascendant climb and similar metrics are being proposed to measure its success. Time to market, mean time to recover, lead time for change, and deploy frequency are among the more common measurements bandied about when we focus in on the “M” in the CAMS (Culture, Automation, Measurement, Sharing) definition of DevOps.

These are good and necessary, but there’s a benefit – a use case, if you will – of DevOps that’s rarely discussed that is just as critical: operational scale.

It’s the same problem SDN tries to resolve “in the network” through operationalization; enabling the scale of teams through technology to match the rate of growth desired and being experienced by the business thanks to the rapid growth of mobile and web applications. It’s a classic “30/30/3” problem resulting from the growth of data driving up IT costs (to transport, process, and store) with only a minimal increase in revenue. Solving this problem requires focusing in on the one piece of the equation over which we have control: higher IT costs. So if you want to call it SDN, go ahead. If you want to call it DevOps for the Network, go ahead. If you want to call it SDDC, why not. Call it cloud, too, if that’s your thing. They all carry a common premise: rapid operational scale is critical to growth.

It’s not just about hardware and software resources; it’s also about how we provision and manage those resources. It’s a need to reduce the amount of effort required to manage the set of resources – hardware and software – required to deploy and deliver an application so.

That’s where the “A” for “Automation” plays well in reducing the IT costs needed to change the growth equation and enable the scale to support greater business growth. 

But it’s not just the superficial view of automation we need. While automating (using scripts and orchestration to drive provisioning and management and the operational processes required to deploy services and apps) is important, let’s not forget about the critical role “infrastructure as code” plays.

We can do that in part by taking a peek through the wayback machine at the success of virtualization in scaling management of compute resources in (no small part) thanks to treating that infrastructure “as code”.

I know, I know, it wasn’t really code in the sense that it wasn’t a script or a configuration file or anything that looked like “code”. But it was treated “as code” in the sense that we used centralized repositories of “golden images” from which to rapidly provision and configure servers. Web servers, app servers, data servers. Different kinds of servers were idealized by a pre-defined “image” that enabled operators to scale.

And when I say scale I mean SCALE. While there’s lots of numbers bandied about, it was not unusual all the way back in 2011 to find organizations with a 1:350 admin:virtual server ratio. Some claimed upwards of 1:500 to 1:1000, while others, simply stymied by the size of their org, could only claim 1:100 or 1:150. A 2012 report analyzing data from multiple IT benchmark reports noted the admin: server ratio as being 1: 50-75 for physical servers and 1:185-450 for virtual servers.

In terms of scale, that’s amazing. That’s growth-enabling without the usually complementary higher IT costs.

Now, consider that the median engineer:device ratio across all size businesses is about 1:36. That is interesting in an of itself, don’t you think? The ratio doesn’t appear to change as business grows. Which is kind of a bad thing and just contributes to the 30/30/3 problem.

But if we could change that in some way, even just to double the devices per engineer, we’d cut the costs of growth and enable better scale of the entire network.  To do that, we have to emulate the success of virtualization. Not necessarily using virtualization, but using the concepts that enabled it to support unbelievable ratios of admins to servers: infrastructure as code and automation.

The reason we can’t just create golden images of switches and load balancers and the 20+ other L4-7 app services we know organizations are employing to deliver and secure their applications is because every config is unique; it’s app-centric, and that means while you can certainly go software (virtual) and deploy a golden base image for any one of those services, you’re still going to need someone to do the configuration. And it’s not a simple configuration.

Configuring some app services for Exchange? It requires over 80 different objects to be created, configured, and associated correctly to get the availability, performance and security needed.

This is certainly where time (and its related costs) are incurred “in the network.”

Which is where we need to scale. Where we need to treat infrastructure “as code”.

This is the reason that templating is included in the “A” for Automation component of DevOps. Because templating enables net (and sec, too) ops to treat common configurations “as code” that can be managed in a central repository. The template becomes the “golden image” from which app services are provisioned and configured. That approach enables automation and orchestration that mimic that of the provisioning of virtual machines and provides the basis for the operational scalability orgs need to enable business growth.

DevOps and SDN and SDDC and even cloud aren’t just about improving time to market or reducing operational costs. They’re also key to efficient scale that enables instead of impedes business growth. The cost of adding more and more operators or engineers to manage the increasing resources across the entire data center (compute, network, security, storage) is going to devour the growth that comes out of that scale. Scaling more efficiently using automation and treating infrastructure as code can be one way to manage the scale needed to support the growth desired by the business.