StormForge Fireside Chat Podcast | Episode 2

Mike Fuller, Chair of the FinOps Foundation Technical Advisory Council and co-author of “Cloud FinOps,” speaks with us about the issues addressed by the FinOps Foundation and FinOps at large. We talk about how users and members get their footing, how it differs from org to org, and the types of tooling and solutions people use to get a hand on their cloud financial awareness.

NOAH: Hello everyone and welcome to today’s session of the StormForge Fireside Podcast.
This week we have a slew of guests as we are talking about pain points. We’re talking about their identification, and how they lead to solutions and products and all sorts of various things.

I as always am your co-host, Noah Abrahams, Open Source Advocate here at StormForge, and my other co-host…

CODY: Cody Crudgington, leading Professional Services Customer Success at StormForge.

NOAH: And with us today we have, as a pleasure, Mike Fuller, co-author of this wonderful book “Cloud FinOps” and the Chair of the Technical Advisory Committee, is that correct, of the FinOps Foundation.

MIKE: Yeah, Technical Advisory Council.

NOAH: So, why don’t you tell us a little bit about yourselves, Mike?

MIKE: Yeah, my name is Mike Fuller. I’m a Principal Engineer at Atlassian. I’ve been there for about nine years. I live down here in Australia, so nice and far away from all those people in the US who are hopefully watching. But yeah, so I’ve been at Atlassian and doing sort of cloud financial management within Atlassian for sort of six, probably seven or eight, years now actually. Sort of being active in this space including the FinOps Foundation as an advisory council there and also on the board. And then yeah of course co-author for the book with JR Storman.

NOAH: Fantastic. So we’ve got a few different guests this week. We’ve got some vendors, we’ve got some end users, but you’re coming to us as part of a foundation which is an interesting way for a pain point to manifest itself. So let’s start with how that happened. Why does the FinOps Foundation exist and what was the pain point that spurted into existence? What created that?

MIKE: Yeah, so there’s a bit of a I guess a little community of public speakers that always in this space talking about cost optimization back sort of 2015, 2016. So we all sort of knew each other on the circuit of talking about this topic of optimizing cloud costs and generating cloud savings, and I think that we sort of collectively understood that at the end of those sorts of talks, you would be talking about things like reserved instances and committed use discounts and all the sort of levers you could do to save money, and you’d often get people coming up at the end going like they get it. They get the levers, but they’re trying to figure out how to implement these savings programs within their organizations and they were struggling to get the commitment from the orgs that they were working at to sort of give them the time they needed to pull these levers.

So collectively, we sort of stood back and realized that talking about cost optimization is really just one piece of this sort of bigger puzzle that people need to implement cost efficiency within an organization. And so JR and I got sort of really talking about if we could get a group of experts that are successful in this space together and build sort of a community or a foundation to generate sort of the best practices, sort of what’s common across all these people that are being successful, and guide people getting started in this space on how they can convince their org to buy in, how they can set up you know a team effectively, and really talk about the bigger picture of this story of just you know whereas we had been just focusing on that cost optimization piece.

NOAH: So is the FinOps Foundation today, you talking about cost optimization – is it just about saving money or are there other factors in play that come into all of the visibility that come into all the understanding about your costs?

MIKE: Yeah, so that was one of the big reasons for moving away from the term cost optimization and choosing to create a new term, FinOps. We wanted to sort of separate ourselves a little bit from just this cost optimization of the talks from previous past, but also to create a new sort of word that we could pin sort of this bigger picture story against. What we were trying to say was that cost optimization would be an outcome of good FinOps practices, but it’s not the you know edges, all the edges of FinOps.

FinOps talks about cost efficiency really is the language we wanted to transition to versus cost savings. And JR does this in a nice little saying and I hear him talk about the idea that the dirty little secret of cloud is the cost will always go up. I think what he was trying to say with that is that quite often even though you have really good savings programs within your FinOps teams, that your consumption, your growth, your development of innovation inside the cloud will usually outstrip that amount of savings you’re generating. So while your bill is going up, but you aren’t generating bigger savings, and the only way to really measure that is to look at the actual cost efficiency – how much cloud are you getting for your dollars spent.

CODY: Okay interesting. So, what are some of the other outcomes of implementing these FinOps practices and how would people go about doing that?

MIKE: Yeah, so within the book, and I guess within the foundation framework, we talk about this journey towards getting to unit economics, unit metrics if you will. So the idea is to be able to sort of measure what’s the business output of your company and so you know within an Atlassian you have monthly active users, if you’ve got within an airline it might be like you know seats booked and flown on an airline, and things like your streaming services would do things like you know number of streams as their unit. What we’re really trying to work out is how much cloud dollars are we spending in order to generate that business value. So cost per monthly active user, cost per stream, and when you look at other sort of public talks from companies like Netflix and Spotify, their unit economics really helps them understand their efficiency of cloud and that’s kind of what I think, you know, what we call the FinOps nirvana is where you’re able to sort of understand that efficiency, but before you get there really, there’s a lot of value along the way of transitioning from just measuring these dollars saved. They’re really focusing on the amount of culture you build within the organization. So how much, you know, the cost awareness within the org, the cost responsibility, pushing responsibility out to the engineers that are generating that cost, and getting to that position where you’re able to have teams make business decisions about their cloud with cost in mind, and balance that good-fast-cheap decision-making process along the way. Like how much, you know, do they double down on how good it is, but drive up the cost? What’s the business value in that? Or do they need to drive down the cost because they don’t need it to be as good as it is currently, you know? Maybe it’s a low tier service and then it may be over committing and spending on it.

NOAH: So I think that that digs into something else we wanted to ask about because you talk about the, you know, there’s that golden triangle that sort of everybody has for how they want to run the business, and you’re saying that it varies wildly. So is there, well I’m putting words in your mouth there, but is there a particular tipping point for organizations, for a whether it’s a whole company or an individual, or to say we’ve gotten out of balance within the triangle, we have to start taking action. Is there a particular tipping point or does it change drastically?

MIKE: Yeah, that’s some like… you’ve heard the horror stories over the years right where someone’s magically spent some amazing amount of money on cloud because they weren’t paying attention to cost, and I think if you sort of dig into those stories a little bit, the main thing that happens… There’s this sort of common story of like get to the cloud no matter what the cost, or we need to get this bill out and deliver to customers, it doesn’t matter how much it costs. This doesn’t matter how much it costs really has a hidden word when they say that which is doesn’t matter what reasonable cost is. That reasonable is like this understanding within the business where some people believe it’s, I don’t know, a million dollars a month, other people think it might be five million dollars a month, and quite often there’s a handful of people who think that it’s literally an unlimited amount of money per month. So I guess what happens is eventually you get to that bill shock moment where someone within the sort of you know finance chain usually picks up the cloud bill and says well hang on this is way more than we thought was going to happen with the cloud journey. Then you get the oh crap moments, the stop doing what you’re doing moments, and worst case the pull back and pull stuff back into the data center moments. I think everyone sort of talks about it as the bill shock, but I think really what you’re looking at under the hood there is the fact that the company feels like they’ve lost control of cloud spend. They don’t know what to do about this cloud spend. I think when we set out, we thought there was just going to be a dollar figure like a million a month or percent of revenue or something like that where you just go once a company hits this value, you have to be doing FinOps. But what we found was a kind of a confluence of two different things. It was the dollar figure, yes, that’s the easiest one that you know people see. But under the hood, it’s like how complex is the cloud consumption within your organization? If you have one single team that’s just deploying everything, a very simple one team to talk to when you’re trying to figure out what’s going on with cloud costs, it’s a lot easier to see a larger number on that build without FinOps because you really just have one touch point. If you’ve got an organization that’s gone really down that line of distributed consumption of cloud, the devops model with self-service adoption, now you have a much more complex conversation around figuring out what’s going on with the cloud costs. So you’ll find that you’ll hit this sort of tipping point at a much lower dollar value because you find that you’ve lost that single point to just ask how much is this going to cost next month. It becomes 100 conversations of how much is this going to cost next month and you’ll get 100 different measured ways of answering that question. So that feeling of we’ve lost control of the cloud cost is really that tipping point. Hopefully what we’re trying to point out with the FinOps Foundation is that you start this FinOps journey at the same time you start your cloud and develop it as you grow. You cannot try and avoid this whole tipping point mentality of throwing some emergency measures in at the last minute.

CODY: So a lot of our customers we find, we talk about, you know, you talked about complex cloud infrastructure, a lot of our customers that we’ve spoken to they find they’re now moving from a hybrid cloud scenario because this uncontrollable cloud spender, just cloud spend that got away from them and they weren’t very aware of it, are you seeing that a lot? Do you feel like that’s something that’s bringing people because a lot of our customers are either moving back to one cloud provider, or they’re moving back to the data center, is that something you’re seeing quite a bit of?

MIKE: I don’t see a lot of it. I definitely hear the stories that they’re in the market with it. They’ve got out of control costs or they’re not confident in the way they can do their journey into cloud, or they’ve gone multi-cloud and really struggle with the balance between what’s reasonable in cost for them. I think it really does come back to that, like setting expectations within the organization for what’s required by engineers, what’s accepted by engineers, the building out as much transparency across the whole organization of where costs are and getting that as near real time as possible. So the idea, we talk about this concept of we used to still call it the Prius Effect, but I think everyone likes the Tesla Effect because they’re more cool, but the idea was like if you get this old car and you know you fill it up with gas and you drive down the freeway, you really the way you’re driving that car, you can’t really gauge how much the impact of your actions on the car is having the efficiency of the fuel until you sort of empty the tank and then you can sort of back calculate the miles per gallon. When you get into a nice modern electric vehicle, as soon as you put that foot on the floor, the dashboard shows you that there’s a pile of energy rushing out of the batteries into the wheels. So you have this immediate feedback of the way you’re driving and the impact it’s having on the efficiency of the car. So when we translate that to cloud costs, we want to have it so that when engineers are making decisions, they’re getting that feedback as fast as possible. That the deployment they did yesterday has increased costs by 30%, and they can then make the decision that oh should we look at that and adjust what we did yesterday, or is 30% within the expected outcome of their spend. Versus waiting till the end of the month and figuring out why the whole bill jumped 50% and trying to figure out which teams to have a conversation with.

NOAH: So I think we’ve got a good understanding of what drives them in now, from a we’ve only been speaking for a few minutes standpoint. How does the company, how does an org get started? They’ve identified that there’s these problems. They want to take action. How do you get started?

MIKE: Yeah, so I mean like I guess the foundation salesman me would say join finops.org, but the reality is I guess we see sort of two different stories. Common stories. And we believe it’s where the pain is felt first. So if it’s finance putting pressure on engineering to answer the questions, or if it’s the business putting pressure on finance to answer the questions, usually someone from the finance side of the org or engineering side of the org will start with this task of this sort of figuring out the cloud cost. What we recommend is to have a sort of combination of an engineer and a finance person within your organization, just starting the conversation together, collaborating around what is the right journey for them. You can call it FinOps, you can call it cloud financial management, you can call it your cloud economics group or whatever. It doesn’t really matter what the term is you give this, but it is important that you get someone from the engineering side and finance side of the house to start to collaborate on what’s going on with cloud spend and start with the visibility. Bring in the cloud bill, get it as near real-time as you can, get the figures out across the business so people to see that’s the impact. So the idea there is we talk about the phases of FinOps where you have to inform, optimize, and operate, and I always advocate that you start that inform. We’re sort of drawing the map and putting the thumbnail as where are we today, where’s our cloud spend, what’s the drivers, which teams are driving our cloud spend every month, what are the services that are you know the most costly services for us? Just building a bit of a lay of the land so you understand where you are. That’s definitely the best place to start.

CODY: How granular are you seeing those who implement the FinOps Foundation practices? How granular are they getting within metrics and determining we can save here on this service or like you were saying this development team is you know they’re the biggest bill, right? How granular are you seeing various ones get?

MIKE: Yeah, so I guess that you see at least division granularity as far as division costs. So you know which sort of departments spread of your cloud spend at division level. Breaking that down into a service by service, so your company’s services within the cloud, makes a big jump in the benefits because you’re able to figure out which of your services are driving the cost and also it opens up a much quicker conversation between finance and engineers when you can say that it’s that service that’s jumped in price, or you know we would like to see reductions in the price of this service because we don’t want to fund it. Then you know once you get into the service level, the cloud bill is super granular. It’s like fine sand. Sometimes it can be the detriment of someone’s lifespan because they take 10 years off their life and they’re trying to manage this cloud bill that’s in you know in the hundreds of millions of billions of lines long, but the benefit of that is you do get the ability to go right down to you know the exact Amazon service, the exact Amazon resource, or the exact Google resource that you know needs to be considered.

So you’ll end up with these reports focused on the sort of spend, spend history, spend forecast, but then you’ll also start to then generate reports on the optimizations available to you. This does loop us back and focus in on those cost optimization talks from years past where we were able to actually say now we understand how this sits within the organization and who’s involved in talking about it. Now we can bring back those levers in and say these are the optimizations we have available, now let’s have the conversation on what we do with them.

NOAH: So I would assume all of that is going to need tooling of various kinds. So have there been preferences in the past for the various members of the FinOps Foundation, whether it’s the end users, whether it’s the people that are involved, whether it’s just people that are looking at it, for going out and finding vendors, versus finding open source products, versus tooling their own, versus just using the Amazon provided, what is it, Cloudwatch I think…

MIKE: Yeah, so this story really just… it goes for me, the decision process should be driven around the time to value. You’ll find that most often people in this space will recommend that you go and talk to vendors because they’ve got years and years of experience. They’ve got a very easy on-boarding process to get your cloud bill consumed in and get your visibility going. The idea is that if it takes you six to 12 months to build an in-house tool, that’s six to 12 months where you’re really just letting cloud costs go wherever they go until you’re building out all those functionalities. So starting with the vendor tooling is a really good starting point because you’re able to just hit the ground running, you’re going to get recommendations, you’re going to get cost visibility really quick. Then in addition to that, and especially as you grow in the cloud complexity and cloud spend, the open source tools, I would see those as the second preference as you grow because you’re wanting to look at ways that you can adapt tooling to fit exactly your organization. So vendor tooling is great. It has a very sort of broad hit, but open source tooling then allows you to really customize that. Start hitting the corners of the organization the way you want to work with your cloud spend and the way you want to populate it. Then in-house tools. If you’ve got the skill set within your organization to build in-house tools, it’s where you can get the real most custom tooling in place, and so definitely important if you’ve got you know in-house platforms that allow you to do self-service access to the cloud, or you’ve got a particular way you want to be doing you know deployment, CI/CD deployments, and you want to be able to surface things like dollar values in those pipelines and stuff like that. So you start to then adapt all of those sort of built-in house tools and reports to bring in the FinOps story to that conversation. But, yeah. So it’s kind of like, I feel like it’s not so much a journey that you go from one to the other, but it’s you implement one and then you supplement with other parts of the puzzle available to you until you’ve got this real sort of mature mix of a bit of vendor, or a bit of in-house, and some using the open source and improving the open source tools to fit your needs, to give you the sort of feel all the corners of the story you’re trying to tell.

NOAH: Very cool, and I think as a vendor ourselves, I think we really like the idea of starting with vendors.

CODY: Oh, absolutely.

NOAH: So speaking of which, this is part of our lead up to KubeCon and as a vendor we’re going to have a booth at KubeCon, so hey come visit us, but the FinOps Foundation will not have a booth at KubeCon. So if folks are watching this as part of the lead up and they want to learn more about the foundation, where can they go? What can they do?

MIKE: Yeah, so hopefully next year we’ll have a booth somewhere and some of these expos as the human malware goes away, but yeah finops.org definitely the right place to start. We’ve got memberships for practitioners. Just simply come in and then you know the vendors we love to get you involved and hear your voice in growing this and developing the practice. Of course you mentioned my book earlier, thanks for that, but yeah probably the foundation FinOps.org website is a really good starting point to get connected to everything we’re doing over here.

CODY: Awesome, awesome. That leads us into our Rapid Fire questions. Noah, do you want to run with these or do you want me to?

NOAH: Why don’t you go for it?

CODY: All right. I’m going to do these very quickly, all right? Pineapple on pizza – yes or no?

MIKE: Yeah, so I will have pineapple on pizza, but I wouldn’t pick pineapple on pizza.

CODY: Fair enough. Favorite piece of technology?

MIKE: Oh, I like my eye devices, but I think that I really do like the raspberry pi, or all the raspberry pi suites. I think it really has brought hardware technology and tinkering back into the life.

CODY: Yeah, like Radio Shack, right? Yeah, all that stuff in the day.

MIKE: Yeah.

CODY: Absolutely. Okay, favorite open source project?

MIKE: This is the interesting one… actually probably Linux. I mean… The OG, right?

CODY: Absolutely. Okay, favorite hobby?

MIKE: I play pinball. It was a side project, so I really do enjoy that.

CODY: Absolutely cool. Okay, last one. Favorite place to vacation?

MIKE: I live out on a property and I just love just being out here in the country away from everyone and tinkering out in the field.

CODY: Awesome, that’s great. I also…

NOAH: You live where you vacation.

CODY: Yeah, yeah. I also live in a very rural area, so I can respect that.

NOAH: Fantastic, well that’s all we got. Thanks for joining us today, Mike. It’s been a pleasure talking with you and we hope that everyone watching or listening will tune in for our next episode. We’ll see you next time.