A learning journey

pollirrata.com

Cutting Cloud Costs Smartly

How much of your infrastructure is currently in the cloud?

According to the latest IDG Cloud Computing Survey, 92% of respondents have at least part of their environment in the cloud. Given recent events (including the pandemic requiring companies to accelerate their digital transformation), this may not be a surprise.

Of course, beyond the technical changes this implies, leveraging the cloud also requires a financial transformation. Companies move from capital expenses to operational ones. While this may be a good thing for many organizations because, for example, it reduces the risks of starting a new project, consuming computing resources as utilities may also represent a challenge. Instead of spending once, you get a monthly invoice. Paying it may become a routine task, but the meter continues to run. Always. Ticking. By the time you notice, you get a bill for tens of thousands of dollars.

In Information Technology, CAPEX relies on a well-defined process that is similar for many organizations. You plan your project, define the budget, get the required approvals, send the purchase order, get an invoice, pay, and voilá, you get your infrastructure. After that, you don’t need to decide much other than ensuring you’re using your assets efficiently.

OPEX is, in a sense, much more straightforward. You don’t need that many steps. But, at least in the cloud, that’s why it becomes tricky. Since often there’s no need for a “formal process,” you somehow lose visibility because your team can create new virtual assets without any approval from Finance. And since the developers are busy constructing fantastic software applications, or the IT crew is swamped virtualizing new servers, nobody remembers to look at the billing forecast. By the time you notice, your CFO is having a heart attack after receiving a multiple-figure invoice from the cloud provider.

After some time, you may get used to paying for these cloud resources. However, when times get tough (i.e., an economic slowdown), a common reaction is to look for ways to cut costs. In some of the organization’s departments, it’s straightforward to make this happen. For example, you can reduce a certain percentage of your software licensing costs by renegotiating with the provider.

Now, let’s say you aim to reduce your cloud spending by a specific amount, for instance, 20% of your overall cloud spending. Yet, in this case, the costs you get are a matter of individual resource usage and size. Should you switch to cloud resources that are 20% smaller? Or just determine your usage metrics and aim for one-fifth less? Is storage usage equivalent to compute? The answer to each of these questions may vary from company to company.

A useful first step is to determine which of your business capabilities are being supported by the cloud. Are any of these something that gives you a competitive advantage? Or just something you need to stay in the game? This distinction is something you should know at every moment and will determine what your priorities are. Aligning your strategy’s cost may look like an obvious thing, but it’s common not to have this visibility.

If you have multiple products or maybe various departments, it’s essential to identify how much each is spending. Tidying your cloud resources by ensuring they are linked to the right cost lines or centers is a good start. Once you have this information, you can proceed with the cuts.

Determine Where the Leak Is

According to The New Stack, Forbes, Deloitte, and many other analysts, in 2020, the average cloud waste was between 30 to 40 percent. As I’ve witnessed in multiple companies, a natural question arises: why does this occur? Well, there can be various reasons.

A common source of the problem is that many companies allow team members to create the resources they require for their projects. But the engineers aren’t to blame; decentralizing the cloud resource management process is suitable for velocity and cadence but not for control if you don’t have the tools or strategies to support it.

For example, giving unlimited freedom to the team may mean allowing them to create a premium virtual machine instance or a storage bucket with geo-replication even when it isn’t required, like, in testing or development environments. It’s easy for this to happen because sometimes it is the suggested configuration or the default values in the process. Who stops to read anyway? Three more clicks to check the pricing schema? Read through the table to see where my planned usage will fall? Thinking of how much I will use? Nah, not worth it. I’m busy. Next, next, next, create. Of course, the opposite approach is not an option either. If you end up controlling the creation of each resource, your team may not get too far.

A better approach would be determining the allowed cloud resource types, services, levels, or plans your team can pick from and communicating this to them in advance so they know what to choose. A good understanding of your cloud provider’s offering is useful to know what this list should include. For example, if you’re using AWS, the “approved” catalog wouldn’t include virtual machines of type “C5” unless you were doing high-performance computing, video encoding, scientific modeling, or similar heavy tasks. Maybe all your development environments should be of “T2 small” size.

Down the Rabbit Hole

Many other culprits may exist. They’ll require different treatments, depending on if they are related to usage metrics or practices, architecture, etc. However, this can give you a good sense of what to look for when looking to reduce spending. Cloud providers have dozens to hundreds of services with diverse cost models, and because of that, they represent different challenges around knowing where to save some money.

If you identify where your investment is going, you can determine the best way to maximize its value. Maybe, cost-cutting isn’t even optimal, but if it is, you can do it smartly.

Leave a Reply

Your email address will not be published. Required fields are marked *