Sweat your infrastructure, review your contracts and assess your workloads

All mid-market organizations are reviewing how they can make better use of their budgets next year. This starts with the infrastructure you have already paid for and how to get the most out of it. When I talked about sweating assets in a previous article, this really has to do with some cost management – how much I can sweat an asset is how much I can continue for it to run after its ideal lifespan, which for most infrastructure purchases is 3 years. If I push that beyond 3 years, I’m now sweating the asset. 

What I want to think about is, where is a good place to do that, and where’s a bad place? Most infrastructure is fairly reliable. That being said, with the infrastructure that I have on Prem (and I’m never getting rid of all of it, even if I go to cloud first), I still have to run a network. I want to think about the kinds of categories of things that I would say are ‘sweatable’, and you could put them in Tier 1, Tier 2, Tier 3.

So, Tier 1. These are things I cannot sweat. The big one is my Tier One Storage. If I’ve got a database, I probably don’t want to sweat the storage as I’ve got that business-critical database, I really need to be on top of it. So that’s a place where I’m not going to want to sweat that investment. 

Tier 2 are things that, well, my business is going to continue to operate well if I use these beyond their three years. Maybe I can get 5 years out of them. For example, servers: I don’t really want to sweat these, but at the same time, I’m not necessarily using all of my CPU, really working that piece of hardware. The likelihood of failure doesn’t drastically increase between 3 and 5 years, so it’s okay to sweat that. I probably don’t want to sweat up to 7. That gets a little risky. Reliability issues increase after five years. Even things like fans failing can become a huge maintenance problem. 

The network goes into that Tier 3 bucket when it comes to non-security components of my network switches. Routers. Those I really should have no problem sweating into this kind of 7-ish year range. Where that becomes problematic is if I’m getting into capability issues, for example, security. Or capacity issues, where I’m pushing more network traffic than the switch can handle. Let’s say we have 10G at my core, or 40G at my core, and I’ve really pushed beyond what the 10G or 40G can really handle. 

As you look at both Tier 2 and Tier 3, as you start to sweat those beyond what the manufacturer considers to be the standard lifespan, you’ll find your first party support costs go up. For switches, if your manufacturer still allows you to get access to firmware, you might consider third party maintenance. First-party firmware is a must: a lot of manufacturers restrict your ability to get current firmware, which has a direct impact on how secure those devices are. 

That works for servers as well. If you can’t get current patches, if you can’t get current drivers, at the very least, you’re going to miss out on security updates. You’re also going to miss out on any stability and bug fixes. So really read the fine print. Make sure that you stand up on that. 

As part of this exercise, I would do some significant contract reviews: it may be worth engaging a company to make sure that you understand what your total spend is, and look for potential to consolidate across the organization. Then you can start doing some master services agreement (MSA) negotiations and contract negotiations to really drive the price down. 

Especially in endpoints! We find a lot of organizations think their spending is anywhere from 40 to 60% of what their actual spend is in things that have been distributed out into the organization for buying power. The ability to consolidate that and say, we’re going to buy all our endpoints from Dell, Lenovo, HP, Microsoft or whoever, and then go to that vendor and negotiate an MSA with discount levels. This can be a significant cost saving. 

The other thing that you should look at is vendor/partner consolidation. You will likely have more vendors than you need, so which ones are really providing distinguished value back to your organization? Which are really helping you think about your business and providing technology as a business asset? If you start consolidating to those, first you can lower the chatter that occurs, but also, second, you can leverage the power of your wallet and get more value from those relationships. 

I would recommend fixing on three vendors. I don’t think you should consolidate any lower than that. Three gives you the ability to do some competitive pricing when necessary. It makes sure that you have a wider gamut of options when you’re looking at products. Higher is okay, or you may not have the time and patience to entertain three vendor relationships, so less is also a possibility. You have to make a choice for yourself. 

These questions don’t go away with Cloud. The first thing to remember is, Cloud should not be arbitrary. By which I mean, it’s okay to have a ‘cloud-first’ strategy, but it’s not ok to have a ‘cloud-only’ strategy. This tends to go poorly. Cloud-first is when the first thing I do is look to the Cloud and say, is this the right place to run this workload? Is the Cloud really built for this? And does my business require the things the Cloud provides? 

Two things should push you to the Cloud; the first being a reduction of technical debt, which means all the shortcuts that were made in deployment, that now cost you in performance, capability, flexibility, or simple maintenance. So, if I deploy this thing to the Cloud, can I do so in a way that reduces technical debt? Am I going to be on the newest version? Can I do it as a SaaS, where I no longer have the same maintenance level/maintenance requirements, and where the software will not continue to be aged, and the age of that software, the currency, or lack thereof, will become a problem?

The second is agility. By putting this thing in the Cloud, am I going to be able to leverage the agility of the Cloud – either in scalability, or left-right add-ons? For example, will I be able to take advantage of some of the AI or ML tools that exist in the Cloud? Would those things complement this application, and thus give me a far greater capability than I would if I had it on premise?

If the answer to both of those is no, and you think you can go to the Cloud and save money, then that’s likely only true if you’re already 94/95% in the Cloud. What I’d really think about is, is the Cloud the right place to run this workload? If not, do I have on-premise infrastructure that can run it? If the answer to that question is yes, I should have it on-premise. Then we drop back into that vendor-tool-contract conversation. 

If the answer is no, and the Cloud is the right place to run it, then deploy to the Cloud, but the conversation stays the same. There are 270 CPU combinations available in AWS. Have we standardized on those? Have we standardized on how we’re going to consume S3, and specifically which S3 products we’re going to consume? Same for our AI choices and ML choices. Can we apply governance to those things, so that it’s not the overwhelming monster that Cloud can become? 

I don’t think the contract conversation changes, whether it’s on-prem or cloud-based. There’s a lot of credit card AWS within an organization. So, can we consolidate that, and enter into a contract and take advantage of contractual discounts? As a customer, can we take advantage of some over provisioning during our contract period, without incurring an increased cost? This is only available on an enterprise agreement, so are we large enough to have an enterprise agreement with AWS or Microsoft?

You can see the relationship between this and asset sweating, tiering. When I’m going through that tiering exercise, I’m also exposing the criticality of the application and its underlying infrastructure to my business. By determining what’s critical to my business, I can also see what is going to benefit from the resilience and elasticity of the Cloud, early, first and foremost. If I can’t sweat this infrastructure, and it’s coming up for renewal, and it’s a significant buy, is running on-prem still the right way to do that?

I also want to consider whether my access patterns have changed. Over the past three years, everyone went home and started to work, and many organizations are finding that productivity is the same or better, or the differences are negligible. But employees really see that flexibility is a huge benefit. Meanwhile we’re seeing in the news how companies are calling on employees to come back to work in the office, and they are seeing a lot of resignations. 

If you’ve looked at that and decided to keep a large percentage of people working from home, it’s likely that driving people to a central data center to access an application may not provide the greatest experience, since you don’t control their last mile network access. It may be worth looking to the Cloud to improve that experience for your distributed workforce. 

This is all about getting in shape, ultimately. Tier your assets, sweat your assets, and move workloads to the Cloud where it makes sense. Most of all, get your vendors in shape, whether they’re on-prem or Cloud, otherwise, you’re just going to be paying more for things you don’t need or which can be discounted. Don’t assume the status quo is your friend, that’ll just cost you money, and nobody can afford to do that.