I had a really organized map of things in my head I’d like to tell my younger self about FinOps last night. This morning it is gone. Let this be a lesson to me - jot some notes down. It was a primer course, from the point of view of a data person who was placed in charge of a FinOps practice - how to think about FinOps, what data are you going to need, what do the terms and costs mean, etc.
So what is FinOps?
Well, it’s the driest sounding topic that I’ve ever found incredibly interesting (so far). Essentially, the cloud has upended what used to be an agreeably distant relationship between Engineering teams and Finance teams.
If an Eng team needed to launch a new thing to the young internet in the year 1999, they went through a procurement process with their employers Finance team. A server was purchased and placed in a rack somewhere and the interaction was largely done - Finance depreciated the hardware as they saw fit and Engineering optimized the workloads on that hardware as they saw fit. It was paid for, who cared after that?
Well, The Cloud screwed all that up. The cloud allows engineers to directly spend company money by pressing a button. Pressing buttons and launching resources without asking anybody is fun af, so Eng did it, lots. Some time later the bill comes to the old IT team or to Finance and friction entered the chat.
Finance could no longer control IT outflows. Engineering could no longer be totally ignorant of the company money they were spending. Both sides needed more information to do their jobs and make better decisions and into that dysfunctional gap grew the practice of FinOps.
How does FinOps Op?
“Financial Operations” is, I guess, what it stands for. See, cloud vendors - AWS, Google Cloud Platform aka GCP, and Azure (Microsoft’s cloud) - don’t make their money by making it easy for an Engineering team to understand the impact of their hardware decisions. They don’t make their money by making it easy for Finance teams to surface anomalies in spending. They don’t make their money by generating understandably reporting and forecasting tools. They make their money by selling Moar Cloud. And turns out one of the easiest ways to sell Moar Cloud is by making all of the above as difficult as possible!
I’m being cheeky and slightly humorous, or so I tend to think over my morning coffee. Truth is, these are huge suites of very complex products, upon which the largest companies in the world are:
- running their enormous, heterogenous workloads
- across dozens or hundreds of products within the cloud vendor’s catalog and
- asking to be able to report on those any one of these workloads in a manner that fits their organization.
So what pops out of these requirements is typically a very granular bill with millions (or billions, so I hear) of line items. Those line items were generated by the various teams that built the products within the suite, so they tend to be pretty heterogenous themselves in terms of data points and consistency.
This is where FinOps finally steps in. It’s basically a heavily data-backed job of informing both sides of the equation in as close to realtime as possible about the workloads and the financial impact of the workloads.
I intend next chapter to talk about “reservations”, which is part of the bread and butter of the cost management and therefore FinOps domain.