What’s next for FinOps ? FinDev !
Mindset, tools, skills, best practices… Today, the wide and new playground of financial optimization in the pay-as-you-go domain is being covered from all sides: new players and frameworks, books, training, certifications and so on…
A FinOps Foundation was even created in the US in February in 2019 (what would IT do without all its foundations?) as well as the first French Meetup group on the topic, of which Timspirit is glad of being a founding member and which is waiting for you!
The relevance of cost control is obviously not to be questioned. At a time when large and small organizations are struggling to define their FinOps approach practically, what could we say about its future if we raised our heads ?
Go back to the origin first
The optimization and control of expenses did not emerge with the Cloud, or even pay-as-you-go. So why have this term and discipline become so popular in recent years?
In this paper, let’s look at one of the source of FinOps. In this common-sense accounting assertion, let’s look at the first part: IT resources usage.
We all have this kind of curve in mind, opposing over-allocation of resources (leading to waste) on one hand and under-allocation on the other (leading to degraded quality).
All of this highlights the inability to align at any given time the allocation (or provisioning if you prefer) of resources with their actual consumption. In short, the opposition between container and content needs to be actively managed and supported in the enterprise.
The opposition between container and content needs to be actively managed and supported in the enterprise.
The impact of the Public Cloud, especially the generalization of pay-per-use billing, leads to a new momentum to the handling of this content/container opposition for two main reasons:
- It modifies the granularity of the content.
IT resources deployed are more abundant and diverse, easily manageable and can be assembled together.
In short, they can be assigned the 4 properties of the CRUD acronym (Create Resources, Update and Delete Resources, as well as the constant ability at any time to know their properties and status), previously reserved for data management. - It improves its optimization.
The savings can be viewed in near real time. The inertia resulting from large CAPEX investments and their amortization over several years disappears.
For instance, let’s compare the distribution of costs between a legacy on-premise infrastructure (including Private Cloud) and an IaaS Public Cloud with pay-per-use:
Previously, the very high cost of equipment (facilities, energy, consumables, maintenance, etc.) committed the company over several years and had to be renewed at a regular basis by mobilizing significant human resources (managing RFP/Q, technical and legal expertise, purchasing process, etc.). The levers, although existing, were difficult to operate: limited gains whose impact was slow to show up.
Today, these investments are moving away. The big FinOps challenge is about IaaS resources and their use.
Currently, the FinOps tools on the market mostly collect usage metrics from the deployed IT resources and give recommendations about the changes to be made. Right Sizing is king: it’s all about getting the allocated as close as possible to the consumed.
If we make the analogy with AWS services, here is the evolution of a typical infrastructure:
Adjusting EC2 instances, EBS volumes, and RDS databases as needed does not in itself change the container/content dichotomy. We are not far from the waste chase that can also be carried out in an on-prem infrastructure.
Game changer is that the savings are easier to achieve, quicker to obtain and far from negligible.
Evolution to the Serverless
To put it bluntly, it is highly likely that Serverless will end this container/content opposition completely. In this new paradigm, resource allocation will either increase or decrease based on usage. In other words, in the analogy of the glass being half empty or twice too full, the glass will grow as the water level rises.
In the analogy of the glass being half empty or twice too full, the glass will grow as the water level rises.
FinOps generally speaking (practices, skills, culture, tools) will have to adapt and migrate gradually from an Ops/Infra orientation to a Dev orientation. It will be mostly a question of application efficiency and code optimization.
Extending the analogy with AWS, the Serverless service pricing model already leaves little room for hunting down wasted resources.
There are still some signs of this in AWS Lambda (resource allocation, especially the memory allocated to the function — see here for FinOps in Lambda) and AWS Aurora Serverless (allocation per ACU slice, i.e. a Memory/Compute combo — see also this excellent article): it is therefore still possible to fine tune cost drivers related to resource allocation.
But there is a clear trend towards generalizing consumption to actual usage and abandoning resource allocation/provisioning : we will pay in GB, in IO, in runtime, in number of requests… what our applications will actually consume.
We will pay in GB, in IO, in runtime, in number of requests… what our applications will actually consume.
Welcome to FinDev!
FinOps will therefore become a code-centric optimization task devolved to the development teams.
In a hypothetical « 100% Serverless and On-demand » world, FinOps will therefore become a code-centric optimization task devolved to the development teams. Probably with lower gains, as savings are more limited and harder to obtain.
These new FinOps practices, let’s say FinDev to differentiate them, will then have to evolve as well as the tools. New topics will become more important, especially at scale, for instances :
- Which libraries for optimal CPU and memory consumption?
- Shall we consume more CPU and less storage or vice versa for a given Use Case?
- Which data formats to adopt (interesting example here)?
Conclusion
But don’t worry, this hypothetical world is far from existing and you won’t have time to get bored! The IT landscape will always remain very heterogeneous: mix of IaaS and Serverless, mix of clouds (multicloud), PaaS and especially SaaS offers, which also differ in terms of financial management.
Other criteria can — and must — also be taken into account when optimizing expenditure:
- The profile of the applications and their predictability in terms of load (24×7 vs. Business hours, constant demand vs. high variability).
- Purchase options with Reserved Instances, AWS Saving Plans and other Committed Use Discounts over 1 or 3 years
- Service-specific options or resilience commitments
- Lock-in
Financial studies, Business Cases and other Cost Evaluation still have a bright future ahead of them.
Note: Paper initially published on timspirit.fr.
