FinOps is the operating model for the cloud. And we really need FinOps to enable companies and people to leverage all of these advantages that the cloud is promising, such as lower costs, innovation, scaling, and availability. We invited Vanessa Kantner and Manuela Latz from Liquid Reply to discuss the topic.

Marc (00:04):  Welcome to DevOps Sauna Season Three.

Vanessa (00:09):  You can save around 30% just by turning off resources and optimizing here and there. But to start our journey, you have to start with cost transparency, of course, and you have to show all of these people that yeah, sure, they give their best, but sometimes, yeah, knowledge is missing. 

Marc (00:32):  This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:37):  I've been to depths that remain classified, and Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom.

Marc (00:47):  In DevOps Sauna Season Three, we will explore platform engineering and the people and cultures that make it happen.

Andy (00:53):  Enjoy your time in the DevOps Sauna.

Marc (01:05):  Hi, this is Marc, and welcome to DevOps Sauna. I'll be your host today. And we have a really interesting podcast talking about FinOps. We have with us a couple of guests, Manuela and Vanessa from Liquid Reply. 

Manuela (01:20):  Hi. 

Vanessa (01:21):  Hi. 

Marc (01:22):  Hi, Vanessa.

Vanessa (01:23):  Thank you very much for having us.

Marc (01:26):  Hi, Manuela. And we also have, as usual, my co-host here, Mr. Andy Allred. 

Andy (01:31):  Hello. Happy to be here. 

Marc (01:33):  All right. We're all consultants at the table today. So our intention is to just kind of talk shop about how we see FinOps, maybe what the trends are, and how this is affecting people and how companies are looking at the things. So Manuela, Vanessa, would one of you like to talk about: What is FinOps? And how do you see it today from Liquid Reply?

Vanessa Manuela(02:08): SURE! <laughs>

Marc (02:01:):  I said I wasn't going to put on anybody on the spot and here we are. You're at it.

Manuela (02:05):  You can start, I'm fine with that.

Vanessa (02:09):  Okay. For me, FinOps is the operating model for the cloud. And we really need FinOps to enable companies and actually also people to leverage all of these advantages that the cloud is promising, like, of course, lower costs, innovation, scaling and availability, stuff like that. The thing is, I think most of the companies go to the cloud to actually save costs and to lower their costs. But as soon as you migrate some workloads, you will see that it's not that easy, you can't do that in the beginning. So usually, the costs are higher than before. And so that's where FinOps comes in, and helps you save costs. But I mean, that's also the promise, I think FinOps does, like say, okay, with FinOps, you can save costs as a company. But then, if you dive a little deeper into the topic of FinOps, you see that it's all about change management. And it's all about like, you need to adapt your company culture and your processes to that new whole world and promises of the cloud, and to really be able to leverage the advantages. Yeah, and so at the end of the day, FinOps is about change management. It's about just updating the existing, the old traditional processes to a new level, to make it possible to work with the cloud. And of course, for that, you need the people to make that possible.

Manuela (03:35):  I would add here something, I think one major part is missing. So yes, FinOps is as a management and the culture of practice. So it comes with everything Vanessa just said, but I think one key factor is data-driven decision making. That's a very textbook term, I'm aware of that. But when it comes to cloud, you have IT resources with a push of a button, right? And what was in the past centrally procured is now like de-central, and like brought up by anyone who has access to internet, to a cloud provider. And this increases lack of control, in a way accelerated by the time, by the development of technological possibilities that departments like finance and controlling can catch up. It's impossible. At the same time, you create expertise within environments, within workloads, right? So me as an engineer, me as a developer, I'm 100% aware of what's happening in my account. But my line manager, or even higher, my department leads-if this person wants to know how much did we spend, let's say over all tests accounts, like for the last two months, you need different metrics than you would have needed 20 years ago, to make an evaluation of how much you spend for a certain activity, and how much you might need in the next year, right? So enabling data-driven decision making is one key essence of FinOps as well. And there again, you need the people for it, you have to link different stakeholder groups.

Vanessa (05:30):  So I mean, in short, FinOps is all about enabling people, right?

Marc (05:36):  I think that's really cool because one of the things that I've seen is we have a lot of, you know, there used to be FinTech, right? Financial technology things. We have a lot of financial institutions that have a big on-prem, and control and yeah, they centrally procured it, like you said Manuela. And now when they look at cloud, the first thing they is hear stories of the guy that left the expensive servers, or the expensive cluster, on when it wasn't being used. And then the cloud bills all of a sudden. They hear the horror stories. But you have a whole methodology mindset and a science around FinOps about optimizing the usage of the cloud for companies.

Manuela (06:19):  Absolutely, I agree. And think about it, I mean, it's an extension of DevOps, right? And if you think about before DevOps, that's basically when I suspect Vanessa's most favorite story, we've talked about this in our KubeCon talk as well, it never came to mind that it might make sense to link two separate units to create more value, right? And now with FinOps, it's basically the same. I mean, you can create more value, when you link people who decide on what to spend, and people who actually spend money, right?

Vanessa (07:06):  I think that's a great example because we've development and operations before DevOps, they were always struggling with communicating. And so there was tension between those two teams or people. And they kind of, not hated each other, but yeah, there were discussions about how things should work and be. And so you have the same thing now with FinOps because now you have the DevOps teams, and then finance, business, or whatever stakeholders involved, really. And at some point, they stop talking, I think, at least for non-technical people, from time to time, they still think that IT is just, I would say like a 'supporting tool' for the company. But some years ago, that changed, I think IT is now like the main driver of a company's business model in general. And so also, then, more or less non-technical people need to have at least the basic knowledge of what Cloud is or how IT works.

Andy (08:00):  And I like the idea that cloud architecture and cloud cost-management are almost exactly the same thing. That when you choose an architecture, how much cost is inherent in that architecture is already kind of preset. So how can we get developers and architects and decision makers on the technical level to understand how the decisions they make are really affecting the costs. And I think that's where kind of FinOps is exactly, perfectly positioned, that making this data, making these links apparent and available. So people can see what's really happening with the cost compared to what's actually running and make the right decisions based on that data.

Vanessa (08:48):  Yes, I think monitoring is one very important part. I think the other one is thinking about strategies, you were talking about architecture. You cannot stop resources on weekends if there are too many dependencies, right? So this is something you have to have in mind when you build something, even if it's not producing cost yet. But you might want to have a strategy within your organization where you say, every dev and test environment is shut down during weekends. So if you need the buy in, you need the technical buy in, even if it's not their daily operating business, you need it. Because you need their help to make cloud more efficient.

Andy (09:33):  Exactly. And to make these kinds of these links more apparent and transparent. That of course, the easiest way to control costs is just turn everything off. Let's just shut it all down and hey, our costs drop. But what does that cause? So how do we understand the dependencies between the services, what other services are depending on them, and especially compared to what the cost is, related to those. So we're able to kind of make a trade off and a balance between these two, sometimes opposing angles.

Marc (10:10):  There's something that I'm trying to get to here, like an elevator pitch. FinOps is the methodology whereby we create systems that are only generating cost when they are generating value for a user. Is that true? Or how can you make that better?

Vanessa (10:37):  I would rather say at least, it's not like set-in-stone methodology, it's more a set of best practices. And you have to customize them depending, and the mindset, of course. Depending on your situation, you have to adapt a little bit.

Manuela (10:53):  I would say, you can narrow that down that FinOps has about three main pillars. People, data, value, means that you create the meaningful collaborations by bringing right stakeholders together. That's one part. It means making cloud resources transparent and allocatable. Because especially when we're talking about an abstraction level, like you're in, it is impossible to do that, just coming out of mine. And it means increasing business value by being able to spotlight inefficiencies. And this gives you them starting points. And this is very individual for every organization. So you might have like storage thing going on that can be optimized while someone else is like producing costs mainly in development and test environments because most of their stuff, still has an on prem behavior would need a completely different strategy to tackle that to start optimizing, then it depends on, are you single or multi-cloud? Are you hybrid? Do you use all of these approaches at the same time? So yeah, I think it's people data value.

Manuela (12:08):  Does that make it better, Marc?

Marc (12:13):  I think that was really fantastic, really fantastic. Cool. So one thing that we had talked about is that developers be like, one of you, Manuela, I think it was said that the developers are aware of what they're spending. But are all developers even really interested in that kind of level of things? Can you elaborate a little bit on the psychology of the ways that different individuals, different people would look at FinOps, and the cloud costs and architecture and things like this, I think there's a lot there?

Vanessa (12:58):  I think it's not only caring, it's more the topic of awareness.

Manuela (13:04): I would like to bring out a quick example. At KubeCon, someone approached me and we were talking about rightsizing. Rightsizing is also a FinOps term, just for the ones who don't know, it means that you are able to spotlight under-utilized resources, and then size them usually down to the right size so you're not wasting resources and money. And it was productive for your needs [in a] Kubernetes-developing team. And he came to me and he was like, "Yeah, well, with Kubernetes. You don't need rightsizing anymore, right? You have autoscalers." And I was like, "Yeah, that's right." But what do you need to use autoscalars? And he was like, Yeah, well, I need I need my resource requests, right? And then everything is automated. I was like, "Yes, that's right." So automatically, inefficiencies are spotted, but who sets the resource requests? And I was like, "Yeah, me does." And I was like, "Okay, well, if you do that, how do you do that?" And he was like, "Yeah, well, you know, usually it's just experience and like, I'm doing a just in case." And I was like, "Okay, so just in case, what are you doing?" And he's like, "Yeah, so usually it's 10%. So 10%, just in case, and then I do my requests. And then everything is automated." So you're saying like your whole environment is 10% over utilized, just in case. So even if you're using auto scaling, you're not right size right now, right? You have resource waste. So you have money waste, and he was like, "Yes, I didn't think about it." How would you do that? And then we continued the conversation. So long story short, awareness is the main topic when it comes to FinOps. And when you are able to have, especially with this target group, a discussion that is more on a technical level, you get the buy in easier than a manager coming and saying like, listen, we have to save 10% cost, just turn something off.

Andy (15:04):  You mentioned rightsizing. And I like that, I generally try to follow that and make sure that my containers and my nodes and everything are kind of the right size. And usually, as you even said, that means making them smaller. But the main thing with Kubernetes is kind of been packing the nodes as much as they can handle. And there are shared resources on every node. So right sizing sometimes includes could be increasing the node size. So you have enough capacity, which is the shared layer, you're not replicating the shared layer over multiple nodes as much. So but understanding that because Kubernetes is an abstraction layer for many things, understanding how much of the utilization is the shared part, how much is the dedicated part, how much of it needs to be elastic, that's often rather difficult. But if you get the right tools that you can do that, then you're able to make the right decisions with this. And then this kind of FinOps mindset, you're able to really apply in Kubernetes, and all these other abstraction layers as well, that when you get the visibility of what you're doing, then you can decide is this something we need to scale up? Or change our autoscaler? Or do we have an extra 10% here all the time? Or should we use a bigger node, so this shared resources of logging and monitoring whatever is actually less of a percentage of the big picture. And you're able to see these things and make the decisions based on data.

Marc (16:51):  I just kind of want to point out that we talked to lots of companies that have like 5% operating margins. So if your consumption is operating at a 10% over-cost, then that could really be a game changer for you compared to your competition.

Andy (16:59):  And another thing that Manuela brought up that she didn't say this explicitly, and I'm not sure how the conversation went with his engineer, but well, it's kind of based on my best guess and a lot of experience in some hand waving. And then I add 10% safety buffer. So you're adding 10% based on a hunch, based on this is what I saw before, based on this is how it worked in previous version. So how much waste is really there when you actually start measuring things. And I feel comfortable to say that because I've been guilty of it myself so many times. <laughs>

Marc (17:47):  Okay. Is there some examples of using data or some stories about the data aspect of FinOps for these kinds of cases?

Andy (17:51):  I'll jump in with mine while you're thinking. So I was taking a telco company billing system and pushing it into Kubernetes. And we wanted it to be in multiple clouds and deployable anywhere and use the same tooling and the same databases and what not everywhere. So we came to the conclusion that we need to put everything in Kubernetes. So we had Cassandra, and Kafka, and Maya DB, and Elasticsearch, and Grafana, Prometheus, and all these kinds of supporting tools, plus our applications, running everything, plus tools to coordinate that inside the cluster. And we deployed everything inside of Kubernetes. And it was a bit complicated, but it worked. And it was fantastic. Lots of tradeoffs in there and what not, would do it differently now, but it was great at the time, then we had two, of course, have dev cluster and test cluster and whatever. So okay, we just deploy everything over there. And everything's in AWS. And who cares, let's just let's just spin it up. And our cloud costs went crazy. And we started looking at it, and a single dev cluster cost us a little over 4k per month. Like, okay, this is ridiculous, we have to do something. And so then we started looking at, okay, how much of these resources we actually could share without affecting our testing? And how much of this can we move outside of Kubernetes or into another Kubernetes cluster, which is shared between many different systems? And how can we really optimize that, and I left before we kind of finished that project, but we were able to start scaling things down and save immense amounts of cause just by looking at what's really running inside of Kubernetes. Instead of just saying, well, let's just throw everything there and this is deployed and there you go. So kind of the big take away for me in that was understanding really what's running as a percentage overall, helped me understand that these things are actually shared costs and shared across multiple applications, multiple services, do we need to have an individual one for every single system? What's the value bringing from that? So of course, for dev and doing so, or for production, and for production load testing, and what not, you want a carbon copy. So you're really, really sure of everything. But you don't need a carbon copy of production for every developer, obviously. But where's the right trade off? And what does that mean for different types of system testing, different types of unit testing, and understanding that we were able to really, really drastically reduce our cloud spend, just by understanding what's running inside the single line item on the bill, which said, Kubernetes.

Vanessa (20:52):  I have one more, I would say business related story, because we, as consultants, of course, have these sales pitches. And one of our customers or potential customers, now customers, are saying, yeah, we don't need that FinOps because our people, our IT people, people working with the cloud, or sign an agreement that says they do the best, and whatever they think is best for the cloud architects and for the product they're implementing. And so there is not a lot of waste because they are doing whatever 'the best' in relation to the cloud costs, and then we were like, "Okay, just give us half a day. And let's assess your environment." And of course, as it is, these days, they had like more than one cloud provider, that, of course, increases the complexity and the costs. And then I mean, as it was, they had like 30% waste, just like resources that were idle or not rightsized or anything. And I think that even, Manuela correct me if I'm wrong, I think it's like the statistical percentage number there, the 30%, or something that's usually found in these projects. You can save around 30%, just by turning off resources and optimizing here and there. But to start our journey, you have to start with cost transparency, of course, and you have to show all of these people that yeah, sure they give their best, but sometimes, yeah, knowledge is missing. Sometimes it's a gut feeling. And then you add 10% just to be sure everything works fine. And so, I think that's where you have to really start with getting that transparency and also getting that feedback. And show the people the issues or where they can improve.

Marc (22:53):  Is there anything we could expand on a little bit about starting a FinOps journey, or if a company is looking on-prem to cloud journey, the entry points to FinOps?

Manuela (23:05):  Yes, I would like to quote one of my clients here, his favorite sentence, and he said it on stage many times already is just start. 'There is no point at a time where it's the right time or preparation you need to have.' As soon as you migrate to the cloud, you produce costs. And whether you did that for the last 10 years, or you just started your migration journey, you produce costs, right? And when you make the decision that you want to gain or maintain control about your IT resource spend, that's the very moment where you start basically start funnels. I think one advantage of funnels is that it's not right away about architecture, it can be, it really depends on your team, but there are so many low-hanging fruits on a higher level that can already have like a huge impact. It starts with providers specific features. Let's talk about AWS, for example, and the consolidated billing feature. The moment where you conglomerate your usage to one master account, you are able to get discounts. And this has a huge impact. Plus, and like if you think from the perspective of monitoring, it gives you a way better overview of what's going on. So these are easy steps. Another thing is to start onboarding processes between different departments, like set roundtables, say like listen, okay, we have to make room for discussion about this topic. At least get the buy-in from product owners, from line managers from finance, it's about starting.

Vanessa (25:07):  Definitely. Yeah. I mean, we have an ops consultant. So customers that approach us, they already have the issues, they already see their cloud bill exploding at the end of each month. But of course, you can start earlier than that. And the advantage of doing that even when you're just starting that cloud journey at your company, is that FinOps change, and the things you have to integrate into your hole, or can integrate into the development process. It's easier to start with that earlier because you're already in the change because you're getting used to the cloud and whole mechanics. And then it's just easier to start at the beginning and start doing it right. But of course, as Manuela said: just start!

Andy (25:58):  It's like the question, when's the best time to plant a tree? 20 years ago, and the second-best time is right now. So if you're at the beginning, then of course, start at the beginning, but wherever you are, start now.

Marc (26:10):  Hi, it's Marc, again, if you're interested in sustainability, and GreenOps, and FinOps, may I recommend Cheryl Hung's keynote from The DEVOPS conference - Copenhagen 2022. I'll leave a link for you in the show notes. Now back to the show.

Manuela (26:33):  And I think when it comes to kind of their like, again, it's a cultural management practice. So it's like everything and nothing, right? But I think you can narrow it down to, let's say, three success factors. I think what you need, at a certain point of time, best would be right away, is someone or rather a team dedicated to the topic to have some someone, people within your organization that continuously driving the topic. Because as with everything else, if you just drop the ball in the beginning, and you expect it to roll by itself, it doesn't work like that. And the second thing is that, at a certain point, you will need tools that support your journey, right? As we were talking in the beginning, you have to link performance and cost metrics. Usually, developers use performance to tracking through monitoring tools. But they don't display the data that come from the cloud bill. So either you do it yourself, or you find a partner. We are also working with external tools, we're using their cloud providers, cost management tools, it doesn't matter. But at a certain point, you need a tool dedicated to the topic. And then the third thing is a strategy, a plan. So what is the one thing you want to achieve in the beginning? Is it creating awareness within the company? Is it cutting costs by 10%? I don't know, there are many different options. Because in this context, I don't know how to phrase there right now: unpopular opinion, for me, cloud efficiency and cloud's costs are not the same. And yes, as an operating business, you are very happy to save money, or reduce costs. That's not, in my opinion, not what FinOps is about. It's about making what you have more efficient, and make it scalable, while maintaining control.

Andy (28:46):  Yeah, if you can increase your cost a little bit, but get several other benefits out of it and extract more value out of the efforts that you're putting into it, it might be worth it to increase the cost. So it shouldn't always be just reduce, reduce, reduce, but instead optimize, which doesn't necessarily mean reduce.

Vanessa (28:58):  And I would add to that, to make the FinOps practice sustainable in the long run, you need to buy in so you have like the two perspectives, to have a top-down and bottom-up. And you need both to make it, yeah. So top-down means it helps if you have to buy in from the C-level or team leads or whoever, right at the beginning because of course they can add some pressure to the topic. Of course, they can free up resources to then have like the resources people dedicated to the topic and studying that FinOps team or anything. But at the same time, you need the bottom-up people so you need two people that are excited about a topic and that work with and under topic so that they can really form I would say best practices for the company itself. Does customize best practices. And they then they can run around and tell their colleagues how awesome that is, and how much fun it is to do FinOps. And I think that's the only way you reach all the people in the whole company. Because at the end of the day, again, it's a change in the company culture.

Andy (30:10):  When I was spending 4000 per month on a dev system, it was really, really easy to get C-level by into let's fix this. But then getting the low-level buy in is often a bit more tricky. But as if we can kind of gamify it somehow. And like, here's the target you're trying to reach and make it kind of applicable to the, to the developers themselves, then maybe it's easier to get that by and also on the low level and push from the top or from the bottom up as well.

Manuela (30:43):  Yeah, I mean, it's the same with every incentive strategy, right? If you're the person that loves to come by bike to, to the office, not because you have to, but you like it. And I would say like if you reach your annual goals, you will get a car, I don't get you. So I think this whole gamification, and what's the benefit for the engineering and developing teams is to listen to them and try to understand what they need. We have a customer that made his like one of the big spenders within the organization, like one of the IT projects increase cost by 25%. decrease costs, sorry, about 25%, because you wanted to have a new hire, you wanted to have a new developer, and they agreed if he can manage to do that, he gets the higher. So that was the incentive. So they did work there, they made analysis and monitoring and like optimization for a couple of months, they reached the 25%. Easily, by the way, they didn't have to cancel a project or something. It was just about waste and inefficiencies. And then they got a new developer.

Andy (32:00):  But too often if we tell the development teams that uptime, performance, reliability, that's what you need to focus on...Ooh yeah, costs, we should think about and let's think about it but uptime, reliability performance. And if that's what the only goals are, then of course, that's what's going to be designed for. But if we can build in this FinOps and thinking about cost, thinking about efficiency and what not, into the low-level objectives as well, it's easier to get this bottom-up kind of buy in.

Vanessa (32:34):  And I'd say gamification is like my most favorite methodology or framework out there. Because I think at the end of the day, all of us just want to have fun in our daily lives. And a story of one of my customers is they really managed to build an IT community, not even focused on cloud topics, but they have like regular round tables and shared stories, and they really got the buy-in that it community at that at some point. They started with FinOps. And they wanted to motivate people to also do FinOps. And so, they somehow enforced that gamification approach by adding quizzes. So at one point, the topic of all of these community roundtables were of course, just around FinOps and how to save costs and how to improve and stuff like that. But then they added a quiz. They just implemented a quick app like a super small one. And they shared a quiz each week where you could collect points by answering questions about FinOps, then they had like WordPress website where they showed the leaderboard, but then one's going further: How do you get really defined so that the people participate in those things. And the tipping point for them was about giving them yeah, just prices for reaching the leaderboard, but interesting prizes. So they were asking their cloud providers about sending the merchandise, like really cool, AWS, Azure, GCP, whatever IBM merchandise, and they did that they were really happy to share their merchandise with the customer. They even got like problems with compliance because the merchandise was so valuable. But then for some reason, that was really the tipping point, because all of the developers were: they wanted that thing. They wanted that drone, that branded drone flying around in their garden or anything. And so, since then, the people were attending the round tables. I mean, it just exploded, and even beyond the borders of the IT people then suddenly also sales people came in and were like, "Okay, I saw the drone. I want one as well. How can I participate?" And then yeah, it just grew from there and it worked.

Marc (34:58):  Really cool. There's something that you guys’ kind of alluded to a little bit that I'd like to play with. Obviously, you need ownership for initiatives in order to get things done. And I'm kind of thinking like from maybe an SME perspective or something like that. When we say we need someone or a team dedicated to the topic to continuously drive it, I see a few different things. One is, is it easier to have an expert as a consultant, and we're all in the consulting business here. So we're not just self-promoting, but seriously, to have someone as an expert, as a consultant come in, and help to get the initiative started, understand, these are some best practices, these are some things. And then like the other part of this idea that I'm playing with is, can this be a guild? We said the word community, can it be a community? Or is this supposed to be like a mindset for the entire organization? Like, can you play with these topics a little bit and tell me what you think?

Vanessa (35:59):  I think when you start with a FinOps team, you have three different approaches. So the first one would be you have an interested person internally, that for some reason, is just interested in the topic. And of course, he or she needs education for that. So you would send them into training, there is the FinOps foundation out there, foundation that leads to topic, it's an open source communities, so that person can participate in can get experience and exchange with other people, and then evolve the best practices for your company that way, then the second approach would be, of course, to hire a person, I mean, FinOps is pretty new out there. So it will be hard to find a person doing FinOps, or at least here in Germany that started around two years ago with that password. But of course, maybe you have luck and find a person. And then the third approach would be to combine the first two, so you have an internal person that is semi interested, he or she can dedicate a bit of time to that topic. And you could kind of enable him by adding a consultant or by adding a kind of a FinOps coach, I'd say, and so that knowledge transfer is just faster than then if he or she does it on his own.

Marc (37:08):  Cool. I like so much, Vanessa, that you added the word coach there because I was thinking as if it was some external, it's going to be all about knowledge transfer. So and coaching is exactly about getting the best out of the people to under make sure that they understand the ways of doing things. I have another topic. So there's a sustainability angle here, isn't there? Would you like to open up about from FinOps to GreenOps, perhaps?

Vanessa (37:49):  Definitely. One of my favorite topics. Thanks for asking. So yeah, GreenOps is all about reducing the carbon footprint of your cloud or your Kubernetes cluster or whatever. And at the end of the day, FinOps and GreenOps are really related to each other. Because, of course, rightsizing resources, or just turning off an instance means also preventing the energy consumption of that instance. And so these topics are related to each other. But it's not like FinOps equals GreenOps, because some parts for example, rate negotiation, or getting a discount on your cloud resources. That, of course, doesn't save carbon at all. You just pay less. I think the GreenOps best practices and I love that you said GreenOps, but because I'm not sure that's already an official word. GreenOps is pretty similar to FinOps because it means or it also is about the developers taking action. Because you have to include that whole GreenOps mindset again into company. And that starts by creating awareness and transparency about the carbon footprint to resources.

Marc (39:03):  I think that we are nearing the end of our time. Is there anything else that you would like to add about FinOps or Liquid Reply today?

Manuela (39:16):  I think I would start with a FinOps part. I mean, you already experienced we are very, very passionate about the topic and we kind of evangelize it a lot. But I think and I truly believe that organizations nowadays can't get around pinups because you have more IT resource diversity, more it usage and cost variety than ever before, full stop, and you still need to be able to allocate costs. You still want to reduce costs, Spot inefficiencies, plan budgets, and means, yeah. So this is basically the reason why at a certain point, you need that. And I think the most important message I would like to send out is that you need dedication for that, think back about when innovation was something product teams were supposed to do like on the site. And then companies were wondering why they never got the unicorn idea on the market. Nowadays, we have hubs, accelerators, whole departments, taking care of old solely the innovation topic. And it kind of got a very, very importance in the whole how we pursue business development kind of thing. And I think with FinOps, in context of it, resource procurement and budgeting, it is the same. If you don't give people time to elaborate on the topic, somehow, it won't be done.

Vanessa (40:59):  So I'll cover the Liquid part. But you mentioned the word evangelizing. And I think that's a great starting point for finance. And I would say, you really need that FinOps mindset in the long run in your company. And you can have consultants like us, for example, to of course, kickstart that topic in the company. But at the end of the day, you need to buy in from all your people, your employees, your colleagues. So I still think it's a great way to really make the knowledge transfer a lot faster when you have consultants or when you're actively participating in stuff like the FinOps foundation, but you really have to make the change in your company. And in the processes in the people's head.

Marc (41:49):  Awesome. I have two questions that we are asking everyone that comes to our podcasts. And the first one is, think back to when you were a child, what was the first thing that you remember wanting to be when you grow up?

Vanessa (42:04):  No, I want to start.

Marc (42:09):  Okay. Go ahead Vanessa.

Vanessa (42:03):  I always wanted to become a policewoman. That never worked out. So the reason I wanted to do that job is all about justice and fairness and equality. I'm happy to still have a job that's really focused on these topics. That well, it didn't work out because I was wearing glasses at that time, and in Austria, it wasn't possible to have that career with wearing glasses at the same time. So yeah, that's how I ended up in IT then.

Marc (42:49):  Okay, cool. Thank you. All right.

Manuela (42:52):  I have to think about that's a tough one. I wanted to be CEO.

Marc (43:00):  Okay.

Manuela (43:01):  It was not about leading people or a company. I just wanted to leave the house every day with a suit like, like my dad did. I wanted to travel to important countries having important meetings, and wearing my suitcase. I basically did that for a while. Not as a CEO, obviously. But I was in product and project management before. And I had to travel a lot. But yeah, I ended up in IT as well.

Vanessa (43:31):  I mean, you can still wear that suitcase.

Manuela (43:34):  I do. It's quite funny.

Marc (43:41):  I think the word in English is precocious. Okay, question number two. And I won't pick on you by name this time. But do you remember a time in your life where you realized that you know what you had intended needed to change or maybe something reinforced that you were on the right path that you're on?

Manuela (44:01):  Yes, I think it was in my mid-20s. I was working for a couple of years in as I said product and project management. And I stopped learning something new every day. And I felt like this is since I'm very eager to gain knowledge and to learn. This was kind of a moment where I realized okay, I have to change something. I did. I quit my job. I went back to university. I was doing my master's in Applied Business Innovation, and I somehow accidentally slipped while studying into IT. I was like working for cybersecurity back then. And I learned something every day. And I figured, well, this is an industry where you never stop learning. And so I decided this is my new sweet spot. I want to stay here. Yeah.

Vanessa (44:55):  For me. When I grew up, I was always sitting in front of a computer, starting I think with nine years or so with the first computer we had at home. And so I was pretty serious about all of this IT things. Then I started software engineering and I ended up doing internships as a programmer. But pretty soon I was like, "Oh my god, it's so boring." So boring to sit in front of a computer or eight hours a day and just type in stuff and program things. And to be honest, I struggled a lot with that because I always saw myself as that IT person. But pretty quick, I found, I would say, my passion and talking to the people around me. And so yeah, I changed to technical project management, and was really happy with that. And to be honest, and now I still sit in front of my computer, like every single day of my life, I'd say, but it's fun. And it's okay to have that mixture of both worlds.

Marc (46:06):  Okay, wonderful. Thank you both, again, for joining the podcast. And I'll sign off now. Thank you, Manuela and Vanessa, I've learned a lot today. FinOps being a management and culture practice, to make what you have more efficient and with more control, bringing together people data and value. And I learned that it could be pretty easy to get buy in from the top down when we start talking about cost savings and getting in there ahead of the cloud bills going out of control. And I absolutely love this idea that there's never a right time to start other than right now. So if you are in the cloud, you know, start investigating and looking at FinOps today. And you know, not only will this potentially save you money, but it also makes the world a better place. Energy is a pretty hot topic at the moment. And it's time to start thinking about GreenOps as well. I'd like to thank you, Manuela and Vanessa, again, Andy for being part of this. And this is Marc in the DevOps Sauna podcast signing off. Thank you.

Andy (47:07):  Thank you very much.

Vanessa (47:09):  Bye. Thank you very much. 

Manuela (47:12):  Thank you.

Marc (47:15):  Before we go, let's give our guests an opportunity to introduce themselves and tell you a little bit about who we are.

Vanessa (47:32):  Hi, I'm Vanessa. I'm leading a team of excellent Philips’ consultants. All of them are awesome. I have a background in IT, as well as project management. And I ended up doing Fi Ops and I really love that my job mostly consists of talking to people and working with people. And I think that's what FinOps is all about. Bringing all of these people together. Thanks for the invite.

Manuela (47:59):  Hi my name is Manuela and I am a FinOps consultant at Liquid Reply. And I'm basically the numbers crunching person here. And focusing on cost monitoring, developing KPIs and optimizing cloud resource usage. And what I love about my job is that I can sit down with IT projects and learn about how they use the cloud and bring together what I see in the monitoring and how they use it. And then we think about how to optimize it together. I have been transitioning from innovation-oriented education. So I'm fairly new in the whole IT world, but always have been fascinated. I'm so excited to be here today.

Marc (48:50):  My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (48:55):  My name is Andy Allred and I'm doing platform engineering at Eficode.

Marc (48:59):  Thank you for listening. If you enjoyed what you heard, please like and subscribe it means the world to us. Also check out our other interesting talks and tune in for our next episode. Take care of yourself and remember what really matters is everything we do with machines is to help humans.