Getty Images
SADA's FinOps lead sheds light on an emerging field
In this Q&A, SADA's Rich Hoyer discusses the fundamentals of FinOps, why it's gaining visibility, and the conundrum of cloud technology and its value to customers.
FinOps, or cloud financial operations, is a nascent practice that dives into the nagging questions of cloud cost. IT services firms have begun to launch FinOps services as an extension of their cloud advisory offerings.
Among those firms is SADA, a business and technology consulting firm based in Los Angeles. The company unveiled its FinOps group in May 2021 and appointed Rich Hoyer as director of customer FinOps. Previously, Hoyer founded the FinOps professional services practice at cloud consultant Onica and, prior to that, helped clients manage their cloud spending at Cloudability.
At a time when cloud value has been called into question, Hoyer takes a nuanced view. He weighs cloud costs against the technology's potential to drive revenue well beyond any cost premiums. "There are complaints out there that cloud is more expensive than on-premises infrastructure," Hoyer said in an interview. "But to ask whether it costs less or more is to ask the wrong question. If a workload is more expensive in the cloud than on premises, that could be a good outcome if the cloud technologies generate incrementally more revenue for the business on top of the cost premium."
Following are excerpts of that interview, edited for clarity and length.
To start with the basics, what is FinOps? And how does it differ, if it does, from cloud cost optimization?
Rich Hoyer: FinOps encompasses optimization, but it's broader than that. I like to say that FinOps is the discipline of everything to do with managing the spend on public cloud. Obviously, optimization would naturally fall in there. There's a whole discipline around visibility and reporting. If you think about a public cloud billing file, it's kind of like the world's most terrifying phone bill. And there's a whole art and science around how you manage that and how you figure out how to pull out the reporting that you need.
There's another concept we consider to be distinct from reporting, which is visibility. And the way they're different is, visibility is having real-time insight into what's happening. Imagine, for example, you have an engineer who is responsible for having generated spend by virtue of using a variety of resources. We need all those individuals, who are what we call technical responsible parties, to have as real-time visibility as possible into the spend they are generating. And that's a distinct concept from reporting, which is more analytical in nature. It might be for compliance reporting, for example -- tax or regulatory reporting. But also, if you think about managerial decisions, [there's a] managerial accounting component of it. All these stakeholders need a way to get visibility into how the spend works.
Rich HoyerDirector of customer FinOps, SADA
There's also a feedback loop between visibility and reporting and optimization. There's a very specific way that you will want to run reports in order to figure out what the art of the possible is as it relates to optimization. So, some of these disciplines sound like they're a little bit distinct, but in many cases they're interrelated.
And then there's another component around budgeting and forecasting, which we consider to be part of the discipline. And when you add all those up you have FinOps.
What's driving FinOps?
So, why are we hearing a lot about FinOps now? Is it a fairly recent development? Have factors such as last year's mass adoption of cloud brought it to the forefront?
Hoyer: I think there are two or three reasons why this is becoming such a top-of-mind topic. As more and more workloads move to the cloud, we have more and more consumers of public cloud who are realizing the challenges associated with managing spend on public cloud. And in parallel with that, you have practitioners who have come together to form the FinOps Foundation, a global, central clearinghouse for the best FinOps practices. I think all these practitioners realized that there was a lot more power in working together and sharing knowledge and standardizing practices. I think the Foundation has probably gotten a lot of attention. [There are] more and more cloud workloads coming in, and, therefore, more practitioners learning the importance of doing this work well.
And then also you have vendors like Google who have become premier members of the FinOps Foundation [and] who are also very publicly emphasizing the importance of doing this work well.
Are there any FinOps issues that are specific to Google Cloud? Or is it more the case that these are general practices that can apply to any type of cloud?
Hoyer: I think the vast majority of best FinOps practices apply to any cloud. The nuance with Google would just be the type of services that they offer, and the way they bill for them is slightly different. But that doesn't imply that the practices of managing it really differ materially. I think something like 80% [to] 85% of the practices directly translate across the cloud providers. And you have a 10% or 15% variance depending on how they bill, structure the billing files and the type of products that they offer.
I will say one major advantage that Google has over the other clouds is that they have a very easy means of taking the billing data and putting it into what they call the BigQuery offering, which is this large relational database offering. And the fact that that's just an easy automatic process means that doing very deep analytics against the Google Cloud data is easy out of the gate. If you have practitioners that know how to query a SQL database and have good SQL skills, then they're way ahead in that sense.
FinOps services
From the SADA point of view, what are the main deliverables of a FinOps engagement?
Hoyer: It really depends on the client need. The first thing we want to make sure of is that all of SADA's customers benefit from the standardization of practices across the different teams that we have, so they never necessarily need to engage the FinOps practitioners themselves. Rather, we want to make sure that all of the teams, whether it's support folks or technical account managers, are benefiting from each other's best thinking and we standardize on the best practices and bring in the best thinking in the foundation. So, there's some base level of FinOps discipline that all the customers will benefit from.
We're then going to have a professional services offering for clients that have needs that would exceed the standard ongoing operations of a pretty smooth [cloud governance] operation. Imagine a customer that was either fairly new to the cloud or had been in the cloud for a while but had not set up their own FinOps team internally. One of our main focuses will be to enable our clients to establish those teams. What does that entail? Well, the first thing that entails is helping them to recruit folks internally that would do that work.
It's more typical that the FinOps team will actually be a timeshare, a fractional share of people who have other day jobs in the organization. You might have some folks from accounting or some folks from the technical side, finance and so on. What you do is you say, 'You're now part of the FinOps team, and X hours of your week you're going to be doing' all the things noted earlier: helping to set up the tooling so there's good visibility, helping to do good reporting, having sort of a rolling efficiency analysis.
What we could do is come into a client who didn't have that team, help them identify who the right individuals are and begin putting in place the practices alongside them. It's not doing for our clients; it's doing with them. We'll create run books to leave with them, so that they then have a means of carrying the process on after we're out. This type of engagement would be something like a four- or five-month engagement. And I like to joke that, like any good psychologist, as a FinOps practitioner, my job is to get you out of my office as fast as possible.
Realizing vs. documenting cloud value
I've been reading a lot of cloud studies and reports over the past 18 months and a common theme is a very high percentage of cloud adoption and a fairly low percentage of companies that think they're getting the most out of the cloud. Is FinOps a possible antidote to the issue of obtaining full value?
Hoyer: I think there's a mixture there. When people talk about the low percentage of folks that feel like they're getting great value, more often what we see is people who are not measuring what the return on investment of cloud is, relative to other infrastructure. And that's pretty complicated work. In that sense, it's very much related to FinOps. If you think about any workload, how do you decide whether it should be migrated or not? And the answer is, you should always look at whether the cloud offers unique technologies, or the elasticity of the cloud or the geoflexibility of the cloud. If those differences in the cloud infrastructure will fundamentally change your business in a way that exposes new opportunities, that is a good argument for adoption in the cloud as opposed to being on premises.
Let's say [customers] are migrating. They're going to do an analysis and say, 'What does the on prem cost me? What does the cloud cost me?' And if those numbers are anywhere near, a lot of times they'll say, 'Okay, let's go to the cloud.' That's not the same thing as measuring the return on the investment. Because our return on the investment will be, 'Look at how our revenues changed because we were in the cloud.'
Common examples of how revenues can be enhanced: One is speed to market. Do we have a way to, for example, quickly bloom a whole bunch of resources to do that -- research and development -- to get something to market faster? And when we do, let's say you accelerate your revenues by months or a year.
How do you measure the value of the return on that investment to that organization? We don't see a lot of folks doing that. We need for more people to do it so that they can quantify when that cloud workload was, and was not, a positive investment -- assuming it was even more expensive.
What they're saying is, 'We're having a hard time quantifying the value.' That's not the same thing as saying, 'We don't see that value.'
Most of what I see in my client base is an intuitive understanding that [cloud] absolutely is adding value, but it doesn't mean they can quantify it. There's a big difference between those who can document that they've achieved value from the cloud, and those who have achieved value. Many more have achieved value than are documenting it.