Finances, cost, spend… It’s the second most important topic when it comes to the public cloud, right after security.
But today we won’t be talking about a simple recipe for cutting down the cost. In fact, I think you might be more interested in raising the costs in some situations.
How so? Keep reading to find out.
In the previous posts I’ve guided you through various aspects of cloud operations:
I think that in the future, the most impactful of all will be Financial Operations (FinOps for short).
Do you have a Cloud Financial Engineer on your team, or do you work with a Cloud Economist? No? Hardly anyone does yet, but this is clearly an emerging position, and an essential part of an organization’s cloud journey.
The most significant change in the public cloud model compared to on-premises operations is that you can assign a budget to every element of your solution at the flip of a switch.
It is not a big “datacenter” bucket anymore; it is an individual machine, storage, SQL database; each of those elements has a distinct line on a monthly cloud bill.
This shift is not clearly visible in the beginning. At first, most companies approach the cloud in the same way as on-premises resources: in terms of IT cost and budget. Even if it is included in a project’s budget, it still falls into the “IT” bucket.
Only later, when the cloud bills start to pile up, do the questions arise: “Who is using all those resources?”, “Why is our bill so high this month?”
This is the first moment when you will meet with the cloud economy and financial model. Typically, it is an approach aimed at cost-cutting. But as your cloud usage increases, it evolves into a more sophisticated strategy.
This is the essence of cloud FinOps. It’s an approach focused on getting full visibility into your cloud resources and associated costs.
Instead of aggregating all cloud expenses as “IT costs”, you take a more detailed approach, monitoring expenses at a resource, service, and even action level – and not just in production, but also during development.
With the public cloud, solution architecture and code will be functions of cost.
Yes, cost is an additional dimension you have to consider when designing solutions and writing code.
In the public cloud, every decision regarding scalability and approach to resource allocation drives costs up or down. The same with code – a different approach might save you money on execution time, or cost you a lot in machines seating idle and waiting for a request.
Let me give you some real-world examples, where the budgeting approach alone has changed how the company built a solution.
Case #1: A retail company with a large B2B base
A retail organization with extensive B2B and B2C user bases moved to e-commerce. To handle security, it built a custom service based on open source components. It required a lot of maintenance and skills the company was struggling to get.
We considered Azure AD B2C as a possible solution. Technically, it was a fit. Finance-wise, not so much: the service model was built on per-authentication billing, and it was hard to predict the future cost. The project was stopped.
Few months into the future: Microsoft has changed Azure AD B2C pricing; it is no longer per-authentication, but per monthly active users (MAUs), with a hefty (50k) free tier. Nothing has changed on the requirement side. The only difference is the cost of the cloud service. As a result, architecture decisions needed to be revised.
Case #2: A financial startup
A financial startup built on Azure used Cosmos DB as a service. It made up a large part of their cloud bill, so a decision was made to switch to other services. During the development period, Microsoft has changed the Cosmos DB pricing model. The decision was reversed, as it was no longer economically justified.
Those two cases are straightforward but show how choices regarding solution architecture and code are driven not necessarily by business or functional requirements, but by cloud infrastructure expenses.
As your organization’s cloud footprint grows, you will find more and more of such examples.
On their cloud journeys, organizations will usually go through three distinct stages of approach to cloud Financial Operations. Typically, everyone starts with a strategy led by cost-cutting. It is natural, as a budget-driven approach is familiar from standard, on-premises budgeting practices.
Here is where the majority of public cloud users are. The cost control lens. Moving from on-premises to the public cloud, an organization struggles with getting to know the new financial model.
Those questions are justified and are all part of the learning curve. You need to understand that FinOps is part of your routine, just like patching servers and keeping them secure. It is just that nobody did it before, and no one taught you how to do it.
After all, you’re in IT and technology, not accounting.
Getting started with managing cloud spend
The key here is to be pragmatic:
At this stage, KPIs for your team will be operational and cost-driven:
Once you master the basics, you graduate to stage 2: you consider your cost at the time, and the solution architecture is designed. Then, it is redesigned, to manage the finances.
At this stage, you know your service footprint and its pricing models. Now you are ready to review and evaluate new and existing services.
For example, do we really need so many instances? Do we really need to have these resources across regions? When was the last time we reviewed solution choices and changes in cloud provider pricing?
Now you are also ready to take a business-driven approach to cost control.
It might be OK to burn more cash to quickly evaluate a service approach and business outcome, but it is not OK to stick with it for a long time. You can make informed decisions at this stage, equipped with cost control tools and an understanding of your business.
FinOps is not just about reducing the cost. It is about leveraging the right resources for the desired business outcome.
Here you can create different KPIs for your teams in Financial Operations:
What if you could tell how much generating a PDF invoice costs in your e-commerce solution? How much does registering a new user, and then keeping their records, cost you in terms of resource usage?
Wouldn’t it be a different level of conversation? The backlog of your product could have an additional dimension. Changes to the backlog would have clear KPIs based on expenses.
We are not quite here yet, but this part of Financial Operations matures quickly, especially with the advent of serverless as an approach to solution architecture (not just as a serverless technology component).
As technology and its usage & patterns mature, more organizations will reach this stage.
KPIs here will be business-driven, and as I don’t know your business, I can’t suggest any right now. But I’m happy to talk about it – just get in touch.
This is how I see the cloud journey in terms of Financial Operations, and why I think it will be one of its main pillars. Better to start practicing it right now.
How? Here are some guides.
The Azure cloud provides an entire toolkit for you to manage Stage 1 and Stage 2 of your FinOps journey. It starts with a proper governance model in place, including cost management.
If you haven’t read it yet, check out the Manage cloud costs section of the Cloud Adoption Framework for Azure. Start there and continue reading; it provides all the necessary information regarding both approach and tooling.
The crucial tools you can deploy quickly and at no additional cost:
These are the services you can deploy immediately, at no additional expense, to get a grip on your Azure finances.
For a practical take, have a look at our tutorial on Azure Cost Management from our Cloud Governance series:
A guide to Azure cost management
Additionally, let’s go over some quick tips on where most organizations can quickly look into cutting down the cloud cost without changing the solutions.
Here is where you can get started.
Shutting down unused resources
Powerful but straightforward. Place your development and test instances in separate subscriptions. Deploy an Azure Policy to control shutdown. Set the VMs, and other compute resources you don’t need, to switch off outside of business hours.
Azure Hybrid benefits
Often overlooked, they allow you to use licenses you already own on-premises with cloud resources. Remember – the cloud still has licenses for OS or SQL. It is part of the hourly usage cost. If you have those licenses already, Azure will remove this expense from your bill. Read more and calculate your savings here.
Reserved VM instances
Is your solution VM-heavy? Or are you planning to run it for a long time? Reserved instances are the way to go. They allow you to reserve VMs for an extended period, which makes it more economical. Combined with the Hybrid benefit, the savings could be HUGE. Read more here.
Your developers use Visual Studio, and you are an Enterprise customer? You should take a look at Enterprise Dev/Test subscriptions. They offer the same Azure for your developers at a reduced cost.
Azure is not the only place to introduce savings!
Using Microsoft (but not only) SaaS software and licenses also contributes to your spend. Here are quick tips on how to keep those under control as well:
These are relatively simple solutions you can deploy within your current resources and licenses. There is more, but as you can already see, Financial Operations can offer a lot of value for your organization. Both in terms of quick benefits and in the way it fosters a different approach to using the cloud and building solutions on it.
If you don’t want to deal with cost optimization yourself, we can help you out – our free Cloud Optimizer service takes care of just that. And yes – it’s really free!
Predica Cloud Optimizer
Here are a few additional articles on the subject:
I firmly believe that Financial Operations (FinOps), together with Security Operations (SecOps), will be one of the leading topics in the public cloud for years to come.
Next time, I will wrap up our 4xOps series and show you how you can practically put it to use in your projects on Microsoft cloud.