SoftwareOne logo

How to implement Azure governance? A practical toolkit - SoftwareOne

SoftwareOne blog editorial team
Blog Editorial Team
A white hallway with a light shining through it.

Finances, cost, spend… Money is 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, it may make more sense to raise 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:

  • DevOps to improve communications and product delivery
  • SecOps to make security everyone's business
  • DataOps to make sure you get the right input from your data, and that you can trust it.

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.

What is cloud FinOps?

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. Every 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, so you can make the most of what you already have.

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.

Shifting cloud cost management left: Examples

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.

Retail company with a large B2B user 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.

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 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.

The stages of FinOps evolution

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.

Cost control

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. Typical questions raised at this point include:

  • What is the real cost of the service?
  • Why do different services have different usage and cost models?
  • What will be the overall cost of running this solution a year from now?
  • Why is my cloud bill so high and who runs this vast instance?!

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 :

  1. Learn what your usage is and focus there. Do not try to understand the pricing models of all cloud services. Your typical usage is most likely focused on a handful of services: virtual machine instances, storage, databases, networking. Look at the top 5 or top 10 services on your bill and master the financial model for those. You can learn about the other 150 services later.
  2. Make sure your model is accountable. A running virtual machine instance with no clear purpose? A SQL database with no apparent use in running 24/7? Here is where a simple approach from cloud governance helps:
    • Organize your resources into separate subscriptions and resource groups
    • Put Azure policies in place to tag all of them for cost control
    • Use Azure policies and RBAC to enforce business rules of who can start which type of resources.

At this stage, KPIs for your team will be operational and cost-driven:

  • Keeping all resources under cost control (no resources outside the scope of the policy)
  • Optimizing cost on a monthly/quarterly basis.

Designing with cost in mind

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.

Azure 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:

  • The cost of redesigning architecture vs potential gains from it in cloud usage
  • Optimizing the code vs what it brings in cloud usage bills
  • A change in the cloud bill vs business revenue from the solution.

Tracking the cost through actions

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 there 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. Costs will then be monitored not just at resource level but as granularly as at action level.

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.

Summary of cloud Azure FinOps evolution stages

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.

Tools for Azure cost management

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:

  • Management groups and subscriptions: use those units to separate workloads and projects with different cost-allocation structures (production vs development etc.)
  • Azure Policy : put policies in place to tag all the resources, and control what resources can be created and where
  • Azure RBAC is mostly considered as a security feature; it controls who has the right to create resources in your Azure (remember, every supply increases your expense)
  • Azure Cost Management : a single service that lets you take a look at and control Azure cost. It's included in your Azure subscription.

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.

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.

Quick tips for Azure FinOps

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 .

Dev/Test Environments: 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 spending. Here are quick tips on how to keep those under control as well:

  1. Do not manage your license assignment manually . Use the Azure AD group-licensing feature. It makes figuring out who is using what and making changes so much easier.
  2. Using Azure DevOps? Do you know about Stakeholder access ? If someone participates in your product delivery, but doesn't need access to code or pipelines, a stakeholder license is enough, and it is free. The same goes for your external partners and guests.
  3. There's also Azure DevOps assignment-based billing . Put it in place to work for you.
  4. Did you know that you can mix different types of licenses in Office 365 and Azure AD? Use Office 365 usage analytics to figure out who has a license assigned and is not using all of its features. You can move them to a different licensing plan, and with Azure AD group-based licensing, it is actually quite easy to implement.
  5. Using third-party SaaS applications? Azure AD can help you with that. When doing SSO through Azure AD, you can track who is actively using the license, and who is not. Then you can assign and revoke access through groups.

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.

Here are a few additional articles on the subject:

I firmly believe that Financial Operations (FinOps) , Azure FinOps together with Security Operations (SecOps) , will be one of the leading topics in the public cloud for years to come.

Author

SoftwareOne blog editorial team

Blog Editorial Team

We analyse the latest IT trends and industry-relevant innovations to keep you up-to-date with the latest technology.