Episode Transcript
[00:00:00] Speaker A: We need to be devsecops, we need to do agile, we need to be 10x developers, we need to do AI prompting and I also want people to do finops. Hey, I'm not saying it needs to be cheap, it needs to be well spent.
We need to maximize business value out of your investment.
Sometimes that means you need to do more scaling, which is totally fine. But if you don't know if it is totally fine because nobody is using that little feature that you just built and then why are you building it? Sad that you need to spend first before you can make money, that's totally fine. Just not just a finance thing. And it is also something that you can at least bring to your product teams and say this product, how much is it making? So I think that story coming down from the top saying, hey, we are now driving a good business because our cost is this, but our revenue is this.
[00:00:47] Speaker B: Welcome everyone to a new episode of the FinOps weekly podcast. Today we have a very special guest, someone that I have been talking since and we have been interacting so a partner from a newsletter perspective. Today we have Mitchell. How are you doing man?
[00:01:01] Speaker A: I'm fine, doing fine. Thank you for inviting me here.
[00:01:04] Speaker B: Pleasure. Pleasure to have you. And today we have a very interesting talk, especially if you are a developer and you are in the Geneine ecosystem or if you are interested in all this open source stuff. We have someone that has maintained an open source project and we want to talk about it and how the developer's role is on Philips.
But before anything starts, Damian, how are you doing man?
[00:01:28] Speaker C: Doing great. It's always a pleasure to be here and thank you Michel for coming and joining us.
[00:01:35] Speaker B: No problem, pleasure. Pleasure to have you both here.
I wanted to start kicking things off for people to know that Mitchell runs the Azure cost CLI and maintains the project which is an open source CLI tool to help you with the Azure costs and want to ask you a bit more about what drives you to create this. What's the benefit for a developer to use this and if someone doesn't know the tool, like who would you suggest it should download it and how to use it. A bit more about how this project can help FinOps developer or any developer on Azure.
[00:02:15] Speaker A: Yeah, let me explain some of the background of it because I'm consultant with wixvia. So we had a big customer and they asked the question are we running cost effective?
And I think you probably recognize the question that the answer is always no, you're never going to run cost effective because you always have Cost because you have scaling problems or you have developer productivity, or you didn't make a choice yet. So that's an easy answer to give, but I want to have the answer on skill. And I had around 200 teams, a lot of Azure cost, a lot of different subscriptions. So we needed to scan their environment and also scan their Azure costs. And of course there's a lot of already existing tools in the market, but you need to install those, you need to set them up to start collecting their own database, their own storage.
So we thought, yeah, let's make that easier. How can we actually get it from the API? So that is where I started to look at APIs and got interested in how can you get the data from the Azure environment. And it's a very nice.
Well, nicely there isn't a set of APIs that allows you to get all the cost data.
And then I found another project in AWS land, another cli.
It was pretty neat, it was very easy to start. You could just kick it off and then it will show you the cost of the last week or month, whatever you had in different outputs and those really built and you could run it, have the output, put it in a slack message and then do something with it. And that really aligned with my thinking. What if you could get data out of the system and directly bring it to a developer so you could quickly see I spent this amount of money yesterday or this amount of money in the last couple of hours or this is what we're going to do in a couple of days, the forecasting and combine that with my love of developing, trying to see how we can get the console to do nice stuff and talking to APIs. I started to build this tool and it focuses on a couple of things. Easy install, so you need to get it without installing all kinds of components and build it yourself. Now, if you know Net a little bit, there's a nice NET tools stack that you can use to get the tools to your local machine and I wanted to be able to pick up the authentication you already have and if you're familiar with the AZ cli, added the Azure CLI that allows you to do all kinds of stuff within. In Azure land, this is. There is a concept of logging in. You need to authenticate yourself, you need to talk. I'm this person, I have access to this subscription. Let me see if I can leverage that. And luckily you can. In Net there's a lot of capabilities to capture a context which allows you to call APIs on behalf of the user so combine that with easy install, easy authentication to something else. I was able to fetch the data in all kinds of different structures like current cost, cost per day, cost per resource group, it have other dimensions around it, look at the forecasting cost and then triggered by what if you can actually format it differently. So the console is a very nice way and it looks very old school Ms. Dos, but it is a very nice way to visualize stuff as well. And I always wanted to play with the Spectre console just because I wanted to play with something and that has very nice bar graphs and you could make very nice overviews. So combined with that I was able to mimic what was on the Azure cost page and then show quickly to users, hey, this is the cost I had the last day or the last week or this is cost. What I kind of have to dive a little bit further. What if you have other formulas that converted to JSON or Excel or Markdown, and with Markdown you could hook us into your GitHub pipeline or any pipeline that you have. So you have an automated process.
And when I release this tool, of course I just announced it to say, hey, this is doing these kind of things. And apparently it's got some traction and I've got a lot of feedback for people that are using it to export and import the data to another system. They use it to actually feed it into another tool to actually process the data further.
They use it to generate reports because it generates the markdown. You can convert to HTML, you can actually send it for email to somebody else and have a weekly or daily report just by hooking it up to some sort of pipeline that allows you to get the data.
You can use it to make decisions. If the budget is higher than this or you basically have more anomaly, it does something very raw anomaly detection based on your last amount of cost that you have, you can trigger to be an.
You can trigger to run a negative value so you can stop your build because you did something that impacted your cost in the past. So all these kind of things are being used now with people to hook it into a pipeline model to generate outputs to use it for input output to other systems. I think that is a very nice way to see this tool integrated into a developer flow in interacting with data, etc.
And from there it grew to other overviews, getting the price list, see what is the most efficient region to run your your VM in. What's the most expensive one, the most cheapest one. So I'm experimenting with all the cost data that gets out of the system.
So I'll just give you attention.
[00:07:56] Speaker C: It's very good. It seems we see lately in the, you know, in the industry that a lot of the phenops or cost has been shipped to the DevOps to the engineering teams. It seems that you thought about it before, right?
Do you also see this movement?
[00:08:15] Speaker A: This movement if you look at the finops definition, it's a cultural thing and I think that is shared between all kinds of different disciplines. One of them is the engineering teams, it is the developers, it is the people, people that make the software. And what I see when I talk to developers, it's mostly fit ups. You already want us to do DevOps, we need to be DevSecOps, we need to do Agile, we need to be 10x developers, we do AI prompting and I also want people to do FinOps. Why?
What is for me to gain there? What can I do? FinOps is something that the finest people do. They do the contracting, they do their reservations and all the, the safety plan. I don't know anything about it and I think that you have as a developer you have a very big stake in it. All the users optimization is your part. You can do a lot of stuff there if you have the right tools and the right means to act on it. And that can be as far as the shift left methodology. If you do it as early in your development process you can actually make sure you have cost avoidance that you're not spending the cost because you didn't rule out that resource because you already sold. This doesn't make sense.
I'm scaling it now to 100. That makes, makes a lot of additional cost. Let's not do it, let's have a budget there that says you shouldn't do this because it has a much impact.
And I think that kind of help for developers can help them be more active, be more aware, be more working together with the FinOps team to save on the cost and make more efficient choices. And then you still have a finoff team that does more of the centralized work where they talk about hey, how do we educate the people? How do we enforce a culture in the company that is looking for the best value out of the clouds? How do you make sure that the right rates are negotiated, that you use the right plans?
They need the developers role. You cannot make a safety plan without knowing if this resource is going to be used for longer term. You need to have that conversation.
I think the spin off definition all captured that. But at this high level I'm trying to bring that down a little bit more concrete stuff.
[00:10:28] Speaker B: Yeah, you need to make it clear for the people to employ.
[00:10:33] Speaker A: Yeah. And I think the developers have, they don't know that yet too much. And of course there are mature teams which are cost aware. They really design with cost in mind. They have good conversation with the product owner, how much can this product cost?
But a lot of organizations don't, they just spend and they just think, hey, if I turn this option on, I get additional features and let's also turn it on in development and because that's easier. And then you have in development the server running 247 with all the bells and whistles on it and yeah, just spending money, you shouldn't be spending that money.
So there's no value, why should you run it? And I think that awareness, yeah, that's for a lot of companies not yet there.
And I hope with tools like the CLI tool, it's just a quick way to get started.
And I know there is also in aset, CLI tool is cost options.
Yeah. But they're very raw, you just get an export of your data. And I wanted to be a little bit more graphical about it and show you right in your face you have an anomaly, you can do something with it or this is a graphical way the cost that you're going to make. So what are you going to do about this? I think those things will help developers be more aware of it together with all the other stuff, tooling, processes, education, training, etc.
[00:11:51] Speaker B: Especially. And it reminds me of when you do like security validations or validations of some kind where you are provided with tools, new tools that you don't know because it's not like your main.
But they help you like okay, this is not well done. You need to do this, this and that. These are the guidelines, these are the tools that you can use and how you can implement them in your pipeline. So now the pipelines, I think we discussed this are larger, like more, have more steps. But the final product that you get once the pipeline is finished is way more bullish and way more finished. With security checks, fainup checks, validations, code validation, et cetera, et cetera. And those like yours style it in the workflow of the development, makes all the development process in a single cycle. Instead of making it different cycle like you deploy, you have a final product and then everyone attacks the final product. Right.
[00:12:54] Speaker A: I think we see a lot of companies did that you have certainly with finance it is normally you get the invoice days, days, weeks later and Then it goes to a completely different team. It goes sign off by some manager somewhere and he has no clue what he's signing off on. And I think that is something you want to bring much more closer to the development teams that needs good ownership. You need to have a right backing, naming etc so you know what is yours and what the shares etc. And you need to have that shift left methodology and the mindset that you actually. Yeah, like language security. If you find an and security vulnerability in production is much more costly to fix than when you find it already in development before it goes to all the stages to production. And the same with finops. If you basically find issues that can appear when you go to production and already fix it here it's cost avoidance. It's the best way you can have it not spending the cost because you don't need to.
So I think that is really where you see more vendors stepping in and tools to help us.
[00:13:54] Speaker B: Yeah, the preventive area instead of the reactive area.
And I wanted to ask you for developers that would be listening to us or watching because I know I have a lot of the audiences from the technical perspective you have to say the top two or three actions that a developer can do to help the cloud cost of what they normally do be reduced or be controlled. What's your top three actions that a developer could take?
[00:14:26] Speaker A: I think that near real time insight in your costs. If you don't have access to that as a developer, I think that's already a red flag. And again a lot of developers don't have that. They don't see it, they are being shielded away from it. It is in tools owned by another department that sees all the tools. So you need to enable that for your customers.
Yes, the Azure portal shows you some of the data, but only if you are allowed to go there. You can see on your subscription level the cost, but not if you're under a CSP because then the CSP is hiding the cost because of all the overfs. So that's something you need to expose to your customers that can either be so to your developers. So that can either be its own dashboarding, more access rights, etc. If you do not see what you're doing headed that's previous effect. If you press the pedal, you see your cost coming up or going down because you reduce the pedal. Yeah. Then you're basically driving blind. So that is the first step. I think the other one is having cost awareness. In your initial conversation with your product owner, a lot of people just start Building features make decisions there and they're not validating if that's a good decision based on cost.
They look at performance, they look at scalability, if you're lucky, they look hopefully at security, they look at the business feature, but not really at value.
I think that is also an agile thing.
You're really just building what the product owner says. But I think it's good to ask the question, is this something that you're going to see sold by a lot of people? What's the value that you want to get out of it? And if it adds a lot of value, then it is not a problem to spend money. I'm not saying it needs to be cheap, it needs to be well spent. You need to maximize the business value. That's the whole definition of finops, not save money. You need to maximize business value out of your investment.
And sometimes that means you need to do more scaling, which is totally fine. But if you don't know if it is totally fine because nobody is using that little feature that you just built and then why are you building it? Why are you building this with this technology? So that conversation is coffers and then a very simple one look at at the Azure calculator.
It's such a great tool to find out how you're being charged for certain stuff.
And a very simple example, a service bus in Azure, I think the cheapest variant is around a couple of euros a month and a little bit more expensive one is €10. And what I see with a lot of companies, they take the one of €600amonth. And why? Because they think we only need it because a it is premium. That could be good because it's premium and it has a F net support and we should use F net support for security.
I'm total favor of that.
Do you need this for acceptance? Do you need this for any other environment where you don't process production data? So if you don't know the difference, then you're easily spending in each environment around 600, €700 of additional cost that you don't need to make.
And same example with the app service, same example with API management.
You can make choices, but you need to know what kind of choices you need to make.
So be aware of your costs, have the right conversation with the business and be aware of what makes costs, where is the cost hidden? And sometimes it's as simple as reading the documentation or looking at the Azure portal and see the price calculated.
These three things help with setting states for a lot of stuff and of course the awareness of why you would do this isn't even what kind of impact you have.
Yeah.
[00:18:01] Speaker B: Once you know what you, how you. What you are spending and how it's going the money flow then you are able to do the adjustments and that's it. Right. Like first you need to be aware and then you need to, then you have to develop the knowledge or maybe the FinOps team can help and then you can do the savings. Right. Because otherwise it's important and it goes in those phases.
[00:18:24] Speaker A: You cannot do this right from the start. No, no, no. You need, you need to learn, you need to build up and that's fine. And then you least you're aware that you're not competent enough which is also good said that you need to spend first before you can make money. That's totally fine. At some point you go to a mode where you have more control over your processes where yeah cloud spend more and more important and then you need to get into those processes. Sometimes that means tools, sometimes it needs guidance card reels like, like this is where you can go to within that boundary, that's totally fine. But if it goes over the boundary maybe you should get an alert of a warning or you should get an email or maybe even stop the build because it goes over certain set of money.
I think these process will help you to still have speed in your process because I don't want it to be limited. I don't like a fin of steam that is saying no that shouldn't be the case.
You want a little bit of control there.
[00:19:22] Speaker B: That'S totally true and swapping a bit the following up but shopping a bit the orientation, making it on the C flat part like being. Because I like the orientation of making pre or let's say proactive approach. So basically what I'm saying is here like from someone that is a cloud architect or a developer designing a project that is going to be on cloud and you know for example a cloud migration or a new product.
Let's say what are your advices to make the cost like a requirement and what are your advice as well to build the cloud architecture in correlation to the cost. Because now we see like for example when I was designing cost was not a factor, it was efficiency, specific technologies, the tech stack, all this stuff but not the cost. The cost wasn't considered up until the end when you see the build. Right. But for someone that is designing what are your advices for making a cost efficient architecture for a product?
[00:20:28] Speaker A: Yeah, I think here it goes indeed back to that Question to your business, what is the goal? If the goal is going quick to market, that's something you need to bypass some of the process and focus more on the technical point of view that it is secure enough, performance enough and you can quickly go to market. If it is about, hey, this is a solution we know to kind of run for a couple of years. Yeah. Maybe it's more efficient to look at cost elements as well. And if you build a system that is, let's say a heavy data driven. So you do a lot of calls to your system. Yeah. Then you need to consider data calls. Yeah. Also cost money. Would it be more efficient to cast data or be more, more strict on the CDN or what kind of stuff to basically overload the cost there.
So then you make other kinds of choices. Then a CDN is not to make sure you have low latency. The CDN is there to offload your more expensive backend server or your database. You don't want the calls to happen. If you choose a more traditional VM like approach, then you need to look at do I need to scale it down at night or does it make sense to run 24 hours? Do I need to scale it up? Scale it down in another pattern?
Because that is more efficient. And if you don't ask those questions, just let it run for the whole day. That can also be a good answer because you don't want to spend time now on that problem. So again it goes back in and collect those requirements. And if you design with the cost in mind from a more architectural point of view, you should have that conversation.
And it can be a simple we don't know that is also an answer. And we don't know yet is also a good answer. But at least you have started that conversation and I can still make a decision later.
I think you get a different outcome if you look at cost than if you look at pure performance or scalability.
[00:22:16] Speaker C: Right. I think you got a point that I think. And of course there needs to be the phenotype needs to go there and ask the right questions.
[00:22:23] Speaker A: Right.
[00:22:23] Speaker C: You have to need to in the design there needs to be like a step in which the phenomenon steps in and just ask questions.
[00:22:29] Speaker A: Yeah.
And I think it also helps the cloud is there is not a platform to just run compute on because it's not just virtual machines. There's a lot of services that if you select them rightly, like the serverless functions, make a very good use case for a lot of functionality. But for other stuff, it doesn't make A lot of sense of the time it could take or the scalability that you might want to achieve or not.
If you don't make those choices, you will not end up with a good architecture.
So cost is a part of it, but I think under the table you always use it as a little bit of an additional attention point in your mind when you pick the right PaaS services and SaaS service in the cloud.
So it's always needed. And I think the cloud offers you all those capabilities. I think a lot of developers might not look at it enough yet.
Just take another criteria like performance, features, scalability that you might have. Not directly on cost, but it is an important element to consider and I think you get a better application.
[00:23:36] Speaker C: I think that the developers don't look at it because I think they're also management needs to come in here and put them in their performance review. It also kind of correlates to the previous question that I wanted to ask. You know that you what you don't need to blame also the developments also where are the managers?
[00:23:56] Speaker A: No, but you can turn it around if you want to do it from top down. You can promote or at least make sure everybody's aware of it.
You can drill down. Cost is important also for me as an organization, just not just a finance thing. And it is also something that you can at least bring to your product teams and say this product, how much is it making?
Because a lot of teams don't know how much the product is even making in revenue. And I only hear at some point, yeah, this is a very expensive. If you look at the cloud bill, the cloud bill is one thing. You also have your people working. And I even have customers say maybe we should go back to the traditional data center because it is a lot cheaper.
Yes, and traditional data center can be cheaper, but you need to do upfront commits, you need to buy stuff and you need to have the skill set to maintain it. And I think a lot of people forget about it. So if you don't take all these things in consideration, the cloud is in a lot of times cheaper, more efficient, more efficient to run if you do it correctly, if you use cloud elements of it. And I think if you don't let, if you don't from a management point of view show you that. So this is a project cost us the five people on this project. But all those five developers are actually developing. They are not maintaining. They use the right stuff to actually add value. And they're not just maintaining servers because that's what you have when you go to your data center, the backups, disk replacements, all the other things that you don't want to do anymore. So I think that story coming down from the top saying, hey, we are now driving a good business because our cost is this, but our revenue is this and that. I think that is a more efficient picture than saying you need to be more, you need to be cheaper, you need to be more cost effective.
[00:25:38] Speaker C: That is a good point that they need to start talking about business value. Does it make sense from business?
[00:25:46] Speaker A: Yeah, I think you want to maximize the business value out of your cloud and that the cloud offers you a lot of tools for that. That's scaling up. Scaling down. If you turn it off, you don't appear any cost. So there's a lot of features there that helps you. You need to use it, you need to make use of it correctly. And sometimes it doesn't make sense to scale because you want to go fast. You need to get quick feedback, you need to get a server up and running. It takes more development time to build that. You don't have that yet, which is okay as long as you're aware and then you have the discussion with your product owner and then you have that discussion with your management team. So yeah, we're aware this cost now a lot of money. Yeah, look, look what we're going to bring in for the next three months and then we're going to talk about scaling down, which is also fine.
[00:26:33] Speaker B: And also I notice personally that when you are engaged, let's say in the conversation of the KPA, the business KPIs and when you know what your product brings to the company or to the customer, not like this quarter report will say yeah, send me a statistics or whatsoever. It's not like, well you know like you can go and check how much users you have per month or how many documents you have processed once you know the developer knows that it's much more engaged with the product and then it can relate.
Okay, are we scaling good, are we scaling bad? We are spending more but the number of documents, let's say is the same. So we are not probably scaling good. You are just spending resources because we have installed whatever update that doesn't work anymore or we have right size, wrong the resources for our kubernetes cluster and we are overspending because of whatsoever. I think once you relate that the developers are much more engaged and much more prone to take action and know the business value that they do.
[00:27:35] Speaker A: Yeah, indeed. And I think that that cloud unit economics where you look at how much is an actual user costing me if I onboard 10 additional users, is my cost linear going up or is it exponential going up or is that not really impacting? Because I have chosen architecture model that allows me to scale the cost over multiple users and so the more user have the cheaper I am because it makes makes a lot more sense in the end. But if you pick a model that's heavily focused on security, then every user gets his own own environment. Yeah. That is of course a linear growth with which you use this. You're not gonna make make a huge profit on your cloud setup in that sense. So these kind of things. If you don't consider those. Yeah you make other architecture choices and you.
I think cloud unit economics is very tricky subject but if you do it right it can really help you to have that conversation. Is the product really successful?
[00:28:31] Speaker B: And it's the core like it's the core of the business. It's the core of what it needs to be. I think it's been a forgotten and I think where it's where finance can have more like an educative part as well and can be much more involved in the development because they are very. They are much more aware of what the whole thing means and that's where the finop let's say finance part can be like okay, how much are you spending Then this is the Oracle build. Then okay, which part is the specific cloud or the specific kubernetes deployment or specific that and then from making being able to the developer to digest or divide the bill and the finance to relate to the business. This is where you build the unit economics.
[00:29:20] Speaker A: That is very interesting one because it's very hard for developers to understand what is actually being sold at the other side of the company and how that relates back to your financial processes and then how it relates back to technical processes. So you do normally have some sort of nested cloud economics where you're your top management reports over different units. Then your developer team probably reports on. But they need to align somewhere. They need to. We have some clues and I think the FinOps team, the centralized FinOps team is the one that can help you. Yeah make those links together. So you see this is costing money because this is more optimized or less optimized and you can link them together.
But this is really tricky. I don't see a lot of companies doing it doing it enough, doing it efficiently enough. They look at other kinds of costs mostly on project cost. How much you say with five developers they spent a Couple of sprints so that this 50k, that is 100k because this is the amount of people I need to set up for this project and that is nice but at some point it goes into some modes that it's constantly run. Yeah. What is the new running cost? What do you really spend per user, per. Per hour, per minute, whatever that is, runs. I think a lot of people don't know that. Well, this is a very interesting question.
[00:30:33] Speaker B: So and, and what I wanted to. To drive back the topic a bit and you know, since you are also writing stuff and you know you have your Azure FinOps newsletter and the mine Byte newsletter and you have the open which will leave the links in the description along with finos Weekly and everything. But wanted to ask you a bit more on the open source perspective and from the. Let's say from the contributor perspective because we may have people listening to us, you know, want to learn, want to contribute. How this contributing mode, let's say that is also something that I do. How is it helping you and how has evolved, let's say your career in FinOps and as a professional because you know, I always, you know suggest to people, okay, there is a form in the newsletter if you want to write a blog. We'll share with you and we'll ask you how this has helped you so you can inspire other people listening to us to do the same.
[00:31:34] Speaker A: Yeah, yeah, yeah. I think, yeah for me sharing is caring. I think it really helped to share knowledge and indeed I do that via newsletters. My open source tools. It's for me a way to get my thoughts on paper and have some sort of reference as well. So I like my, I like with my own ideas so write them down. And I also share it. I share it on LinkedIn, I share it on the.
On paper by having the emails, etc.
But the interaction, that's the interesting part. And I See Mostly on LinkedIn I get a lot of feedback from mostly from vendors which want to sell another platform and not like you sell to me because they see I'm a consultant so it's not very efficient to sell me a cloud platform. But mostly this is a service that adds value if you sell basically advices to your customers. But for me it's interesting to see what kind of problems they're tackling what kind of things in the industry are really working well enough. So for me that is already in validation the story I just have about shift left a couple of companies which are really into that field. Well in the past you saw Companies building dashboards, that was the thing. You ingested all kinds of data for all kinds of cloud platforms. You built big dashboards and then you had a couple of people that looked at the dashboards and did something with it. What I now see is more focus companies that are either on the centralized part, on the savings part and you have companies that are more on how do I get the developers to do something to getting alerts directly on their screen and say hey, this is something you need to fix. I can fix it for you, I can do it automatically if you don't respond even, but we can do it for you or even further we already show you the cost inside your visual studio and when you do a pull request I already say hey, this is gonna change your cost from X to a.
Are you aware of that? These kind of tools and in this case I'm mentioning info cost because I really like the tool to help in that shift left process.
They take a niche in the whole finops which basically validates what I'm also trying to advocate. So for me it's really nice to see people around it and have that conversation. And if you look at more open source part I get some nice bugs in because the cost APIs in Azure are tricky and I don't have access to all the 30, 40 different subscription levels and not even to all the same amount of cost that some of the customers have. I got some nice book reports that hey, we try to render 40 million in the system but you don't have room enough in your screen. So I needed to get some formatters in there. Yeah, that's not normally a value I test with in some of my subscriptions and you see that Microsoft is moving to other kinds of subscriptions levels, other kinds of APIs. So that kind of feedback is very nice for people in the field, even from Microsoft itself. I'm an Azure mvp, so I got some links to the course people got some feedback from them about what we can do, how we can set up stuff.
So I think it's a very nice industry that is a little bit niche, a little bit small, a little bit growing as well in a lot of factors and getting more and more value.
And I think it's also about time because we sold DevOps for the consulted for the last 20 years we sold DevOps SecOps and now we're we see a cloud is there, is cloud is there to stay. We know how to do DevOps, how do we get devoted under control and now FinOps is not a replacement. I Think it's an extension to the processes that helps this conversation.
[00:35:13] Speaker C: That's very good. I think that also, you know, to all the content creators out there, you know, there is a saying that until you don't teach, you don't know. So when you share something like you are teaching, like you said before, you are thinking about it, you make it clearer because you want to express it. And I think it's a win win. You also, it also help you with, you know, connect with other people and share ideas. So again, you understand it more and you share it with them. It's a win win everyone.
[00:35:45] Speaker A: And you really dive into concepts and look up the documentation, play with a couple of things and then, yeah, also from your own experience, I'm, I'm a more broad consultant, so I'm, I'm currently doing AWS jobs, which is completely different than how Azure is doing stuff, which is also nice for the comparison between the two systems and how to do cost management.
So you learn on the job, you learn by experimenting, you learn by reading and investigating. And then writing it down is just another dimension of how do you get your thoughts on paper and share it and get feedback.
I like it. I think it really helps to improve yourself and let other people also learn along, get more knowledge.
[00:36:31] Speaker B: As a recommendation from someone that does it and has previously been stuck in the learning process that you always learn up until some point and then when you start contributing, you get to a whole another level and when you start teaching, you get to a whole another level that because you are, you reflect yourself that you don't. Maybe you don't know as much as you think you know, but it's also good because this will help you learn better and learn more and this way. That's why I always suggest people to, you know, write, do exercises, everything practical. Because learning, you know, seeing material is okay and I always include it. But it's the first step, Dennis, putting yourself out there and sharing the content with, with the others so you can improve because otherwise if you don't share it, you don't get feedback. And without feedback you can improve.
[00:37:24] Speaker A: Yeah, and that's totally true. I think a lot of people underestimate how many people are actually sharing. It is a very small percentage. A lot of people are, are just consuming, which is fine. I'm not saying you need, you need to produce, but it helps you to be indeed more learning more stuff. It helps you to be more active and it also learns how you connect to other people and get, get more interaction. Like we're having now I probably would have never met you in this capacity if I didn't have the conversations yet in the past. So it helped to broaden your horizon and I always welcome people to be more outspoken to share the information I have and I hope it's an open industry and open world where you can just voice your opinion there.
Yeah try try to tell something. I think that always helps.
[00:38:15] Speaker B: Yeah and if you think there is always people you know listening and will in especially in this community as normally you know Damian said that is very surprised that there is a lot of contribution. There is a lot of well thought about. There's a lot of benefit of you know people looking forward to it eager to learn. There is there is not as much content as there is in other topics. So I think people is eager to learn and it's also eager to help getting you better on contributing. Right. That's that's something that I also feel when, when I see that people surprised like yeah I didn't do very much like you are probably one of the unique people that contribute so please continue doing that because I, I it's super difficult for me to find this type of content so I always like like encourage people to to do the same.
[00:39:04] Speaker A: Yeah and it is broader finops is is. I'm not saying it's new but it is is relatively new. It is based on on a technology that is still growing and electric cloud is constantly changing as well and it consists of a lot of broad subjects from from developers to finance to business to unit economics to working together with DevOps but also AI how to use AI in depth in FinOps or the other way around. What is phenols in AI. So there's a lot of things you you need to consider and I really love to read stories about how people do it in their organizations how what kind of benefit they got out of it how much they they optimize or saved because they they look to find something and there's some good stories there that they got. Okay. I never have thought about that but you apparently you you created the right report. If you looked at something or going from version X to version I already help you save this amount of money or choosing another architecture. Those real life stories I think those for me are really valuable because they prove that it can really work. It can make a difference.
That's what I really would like to see indeed.
[00:40:11] Speaker B: That's super inspiring.
So Mitchell, pleasure to have you today. It's been a wonderful talk. I hope people have learned a lot about the tool, the work that you do. And we left all the links in the description below. It's a pleasure to have you. It's a pleasure to have you in the community and also to work with you and to share stuff together.
So, man, pleasure and thanks for attending today.
[00:40:37] Speaker A: It was a nice chat.
Thank you very much.
[00:40:40] Speaker B: Thank you and see you everyone in the next episode. Bye bye.
Sam.
