FINOPS COMES INTO PLAY

As I already wrote in this article, you should treat FinOps as a means of distributing ownership and best practice in order to instill cost-controlling without losing agility.

Sometimes you could hear that is it all about setting budgets and alerts. Well, not at all! In FinOps, what matters most is the organizational setup.

FinOps will focus on bringing maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions. Here, maximum business value comes from a fast time to market. Today, managers often need to take business decisions very quickly. The decisions they take will be based on the data they are provided – if you don’t have the data at hand, you cannot take the best decision possible.

FEDERATED APPROACH

The first and best choice for governing your cloud should be the federated approach. What I call federation here is the collaboration between a central IT team and smaller project teams distributed across the organization.

As per the Cloud Adoption Framework, central team is responsible for a management subscription while project teams get their own landing zones (separate project-specific subscriptions).

In such setup, the central team (CCoE) shall:

• control all landing zones
• control the virtual networks
• allow for cloud governance
• configure log generation
• etc…

Meanwhile, you delegate project-specific responsibilities to the distributed (project) teams. Then, each project team gets their own landing zone for which they are responsible. At the same time, central IT team bears the responsibility for the management subscription. This is aligned with the hub and spoke network approach to networking recommended by Microsoft.

Remember when I stressed the word collaboration when I mentioned FinOps? Now, here is what I meant. The collaboration comes from the fact that CCoE within the management subscription governs pooled, common resources shares across all subscriptions. This could be Log Analytics, gateway costs… Moreover, CCoE will exert control over all cloud policies (full governance of the platform: auditing, encryption etc.). The distributed teams depend on the CCoE, but they do not need to focus on operational matters such as changes to infrastructure (network, private vs public endpoints, exposure to Web). They can focus on building business value instead.

At the same time, CCoE actors can decide what are the boundaries in which the projects are operating ex. if scaling up/out is allowed or not.

THE ROLE OF IAC

IaC (Infrastructure as Code) is the approach to manage your environments and infrastructure within scripts instead of point-and-click. This makes for reproducibility, security, standardization, and control. Surprisingly, Infrastructure as Code accelerates cloud adoption: it facilitates the control of various landing zones in the federated approach.

Suppose the CCoE prepares Bicep scripts (one of the approaches to IaC) for your cloud environments. Whenever a new project requests their own environment, as a CCoE member you can simply standardize and create a landing zone out of one button click (policies, services) by deploying your scripts.

If you need additional services, it’s also easy to customize and adjust your code on the way. Imagine one of the teams needs wants the biggest Synapse instance. You can design a simple workflow for such requests. Then, any changes to the infrastructure code are automatically sent for approval by the budget owners. Only if such approval is granted, can the code be deployed.

CONCLUSION

To sum it all up, I feel that the federated approach fueled by Infrastructure as Code is the best way to tackle FinOps enablement in a larger organization. The federation can vary depending on the business context, with providing autonomy to project teams, but the crucial aspect remains the same: enforcing control while staying agile.