FinOps: How Cloud Finance Management Can Save Your Cloud Programme From Extinction
Time and again we see organisations run into some pretty big cloud finance headaches:
- Your cloud spend is much higher than expected
- You aren’t seeing the cost benefit from your data centre lift-and-shift
- You are spending far too much on licenses and services that you don’t have control over
Engineers often don’t appreciate the financial burden their cloud spend represents to the company. At the same time, finance teams aren’t cloud-savvy enough to figure out how they can rein in spiralling cloud costs.
With cloud spend forecasts predicted to surpass $330 billion by 2022, no longer can organisations and executives continue to stick to existing financial and procurement practices and let engineering teams handle their cloud spend.
In the worst case, this can cause exasperated directors to doubt the benefits of the cloud and pull the plug.
But the problem is not the cloud; it’s your cloud consumption model! Your financial approach to consuming the cloud is fundamentally flawed.
Enter FinOps: a model of cloud consumption that brings the finance team into the new world of the cloud, radically shifting how you think about cloud costs and (possibly!) saving your cloud programme from extinction!
In this blog I’ll explore:
- Why your finance function isn’t prepared for the cloud
- What is FinOps? How does it help?
- The fundamental building blocks of the FinOps approach
Why Your Finance Function Isn’t Prepared for the Cloud
When scaling the cloud, organisations put a lot of time, focus and attention into familiar disciplines such as engineering, security, governance, operations, but their finance and procurement functions are still geared for consumption of traditional on-premise IT services.
The cloud—and cloud native technologies—has fundamentally shifted how organisations view technology spend. Here I’ll look at the three biggest ways cloud has done so and why this causes a problem.
1. Your finance processes are not set up to manage the shift from CapEx to OpEx
The cloud shifts your tech spend from fixed CapEx to fluid OpEx.
Traditionally, finance and procurement teams would categorise key hardware investments as ‘fixed’ assets that depreciate over a fixed period of time until the next hardware refresh cycle (3-5 years on average). Such investments were filed under Capital Expenditure (‘CapEx’).
However, the commercial model for procuring cloud services is considered Operational Expenditure (‘OpEx’) because the cloud is consumed on-demand as a pay-as-you-go service.
Finance teams and processes are not set up to manage how this affects your bottom line, or to account for large sums of cloud spend emerging every few months.
2. You can’t forecast tech spend as easily
Finance and procurement teams also traditionally had complete oversight of the IT services (hardware and software) being purchased. They selected suppliers, negotiated discount rates and knew exactly who was buying what. This meant they could accurately forecast and plan for tech spend.
In a cloud world, however, these procurement responsibilities are delegated to the individual developers or teams, who procure them in a self-service fashion as and when they are needed via their cloud service provider.
In this context, finance teams struggle to keep track of who is buying what and can no longer properly forecast technology spend.
3. You can’t control the self-service free for all, even though it still affects you
As mentioned above, most cloud services are procured by the individual/team who needs it via a cloud marketplace from the provider. Financially, this can be a sensible way of doing things.
But it can become a free-for-all with very limited oversight.
The question for finance teams is how they can put guardrails in place to control spend and make sure people don’t do anything daft. Who can buy what? How can you keep track of licenses? What are the commercials?
All of this is now outside the remit of the finance team, while still affecting them.
Plus, when engineering teams are buying their own services, what exactly is the role of finance and procurement? They are still struggling to figure out how they fit into this more open, fluid cloud world.
These are just some of the key challenges that traditional finance and procurement functions are left asking themselves, with some other notables ones being:
- With technical disciplines now being focused on product thinking, how do you apply this thinking to move non-tech disciplines — finance, procurement— away from an output-based mindset and closer to the agile, customer-centric view you look to instill in product teams?
- Is it possible to have financial governance and control in a cloud-first model?
- Can traditional finance and procurement teams take their existing domain practices and apply those to cloud?
- Does cloud consumption entirely transfer the financial responsibility to the cloud-consuming engineering teams?
If these are questions that you find yourself asking then you aren’t the only one.
Finance and procurement are one of many governance and control functions that are currently reinventing themselves to figure out how they can best apply their domain knowledge to the growing world of cloud computing and product-focused thinking. (As a matter of fact, my colleague Matt Davies has just written a similar article on how ITIL based Operations teams can bridge the gap to support rapid pace of change.)
This is where FinOps comes in.
What Is FinOps?
FinOps is an approach to managing and operating cloud spend by breaking down the silos between engineering, finance and procurement. FinOps is meant to drive a shift in culture in cloud financial management, akin to how DevOps and SRE have driven a cultural change in engineering.
It aims to bring together all key functions involved in planning, procuring, consuming, managing and governing cloud services in order to make the right decisions and trade-offs when consuming cloud without compromising on the consumer experience and value that cloud was meant to offer in the first place.
It prevents spurious cloud consumption patterns and optimises cloud consumption. Ultimately, it could save a cloud program that otherwise would have been mired by spiralling costs.
Some of the key principles of the FinOps model are:
- Finance and procurement not the gatekeepers of cloud spend: finance and procurement are not gate keepers of cloud spend, but rather part of the product architecture and planning process with the engineering teams
- Shared accountability: while financial management and accountability is federated out to a degree to product teams, the FinOps function provides the guardrails and guidance on how to best achieve it.
- Architect with finance in mind: the financial suitability of the chosen architecture is a key part of the design, build and on-going optimisation process for every team that uses the cloud.
- Product- and metrics-driven decision-making: use a financial tracing process that helps align cloud spend to product benefits and customer metrics, resulting in a better approach than making optimisations based on purely financial reasons.
- Cross-team collaboration: in order for FinOps to be effective, finance teams have to appreciate the needs of the engineering teams, while engineers and product teams need to appreciate the financial implications of their decisions and choices.
- Visibility for teams: Providing real-time data and visibility on one’s cloud spend is a right that consuming teams deserve, as it helps them make better decisions and understand the financial implications of their cloud usage.
By combining aspects of financial management, cloud operations, demand management and the core disciplines of procurement, FinOps aids organisations in driving a more efficient cloud cost management and ROI framework and aligning your cloud adoption journey to business value.
Cloud cost management has always been a key pillar when it comes to architecting a cloud environment well. However, with cloud spend in 2020 showing no sign of stopping paired with the directly implied shift from CapEx to OpEx, doing a quarterly review of your cloud consumption is no longer enough.
The resulting benefits of moving towards a FinOps Model are:
- Optimised cloud spend: ensuring every penny spent on cloud services is done using the optimal service offerings available and making use of the appropriate financial incentives and consumption models the Cloud Service Providers have to offer
- You are prepared for a cloud-centric future: A pathway to a financial operating model that is better aligned to the dynamics of cloud computing
- Improved decision making: The ability to make financial decisions driven by data as the key source resulting in optimal consumption of IT services
- Traceability of decisions: Providing organisations with a financial trace aligns business decisions to the cloud spend incurred
- Empowered product teams: Providing them with the autonomy, visibility and responsibility to make their own financial decisions, while operating within the guardrails established
How Do You Get Started with FinOps?
A fundamental mistake most organisations make is to consider cloud financial management and governance either as an afterthought or as a cost-saving activity.
However, at Contino, we take an engineering-first, data-led approach to FinOps. To build a successful FinOps function we recommend starting off with the following building blocks:
A Cloud Cost Control or FinOps Policy
Just like a set of engineering standards within a development team, or an expense policy for any employee within an organisation, a Cloud Cost Control policy provides consuming teams with a control set to comply with in order to achieve the financially controlled consumption of cloud within the organisation.
Every single employee within the organisation must read, understand and acknowledge their compliance and responsibilities when adhering to said document.
The policy should cover vital information such as:
- Information Access: What type of information does the FinOps team intend to gather, track and monitor from the consuming CSPs (cost and usage data, reserved capacity allocations, etc.)
- Organise: The organisational and governance approach the FinOps team expects consuming engineering teams to adhere to in order to simplify and attribute the cloud costs to the right teams. This includes mechanisms such as :
- Organisational structures within the CSPs (eg. AWS Orgs, Azure Management Groups, GCP Folders)
- Tagging and naming standards
- Cost allocation datasets that the FinOps team expects all consuming teams to provide, eg. application owners and sponsors, cost centres, etc. These can be automated and specified within the naming and tagging standards.
- Understand: The key spend and financial data points that the FinOps team expects consuming and operations teams to track, while managing the key cost drivers associated with said spend.
- Control: The cost allocation and cloud controls that expected consuming teams are expected to adhere to, such as monthly budgets, environmental costs, and the key thresholds and notifications expected for any cloud spend.
- Optimisation: A recommended set of technical guardrails and proactive actions that teams should consider in order to avoid any spurious cloud spend.
The Cloud Cost Control policy should identify the key owners that are responsible for carrying out the policy actions (consuming teams, FinOps team, Product owner, etc.). However, it shouldn’t cover the CSP specific implementation detail in how to do so. The policy should be complemented by an engineering implementation approach on how it has been adhered to within the cloud providers being consumed.
Finally, the FinOps function should perform regular audits (see example in figure below) of how well the Cloud Cost Control policy is being adhered to within the organisation and take the necessary steps to ensure increased compliance.
Fig. Example coverage of the Cost Control Policy within an organisation
Implement Guardrails for the Cost Control Policy
Once an organisation has established a Cloud FinOps/Cost Control Policy, a key set of controls from the policy can be implemented as code-based guardrails within the foundational cloud platform implemented (i.e. Landing Zones).
These policies should be versioned, tracked and governed, allowing engineering teams to either enforce them or notify the adequate stakeholders when they have been breached (eg. the budget and alerts set, notification thresholds, enforced tagging patterns, etc). We shall cover these in an upcoming article, going into further detail on the implementation techniques and tools that organisations can use to implement and practice FinOps effectively. The implementation of these guardrails should consider:
- Approved set of tags applied to the cloud environments provided to application teams
- Organisational level policies ensuring actions that would be performed in the scenarios where guardrails aren’t being adhered to
- Budgets and alerts
- Self-service visibility for engineering teams
Establish a Cloud Benefits Framework
As talked about in the ‘What is FinOps’ section, cost management is only one key pillar, with the other being the ROI and benefits of cloud consumption.
While implementing a set of financial guardrails on consuming cloud platforms provides a cost management and reporting approach, a parallel effort is required to establish a framework that helps articulate the benefits and ROI that result from your cloud programme.
Traditionally, business cases are loathed as the key blocker and inhibitor for experimentation. It's the FinOps functions’ role to work with the key value streams within the business to help establish the parameters for a successful cloud business case and the benefits that an organisation intends to track for the applications/workloads/products onboarded. These could be:
- Technology focused:
- Reduction in excess rework
- Licenses saved
- Cheaper infrastructure compared to on-premise
- Innovation focused:
- New business opportunities uncovered
- Increase in Customer NPS by x%
- New customers requests and features fulfilled
Alternatively, one can choose to classify these by tangible or intangible benefits, but the key point is having a benefit framework that helps product/application teams articulate their WHY, with measurable data points that can be tracked.
The best benefits frameworks that Contino recommends are those that can map your organisational values, to business initiatives to engineering efforts. Just like the best OKRs are those that are aligned to organisational objectives, an effective cloud benefits framework is no different.
Identify Your Cost Drivers and Metrics
A fundamental part of any business is understanding your cost base and being able to put some science behind predicting any increase in operational costs that might eventually impact the bottom line.
While any cloud cost management tool helps you identify any increase/decrease in cloud spend, the business drivers behind said fluctuations are often left unidentified.
We recommend that FinOps teams identify and list the key cost drivers that application/product teams can help attest to, such that these can be traced back to business benefits and outcomes. To further simplify the process we can narrow down the cost drivers to ultimately four factors that drives changes in the cloud service provider bill:
- Consumption of new services
- Scaling consumption of existing services
- Choice of financial model for purchasing services
- Suitability of the chosen architecture
Any acceptable change to these drivers should be driven in turn by the business objectives of an application or product team, with an associated metric (listed in benefits framework). By forecasting how we expect these metrics to change, we can better inform our forecast cloud costs.
Fig: Based on defining cost drivers this way, we can trace any unexpected expenditure to a root cause
By assessing what the business goals of an application/product are and the planned technical implementation, teams can come to an assessment of:
- What factors are likely to drive cloud consumption
- How these are likely to change over time
- To what degree these can be controlled or predicted
Categorising these metrics by risk gives FinOps a greater ability to forecast what the future of cloud spend will look like. We typically use two categories:
- High risk drivers: variable and unpredictable and outside of our control
- Low risk drivers: controlled, predictable and consistent.
Establish a Financial Trace to Your Customer Experience
Just like engineering teams use application tracing to profile, monitor, diagnose and pinpoint any application failures, FinOps teams need to be able to trace cloud spend.
Aligning your cloud spend to the benefits and cost drivers as part of a cloud business case helps do exactly that.
A key advantage that cloud spend has compared to that of on-premise hardware assets is that one can instantly get a detailed breakdown of the services being consumed, the unit price, the duration of consumption etc., presented by an ever maturing set of cost management tools that provide a very rich data set in near-real-time.
Fig. Aligning business drivers and metrics to the cost drivers that would impact the cloud spend
A cloud business case brings together the key data points of cloud spend, benefits and cost drivers to understand the forecasted spend by an application/product, the actuals being tracked in real time and projected spend based on consumption volume or business metrics.
It is here where the FinOps and Product teams can now start to answer key business questions that are truly game changing such as:
- Why is our cloud spend more than expected?
- What was the cost to increase the availability of our service
- How much did on-boarding an additional one million users to our service cost us?
You can trace these back to each one of the cost drivers, and verify what has caused the consumption to vary based on the business drivers and metrics that are being measured.
Bringing It All Together
The pièce de résistance in achieving true FinOps mastery is to bring all the information captured above in a format that is tracked throughout the lifecycle of the applications and products hosted in the cloud.
This covers the whole lifecycle from when demand was registered, through when the product is being developed, to the point when it starts serving customers and as it evolves based on customer feedback.
This means that all the key functions within your organisation (eg. a Cloud Centre of Excellence) have a key part to play in ensuring that the right processes and data is being captured throughout the product development or application development/migration lifecycle, including:
- Demand management: helping capture the business metrics and initial forecasts of the application/product
- Application/Engineering teams: making sure the adequate guardrails are implemented, ensuring the cloud spend is tracked and monitored and taking a financial sound approach to cloud architecture and spending accordingly.
- FinOps team: guiding and educating all consuming and impacted teams (perhaps as part of a Cloud Centre of Excellence) around the importance of FinOps and the quality of the output expected.
- Platform Engineering/CloudOps teams: coding the mandatory guardrails that consuming teams have to adhere to by default, further reducing the implementation activities that consuming teams would have to perform.
The output of bringing all of the above together can help multiple teams, including executives, in being able to make data-driven business decisions that can take into account cloud financial data, business metrics, organizational and consumer insights.
Fig. An example business case that combines Cloud spend actuals , the initial forecast, the comparison with on-prem hosting costs, the drivers to track and the business benefits/metrics..
Taking It One Step at a Time
While it’s often quite easy to try to shoot for the stars, we always recommend an organisation taking baby steps in making sure they are successfully building their in-house maturity when it comes to establishing a successful FinOps function. As a matter of fact, FinOps doesn’t have to be a dedicated function on day one, and should grow hand in hand with an organisation’s cloud maturity.
As recommended by the FinOps foundation, starting off with the key building blocks and fundamentals practices is more important than building a dedicated team that focuses on FinOps. The FinOps maturity framework helps you identify what those baby steps should be, whilst trying to drive an organisational change that aligns one’s cloud adoption with product focused thinking.
Fig. A FinOps Maturity Framework
Additional Considerations
While the core building blocks listed above are critical in making sure you set up your FinOps function for success, there are some additional considerations that organizations have to plan for as their aspirations for cloud adoption scales:
- How does one integrate all of the above as part of a demand management process?
- With Cloud CoE’s increasingly looking to offer shared services to consuming teams, how are the financial approaches of chargeback and showback implemented?
- Where does FinOps best fit within your organisation, and how does it interface with key functions such as a Cloud CoE, Cloud Operations and one’s existing Finance and Procurement teams?
- What does a FinOps team/function consist of, and how do you build one?
- What tools should one use to drive towards a high performing FinOps function?
- How does a FinOps team work within a multi-cloud scenario?
- How does the role of a procurement and finance team evolve as part of FinOps function?
We shall consider these in an upcoming article, where we look at how an organization can take the core foundations listed within this article in order to move towards a fully fledged FinOps function that is key part of one’s Cloud Adoption strategy.
Conclusion and Key Takeaways
- FinOps aims to bring together all key functions involved in planning, procuring, consuming, managing and governing cloud services in order to make the right decisions and trade-offs when consuming cloud.
- FinOps is meant to drive a shift in culture in cloud financial management, combining aspects of financial management, procurement, cloud operations and demand management in driving a more efficient cloud cost management and ROI framework whilst aligning one’s cloud adoption journey to business value and customer experience.
- Establishing a financial trace of cloud spend to the benefits and cost drivers as part of a cloud business case helps create a critical feedback loop to drive the appropriate business decisions.
- Designing a FinOps Policy helps establish a common control set that employees can attest to and engineering teams can implement as guardrails to achieve the financially controlled consumption of cloud within your organisation.
- Taking small steps towards establishing a FinOps discipline is more important than having a dedicated FinOps team. The FinOps Maturity Model can help organisations understand key steps to take and grow your FinOps maturity in-line with one’s cloud adoption and organisational maturity
