YES. WE GET IT. Right-sizing, right family, lifecycle policies, detached EBS volumes, underutilized RDS/Dynamo/etc. Everything here is considered "FinOps" best practices. But (and not to offend anyone) any monkey can do that. This is not Financial Engineering, this is (at best) righting wrong configurations based on "OOTB recommendations"
Is it important? Absolutely.
This is what the industry today is defining "FinOps".
But, what is Financial Engineering?
In short - moving from a reactive approach of suggesting the regular FinOps optimization methods to a pro-active approach focusing on design, generating business value, and meaningful measurements. Every dollar designed to be optimized from day one will save double - the work post provisioning, and by definition - ongoing waste until it's solved.
Pillar I - Visibility and monitoring (What)
The beginning of the journey is to understand what we have at hand. We need to integrate with our monitoring services (internal and external) and create an overview of what is currently running. Cost dashboards? Nice to have. Utilization dashboards emphasizing actionable items we can generate? Definitely.
Questions at this phase (besides the obvious):
Do I know what is the infra team roadmap?
Am I aware of new agendas and part of the design process?
Do I have integration with the business side? Is it (at all) measurable?
If not - how can we test the business value?
Can I generate action items from the information presented to me?
Can I generate action items from the dashboard I'm building?
If your dashboards are only "FYI" - it won't give any value in the long term. If your dashboards generate action items it generates value. No one optimized anything looking at dozens of "Usage Types" or "SKUs" and guessing what is non-optimized.
To understand what is running and how much it costs you have proper visibility OOTB from the different clouds (Cost Explorer, reports in GCP, etc.). For actionable dashboards - you have to bring the engineering side to the table.
Pillar II - Design and optimization (Why)
Once our business process is in place, and we're aligned with the business. we want to start reviewing the environment. We can take the actionable dashboards we created and delegate cost optimization agendas to the different teams based on severity, the cost impact, the optimization effort needs (AKA the operational cost), etc.
Examples of creating actionable dashboards can be:
Kube utilization dashboard for pods resource consumption, the difference from allocated resources (or: waste), and pod provisioned in the cluster correlated to the traffic they're getting.
Instances utilization dashboard for resource consumption which we can filter based on user-defined tags (AWS/Azure) or custom labels (GCP) in which we can test not just a single resource, but how a cluster behaves, how a business agenda is utilizing its resources, etc.
Object storage access patterns to alert on wrong classes
etc.
The backend of those dashboards should implement some alerting mechanism that will notify us automatically about the waste that occurs based on our own algorithm.
It can be a 45% difference between allocated resources to the utilized resources on the pod level, (free_mem > 75% and cpu_consumption <20% on the cluster level), etc.
Pillar III - Education (How)
Once we have everything, we can start delegating the cost KPI to different teams. Our goal here is not to be the dutch boy - a boy who plugs a dike with his finger - our goal is to create a framework in which the company can onboard the financial KPI on the engineering side.
The process itself involves better design before provisioning, implementing an architecture that can solve our problem in a more optimized way, creating a "Newsletter" that share success stories of engineers applying that KPI in their day-to-day, as well as financial incidents that have a post-mortem process and treated as a production incident.
We need to create that framework to treat the cost as an "Engineering Best Practice" - you wouldn't write a wasteful code, why would you run in a wasteful environment? From cost terminology, we shift the responsibility to the engineers, because it's just bad engineering not to apply that KPI.
Change the minds and hearts of the company, create that framework that people know where to look and what to do, and delegate that responsibility because it's considered "good engineering". This is how you implement a culture, and this is why Financial Engineering is so much different from FinOps - we're not doing operations. We're engineers.