It has been estimated by Gartner that cloud spend in 2021 will grow an additional 23.1% to a value of $332 billion, a $60 billion increase from 2020. With the omnipresent existence of engineering teams elevated cloud access, automation and devops, engineering teams are now able to rapidly and autonomously spin-up new resources and release new features and services into production on a daily, sometimes hourly basis. As a result, organizations of all sizes have realized that cloud financial management and accountability is an absolute must.
If your organization like the majority, then keeping track of cloud spend at a granular level, and measuring against key business metrics (unit economics), is not achievable. Ideally these costs should be compared against some of the following examples: Revenue, Sales Volume, Paying Subscriber Growth, Decreased Internal Operational Costs and efficiency, etc… Each product line, division, cost center, or other, should be able to know their share of the overall cloud spend; the more granular the better. It is imperative to define and track these type of metrics in as near real time as possible, making them visible to anyone that contributes to these costs, or is responsible for paying them. Typically this will spread across top-level executives, product owners, managers, architects, engineers, and more.
The FinOps Organization is a not-for-profit committee that is part of the Linux Foundation, and in short, “provides a framework that brings financial accountability to the variable spend model of cloud, enabling distributed teams to make business trade-offs between speed, cost, and quality”. Essentially, everyone takes ownership of their cloud spend. This is phased approach (crawl, walk, run) and is implemented with guidance from an appointed FinOps Practitioner and a supporting team that typically consists of cross-functional stakeholders from the business and technology sides. In order to maximize cost optimization and financial accountability, larger organizations with multiple clouds and product lines will require more time and discipline, and possibly multiple FinOps teams.
Only 15% of organizations regard their FinOps program as being “mature”, and those who are not, are unaware of their cloud spend, are not aware of their costs until it’s too late, and have no consistent cost optimization processes across cloud initiatives. Cloud spend optimization and cost accountability need to be a key pillar of the DevOps, Agile, and Lean practices, and in my opinion, should also be part of the framework for building High Performing Teams. Just as Agile and Lean processes provide for cross communication, accountability, real-time reporting, product based teams, and more, FinOps greatly overlaps with many of these aspects.
As the focus of this article is to only present a cursory introduction, I will say that the end goal of a FinOps practice should be for product teams to understand that everything has a cost, designing, building, deploying, supporting, hiring, training, etc… all of it incurs a financial cost. It is important that non-technical stakeholders become a little more tech-savvy, and the technical stakeholders become a little more financial-savvy. Technical teams need to understand at a minimum capex vs opex and how this can impact architectural decisions. For example, if a heavy investment in private data center capacity (capex) with an amortization schedule of a few years already exists, then it may not be practical to deploy a new app to the cloud and use “pay as you go” (opex) services. In addition, technical teams should understand what a charge-back is (Costs are directly tied to a budget or P&L) as apposed to a show-back (Costs are allocated from a separate and usually shared budget). Non-technical teams at a minimum, should understand the nature of product development for the cloud, a general understanding of agile, devops, the “cafeteria model” of the cloud, and how these have greatly impacted the “Proverbial” procurement process as we know it today. Engineering teams need to be able to deploy as necessary, and not be blocked by drawn out processes to approve these initiatives.
How applications are built, deployed, and supported can greatly effect cloud spend. POs/PMs/Architects/Engineers need to include cost into their thought process when building applications or adding new features to existing ones. For example, the addition of a new microservice can and in most cases will increase cost, and therefore the added costs should be weighted against the KBMs mentioned earlier. Cost reduction is not always the right thing to do, there may be ways to reduce cost but due to other business metrics it could have negative impacts in other ways.
The “True North” of Finops is to vet every effort that goes into product development, and to understand how the financial costs of a new feature, architectural change, hardware upgrade, new hire, etc… add value. It is strongly recommended that a mini-business case is done for every initiative in order to determination a more granular ROI on each of these. For example if you upgrade a new server, add a new set of lambda functions, build up a new team, or add a new product feature, you should be able to compare the cost incurred to the value it will or could (based on historical patterns) bring. For example, if your monthly cloud spend increases an additional $500 as a result of a new application feature being added, but that feature is not getting used, generating more than $500, or bringing more value to your customers, then was it really worth it?
I hope to provide in future posts, a further analysis of the selection and setup of your FinOps team, necessary steps to be able to segment and allocate costs at a granular level through the use of tagging and tagging strategies, how to adopt a real time reporting strategy, and the culture changes needed for a successful FinOps adoption.