Episode Summary
#awscloud #cloudcost #costoptimization
Welcome to the Jon Myer Podcast! In this episode, we're diving into a fascinating discussion on #FinOps on AWS: Method versus Methodology – a topic that might sound like a cage match, but it's all about optimizing cloud costs and maximizing value. Our guest today is David Wharton, a seasoned tech industry leader with over 20 years of experience, including a stint in the United States Marine Corps. David currently serves as the Chief Architect at CDW, a Fortune 500 technology services and products supplier.
Before we jump into the cage match, we'll get to know David better, exploring his impressive journey from the military to the world of AWS and his role as the Chief Architect at CDW. David shares valuable insights into why #FinOps is essential, particularly in today's budget-conscious environment. He highlights how it's not just about saving money but also reallocating resources to innovative projects that drive growth.
David and Jon discuss the importance of showing the value of #FinOps to stakeholders, engaging engineering teams, and fostering collaboration within organizations. They emphasize the significance of methodology in implementing #FinOps, breaking down the "why" and "how" aspects of cost optimization. The conversation touches on various aspects of #FinOps, including methodology, stakeholder buy-in, reporting, the role of executive leadership, and the importance of building trust with clients.
David also shares CDW's #FinOps capabilities, such as the #FinOps accelerator, advisory services, and managed spend ops, which help organizations optimize cloud costs and mature their #FinOps practices.
Don't miss this insightful discussion with David Wharton, shedding light on the world of #FinOps and the strategies to unlock value in your cloud operations. Join us for an engaging and informative episode of the Jon Myer Podcast at AWS Reinvent! And be sure to check out CDW's booth for exciting product offerings and cool swag. See you there!
Are you looking to elevate your brand through compelling and highly professional video content? Myer Media has the solution for you, from start to finish we offer complete video creation services that include Customer Case Studies, Creative Content, Podcasting, and more.
To learn more CLICK HERE:
About the Guest
David is the Chief Architect for AWS at CDW, a Fortune 500 supplier of technology services and product. David has 20+ years of tech industry leadership experience, with the past 12+ years focused on migrating legacy (+ new) workloads to AWS. A former CDW customer, David held Director level roles for Blue Man Group, Shakespeare in the Park, and AIG. David also founded the FinOps function at the world’s largest restaurant chain, achieving over $2.75M in cloud savings for Subway World Headquarters. In July, the FinOps Accelerator was launched along with other founding members of the CDW FinOps team. The mission of the CDW FinOps Practice is to unlock savings for customer, to enable innovation and sustainable engineering.
#aws #awscloud #finops #cloudcomputing #costoptimization
Episode Show Notes & Transcript
Host: Jon
Hi everybody and welcome to the Jon Myer podcast. Today's topic is #FinOps on AWS method versus methodology. Is that a cage match? Our guest today is David Wharton, who's a chief architect at CDW, which is a Fortune 500 supplier of technology services and products. David has over 20 plus years of tech industry leadership experience with the past 12 years focused on migrating legacy applications and new workloads to a WS. Please join me in welcoming David to the show. David, thanks for joining me.
Guest: David
Thanks for having me.
Host: Jon
Before we kick-started on this cage match that we're going to talk about, and I like the idea of that, I can see this visually. How about you give everybody a little backstory on yourself?
Guest: David
Sure. So like you said, I've been in the IT industry for over 20 years. Some of that was spent in the military for about eight years, was in the United States Marine Corps from 2000 to 2008. So that was a nice little distraction, spent a lot of time in the reserves but was of course activated post 9/11. So that spiced up the computer career a little bit. And yeah, in 2008, 2009, got into AWS and started moving companies over and it's been a great run. Got into #FinOps pretty heavily in about 2018, 20 19. Had done it before, but mostly in the context of TCO and just making sure there were ROI use cases set up for certain solutions that we were looking to execute. But yeah, since 2019, started at the Subway World headquarters as their cloud cost manager and that's kind of when I did the deep dive. Since then I joined CDW last May and they promoted me to chief architect in August and been building out solutions for AWS, but also the #FinOps practice, the Cloud #FinOps practice. I'm so excited to be doing that and excited to be talking to you.
Host: Jon
Okay, so you've been doing AWS for a long time moving workloads over in the early stages when nobody was thinking about cloud cost, and now cloud cost has been a predominant subject for the last couple of years and #FinOps has only been around for a couple of years. Why #FinOps?
Guest: David
Well, I think providing value is a powerful thing, especially in times like this where there's a downturn and budgets can be tight. I've noticed a lot of our engagements with folks aren't so much about saving money so that they can unlock value in terms of money back or money saved. They want to repoint those dollars to a project. They still want to do something but they can't do it because they don't have the approval. But they know that if they can unlock savings, they can just use that compute and point it toward that new project and not necessarily please the procurement or the finance teams. Sometimes that is the main driver, but most often I've found that companies just want to repoint their projects or the savings to projects that are driving innovation.
Host: Jon
I find that completely true that the savings that you get from any project going to the cloud, whatever it may be, those dollars have been allocated and you saved X amount. Now let's reinvest them into the company doing other things and growing. Maybe we want to innovate, we want to do r and d, whatever it is, but now we're able to achieve more,
Guest: David
Right? So that's exciting. So providing that that value for customers is thrilling when you're a customer like I was previously, and you're doing that as your role when you can all of a sudden within a couple of months, unlock double your salary, that feels very rewarding. And to prove out those numbers and to graph out those trends for your team and the leadership, everyone loves to see that. So it's good stuff. Well, let's
Host: Jon
Talk specifically about what you're doing at CDW.
Guest: David
Sure. So chief Architect is primarily responsible for emerging trends in the context of the go-to-market, helping approve things inside the go-to-market portfolio, and solutions things to bring to the market natively. And then really just there's also customer interaction. Sometimes there's customer rescue, there's all sorts of things that we can get pulled into. We have cloud architects or chief architects across the three CSPs. And we also have chief architects that are focused on particular areas like application modernization data. So it's an interesting role, but it's I think crucial for advising the company in terms of direction and just helping make sure that we're on the right track and that we're listening to the trends and not just unable to see the forest through the trees. So I think that's one of the great benefits of being in this position.
Host: Jon
David, our topic today is #FinOps on a w s method versus methodologies. How would you define methodology?
Guest: David
Methodology is handled I think a little bit differently because that's about why to do it. So what's the purpose? So of course you're familiar with the #FinOps, the big three, and inform, operate and
Host: Jon
Optimize,
Guest: David
Optimize, thank you. And so to be able to do that, you also need to know how to do that. So the actual optimizations itself, so the approach isn't just about the philosophy. It's about, okay, how do I do it? And that's when you get really into the methods versus the methodology. Methodology is more philosophical stakeholder buy-in, how many of your workloads are tagged, et cetera. There are specific KPIs just focused on the methodology, but the actual methods are right-sizing using spot. Are you using Riss SS's three lifecycle policies, automating cleanup, et cetera? So there's a whole list of things you can do specifically in a W Ss and in the other clouds that will unlock the cost, unlock the value that you're looking to achieve. You can do this manually, or you can do this with automation. There are SaaS tools that can help you do these things, but that's what I mean by methods is the's why. And then there's the how and they're two related but different things.
Host: Jon
Do you find that companies struggle between the why and how to understand why I should do this versus how I should?
Guest: David
Well, I think they understand the why pretty quickly. They know they want to save money or they want to unlock the money, but they don't understand all the mechanics behind the why stakeholder buy-in. They don't necessarily understand why they should go move across the app teams and explain to them why they should be engineering in a more sustainable fashion. Well, if you just show them the stats from a report of what they were doing, how much that cost, and then just let's say in the dev layer making that change and then how much it was running when it was engineered more efficiently, then you can kind of get them addicted. And that's where buy-in can happen pretty quickly. On the engineer side, you just have to show them the numbers and then they're like, oh, so you mean if I do it this way it's going to cost less?
Guest: David
And then all of a sudden I noticed at Subway, for example, I was getting emails from engineers saying, oh, look how much I saved this week. And before that, they were very, they're like, oh no, I don't want to do that. I don't want to do that. I'm like, well, this change can save you this much. And they're like? And they're like, it can and yeah, they do it and at that point, they can't let it go, so you're not always going to get that buy-in. Sometimes app owners, they're not hands-on keyboards, they just administratively own the budget, so you have to explain to them, of course, they'll want to unlock dollars, but they don't necessarily know how to explain from their role to the engineers why to do something a certain way. So you have to really look at the whole landscape of personas and work the buy-in at every persona level and each conversation's different, but the narrative is ultimately the same, and I think a big driver for methodology and then the methods, it's really up to either the third party that's helping clean up or unlock cloud cost or the internal stakeholders that are #FinOps engineers or cloud financial analysts that can do some sort of execution inside the environments.
Host: Jon
With your example of Subway and the engineers caring about the cost of something, how did you get them to care?
Guest: David
You got to just show them the information. Some people react differently. Some people like pie charts, some people like a table with numbers in it. Ultimately people like dollar signs, so show them use dollar signs is what I say in your numbers. It's a powerful, powerful tool.
Host: Jon
You also talked about the teams working together, and the app owners trying to collaborate and tell the engineers why they should do something a certain way. Part of the #FinOps culture is that the teams are always collaborating and working together. You either have a central decentralized hub and speak however you want to be, but there's still some type of collaboration and understanding of why the app is built this way, but also trust in the engineers that they shouldn't build it that way because now they start to care, Hey, don't use those. Let's use this instance. I find that hard to do or hard to implement in an existing environment. Have you done that?
Guest: David
Yeah. Well, one thing that's important in terms of showing them the data is that what happens is the next time around when they're solutions something or building something, they'll do it well, it's not necessarily the right way or the wrong way. They'll just do it differently. They know how they're accounting for cost and it's a pillar within the well-architected framework inside of a W s, but it should be a component and a pillar of any cloud and even something that you're constructing on-prem, you set it up a certain way, it's going to be either more energy efficient or less energy efficient. So I think the approach can cascade across many different scenarios and many different platforms. It's just about showing them the data and then giving them that information and then they can make better decisions going forward. I think that ultimately the best benefit of business intelligence is informed decisions going forward and then being able to change hearts and minds with data is sometimes a lot easier than putting it in a word problem. Just show them the actual goods and then they'll get it and make it, make them think it's their idea.
Host: Jon
That's speaking from a true salesperson type. If you got 'em feeling like it's their idea, their own thing, they're going to go in. It's like buy-in in any meeting that you have in any type of company when you're trying to get people on board, you lead 'em to the ultimate answer, the answer that you'd like to get, but they have to feel that they've come to that answer, and what it does is it empowers them and it's like ownership of it. David, let me ask you about the reporting that you've just talked about, in fact, you've been talking a lot about reporting and showing them the numbers, showing them the visibility of it. How important is this data when you're showing it to them and for them to get to trust that it's the right data,
Guest: David
You have to give them the data and the source. I remember I showed an app owner how much their cloud cost was, and they had complete sticker shock. They didn't know how much it had cost prior. And keep in mind, this was on the email chain with the CIO, so it was sensitive, and then my reply at the back, it's like, actually it costs a lot more because there are third-party integrations, so there are third-party integrations that were outside the Azure bill. It was connecting to on-prem systems. So when I added everything up, it added up to, it wasn't the $600,000, it was a million dollars. It cost a million dollars a year to run this particular app, and that blew everyone away. The fact that it costs that much. But I had the data to point back to, I had the sources of that data, and you can't really contest that, and finance is your best friend the ledger, and you can pretty much figure out anything through the books at some point. So it's not always about your Azure bill, your AWS bill. Sometimes it's about the things that are connected to that service and the other external bills that are associated with it. So sometimes what your app costs, it's the true cost, and sometimes you have to look a little further to see what else might be involved and what else is in play.
Host: Jon
We've been talking a lot about the methodology around #FinOps on a W s and the implementation and getting your engineers, and in fact, we talked a lot about the engineers and the business owners on the finance side. How do you get finance to understand the engineering side rather than they go, yes, go make this change and reduce my cost, but then also listen and collaborate as a team?
Guest: David
Well, you need to make them understand why certain changes can't be made, at least not quickly. Some of them can be made in the dev layer in a non-production environment rather quickly of course, and that will unlock some quick value, some quick wins. But ultimately you don't want to mess with production environments, especially if it's revenue-generating. And that's easy to explain to them. Say, look, we could apply this to production, but we're also going to lose money during that outage when we perform this change. Or if something goes wrong, we're not going to lose more money just experimenting with production than we were to just apply it to all the lower environments except for maybe one so that there's a parody. But yeah, so you need to explain these things, the actual business case behind it. Sometimes unlocking value in certain places like a production environment is not the best idea. That's a quick way to make enemies when production goes down. So you want to do it in a very concerted planned way in the lowers first, prove it out, and make sure that it's operational there before you schedule any downtime or you do any hot changes or anything like that you want to make sure it's well planned for. So that goes into the conversations I think with finance is that is in layman's terms trying to explain those things to them.
Host: Jon
David, let's talk about some of the methods to accomplish these tests. I have my methodology, I have my reporting, I've gone through it and I've identified my resources, I identified this stuff and now I have methods that need to be done. What are your thoughts on doing in-house versus third-party mix, and how do you implement these?
Guest: David
Yeah, think having a concentrated tech staff that has this skillset is important. So it can be part of DevOps or it could be part of some other aspect of the IT organization, but they're not going to learn it quick enough to unlock the amount of savings that they should achieve quickly. What I mean is it's probably best to have someone external come inside the organization and show them what to do, how to do it, how to do it well, and effectively teach them how to fish and then they can fish on their own. I think that's the best approach from my perspective, because just outsourcing it, they're, they're not necessarily vested enough to want to continuously unlock that value. And they also don't know the ins and outs of every application.
Guest: David
They could shut down something that's meaningless or they could shut down something that's used every day and that could cause a big problem from just a workflow perspective. So you want to be careful in terms of who you empower, at least from an approach perspective, how to do it, and when to do it. The tools used it is best to bring in someone at least for a short term who can tell you how to do it, how to do it well, and then at some point peel off. And then there's an internal team that's working on it. So the answer is hybrid,
Host: Jon
I think getting started, right? A #FinOps consultant comes in, and they find a couple of internal advocates who are looking to wrangle in the cost but also understand everything in general. And then what they do is they empower it. They have executive created these teams, and then here's how I put it. I do podcast consulting and I tell people, listen, it's a year-long engagement. By month 10 we play TV series and I get killed off and you own everything because I don't want to own it afterward. You are empowered now to run with this, and it does me no good to stay on long-term. And I think that's the way most consultants should do when they're kicking something off. The longer they're there, they start to become part of the furniture and then it's a never-ending thing, and then it's not actually kind of growing. It's not growing internally and the investment and all that. It's just a natural feeling, right? Yeah,
Guest: David
That's exactly it. I mean, the reality is at CDW for example, there's no value in us being at a place for three or four years doing #FinOps for 'em. Best case, we're in there a year and it's fire and forget at that point they know how to do it. We've established all the buy-in has already happened either through us or through them. We're in a partnership, all the tools are in place, all the workflow is in place, and then they know what to do in year two or year three, and then we're able to shift to other customers. Otherwise, it's very hard for a company, whether it's CDW, Deloitte, Ernst and Young, it's very hard for them to scale even at their massive size across the entire commercial and nonprofit workspace because how are you going to be in every company for three, four years?
Guest: David
It's not sustainable. So it's best to just bring in the right talent, teach them how to do it well, and then move on. And that also builds trust. So the next engagement, whether it's like application modernization or some other effort in terms of modernizing their environments in some way, maybe it's AI, who are they going to go to? Well, they're going to go to the company that came in and taught them how to do it and wasn't interested in just clocking in day in, day out, week in, week out, year after year. I think there's value in building that trust with customers. So I think that's important.
Host: Jon
Do you do periodic checks or audits to help them make sure that they're still on the right path within their #FinOps culture, and within their teams?
Guest: David
Well, we have custom IP that is essentially #FinOps tooling that they can remain on in their environment, which will continue to lower costs for them. So that's going to drive reporting. They can shut off the feature that sends cost savings reports back to us. But yeah, so to answer your question, yes, we have that ability, but it all depends on their preference for privacy. In some cases, after you've left the company in terms of engagement, they don't want their data, even if it's how much you saved them from the tool you left behind, they don't want that data leaving the company, and that's fine. I think it's transparency is the most important thing. It's probably the most important thing about #FinOps is making the data of how much things cost transparent and approachable to all the stakeholders involved.
Host: Jon
How important is executive buy-in when trying to implement #FinOps?
Guest: David
It's important to have executive buy-in because you want them to be in the meetings with AWS so that AWS can see how serious of a project this is, and if it's just Joe engineer in the cloud, you're not going to have the same pull with AWS or any other cloud provider for that matter. Having an executive on the call, that's always very powerful. I hope that answers the question.
Host: Jon
Oh yeah, definitely. Now, what advice would you give somebody who's just starting in their #FinOps journey?
Guest: David
First and foremost, I would say get some sort of certification, even if it's one of the persona certifications from #FinOps Foundation, and then move on to the practitioner. And as far as if you can't get hired at a company, it's very easy to just walk into even a retail store and say, are you guys on the cloud? And they're like, yeah, well, you should probably talk to this guy about it. And then there's someone that has some sort of relationship with a W s or another cloud provider and they're like, oh, okay, do you want to save money on AWS? I know of some ways to do it. And so you can start very grassroots about it. You could start as a freelancer, you could start your own company. You could just do it for a couple of small businesses and see real world the impact that you're making and the savings that you're achieving. So yeah, there's so many ways to approach it. If you can't get hired as a #FinOps analyst or engineer, just get hired as a cloud engineer and you can circle back and prove that value. So I don't think you want to pigeonhole yourself with just a #FinOps certificate or certification. You want to also focus on some other cloud certifications as well and just get in as some sort of cloud analyst, or cloud engineer. And then you can circle back to the #FinOps use case and value proposition.
Host: Jon
If you get involved in the cloud in any way, engineer, architect, or analyst, you will be able to get into #FinOps if that's what you want to do, because you'll understand Cloud in general. You'll have a voice within the company around it, and you can always start doing it yourself, like advocating, working on it, and then showing the actual, like you've said, David, showing them the numbers, showing here's what we could do, here's what we are doing. Let's make sure we're making the right business-driven decisions on our applications. And I think that allows you to start your own. I mean, if you don't even have a #FinOps role within your company, it might allow you to kick something off. A small team of one grows two or three, now you have a whole company to what you started yourself.
Guest: David
Absolutely. Yep. So much value to show and show back and to unlock. I keep using that word. I must've said unlock 16 times, but ultimately that's what it's about, proving the value.
Host: Jon
Can you highlight some of CDW's other #FinOps capabilities?
Guest: David
Yeah, so we've got the #FinOps accelerator that's 68-week engagement depending on the size of the company that does just that accelerates the #FinOps capabilities of a given organization. We'll take someone from the crawl, we'll get them to walk. If they're at the walk, we'll get them to run in terms of maturity and we will help with stakeholder buy-in, tagging policies, best practices, tooling, both automated and manual associated with saving money. But ultimately one of the great outputs of IT and outcomes is an executive roadmap that shows them from an IT roadmap perspective, the tasks, projects, and initiatives that they can implement over 12 months and beyond that will drive down their consumption, but also increase their #FinOps maturity. And the two are very closely correlated. So as you become more sophisticated, as you become more mature from a #FinOps perspective, your consumption is driven down and that's the great value of the accelerator.
Guest: David
If a company doesn't want to take on the role quite yet internally, there's the #FinOps advisory and that can either come in as a standalone offering or it can follow up the accelerator and the pricing model for that's a little bit different. It's charged based on the percentage of savings realized, so there's no risk to the customer in terms of pursuing that effort. And then of course there's the managed spin ops component, which is part of our managed service organization, and that's monthly reports, quarterly reports depend on the desire of the customer in terms of cadence on #FinOps and then the savings that were achieved based on certain engineering actions that took place over a given month or quarter. So those are the three things. David,
Host: Jon
Before we wrap things up, what is CDW doing at Reinvent?
Guest: David
Yeah, so we're excited about our booth there. We've got a booth over by the infrastructure solution zone, and I think we're going to have a London phone booth there. And we've got a nice skyline backdrop of the booth representing all of our global presence. So we've got landmarks from Canada, Toronto, and Space Needle skyscrapers in New York. We've got I think, Big Ben and London Eye and London. So obviously we've got CDW, UK, and CDW Canada. And so it's cool to represent all of those areas of the business. And yeah, it's exciting. It's going to be our biggest presence at Reinvent to date, and we're going to be launching product offerings, and we're going to have some great swag. So we're excited to see you there. And all those that are attending
Host: Jon
CDW is a sponsor of the Las Vegas experience at Reinvent. We have a cool studio, the Blue Wire Studio located at the Wynn CDW is going to be over there. We're going to record some great content and some prizes. Things are going to be happening. Don't forget to go ahead and check CDW out at the expo, but come over to the studio and watch us do some cool recordings. I hope to see everybody there. David, thank you so much for highlighting #FinOps capabilities. David, thank you so much for joining me.
Guest: David
Thank you. Thanks for having me. Well,
Host: Jon
Everybody, this has been #FinOps on a W Ss method versus methodologies, and I've been talking with David Wharton, who's also a chief architect at CDW. My name's Jon Myer. Don't forget to hit that, like subscribe and notify because guess what, we're out of here.