Seriously? Not everything needs to be xxxOps. And if you need a "FinOps" team to manage your cloud cost, I would argue that there's something wrong with your whole damn paradigm.
I kind of agree that I don't love the term. That being said it has become the de-facto way that people refer to the space and practice. The FinOps Foundation hyped up the term and space quite a bit which they deserve credit for but do wish there was a better name :)
> if you need a "FinOps" team to manage your cloud cost, I would argue that there's something wrong with your whole damn paradigm.
How would you manage your cloud costs if you ran a company of, say, 4,000 engineers? Balancing the needs of delivery teams to build their technology with the needs of the business to manage costs. Do you think every single team should directly report their cloud costs to the CFO? Or at that scale does it make more sense to report costs to another individual? And when that needs to scale, maybe we give that individual a team?
I think for most smaller orgs you can get away with an off the shelf product to surface some more basic cost stuff. In relatively large engineering orgs, you're looking at optimising on stuff like cross-region calls to save millions a year so yeah there's a good reason to invest in cloud cost management.
> And if you need a "FinOps" team to manage your cloud cost, I would argue that there's something wrong with your whole damn paradigm.
FinOps isn't a dedicated job but something a cloud engineer can do as part of its job. In the same way that DevOps doesn't need to be a dedicated function itself.
And as for the cloud... Yes that turned out to be a whole lot expensive for companies than predicted - and you share compute with anyone so that dualcore CPU isn't always that fast. But cloud is also flexible and that is where FinOps comes in.
Sadly it’s one of the only ways of getting through the thick skulls of dumb middle management that seem to always be leading software projects despite having no technical background.
If it’s not got a familiar marketing thing going on, they’ll refuse to acknowledge it even if their devs are practically begging for it.
What about a 5k engineer org. Having 10 finops people would make it 0.2% of the workforce. Those people help surface the information for other teams to act.
Start with educating architects and developers on how to measure and optimize costs. They are the first point (and probably cheapest) to optimize costs.
Later, FinOps role can evolve but expectations will mostly be reactive.
I don't care for this paradigm because the architects and developers likely have very little context upon which to base decisions. There are tradeoffs between time to develop, cost to run and reliability that it runs at. Where you want to make those tradeoffs is more of a business decision than a technical one.
A high margin product might want to launch quickly and reliably, costs be damned. Another product may need to run as cheap as possible, even if it's unreliable and takes a long time to develop.
FinOps translates business goals into technical requirements. It's not just cutting everything down to as cheap as it can be.
at even $70/hr of employee cost + $200/employee per employee training cost + at 20% annual employee churn + added salary payout to hire devs who are cost conscious.
Lets see how long that is cheaper than just hiring 2-3 finops folk and just put them in every room where the software architecture is being designed for new services and make them drill down hard into team on what to avoid.
Not to mention it’s a better way to do things in the Single Responsibility Principle that most great teams follow
if everyone is responsible for cutting costs and optimizing.
