The biggest thing enterprises can do to be more cloud-like
The rate of technology introduction in IT is faster than ever. And it’s accelerating. With each new technology comes an associated hype cycle, leaving enterprises fatigued with how to manage everything. To make things worse, there is a bit of Keeping Up with the Joneses. But in the case of enterprise IT, companies aren’t comparing themselves to members of their peer group. Instead, cloud envy is taking grip as companies imagine how they can be more like the major cloud and XaaS players.
But despite these cloud companies being associated with everything from DevOps to OCP, if enterprises want to make a real change to their IT fortunes, the one thing they should be copying isn’t technological at all.
This point almost goes without saying, but IT’s overall efficiency is directly related to the number of things they have to support. The more things you have to do, the more difficult it is to get everything done.
While your mind might immediately race to heterogeneous environments where there are multiple vendor solutions for common IT problems, there is actually a bigger culprit where efficiency is concerned.
You see, IT tends to be very incremental. We are always reacting to the next request. A line of business needs a new application? Let’s make a plan. We need to turn up a new site? Here’s a different plan. Deploying a new solution requires an upgrade to the software for west coast customers? Yet another plan.
Enterprise IT is masterful when it comes to adding on. Where IT is truly dismal? Removing stuff. And this creates what I call infrastructure drift. It’s the IT equivalent of the common developer phenomenon scope creep. With each new thing that gets added, the infrastructure over which IT presides becomes larger. Over time, this drift from center creates sprawl.
The cost of drift
While there is always a specific need to add just one more thing, there is also a cost. In most companies, this cost remains hidden, typically buried behind a large line item on the budget called Keeping the Lights On (KTLO).
As infrastructure drift creates IT sprawl, the support burden increases. You have to support everything that has been deployed to date, plus the new thing. And if that new thing is truly new (a new architecture, a new solution, or even just a new version of operating system), it carries a heavier hit as it might not completely leverage existing tools and processes.
If you have ever wondered why IT is so slow and expensive, chances are that it’s because most companies put lots of effort into adding stuff, and spend virtually zero time on removing it. The ever-growing IT support burden is rarely well understood, and when the accountants and controllers come looking for costs to cut from the system, they scrutinize that large, nebulous, value-sucking KTLO line item. And while CIOs put up a good fight, it’s pretty tough to prioritize KTLO over the next big thing, so you tend to see commitments to the future thing while holding budgets flat, a behavior that feels good at planning time but only exacerbates the problem.
Are you suffering from IT drift?
How would you even know?
In the networking space, you might consider taking an inventory of all the applications you have to support. Or maybe you look at all the devices you have deployed. Or maybe it’s the number of different operating systems (including different versions) that are deployed. Or perhaps it’s the variation in configuration files that are spread across those devices. Or it could be your growing list of firewall rules.
Each new thing—whether it’s a device or a policy rule—is another thing to manage. And if that list is growing unchecked over time, you are suffering from IT drift.
An interesting exercise would be to include the age of each item in your inventory. And then track the net puts and takes over the course of the year. How many things are added? How many things are removed? If your remove list is short (or zero), you might raise a red flag.
What do cloud companies do differently?
Well, first off, they are not as old as most enterprises. The major cloud and XaaS offerings are relatively young. Most of them are less than 10 years old, with AWS being among the eldest with its 2006 launch date. And because these companies are so young, they have a relatively short history of things to deal with. Almost by definition, their sprawl will be less.
But they also build in a different set of practices designed to keep their sprawl in check. Almost every one of these companies relies on their operations as a key element of their business, which means they optimize for agility. This means that efficiency is not just a nice-to-have—it’s an absolute necessity.
If you were to take an inventory of your favorite cloud titan network, you would find that almost every device in the datacenter is less than 5 years old. Generally speaking, the major cloud and XaaS companies refresh their equipment every 2-3 years.
Why refresh so often?
The first thing to know is that cloud companies do not treat individual devices like prized trophies. To steal Randy Bias’s analogy, they treat them like cattle, not pets. They are not concerned with sweating their assets for 7-10 years, understanding that a more aggressive refresh cycle means two things for them.
First, it means they remain current. They can take advantage of the best technology. And better yet, they can do this as a part of their normal business. There are fewer massive upgrades to budget for, which means the budget is easier to manage (it is less lumpy).
Second, they have less infrastructure sprawl because their devices (both physical and virtual) will be narrowly bounded in time. This means that their tools, their processes, and their people will be focused on a small subset of what a typical enterprise might have to deal with. Specialization is what breeds innovation, and this is where the cloud companies absolutely excel.
The bottom line
There is a degree of architectural planning required to make all of this work. You have to have a relatively small set of technology building blocks, almost certainly pulled from an open ecosystem to allow flexibility in your path forward.
But it’s not the architecture that is difficult for enterprises to replicate. It’s the discipline around refresh, which is a decision that requires major procedural commitment. Budgets have to account for it. The corporate policy around amortizing costs has to consider it.
And most importantly, this means IT has to be at least as good at retiring things as they are at adding things. The cultural implications here can be profound. But enterprises with cloud envy who fundamentally believe that their future is completely technological are going to be sorely disappointed.