Cloud computing has made it easier for development organizations to deliver software and updates more rapidly, by empowering engineering teams to autonomously create the environments they need, add more storage and leverage microservices through containers and Kubernetes management.

But there is a downside. Cloud costs can spiral out of control if not watched carefully. And one way to tackle the issue is through the implementation of FinOps – running your IT organization with an eye on the spend.

FinOps is a nascent discipline that’s about enabling data-driven decision making in order to determine how much to invest in cloud resources, and where to use that investment. And the question of who’s responsible for monitoring and controlling cloud spending is really on everyone in the organization – not just on IT.

J.R. Storment, executive director at the FinOps Foundation – a program of the Linux Foundation – prefaced his comments by saying that spending on cloud services and environments is not a bad thing. “FinOps isn’t about saving money,” he said, “it’s about making money. Cloud spend is not bad, and spending more in cloud is not bad.” He cited the COVID-19 pandemic as a catalyst for the massive acceleration in cloud spending.

But, there’s a difference between strategically spending in the cloud, and letting cloud costs get away from you. Storment explained how cloud costs can quickly grow if there’s no specific effort in place for ongoing cost monitoring. 

For developers, cost is a new metric. “Historically, engineers wrote code, and they went to Ops teams who went to procurement teams to buy servers and racks, and they just showed up,” he said. “Now, engineers click buttons to procure resources, they write infrastructure as code, software as code, and money gets spent without any controls. And again, that’s not a bad thing, because it enables faster delivery and better features. But ultimately, the shift for engineers was probably the biggest because they historically haven’t had to consider cost as part of their day job. They’ve got all these constraints. It’s like, I got time, I got delivery, I got security, I got performance, I got reliability, all these things. And now, include cost.”

While it’s easy to say that organizations can shift FinOps left so developers are more conscious of what they’re creating and spending in the cloud, Storment opined that cost containment is an organization-wide undertaking – even if ultimately it’s the software developers who are best positioned to ensure costs are contained.

Storment noted that when he first started having discussions regarding FinOps in 2018, it felt like an “us versus the engineers” standoff, since costs were not something developers usually had to consider when writing code. Back then, FinOps was more of an isolated discipline, with a team pushing best practices, he said. “And now, in a lot of ways, the FinOps transformation … is sort of like the security teams in organizations,” he said. “Security teams don’t do all the security, but they’re there to establish the best practices, radiate out the heat of best practices around it, but ultimately everybody’s responsible for it. The product owners, the finance people, the engineering folks, everybody’s there to manage it over time.”

When it comes to needless cloud costs, the first place organizations look is at pre-production staging and test environments, which often are spun up by engineers who, when they’re done, don’t shut those environments down. In large organizations, with many autonomous development teams, it’s difficult to track all of those cloud instances. “I was working with one of the big technology unicorns a few years ago, and by looking into their cloud spending data, they immediately realized they had literally $200,000 a month in these multiple dev environments that have been sitting there for months unused. … That’s the bad story that everyone talks about” when it comes to wasted cloud spend. 

But he added that having organization-wide communication about costs, and considering costs when architecting solutions, is where the spend should be considered. Again, not always easy to do. “Engineering and finance, they speak very different languages. And they have very different motivations. And they have very different focus areas.  So it’s,’how do we get them working around using different app data, and using the business decisions to make over time?’ Ultimately, it’s a distribution of responsibility. Who’s responsible? It comes down to everybody.”