Episode Transcript
[00:00:02] Speaker A: So welcome everyone to a new episode of the Finops Weekly podcast. Today we are going to talk about collaboration focus a little bit of, you know, combining things together in Finops, which is a practice that you know, everyone has to do from time to time. And for people that are working with different Personas or with different clouds, I think this podcast will be very, very interesting. And two talk with us about it. We have Larry, Abby. Larry, how are you?
[00:00:31] Speaker B: Hi. Hi Victor. I'm doing great. How you doing sir?
[00:00:34] Speaker A: Doing great, doing great. A pleasure to have you here and we of course have our co host, Damian Damien. How are you?
[00:00:40] Speaker C: Doing great actually.
[00:00:44] Speaker B: How's.
[00:00:44] Speaker C: I met Larry in the foundation event was great finally meeting you face to face and good to have you here with us.
[00:00:53] Speaker B: Likewise.
Yeah, yeah, we got a time.
[00:00:57] Speaker A: Yeah that, that's great. I, I, I, it's a, I couldn't, I couldn't be there but you know, great to, to Fino's minds. Met each other on, on events and yeah, we, we are going to talk about a bit of that about you know, Personas collaborations and, and how this impacts the Phoenix world. So Larry has a large experience in the Finops ecosystem, especially leading teams. So with leading teams you are always talking about talking with Personas in your team and also with Personas in other teams. So from your perspective and your experience, what's the role of collaboration in FinOps with other teams and what's the role and then I can forward about what's the role of communication in phenops in general?
[00:01:51] Speaker B: Yeah, it's a great question.
Very. I'll say you can go lots of different directions but just to zero in on it, Victor.
Collaboration is of utmost importance and a key element as a part of being a successful FinOps practitioner, person, whatever. If you're working in FinOps, your stakeholders, your partners, your allies, people you're going to work with in the company, outside the company, etc, they are vast. There's, you're working with lots of different people. Even with small companies you're still working with lots of people, especially engineering, product, finance, procurement, etc, so you collaborate with all of them and having the ability to communicate with them and understand where they're coming from. To your second question, how important is communication too?
It's very, very important.
So understanding that engineers are thinking about one thing usually, right? Shipping, code, developing new features, fixing bugs, being more performance and so forth and finance, you know, try to cut costs or improve value, profitability, manage budgets, you know, things like that. It's. They're very different, right. So you got to know who you're, who you're talking to.
I'll say first and foremost.
[00:03:23] Speaker A: That'S, that's great. I think that the collaboration, the communication thingy, it's, it's very important. I think I agree that this one of the most important things to, to cover in, in finops and yeah, especially leading team. So what do you think based on, you know, all the different Personas that are involved such as Phenops, engineering, finance, what do you think for, for the Phenops team is let's say the easiest one to approach and what is your, the, the most difficult one to approach and to make take action? From your experience, it cannot be. Maybe not yours, but from your experience what, what are your difficult Personas on, on your side?
[00:04:11] Speaker B: Yeah, I'll say for me the easiest one to approach would be engineering and that's, that's because I have a, I have a technical engineering architecture background so, so I understand what engineering is going through and what their concerns are, why they care about this versus that. You know, and having been on that side for so long, you know, when someone that's financed comes knocking, it's usually not good.
And so not doing what has been done to me in the past, but instead engaging differently with folks from, from finops as, as a fellow engineer and, and people talking and relating to me going back to the collaboration communication point where I'm able to just be, you know, go with the flow, understand what they're doing, ask questions and lead with a carrot versus a, I'll say a stick.
So that's, that's where I've thought about that. What about you two? What's, what's your.
[00:05:18] Speaker A: Yeah, I'm going to ask that, I'm going to ask Damian about it, but I think he seemed very surprised from your answer.
[00:05:27] Speaker C: Well, to be honest, you know, we had several, many, many talks here in, in our channel and always the people say, you know, the engineers is the toughest one. I came from being an engineer myself, but I find it, I have to agree with most of the people that been here in the channel. For me it's most difficult to work with engineering because I feel that it's hard to shift them. Like you were saying, they have these targets that they need to meet and it's shipping the code and they never find time to do like these optimizations or try to even you know, think about automations.
So it was always like discussion and after discussions and discussions trying to make them, you know, work, do some cleanups and in this challenge, by the way, we say we discussed many things, like, you know, many, many, you know, we gave many ideas like, you know, tell the engineers how to, you know, you're going to make, you know, save money, and you can increase your team, save money and do innovation.
Also, you know, about putting, like, these dashboards in front of them so they can see all the time what, you know, what's going on and from, from, from, you know, from economic perspective.
But it will be interesting, you know, to hear more from you, from you, what, what other, you know, strategies you have, because he's working pretty well. Yeah. Yeah.
[00:07:21] Speaker B: I, I, I love your answer. That's typically what I hear from people.
And I'm gonna, I'm gonna, you know, we, we, we shared a, you know, fun evening there, talking over, over dinner and stuff. 1, 1 Light at FinOps X. So I'm gonna, I'm gonna pull on a thread that used some, some language there. You said, telling engineers.
So you tell them something, they'll likely get defensive and not want to take action on it. Right. But if you propose it to and you ask them, or here's the data, what do you think about this? Do you notice anything with this? Does this look right?
And rather than telling them, hey, you've got a problem here, you need to go fix this instead, ask them, do you see anything that's, with this that could, you know, can you explain this to me? I want to learn more about your systems, the technologies, why it's the way it is, and just being curious about it and not like dictating and putting them, making them defensive.
So if you can, if you can do that, then my experience are much easier to engage and talk with and, but still, you'll run into people that are, yeah, don't talk to me. I don't care about costs. Right. But their manager, director, etcetera, you know, might be willing to have the conversation.
So what do you think about that? So engage, like asking them versus telling Damian.
[00:08:53] Speaker C: I think it's a great, it's all about the message. Eventually.
It's how you.
I like that idea a lot. It's all about the right terminology.
You know, I know that Victor Engineering. So sometimes we have discussions, and every time he hears something like that, he gets upset because, I mean, I'm a DevOps. I mean, don't tell me what to do.
But, you know, Big Top did. But actually he initiated Phenox. Right. It's something you start.
You didn't, you weren't there.
[00:09:26] Speaker A: Yeah, I can share my story. Like some, someone from. From coming from the, from the engineering side. I know what the daily job of an engineer is and the idea that or when I encountered is like yeah, the nails do not take action. It's like yeah, because we are the ones that have to take action.
You may not and that's something that people don't say like you dictate and as Larry said someone has to do it.
Will it be you or will be the engineer? So if you think that people need to do it, you need to make their life easier and make them have options and make their life easier as much as possible. And that's what I mean sometimes when I like yeah, I don't know how my engine is with the take action is like have you teach them how to actually do this stuff. Because if you teach an engineer or you show him or her how to do stuff they will do it. And if it's innovative like for example I can tell that when I discovered this Kube Green tool that was an open source tool to start to schedule shutdowns on Kubernetes you just put all replicas to zero at a given time. That was super innovative for me because it was the mix of doing Kubernetes stuff and doing the Kubernetes stuff applied to FinOps.
But I had to go and discover and know the tool and how to actually do it. If you just let like yeah this is a tool that you can use for schedule automation. You just have to put this manifest. It's that easy as a finops then it will. You will probably have schedule shutdowns made already. Same with governance. When you have governance policies that are a terraform that you can download from a reporter file probably governance will be put in place.
So my advice is like make engineers life easier and you will get some feedback from the FinOps and you will start seeing some actions like as reading the cloud finops book as well and diving and this conversation is like the FinOps team needs to do all the optimization and do the guidelines and etc but the actual like optimization like the details adjusting the instances will be done but the engineers mat engineers will need don't know how many instances there are and what's the most optimal for each specific world of them.
Tell them that information and they will actually like change that and be that easy.
Because for example in my case I don't have time to know all the instances in gcp.
I really don't care about that. I know one that is uptime. My application is live and it's not having me any errors on that and I then check the cost because I care about it. But I understand that people don't care about it rather than. You don't have pots exploding over the.
That's the most important thing.
Yeah, it's, it's interesting.
[00:12:34] Speaker C: It's.
[00:12:35] Speaker A: Yeah, they're learning.
[00:12:36] Speaker B: Yeah. I was just. I love what you're saying. They're making engineers lives easier. And I'll say if you, if you engage them with, with questions and curiosity, they're, they're likely to, to they want to brag about the cool stuff they've built and done. Right. So they want to show this to you. It's like yes, awesome, right? Then you could start building that relationship and at a certain point Damien, you could say because you have a really strong relationship, you tell them hey, you need to fix this, whatever. Right?
But before you get to that point just hey, what do you think about this?
Teach me about your systems, your services, your technologies, etc.
And you can then teach them throughout.
Kind of teach them fin outs a little bit. Teach them about costs, teach them, show them the data, start planting the seeds and introducing them to this stuff. Because engineers, I'll say most if not all really care about value and value comes to them is like efficiency and performance.
It's like less lines of code, it's more efficient, it's more performant, it's cheaper.
Right.
It's a good thing, it's more sustainable, it's better for the environment, etc.
They'll get fired up and passionate about this stuff.
And, and as a, as a finops person you don't have the ability to like dictate go do this typically within organizations because you're not at the level to be able to influence like a CTO to be like you're doing this right.
So but what I'll say at the same time while you're working with engineers to build up that relationship, also having the relationship at the leadership level or Persona leadership level to then drive, I'll say top down approaches that can help finops even further be successful and you can let the CTO be the bad guy or bad gal, whatever, right. And say go, go do this. Right. But yeah, we can do that.
[00:14:41] Speaker C: Yeah, we were talking once that we need to like you know, pulling the management and adding into the performance review and also you know, if it's in the performance review then maybe, maybe he will do it. It will be, you know, he will think about the bonus of the end of year and he will Try to do that as well. But you, you, you give me another idea. We're talking about innovation, stuff like that and there are a lot of companies that actually, you know, do the 80, 20. So either we, we need to add there the 70, 15, 15 like innovation and phenomenal 1515 and then it works. 70 or maybe part of the innovation can be the, the pheno. But that's just a thought that what you were talking about thinking.
[00:15:31] Speaker A: No, no, no, that's, that's a good observation and I think that should be in the conversation because as reminding of what the AWS Rick said.
I remember that he mentioned about that making a more cost efficient application is probably making it a more performant application because you are using less resources for the same thing and you are optimizing the stuff and you are innovating the solution and probably coming with a better architecture.
So that's for sure happen and wanting to transition a bit into, you know, we are talking about architectures and all this complex stuff. I want to talk a bit about multi cloud because some people might be, you know, dealing with one cloud and maybe get used to aws, gcp, Azure and they are super focused into it. But I know that well when you get to multi cloud and you try to group data coming from different resources and trying to control multiple clouds, try to unify let's say.
So it's, it's a challenge. So how have you experienced this multi cloud challenge in, in your case and what are your advice Larry, to people that are maybe you know, starting with a new cloud or starting to want to unify clouds? What are your, your experience and advice there?
[00:16:55] Speaker B: Yeah, I'll say that from a finops perspective that definitely learning the basics with the cloud like a, like a cloud practitioner. Azure, Azure Fundamentals, gcp similar. Right. Going through that basic level of training. So you can at least understand the terminology because they're similar, but they're quite different between all the major clouds. Right.
Basic training stuff and then getting in there and experimenting, looking around, harnessing the data, the cost information. Where is it at in Azure vs AWS vs GCP?
How do you answer similar questions if you're an AWS expert?
You know the console cost Explorer, all that good stuff set. Right. But when you go to Azure gcp, it's similar and it's different enough that you're like pulling your hair out. How do I configure like building profiles or something on Azure?
Like this doesn't really exist on the AWS side like apples to apples. So like Working through that, experimenting with it. And then I'll say at the end of the day, it's really important when you're doing multi cloud to have a single pane of glass to understand all your costs.
And so if you're in one cloud, expanding to others, or if you come into a new role and you've got multiple clouds set up or multiple organizations or tenants, subscriptions, et cetera, projects. Right.
Having one tool to look at all that from top down is of extreme importance because likely multi cloud one cloud is going to be larger than the others.
I've not met one, I'll say practitioner yet that I can recall off the top of my head where it's like, oh, we're split evenly between all three or between two or typically one's higher than the other. Right.
But having all that into one view and then setting up basic like anomaly detection, budget reports, this, that and the other, let us really stay on top of it and understand then like how are you using this cloud versus that cloud, what engineering capabilities are between the two, what business decisions have been made to do this versus that.
And then, you know, optimization, allocation, there's all sorts of other things to get consider that are different between the clouds too. So they're similar enough, but they're different enough to where you may have to bring in or may have to hire some additional help within like Azure or GCP if you're an AWS person to kind of help bridge that gap or you upskill yourself too. So I don't know what's your experience been like, Victor?
[00:19:38] Speaker A: On my side, I have to say that I transitioned from AWS to GCP based on my role and it was definitely different.
I'm now more skilled, way more skilled in GCP that I was even in aws. And it's different, like coming from the engineering side and even from the cost side is way different. So you need to have knowledge on those, like pure knowledge about understanding the tool and using the tool, otherwise you are lost. And what you say about having a single pane of glass, I totally agree. Having a showback tool or especially on the showback side like or visualization tool that you can see all the cost aggregated and you can search and you can find whether it's buy or build case you need something that you can see, every and everyone can go and check and see their cost. And you know, everyone, like, I mean everyone should check the cost. Same as you can see your security issues, you should see your cost and you should see everything.
If you Are an engineer responsible of that cost?
[00:20:49] Speaker C: For sure.
[00:20:50] Speaker A: So I don't know Damien, in your case have you have fought, you know, different clouds, the sceneries, let's say reconciliating cloud invoices, all this stuff like how do you, how you found that?
[00:21:03] Speaker C: And I started the very strong with AWS and then you know, I was working there for the Israeli army, you know, the IDF and then the government made some RFP and both AWS and GCP1.
So what that happened is that basically the most of the organization there were very strong in Azure or they had AWS added either. All of a sudden you were in a place that they had three clouds so you had to learn the three of them.
And I agree with that right there. You need to have basic, at least basic technology because if not you cannot give the, you cannot communicate well with engineering teams.
You don't go deep dive deep, deep enough to understand what is the value adding addition that you can bring not only just the economic but also other sides that you can bring to the table in the discussions and the more technical that you are, it's easier.
And again some things that behave in a specific way in a cloud that you are familiar with all of a sudden were different there. So you cannot give the same recommendations.
And the other thing was that I think the other change that came was the focus.
And what the focus brought was also something that basically that helps you a lot in, in a way that you can think about it from perspective. If you want to do one dashboard, then you do it one time and all of the things correlate together because they have all the same fields not thinking where do I get this information? Which field do I get from here? So I think that the focus was also a very good thing that happened and helped a lot in that point, at least from the visualization point.
So that was my.
Yeah, part of the journey.
[00:23:26] Speaker A: That's a good take. And yeah, definitely when a new cloud appears and you need to support a new cloud, it's totally a disruption. Especially if you have like multi cloud systems working for, for the same project and you cannot separate from, from project to project and you know, you need to integrate stuff, it's. It's tricky. And continuing on the point that you raised about focus, right. I know Larry is a maintainer of the project and we have asked about the evolution of it and how it helped and you mentioned how that establish a framework, a system and a specification for all the cloud providers to align on the output.
So Larry, I want you coming From Hong, this experience and being a maintainer of it, how do you think the adoption of Focus will be in the coming future?
What do you see and what things do you see built in front of Focus that could be, or on top of Focus that could be, let's say, almost generally available for, for everyone? Do you see open source tools? Do you see cloud native tools? Do you see vendor tools? What, what's your, your perspective on what can be built on top of focus?
[00:24:51] Speaker B: Yeah. So let's talk about adoption first and foremost. That's, that's definitely front of, front of mind for us as maintainers and the FinOps foundation, you know, Linux foundation sponsoring focus.
So with 1.2 that just came out, the additional columns that support SAS and other data, other use cases enables to go beyond just CSPs, and that's important because it's a great step.
There are less than 10 CSPs ish. Right.
There are thousands of SaaS, companies, technology companies and other companies that are billing their customers information. Right.
And so I've viewed, I view 1.2 as a, as a next step to really help drive that. I'll say foundational adoption for going from less than 10 to thousands or tens of thousands of companies that could be generating the Focus data set.
It's not going to happen overnight, but we're already seeing some companies starting to commit towards generating that data for their customers, either through APIs, data sets, etc.
And so as we evolve Focus with every release, we're going to set things up so that it can be more successful and adoption will keep hopefully. I expect it to just snowball to where it becomes like, this is the way people are seeing it.
This is how the terminology, right? It's, it's, it's standardizing like we talked about earlier, when you go between the different clouds, things are, they're different terms for roughly the same thing.
Focus is one taxonomy, one dictionary at which to call that thing.
And a lot of success so far with different use cases within Focus to show that even the terminology is helping a lot of people out within companies or between companies, etc.
I think through that the adoption will continue to go basically up and to the right.
And to your question, Victoria, Open source, cloud, native, vendor, etc.
Yeah, I think it's going to build like people are going to identify that and they're going to build solutions to take advantage of that to either open source, you know, just help, help the general community on things.
Cloud, native, you got AWS and Azure and Gcp kind of at the foremost of that, the front of that where you've got dashboards on quicksight within AWS that can bring in focus data. And look at it there you've got the FinOps hub within Azure. That's really cool thing, right? They're showing a lot of adoption there.
And then finally you've got vendor tools, you've got different tools that will allow you to ingest Focus or maybe export it, maybe show it in the focus data too.
I expect that as it starts snowballing more you'll start seeing more adoption from from the vendors, from the CSPS etc to where builds this, I'll say like marketplace or ecosystem surrounding focus that is going to help FinOps and people across companies, all these Personas like we talked about to get at their data much more readily than they have ever in the past.
And I love this because versus getting the data maybe out of your ERP system. But if you have FinOps tools or open source projects and things that understand allocation, visualization, showback, etc.
Then you're able to get so much more granular and maybe more real time with the data versus like your ERP system.
So I think this is going to continue to grow and evolve over time.
So what do you think Victor?
How are you positioning yourself to take advantage of focus?
[00:29:20] Speaker A: So my main take or what I want to work probably in the future is the open source stuff like what can can be done or how you can leverage that for the open source and you know, creating, tooling or any let's say already done case that leverages focus. Because you say yeah there is focus, there is all of these use case but actually having like a tool or a tool, a dashboard, an implementation details, some code that can actually do the stuff like done for you is something that I will probably lore in the future definitely. And I think it's what I'm seeing. I know some practitioners such as Isadora made a Focus dashboard with Power bi that is already something that you can Download there on GitHub.
So a lot of people are doing great stuff and evolving on this question about the evolution of focus, what do you think will happen or what's your say, your insight about the hybrid cloud, private cloud, the data centers? Because we know that that's going to be an important role in the future, especially you know, with AI and these regional restrictions that we are experimenting.
So do you think focus will be at one point able to handle that type of data with ease? And you know, how do you see that integration between with the hybrid cloud and the private cloud.
[00:30:53] Speaker B: Yeah. So having worked with data centers quite extensively throughout my career and understanding how they're, how they're built, you know, the rent, square footage, the power, potential water, other charges. Right.
That data can slide into Focus 1.2 columns and you could show that back and gather that information and, and view it and be able to show how much the power was, the square footage, the rent, whatever. Right.
Extensing it, making it more extensible.
Where folks tend to get stuck on is how do you break up those costs further into this system versus that system or this business unit versus that business unit or team A versus team B?
That's an allocation problem which we're talking about within focus. And how do we, how do we evolve allocation tags, this, that and the other to, to break that down further.
But I'll say like, like a base in terms of having a, an overarching like aggregate cost.
Those capabilities exist today.
And I fully expect that companies that are pushing focus and have data centers will then push their, their data center vendors if they're, they're renting from somebody. Right. To provide that billing data in the focus format so that they can ingest it in.
If they're not, then if they own their own data centers, you could generate the data in focus format to then consume it at the appropriate level. You'd want it to because maybe you understand when you generate it, if it's yourself, it goes to this system or this team or however you want to aggregate it.
So it depends on.
There's different ways to tackle the allocation problem. But I think it's, I think it's feasible to do it. I don't think it's going to be, I think it's going to be a little while yet before it's. Here's a tier. It is on silver platter and it answers 90 plus percent of the use cases.
So. But Victor, to your question and your point is there's definitely still some work we can do to make it easier so that people can generate it and then consume it.
[00:33:10] Speaker A: That's, that's a good call.
Damien. How, how do you find that as a focus right now and what, what do you think is needed for, apart from what Larry pointed that I think it's really important. Like what do you think is needed for the hybrid cloud and the private cloud too, to be more, let's say, into focus?
[00:33:31] Speaker C: Well, I think that partially Larry answered that you need either the engineers or the people providing the product to adopt it, but in order to make and you need of course to make it easy for them to do that. That always works.
But for me I think that Focus is in its very beginning. I mean I don't think that if I recall in AWS today providing focus version 1.0 and of course I would like to add that during the event we were now in FinOps X, we heard about also what Larry said. They were adding some fears so SaaS companies can integrate the data hybrid target integrated data.
And I still feel that the data that we get from Focus today is not there. I prefer to look into cuart file or cigar second version file CR2 which has much more data and you can show a lot more data there than the Focus provides today. So I think that the, that not only you need to add fields for new incomers like SaaS and data centers, but also the providers themselves and you need to help also the providers themselves find or they need to do it or they need to push themselves to find a way in which they adapt faster. Because again, if today I want to use the new things, you have like two versions coming up every year and they don't have a process to accommodate that, there's still going to be a lag and I'm not sure if you're ever going to catch up.
So I think that again we're at a very beginning. I think it's a good beginning, good start, but there's still a lot more that needs to be done in order to be fully integrated and wide.
[00:35:41] Speaker A: In it. In it. Yeah, very, very great points on, on that. And, and I want to, you know, I always like this, this type of question and I think it's something that I want to, to probably standardize in the, in the podcast. It's like for, for someone that is new to the field and may, you know, want to start the practice on their company, maybe they are not new in the field, but they want to start a new the practice of phenoms in their company or they are new to the field.
What's your advice based on your experience for them? Like if you were new to FinOps, to starting and the practice on a company, what's your main advice for people to begin with? What's your priors and that's it?
[00:36:31] Speaker B: Yeah, I'd say I'll say two things because I think there's, there's one that I'll lean on very heavily.
First and foremost is when we've talked about this a little bit, which is just training so understanding what, what, what the heck is Finops and then diving deep into it with the book or the practitioner training or any resources. I know, Victor, you've got a lot of great stuff you're putting out right here recently and you're continuing with that. Right. Getting your hands on any sort of resources out there to bridge the knowledge gap to be curious, start asking questions, learning from the experts, learning from people have done this, the experience and that sort of, that sort of thing. Right.
I'll say beyond that is then with that experience, taking that and starting to experiment and iterate in different areas within your company or your practice and finding out where the value's at and is the value in or the gaps, the pain points and allocation, showback rate optimization, workload optimization, like which capability or set of capabilities are deemed valuable not only for leadership or engineering and experimenting and trying to figure out where that's at so you can align with it and be successful.
[00:37:52] Speaker A: That's a good one. I think that's, that's a great summary and I think it will be really, really helpful for, for people starting out and yeah, knowing what your stuff and knowing, you know, there is enough resources such as the newsletter, foundation websites, all these resources that I personally share every week on the newsletter that you can find below in the, in the description.
It's something that I like to do for people as well because I think there are new things every week and there are resources that are valuable that are very difficult to find and they shouldn't be because they are difficult to find.
They are not less valuable. I find really good gems on stuff.
So thanks Larry for being here today. It's a pleasure always talking to you and I think people have got a lot of insights from, from your. From this conversation. So it was a pleasure man and looking forward to meet you sometime soon.
[00:38:56] Speaker B: Yes, same, same like you. Thank you very much Victor and Damian.
[00:39:02] Speaker A: Thanks a lot Damian.
Pleasure to have you as well.
[00:39:05] Speaker C: Thank you very much. It was a pleasure. Larry, Victor and hope we meet all again soon. Soon in some event.
[00:39:13] Speaker B: Yes, yes, soon. Yes, yes, yes.
[00:39:15] Speaker A: Yeah, yeah, for sure. So thanks everyone for watching and see you in the next episode. Please subscribe if you have come to this point and this minute that you haven't subscribed, please do and give it a like or something.
Thanks everyone. See you next time. Bye bye.
