FinOps — The engineers journey
First there was DevOps
Coming from the area of infrastructure but having a solid background in development, I remember it was around 2009 I noticed a movement that encouraged developers, infrastructure engineers and operations to start using the same tooling, to start talking the samen language, to really collaborate. It was the start of the DevOps movement and it was awesome.
Then there came FinOps
I think it was two to three years ago when I bumped in to a similar movement, the FinOps foundation. The FinOps foundation tried to bridge the gap between engineering and finance departments. Without realising it at first cloud adoption lead to a complete shift in responsibilities. With an easy made mistake, an engineer could cause a huge cloud bill, while the finance department wouldn’t even notice anything until the bill came in.
My first steps
As Spiderman taught us, “with great power, comes great responsibility.” For me that meant we as engineers would need to take ownership, would need to take responsibility but also would need to collaborate. We needed a way to talk to finance about the cloud, about the impact and most of all about the costs associated with it. I joined the foundation, picked up the book “Cloud FinOps” and started studying for my FinOps Certified Practitioner exam.
So what’s in it for me?
Coming from an engineering background I’ve always been a big fan of concepts as infrastructure as code and automation, and I started looking into how these concepts would fit in the concept of FinOps. It turned out they were a significant part of the solution. With Infrastructure as code we could easily build and break down environments, so we wouldn’t need to keep infrastructure we don’t need running. We could define it, and easily build it on demand.
And then, there’s the community
What’s interesting is what happens with FinOps automation. There’s a lot of tooling out there that can rightsize your resources, can shut down unused resources etc. The big question is, how does that ever play well with environments completely built using infrastructure as code? It was somewhere in September this year, someone on the FinOps slack came with a question about automated FinOps tooling and choices. It quickly became a great discussion about automation, infrastructure as code, but also concepts like technical debt and the pressure different stakeholders can put on any FinOps team.
A few days later we were asked to continue the talk and turn it into a podcast. We picked a time and Jérémy Nancel, Joe Daly and me had a great talk about all of this. The result can be found in the 25th of October edition of FinOpsPod
