Cloud costs can quickly spiral out of control. There are a lot of reasons for this, so Emerge asked IT asset management specialist and Licensing Analyst Rich Gibbons of ITAM Review to help us understand the dynamics of cloud costs and how to contain them.
Thanks for taking the time to speak with us today. Can you shed some light on how cloud costs get out of control?
Blimey. How don't they? What I've seen is you can get cloud without any internal sign-off process. There's no oversight. You can put it on your corporate credit cards, etc.
IT asset management has spent years building up a slick set of internal processes around people requesting software, ITAM check if it's required, is it duplicated i.e. do we already have a “spare” license, making sure it's cost-effective, and then giving that person access.
Cloud does away with all of that. You go to Azure or AWS, and you've got access to everything. And that is the easiest reason that it goes wrong.
Why don’t those same on-prem ITAM controls work for cloud?
With on-premises software, you literally can't get hold of the software without going through that process. But, with cloud, it's either people don't know about the policies or people don't care, and they can circumvent them completely and start-up cloud instances on their own.
DevOps and engineering teams tend to put less emphasis on doing things in the most cost-effective way. It's more about doing things quickly that are best for the project. Historically, those people have had less contact with the world of ITAM and policies. You have to build stakeholder engagement to get people onboard to control costs.
I thought it was the business that was driving cloud. How does DevOps drive cloud adoption?
It's the whole fail-fast model. Cloud lends itself to that because you can spin things up immediately, you can turn them off, you can destroy them, rebuild them. It's much easier to do that in a cloud or virtual environment. What might take you six weeks on-premises is a click of a button in AWS. That lends itself to DevOps working with cloud because they can work so much faster.
I see a disconnect between existing ITAM functions in a business and cloud. Many people look at ITAM as on-premises. When they do on-premises stuff, they look after contracts and SLAs. Cloud usage comes from engineering or even security, so there's no concept of, "Oh, we're doing this cloud project. We need to run it past ITAM."
What are the cloud’s ITAM limits?
To a large extent, it's psychological. When cloud started to become a big thing, there was a strong message that you wouldn’t need ITAM anymore. It's all in the cloud. It manages itself. You're licensed per user so you can't become under licensed.
All that came from an underlying idea that ITAM was just about making sure you bought enough licenses. In that regard, yes, SaaS made that easier. But the flip side to SaaS is it's easier to become over-licensed or not to use them correctly.
ITAM to me is also about managing hardware and applications, but it sounds like licenses are the focus for a lot of people.
ITAM generally splits into two: hardware asset management and software asset management. The licensing is where you can get tripped up. Deploy SQL Enterprise or Oracle DB Enterprise incorrectly, and you are looking at hundreds of thousands, potentially millions, of dollars of fines and licenses that you need to buy. Last year, software vendor Quest audited Nike and presented them with a $15.5 million bill.
Poor SaaS licensing management leads to waste. You have 1,000 people and 1,000 subscriptions. Then Tony leaves and is replaced by Claire. HR says, "Right, we've got a new person. Buy the new license." And now you've got 1,001 subscriptions for 1,000 people. It’s incremental, but each increment has a cost.
What about vendor supplied monitoring tools? Don't they help control cloud usage and cost?
People just aren't using those tools—whether it’s AWS Cost Explorer or Microsoft Azure Cost Management and Azure Advisor. Many times, people in the ITAM departments don't know about these tools, or they don't have access to them because engineering has said, "Oh, we can't let you have access to our AWS environment. You might delete everything, or you don't know what you're doing so you can't access."
There’s a lot of internal politics in the engineering teams, the DevOps teams, and whoever's driving adoption. No one appreciates having ITAM come in and say, "Right, we're taking over." It doesn't matter how good your tool is or how good your processes. If people aren't working properly—aren’t working together—there are problems.
What about third-party tools? There's a lot of them out there today.
It's about who has access to the tools. As you go through the maturity scale from zero to a company that manages it perfectly, that's when you'll start to see third-party tools adding in all kinds of extra bits and pieces. In the on-premises world, organizations buy a software asset management tool, install it, and then leave it. Without a champion, organizations neglect ITAM.
Of the big three methodology concerns—people, process, and tools—the tool itself is the last part you need to have in place. You need a tool to automate (e.g., shutting down unused instances, tagging) or the process comes unmanageable—that’s a given. But before deciding on a tool, make sure the foundations are in place for people to understand what they’re doing and why they're doing it.
Can you talk about tagging for a minute and how that helps to manage costs?
With tagging, it's "Everything for Project X, tag it Project X. Everything for Project Y, tag it Project Y." Tools report back on everything you've tagged, and they will also report back on everything that isn't tagged. You get buy-in when you have the people and the processes aligned.
So, how are most companies managing cloud costs today?
Not to be flippant, but the answer is, they're not. Even when it comes to the regular on-premises software asset management, there are a surprising number of organizations not doing it.
For those organizations that are doing it, we're seeing a lot of duplication. They're hiring a cloud-specific team to monitor the costs, to work out the reserved instance pricing, to do chargeback and showback internally etc. But there are people on the ITAM team who have been doing this, or something very similar, on-premises for years.
Can you explain the difference between on-premises costs, even if it’s a private cloud, and public cloud costs and why, in reality, they are quite different?
With on-premises, if you overspend on your Oracle contract, you've got three-to-five years until your renewal and you can kind of write that cost off and work it out for next time. But, in the cloud, if you're overpaying, it's constant.
If this is all about managing cloud sprawl, which is basically what we're talking about, then why not just follow the money?
Part of it is the bill. Let’s say it's $2 million. The first difficulty is working out what that represents. Is it one project for $2 million? Is it 10 projects for $200,000?
Often, when ITAM folks are able to get involved, they'll talk to everyone and add up what they're doing, and it'll come to, say, $1.2 million. And there's all this money that no one owns up to because either they don't realize they're spending it, or they don't want to admit it. So even when you're following the money, it's difficult to find where it was spent and on what.
It’s easy to hide accountability with public cloud. With the on-premises data centers, someone will know what buildings you own, and you can scan your network resources for operational data. When it comes to Azure and AWS, if someone else has created another AWS subscription—and doesn’t tell anyone—accountability only happens once you get the bill. Which is an unhelpful “do first, ask for permission after” mindset.
Also, with cloud, everything is like $3 an hour. No one looks at it and thinks, "Oh right, this is going to cost $1.5 million.” With cloud, if you've budgeted $500,000 for the year and you hit that four months in, I've yet to see any organization go, "We're going to have to turn it all off." They carry on regardless. ("Well, we're cloud-first. We're using cloud. We'll keep using it, and we'll find the money from somewhere.")
There’s a mentality that it doesn't matter. You're going to be able to carry on using it and the usual statistic it is that waste makes up 35 percent of cloud spend because you find different business units duplicating resources. They've both got a SQL platform as a service running in Azure or something.
So, given the differences between cloud and on-prem, what are the best practices today for managing cloud costs?
First of all, it's having ITAM involved. Once you've crossed that bridge there are three main things to look at: auto-shutdown, right-sizing, and reserved instances. So, with auto-shutdown, if you're not using it, turn it off, right? With on-premises hardware, your mindset is - you've bought a server so the more it's turned on the better. That's good. But, in the cloud, it is the exact opposite. People say that in cloud you pay for what you use, but it's more accurate to say that you pay for what you turn on. Whether you're using it or not, you're still paying for it.
With right-sizing it's being sure the cloud services aren't over-provisioned. Make sure they've not got bells and whistles turned on that you don't need, or that the virtual machine isn’t over-provisioned with RAM, cores etc.
Reserved instances are a way of paying for things up front so that you get a cheaper price. So, even if you over-provision the instance, you’re paying the lowest price possible for that instance while you’re working towards the right-sizing.
It’s auto-shutdown first, then reserved instances, and then right-sizing. That makes the most sense for most people as right-sizing can be a drawn out process.
And then it's building links between the cloud teams, whatever they're called, wherever they sit, and the ITAM teams because there's going to be a certain amount of reinventing the wheel. But when it comes to things like chargeback and showback, ITAM teams will have been doing that for a long time. They will have processes for that so just utilize those for the cloud spend - don't try and come up with them all fresh again.
Involve security as well as they will have extra insight into what assets are deployed, and where. With multiple teams and stakeholders aligned, you can manage those assets, and those costs, completely.