FinOps: Way More Than Just Tracking Your Cloud Spend, Yulia Perlis - Logz.io, Assaf Liveanu - FinOut

Episode Transcript תמליל הפרק

Hebrew, then English* בעברית ואז אנגלית:

(*Translated with Google Translate - so there may be some errors.

Please also bear in mind that Hebrew is a gendered language and therefore anything that is noted in a specific gender is intended as neutral and not gender-specific.)

 (opening music)

Welcome to the second season of Dev Interrupted, the Hebrew version of Dev Interrupted, LinearB's podcast for engineering managers. Where we will host leaders in the industry and talk with them about everything that interests engineering managers, those who work with them and those who might want to manage an engineering organization some day. This season we will place a special emphasis on developer experience. I'm Yishai Beeri, CTO at LinearB, let’s get started.

(transitional music)

Yishai: In this episode I am happy to host Yulia Perlis, Head of the Cloud FinOps team at Logz.io. Hi Yulia.

Yulia: Hi - nice to meet you.

Yishai: And Assaf Liveanu, co-founder and chief product manager of FinOut, welcome.

Asaf: Hello.

Yishai: What a pleasure you came.

Asaf: It's fun to be here.

Yishai: So today we will talk about FinOps but we will start as usual with each of you telling me a little about your path and how you got here. So let's start with you Yulia.

Yulia: Like every person in FinOps, I was introduced to the field a few years ago, I was involved for many years in project management, mainly infrastructure projects in mainly enterprise companies, and then I moved a little to the field of operation management, and because I had experience in both project management and cloud project management and I already had an operation team, they said come on , here, we have a large financial expense here that we are not sure what it is, and that's how we established the first FinOps team of Amdocs, and about a year and a half ago I moved to Logz, I wanted to test all kinds of theories on a slightly smaller and more manageable scale.

Yishai: So we will also dive a little later into the differences perhaps between a large company like Amdocs and a slightly smaller company like Logz. Asaf, tell us about your journey.

Asaf: So I rolled into FinOut, yes rolling, so I was a developer for a good few years, I came to the conclusion that developing is nice but not that interesting. I was like one of those strange developers who always ask why and not how, as if I was less interested in the execution, more in how to move the ROI, and then I was simply told that product management was more suitable. I joined a wonderful company called Logz.io, as a product manager, and was there for almost two years. I was the only product manager of the infrastructure division. That for two years I almost only worked in a field that I didn't even know was called FinOps, where I actually met one of my partners and we came to the conclusion that the world lacks good tools for doing FinOps, and two and a half years ago we left Logz to start a company and today I am the CPO, responsible for FinOut's product, already two and a half years, thirty or so people, running with all their might, and that's it, that's how I got to where I got.

Yishai: Cool, so basically your work as a blog product manager was about what, some kind of internal FinOps?

Asaf: So the mix was let's say this, they told me there were projects, everything was crazy, infrastructure, machine learning, whatever, we spent at least 40 percent of our day, me and the director of infrastructure, on answering questions we didn't even know were called FinOps, and yes , it just kind of rolled out.

Yishai: But for internal use, not for Logz's customers but,

Asaf: Yes, yes, internal use, completely internal use, Logz's infrastructures are both massive and cloud heavy, and I was just full of questions all the time. Which I'm sure Yulia today knows how to explain even better than I do, and yes, a need simply arose, the current tools were not amazing, I’m talking about 3 years ago, and we were so frustrated that we just started a company that-,

Yishai: Well, so let's take a step back and ask ourselves what FinOps is. (laughing) Yulia, come on.

Asaf: Let the person with the title answer.

Yulia: (Laughs) What is FinOps? I always divide FinOps or my role into two. One, my job is to understand what the company spends the money on in the cloud. Cloud, cloud providers, Azure, Google, GCP, whatever you are using, what the money is spent on, and the other half of the job is to understand how to get more out of every dollar we invest in the cloud. I think it's quite like that.

Yishai: Okay, so visibility and

Yulia: Not visibility, understanding, seeing the numbers doesn't mean you understand what you see, right? It all depends on the cost of the model you built. Do you look at an account as belonging to a certain unit and then you say ok, this is business unit A, does that mean you understand what they are spending the money on? Or do you have visibility? Right? So you have visibility, you know who is spending the money, you don't know what they are spending the money on. In my opinion, the job is to know exactly what every dollar is spent on.

Yishai: OK.

Yulia: And then it already entered the question of whether,

Yishai: Should I continue, yes.

Yulia: Yes, should we continue, is it possible to do more with this dollar we invested, because in the end it is an investment. True, the transition to the cloud, financially they moved us from data centers that were CAPEX, accounting, we moved to OPEX, actually more expenses but fine, there is an expense here, there is an investment by a company, an investment of millions of dollars in most companies, so make sure that every dollar that goes out is spent from gets out the maximum resources possible.

Yishai: OK. Asaf, how about you?

Asaf: So first of all of course I agree with every word. Like the way we look at it, it's actually a function whose job is to bridge two worlds. That is, if DevOps was born to bridge production and development, then we suddenly have a function designed to bridge the financial world, the business world, and we can also talk about why I make this separation, and the worlds of DevOps and development. There is an expertise here that, on the one hand, is able to conduct financial discourse, as Yulia just explained, on the other hand, she also knows how to conduct technical discourse. And this is something that didn't exist in the world, it wasn't necessary until say 3, 4, years ago, I'll add on top of that that, as if we see companies whose difficulty is not only in the cloud world, they can run on one cloud and still have problems, why? Because the world is moving rapidly, certainly after the COVID. All the worlds of usage-based pricing, now the clouds are like the most classic example of me consuming what I use, and anyone can move my resources and at any given moment they can give me spikes of costs. But I also have data warehouses that work like this. I have observability products that work like this. I mean, today, on the one hand, we want to transfer all control as close as possible to the developers, or the development teams, on the other hand, any of them can cause spikes, break this balance that Yulia talks about, what I spend the money on. And at the end you have to give a good answer as to why my costs looked like this this month. What will they look like next month? Where can I invest in infrastructure now to improve my margins? What new technologies do we want to introduce? Why do we want to include them? It's FinOps, meaning to connect the business world, the financial world with the R&D world, it's a whole world and a very, very unique expertise. By the way, anecdote, when we raised the money, I had to, we went into a room with the biggest VCs in Israel, they didn't know what FinOps was. We are talking about 3 years ago. They sat in front of my face and told me what? What are you even talking about? As if we don't even know what you're talking about, and started really looking up on LinkedIn how many FinOpss there are in the world. Today I think there is no fund in the world that is not looking for, does not want to invest in FinOps, it's like a crazy process that the world went through in 3 years.

Yishai: And what is the trigger? All in all we use the cloud and do, companies have been running in the cloud for at least 10 years, or the money that comes out, CAPEX, OPEX, in the cloud, automation, Terraforms, it's not new, what's new is that FinOps suddenly became a market, became a category of companies.

Asaf: So we recognize basically two trends. First of all, at the height of the coronavirus, there was a lot of money, but there was also a tremendous desire to run fast and become… basically enable a kind of digitization of everything. So anything that I could buy in SaaS or in an external solution, we see companies that went there with all their might because they wanted some - the more to release money and as much as possible, to develop as quickly as possible, because there was a crazy boom in the world for digitization. But on the other hand we know what year we are in now, the money is closed, all the companies are actually now looking at what they have spent and are starting to understand wait, wait, wait, we just opened, I don't know, 10 new budget lines, out of which 5 tools I don't have observability. I have no ability to control their spend. I just listed the types. How do I manage a budget? How do I actually close my sales prospects? I mean, in the end, I can sell as much as I want, but if I don't reflect a reasonable margin, then someone has to do it, and this is exactly the FinOps, they actually close this corner, they connect these worlds, they prepare the answers for finance, R&D is preparing the roadmap for when, where, as it were, the optimization should be invested, and this is precisely the change that has taken place in the world. That is, 2023, is the year of optimization, to understand what we are spending the money on, to see how we build the budget correctly, and that's why it caught a crazy boom .

Yulia: Yes, and it also started to unfold, it's something that has been growing and growing for 3, 4 years. I remember like 4 years ago, our first task was what to name our team, because no one knows what FinOps is.

Yishai: But companies like CloudHealth and all kinds of others that we will come to later,

Yulia: Existed before.

Yishai: I mean cost management on Amazon or Public Cloud, it's not something new, I'm trying to put my finger on what has changed or what the leap is  it that suddenly says okay, this is a new category, it has a name, we had dashboards and drill downs for Cost.

Yulia: But they were, I often divide it, the world of FinOps, the practitioners themselves. It is divided into two, there are those who do cloud financial management, many times it is people who come from operations, people who come from finance and that’s what they really know how to do. They understand very well the business language, they understand very well how finance works, how to manage a budget, how to make forecasts, how to build budgets, all the, how to make a proper procurement, because think, even in a large company, procurement of this cloud something crazy. It's insanely distributed, all the developers consume it, the control is very, very minimal. When procurement organizations are used to the fact that in the end someone comes to them, and here every developer can purchase without any control and governance. Then there is the whole world of cloud financial management, which is one huge and big subtopic. And then there is the whole world, really, of understanding exactly what you spend the money on, and how to optimize. Together, this creates this complex world that today we put under the title of Cloud Financial Management, but there are two worlds here that we started with cloud financial management, and as the world developed, the more this discourse took hold, executives understood the terminology and the questions more, they also understood that in the end the companies have to enter a world of not only understanding who spends the money, understanding what the money is spent on, and how to optimize this spend, and really what happened in the last year for my field…well, it was good (laughs).

Yishai: Okay, so there are actually some moving things here. One, much older, large companies went through an accelerated process of transitioning to a digital world, this can perhaps be attributed to the coronavirus, so we no longer do it,

Asaf: It accelerated a process that started and simply they,

Yishai: It is no longer modern software companies and startups but also large, older companies,

Yulia: Banks.

Yishai: Move a lot of money into this world of Cloud, this world of Digital First and then there is no choice, they probably need a little more tools, a little more depth. And you also put your finger on the need for the finance teams to understand, I want to report a margin, decide what, to which cost center I attribute the costs. Until, let's say 10 years ago, we optimized the cloud to lower the cost, but that was the end of it. There wasn't for example: how do I attribute cost between engineering, between customer support, what is perhaps a cost of sale and the actual margin of my product?

Asaf: Yes, the way we see it, in the end we work with a wide variety of companies but in the end it is divided into two. There are those who were born in the cloud, let's say the companies that were founded in the last 6, 7 years, were born in the cloud, live the cloud, everything is related to the cloud, as many services as possible they want to consume in the cloud, no matter what solution it is. And there are the companies that, by the way, are the ones that were born in the last 6, 7 years and the companies are big, that is, we are not talking about startups here, startups would surely have already been founded in the cloud, there is none here, I don't know a startup that was founded on-prem or whatever, but think about it about a company that was established 10, 12 years ago. So yes, the transition to Kubernetes has taken two years, but that's it. We've already reached this stage where it's a super mature technology, it's happening, and I want to, and now I suddenly also have all kinds of projects for which I have to start using more clouds, just one cloud is no longer enough for me. And in the end it gets to the point where it's huge companies, with huge budgets, and like any budget it has to be managed. And manage it only with the technical resolution - here you threw out CloudHealth, CloudHealth in the end gives me a not bad answer at all with the market leader for how much I spent on services, but that is not what interests Finance. Finance will not come in the end and ask why did you spend so and so on EC2, if this is what they asked you, then we are here at, Yulia is welcome to tell me if I'm wrong, but in my opinion if Finance enters into these resolutions it is not the right way. That's why the customer, that is, how we ended the month and we know how much we brought in, how much we spent, why did our margin move like that, why, how can it be that our expenses increased by X percent but the amount of data that we, if we are a data company, the amount of data that we index did not increase at the same rate? That is, there is logic behind budget management here, it is not just predictions and let's say a number. And this question, we need people and we need tools that know how to connect two worlds that are very difficult to connect, that's why this movement was created. So as if companies that were founded 12 years ago and suddenly started moving in this direction, companies that were founded years ago are still living this problem, so a huge critical mass was created and today we see companies that have existed for 100 years, 150 years, yes, one of their KPIs is how much they managed to transfer from their workloads to the cloud, it's a process that takes 7, 8 years, but suddenly there has been a huge consolidation. In recent years, everyone wants to move to the cloud, they understand the benefits of it, and now they need people like Yulia to help them do it.

Yishai: It would be correct then to think that it is in the interest of the main cloud providers to go deeper there and actually compete with startups that produce FinOps or FinOps tools and provide the solution. In the end the bulk of the budget goes to Amazon or Google or Azure or whoever, it makes sense that I give tools to manage it budgetarily, to load In front of which customer this expense goes. All these questions you are raising now, apparently it is really critical for cloud providers to give it in-house.

Yulia: So not everyone would agree with it, let's say it really depends on the Cloud Provider. There is AWS, who have really engraved this on their flag and they have a lot of transparency in general in how their billing structure works, and also many tools that they develop in-house. They have their own FinOps team. I think they are already some 40 people, really from the top tier, who started 5 years ago roughly, a relatively old team in the FinOps world. Azure and Google are somewhere else, it's also a terrible business model, in the end it's those companies that make money on what you are wasting there, right? In a way.

Yishai: The question is whether the observation is only about waste and optimization? In the end, yes, there is a bit of a difference between how the public clouds help you save or not and whether they play the long game or not, but there are many other questions that are not related to optimization, the link between my spending and my products, this is a move that goes beyond the billing dashboard, Right?

Yulia: Yes, it's a move of,

Yishai: A link to the services, a link to which client, okay?

Asaf: Yes, it is the inclusion of some kind of business logic.

Yishai: This cost is charged to that customer or to this set of customers, and then I start talking about tiers. I say my enterprise customers this is their margin, my scale-up customers this is their margin, these are all tools that I imagine FinOps tools give,

Yulia: FinOps tools give the ability to get these answers, in the end you need the business analyst or the FinOps analyst who will come and build the logic that is adapted to each company, it's kind of like BI people, data analysts of sorts. They have tools and they have the relevant business questions for that company, in the end they build the model because they are the only ones who understand the company and they know how to ask the questions and they know how to find the answers. They build the model, they build the dashboards from scratch, they find the answers, build the models that make it possible to predict the answers and so on. After all, FinOps is a profession that borrowed from 3 schools of thought, let's call it that. This is how I divide it. When I'm hiring for a new FinOps, there are usually 3 schools of thought that you need to understand at some level and understanding at some level, in my opinion, which are the skills that the existing team relies on. But when you come to build it now, you finally look at FinOps, they should have the facet of—a business analyst, for all intents and purposes, they know SQL, they probably know a few more languages, maybe a little more, a little less, they need to understand things , they need to be able to look at large amounts of data and know how to find the patterns, to find the model, to understand how you make the cost model that allows you to analyze the data or organize the data so that he will give the answers that are relevant to the organization. And also knowing how to predict these answers, and the questions more correctly, right? Because sometimes the organization is not yet ready for some of the questions. I have questions today that I thought I would be asked a year ago and therefore my cost model allows this, it is modular enough that I can change the components.

Yishai: So it's kind of,

Yulia: This is the business analyst on this side.

Yishai: A sibling to the world of BI, to the function that does BI in the company?

Yulia: It's a sibling, yes, about a third, a brother to BI, we also work a lot with BI, for example. I actually have a complete model in BI of data that I collect from several sources and I cross-reference it, and it's more things that -, information that we don't always want to reveal or disclose even with a third party. My ARR data, my cost data, are really crossovers that are at the level that they are, the company is not always interested in revealing the information and it is also very difficult to do it through a third party system because really each company has its own nuances. So this is the first pillar, the second pillar really you have to be able to speak the languages ​​of all the stakeholders, Asaf calls it the entity that bridges the worlds. I treat it more like the challenge of every FinOps, we are the entity that comes in that should be able to talk to every organization in the company. I think this year I've already reached the last unit in Logz that I didn't get to work with, that's the marketing team. They were the last. I work on a daily basis, my work interfaces are with each and every organization in the company, and that's fine, now so that we can all have a productive and logical conversation, we created a language. A language that is relevant to Logz and is a cost language for Logz, and then all of us all the time, from the CEO to the CFO to the last developer, are able to speak the same language and understand each other. Then it makes it possible to communicate and have a discussion, to build this language, again, is the responsibility and the challenge of the FinOps teams. It's a skill, a slightly different set. Beyond that, you really have a need here for project management, driving processes, you make a lot of changes in the organization, it doesn't matter, the bigger the organization is, the more it will go in the direction of procurement processes, financial processes, forecasting processes, smaller organizations it really is You can go down to the resolutions of how to do design with cost in mind and all of that genre.

"We (FinOps) created a language...and then all of us all––from the CEO to the CFO to the last developer––are able to speak the same language and understand each other."

Yishai: So you basically brought up here, give a description of what the FinOps team looks like or what skills are needed in the FinOps team, okay, and let's start, where does it sit in the organization? Let's say at Logz, who is the, to which department does FinOps belong?

Yulia: At Logz we belong to the R&D, while I have a partner in the CTO Office who is, there is another new function like this in the world and it is called a cloud alliance partner whose role is mainly to create partnerships in the areas of the cloud. Many times it is more business facing, customer facing a lot of times, so I have also a partner in the CTO Office and I also have a partner in the COO, which is under the CFO.

Yishai: But you sit in R&D.

Yulia: We sit in R&D, from the school of thought of putting the tools next to the people who have the most ability to change the situation.

Yishai: Where is the BI for example?

Yulia: The BI sits in finance. But a small company, everything seems to be relatively close.

Yishai: What do you see Asaf when you sell a product, where is the organization, who do you need to talk to?

Asaf: So we define it differently, of course there is the FinOps and there is the DevOps, I, when I explain to people who I sell to, I sell to the person who accepts in their mind that there are problems with visibility of the costs. In the end there is always someone like that, there is such a function. It could be the R&D, it could be if you've already established a FinOps team and it sits under the CTO. Is there anyone who gets the heat for it, okay? Now what does it mean to take the heat? That is, they come to them with questions, depending on the size of the organization. We work with American organizations that have a FinOps function that can be up to 6, 7 people, sitting under the COO or the CTO so that they can really, as Yulia says, work with the whole company. We work with companies where the person responsible for this is the Head of Platform, because the person specifically likes it and is connected to it and understands that it is important. In general the R&D is more involved in it so they can actually control it more. And they also understand that if they do cost optimization, this money stays in their budget and they can invest it back in infrastructure. So there are a lot of nuances here, but in the end it's the same use cases, it's the same questions, we see that in most companies, at some point, even if there is a person who is responsible for it, whether it's the Head of Platform or VP R&D, there must be a FinOps function and then it will sit under him , because it's a different language and conversation that needs to be conducted within the organization that R&D people are not their specialty - and it's not sure that's what we want them to invest their time in either. So for me it's just the person that hurts the most. We can talk about the nuances between Israeli companies and companies abroad. Abroad we see much more of an independent function below one of the C-Levels. The organizations are also much larger, and then what happens is that they have their representatives in each of the development groups and then you can look at it as one as a small company in itself and then once again the FinOps within the R&D. But whoever elaborates it, as Yuliya said, that it reaches the level of finance, that it reaches the level of overall observation, there is a function that does that. In Israel, the organizations are simply a little smaller, so it seems more logical for it to sit in R&D. I would like to return to the previous point, just something that is very, very important to me to emphasize, the cloud providers release their products for cost management, this is wonderful, Amazon will never, ever, ever allow the connection of Amazon and Azure costs, it will not happen, it will not happen in -Their UI. This is not their business model, we are not talking about other data warehouses and observability products at all, it has nothing to do with what they want to deal with. And today if you think about a normal organization that runs Amazon, now because of compliance must pick up Azure because it wants to work with the, I don't know what, the government of the Netherlands, now suddenly it is stuck. It's just stuck, it has two interfaces that speak two completely different languages, now you can download Excel and start making internal systems, now do it, or you can take a third party tool that connects all these things, builds business logic for you ) above, that's how we look at it, otherwise we can't compete with Amazon's resources but Amazon will never go near these areas because it's just not, like it's not about them.

Yulia: It's not just that either, it's also the abstractions we put on the infra, at the end of the cost it reaches the infra level, right? I pay for S3 bucket I pay for EC2 and so on, but the real costs are, it's not just one EC2. It's EC2 which is part of a cluster that actually serves Kubernetes or Snowflake or whatever. You want to enter and dive to the level of abstraction and this is really for, for the most part, the discourse that is created when there is a FinOps team, in the end a discourse is created around waste KPIs, efficiency KPIs and the unit of economics, and all these things to really reach answers at this level, and manage the discourse , so you have to go to the level where the division is done, right? Where the breakdown can be done. Again, cloud vendors really, they give us infrastructure, they give us managed services, which is also nice, but to break into managed services is even more of a challenge in itself.

Asaf: Yes, and I'm even the so-called I'm Arim for Yuliya and as if what we'll say Lugaz do, they take their infrastructure and they manage the whole conversation within the organization around business use cases. I mean, they really broke the infrastructure for business cases, that is, think that they remapped their entire infrastructure and built the organization from it. Now it's not built according to technologies, because they have, I don't know, from my acquaintance with Logz then I don't know, eight teams that consume EC2 resources. It doesn't help me to talk about EC2 when you manage the so-called inventory and want to negotiate with Amazon, on a general level. Ok, I can look at EC2. But when I want to have a conversation like Yulia said exactly within the organization, we have to break it, so we suddenly build up teams and these are things that cannot be done only within the providers, certainly if you are running with Kubernetes, which means that Amazon does not have access to almost the data of the software , add another cloud, add another observability product, add some data warehouse, and things just get complicated very quickly. And we must have a single source of truth and start mapping it, and it's just like, by the way, what the Lags did, which is wonderful.

(transitional music)

Yishai: Well, so we talked a little about where it sits in the organization, and a little about why you need tools and not to rely only on what Cloud Providerz gives, let's dive a little to talk about the tools. Assaf, I would appreciate it if you could also tell a little bit where the focus of FinOut is and what you see in terms of competition or what kind of tools I even have, what are the basic capabilities of tools in this world of FinOuts.

Asaf: So as we have already discussed, so the most basic layer is observability, now this means my ability to put a dollar sign on what I spend money on. Now each of the services, or let's say most of the services I spend money on, has some kind of native interface, an excellent starting point. Some are better, some are less good, it doesn't matter. Once I came to the conclusion that it's not good enough for me, and I want to start doing consolidation and also start having a dialogue within the organization so we, so you have all kinds of tools that actually allow you to do this connectivity and bring everything and produce as if a unified interface for all your costs. This is the cost management space, there are wonderful companies like CloudHealth that we talked about, Apptio who bought Cloudability a few years ago, now there is a new stream of companies, one of them is FinOut, and the basic, basic is observability, to build business logic and actually produce the thing This one, each has its advantages and disadvantages, pricing, etc., doesn't matter at the moment.

Yishai: That means what, I collect the basic information of the usage, (usage)

Yulia: Yes, it's a cost management platform.

Asaf: exactly.

Yishai: Okay, but why am I not doing the business modeling yet?

Asaf: No, you're already doing the business modeling, you're actually building the, I like to call it like I'm taking my organization and basically taking the infrastructure and basically throwing one on top of the other and creating something. Because the infrastructure has to speak my organizational structure, so that's where you do the budgeting, that's where you do the forecasting, you try to identify anomalies, the very, very basic things that without them, like what you would do in Native, just think of one place where you can do everything . This is the basic of the basic.

Yishai: And there I already map between this EC2 it needs to be split between four products.

Asaf: Exactly, exactly. Four products, 20 customers, as if whatever is your pain at the moment.

Yishai: And what about my building? days and

Yulia: And logics that we build on the...

Yishai: Static loading parameters like I say it looks like this to me, load and then I'll erase it?

Asaf: Yes, now once again, I have, tags is a very big word because I have tags in whatever, let's say AWS and Azure, I have labels in GCP, I have names of instances (instances), I have an organization in Datadog, there I have query tags in Snowflake and these things start to get interesting very, very quickly. So that's the basis. Now, above that, and you can even say that it runs concurrently, there are the worlds of optimization. Now also in the worlds of optimization you have all kinds of tools, you have optimization tools such as the ability to optimize based on tools like cost management, he comes, looks, he doesn't do anything active but he comes and says listen, you have 80 instances that have not connected , let's say RDS, let's say it's data bases, the last week nobody connected to them, maybe it's worth someone taking a look at it because it's a shame, because it costs you a thousand dollars a day. OK? Now at the end, the decision to optimize is an operative decision, okay? As if I, as a platformer, can come and say by tomorrow that you don't need this instance, but someone has to decide that they are ready to take the risk, which may be high, may be low, that someone will wake up at 4 in the morning because they turned off this instance. And it's an operative decision, as if it's also a great question for Yulia to ask, like how do you do it in Logz, how do you manage this operative discourse. But it's the so-called lite optimization we call it. You come, from a map, I call it a heat map of the organization, where I have the ability to optimize and then a project dialogue begins with the DevOps, with the R&D, how we do it. And then you also have the active optimizations, which is already taking this direction into another world, and actually starting to make changes to your infrastructure. Now changes to the infrastructure can be from the level of buying you RI's automatically, as if reserved instances (reserve instances) automatically, okay? which is the only impact you can have is on the invoice, meaning they probably won't drop production, to the point where you could actually change configurations in Kubernetes on an hourly basis. That it's a super intimate intrusion into your organization and it's all a question of if you want to do it. Now it's the broad spectrum of solutions, above all this you also have financial solutions, that is, how do I reflect the worlds of the budget, how do I more correctly reflect my margins, which is also where the cost management platforms come in. I'm trying to think if there's anything else, I don't think so, is there any idea you're coming up with Yulia that I missed?

Yulia: An observability tool.

Asaf: Agreed, right, we were just talking about that.

Yulia: I think that today most FinOps, not most, a large part of FinOps are beginning to understand more and more how important visibility data is, how important it is to use observability tools that are already in the organization.

Yishai: Give me an example.

Yulia: Logz (laughing), I admit.

Yishai: No, but how do I use , where does the information retrieved by Schlogz or a similar observability tool connect me to the movement of the FinOps?

Yulia: So for example, the most basic, I have observability at the end of how many CPUs, how many converters each machine consumes, right? And how much she does not consume from what is available. That is, I can quite easily calculate some sort of waste KPI. And really, with a price tag, I know that the machine costs 100 dollars, I know that it has consumed 80 percent of its capabilities, 20 percent it has wasted. And then the place for the discussion comes in, because it could be that this is a machine that we don't want it to condense the 80 percent used, right? Because beyond that it's not healthy for us, we need these buffers. We want to end up being, as if this is the models we build most of the time, but for that I need observability data and I need cost data and I need to bring them together somewhere.

Yishai: Okay, so we talked, there is actually a move of, first of all, show me what it costs me, and maybe where there is a lot of money, there could be an engineering project to come, we'll change the architecture, let's change the implementation so that it costs half as much. The second level is show me what's not in use, you mentioned here RDS that nobody connects to or machines that really don't do anything, and even before observability I can kind of understand that they're unnecessary, or it's a development environment, let's take it down at night and turn it on in the morning, things like that.

Asaf: classic.

Yishai: And then at the dynamic end I have, here's a machine or a resource whose waste is high, according to what observability shows me, and then,

Yulia: exactly.

Yishai: From these patterns I can offer a solution, it could be changing the instance, it could be increasing and decreasing auto-scaling a little tighter.

Asaf: Now this conversation that we threw out nonchalantly that Yulia's knows how to put the dollar sign on the waste, it's a very big leap that we have made in recent years because once again, if I look only at waste, we now had a discussion before we started recording exactly about this , hypothetically it could be that 90 percent is waste and it is worth half a dollar. As if what is hypothetical, it happens, and then as if you also have to maintain what is called keeping your face in front of the R&D people and not talk to them, as Yulia says, it is a waste KPI, meaning it is some kind of combination of two worlds, as if the wasteful This is impactful at the level of the invoice and how dangerous it is for my infrastructure, and this is the conversation, and the ability to harness the organization to talk like this, it's FinOps.

"This conversation that we threw out nonchalantly that Yulia knows how to put the dollar sign on the waste, it's a very big leap that we have made in recent years."

Yishai: What about what if issues?

Yulia: Completely.

Yishai: As if my data is increasing, what will happen if tomorrow there is double traffic.

Yulia: It's podcasts.

Yishai: And is this something the FinOps team does? analysts? Or is it something my tool gives? I try to put my finger on what I buy as a tool and what I get from personal expertise.

Yulia: So full disclosure, Logz has been using FinOut for two years or so I think, and one of the biggest requests (laughs) no, the truth is it was a small request about a quarter or two ago,

Yishai: Here, now there will be on air a commitment to a delivery date.

Yulia: Exactly, remember I asked you what if analysis? (laughing)

Asaf: Sure.

Yulia: But yes, I think that first of all it's something that in the end FinOps should give. FinOps are also responsible for the tools, to give the tools to the organization. In the end whoever chooses which cost platform management tool, cost management - cost management - the company works, the FinOps team will probably choose which tool will be optimized as well. These are things that the FinOps team will already do across the entire organization. So I agree that there is a lot of room here to really give as many tools as possible to the developers and give them real tools that will allow them to do a small what if analysis on their own for a moment, one on a piece of paper, given the cost in the organization. Because cost in an organization changes, it's not only that, in order to do a real what if you can no longer work according to a price list. What usually happens is that most developers try to do something that is more profitable for us, they go for the price list, and it's as if the price is adjusted. They don't go into the subject of discounts, what's coming and so on, and most of the time I do say that developers can look purely at the price list, it's good enough, it gives them enough benchmarks, it gives them the direction and so on, but when you enter For the worlds of what if or how much a particular design we are thinking of doing will cost us, so we really need to look at how much this particular design will cost us in our organization, and for that we need here, Assaf,

Yishai: When the big gap in your eyes is an issue of discounts and special pricing and commitments?

Yulia: Yes, it's a bit, it's more your commercial terms that are relevant to you in the organization. Because there are all kinds of contracts and sometimes they prioritize certain services or certain machines and so on. And I don't want to put the developers in all this headache, it's my headache as a FinOps to know. But I do want to be able to give them the basic tools, so that they don't have to actually go to the FinOps team for everything, that's also inefficient. The FinOps team is really a relatively small team that serves a lot of people.

Yishai: So, for example, you can give them an average price that is closer to actual, but he doesn't really look at percentages, he says, wow, I pay on average for a machine like this, take that into account when you're there, instead of looking at the list price.

Yulia: Yes, I call it golden numbers, so with us the golden numbers speak in business language. We have all kinds of components in our pipeline, for each component everyone in the organization, whether it's a product or finance to the CEO or R&D, everyone knows what this component means, it doesn't matter at the moment what the resources are that support it. There is a component, it is doing something, so one unit of a component costs like this. When a developer knows how many units of a component he needs and he, when he has some kind of price, today we simply have an Excel that is shared like this with everyone. This knowledge to the developers. And they are obliged to refer to, (laughs) already at the initial designer stage they have a Kost section.

Yishai: of how much it is going to cost. what is the plan

Yulia: Exactly, how much do they think, it's evaluation, the initial evaluation, then we really have a process that really validates the evaluation.

Yishai: And how many check, half a year later, that the initial design was suitable?

Yulia: Yes, but it's because I'm crazy so we check everything, always, but yes (laughs).

Yishai: Tell me, how do you measure the FinOps organization? How are you, what is the KPI you define for yourself, for the organization.

Yulia: So there is the most basic KPI. We know how much we have generated savings, and we know how much we cost per month or per year, so

Yishai: We created savings, this means we raised a flag and engineering changed something and saved.

Yulia: Yes.

Yishai: And then what, each one of these is from a project that receives a dollar amount for it?

Yulia: Yes, we map, today I don't like working in projects because when you work in projects and you say here, I saved 100, I saved 100, I saved 100, you seem to ignore but here about us and here about us and here about us (laughing) it's a bit unfair and a bit naive. between us. Yes, in the beginning you usually do I saved 100 dollars, I saved 100 dollars, projection. I prefer to work with the unit of economics and really with KPIs. So let's say I measure how much it costs the company to ingest 1 gigabyte of data in our pipeline. Really, it's a unit of economics that also goes later to our pricing model, in the case of SaaS companies. So you absolutely take, it's data that gives answers to finance, it gives answers to sales, and enables a very easy conversation, cross, and then also when you talk about your savings in exactly the same terms, then it's very simple. There is no debate here, we all know that a year ago we were, I don't know, 5 dollars per unit, now we are going up 3 dollars per unit, the difference.

Yishai: So you actually take on a KPI whose realization depends on engineering, on Amazon's price increases,

Asaf: in the business performance.

Yishai: Even in the business performance, because they may not have sold enough to allow you to reach the scale.

Yulia: Exactly, so I'm normalizing, that's it, since I can't really assume how much we sold, it's a part that's out of my control, so I,

Yishai: No, but let's say unit of economics.

Yulia: exactly.

Yishai: For every gigabyte or some amount of logs, we had 5, I want to get to 3.

Yulia: So I take one unit of economics. How much we sold, which is the bottom line,

Yishai: Yes, yes, 5 dollars and now you want to bring it to 3 dollars, this is your KPI, realize it, you are very much an enabler but you are not, it is not in your control whether engineering will invest the effort and improve,

Yulia: Do you remember where I sit in the organization?

Yishai: You're in R&D, right?

Yulia: So I have, that's why I strongly believe that FinOpss should sit in R&D.

Yishai: But you do not have your own resources of optimization.

Yulia: No.

Yishai: Someone in the end needs some kind of director or some kind of Tim Lid should say I put people on it, they came with a new idea and made a twist in the algorithm to reach 3 dollars.

Yulia: Yes and not exactly.

Asaf: Discounts are within your control, for example, this is massive.

Yulia: That's it, it's yes and no and not exactly. we will share One, everything that is waste, should have been cleaned and we just forgot it is completely under my control, right? Identify this RDS that has zero connections on it and make sure that team,

Yishai: You need to convince R&D to download this RDS.

Yulia: This is already my ability to influence the organization, part of which is my responsibility, part of which is also the responsibility of the organization, right?

Yishai: Definitely.

Yulia: If the organization will really give me their back and allow me and support me in these desires. If the organization doesn't support you, it's a different conversation, it's a different challenge, as if it doesn't matter what you do as a FinOps team.

Yishai: Like any interesting function in the organization, you take a KPI that you are not completely the owner of from start to finish.

Yulia: Yes, and that's fine, and that's fine, you personally believe in taking KPIs that are a little beyond my capabilities because it actually allows me to tie the organization to me. One of the things we did this year, which I personally very much support and love, the KPI is an organizational KPI, the KPI of what should be the cost of 1 unit of our economics is an organizational KPI, it's at the CEO level, it's one of his 5 strategic KPI . On behalf of every team and anyone who can be relevant to the issue, it's really as if he added the KPI, cut his internal KPI and then there really is a proper KPI management plan, where we have the main OKR and then the

Asaf: By the way, the way I look at it, in the end it's like any degree of SLA of the organization, you can come and say that the DevOps are responsible for the SLA. After all, they are responsible for the application being up, but they keep a list of projects, some or even most of which depends on development teams. But their job is to hold the state, and their job is when someone comes and tells them we have a problem I don't know, availability, great, so here are the four projects that can be done to make availability. Someone needs to do the research, someone needs to collect this, maybe we need to buy a tool, maybe we need to add, I don't know, a function to the R&D organization. Amazon because it expects an increase in the use of this type of instance. And Amazon don't know this is what we plan to do. It's really a negotiation for everything, finance 101. On the other hand, there's also the thing where the CEO comes and says wait, a second, we're going beyond this unit of economics, from our SLA, what projects can I do to improve. So either I I'll lower the costs or I'll come and say listen, to do this I need projects 1, 2, 3, 4, 5, this is what we identified in the infrastructure. This is what we collected throughout the quarter. Now for R&D to come and say it's easy, it's hard , it's mediocre, here you can push it. This is exactly the role and this is exactly the discourse that needs to be created in the organization and this is how it is done, as if there is no other way.

Yishai: So we said FinOps need to work cross-functionally to produce and meet and be responsible for KPIs that in the end they don't deliver end to end themselves, there is nothing to do, there is a matter of impact here.

Yulia: Yes, but most KPI's aren't just up to you, right?

Yishai: Truth, where it matters.

Yulia: Exactly, there is simply an owner for each KPI. So the FinOps are often the owners of these KPIs and they are also responsible for knowing how to raise a flag when they see a risk.

Asaf: And another point that you just have to throw it away, a good organization, its costs go up, certainly a SaaS organization, certainly an organization that is cloud native, meaning to come and say let's lower our costs in the long term is almost,

Yishai: No, the costs are increasing, but the unit of economics needs to improve, the margin needs to improve.

Asaf: Beautiful, excellent, so it's like we always came and said okay, show an invoice that costs 5 percent year over year. There is no way to know if it is a good business company or a bad business company, it is not related, if we measure unit economics, if we know how to anticipate our margin and we suddenly see that our margin is stable at 90 percent, amazing, and the costs of the R&D grow up, the CEO should come, give a medal to the VP R&D to tell him to go wild, keep spending money as you want because you are accountable and you manage to generate this discourse. You have to continue to control it, but that's the beauty of this thing, that is, it's not something that sits on R&D's head and tells them to lower costs in order to lower costs. But in the end, a contract is concluded, which is exactly this unit of economics, exactly this organizational KPI, in terms of R&D, if it lives up to this contract, they will riot, run, that is the goal of every organization that runs. We want velocity, velocity, the goal is to win, the goal is to sell, the goal is not to lower costs. But if we don't know how to maintain and put these guardrails, that's exactly why I used the SLA example, in the end I can't let my error rate rise above a certain percentage. And today developers simply have tools and are more aware of this, when I deploy a service, the first thing I look at is that I didn't get an alert about the error rate. Why not do the exact same thing if I'm on the cost of my service? What exactly is the difference? no difference But it's simply harder, that's all, or conceptually harder.

(transitional music)

Yishai: So we talked a lot about cloud and it sounds like FinOps focus or maybe only or almost only on cloud, on cloud coast, infrastructure, Kubernetes, workflows, etc., but when I look at the costs, even product costs and product delivery costs, there are many more things, maybe a lot Money, which I wonder how FinOps treats, first of all the world of sas, I mean there are other products that I pay for in some kind of consumption but they are not my cloud. These are not the products I run on, they are ancillary products that cost me money and sometimes quite a bit. And I have the biggest ole cost, the developers. In the end, in order to deliver a product I have huge developer costs, I would guess that in most companies this overshadows the cloud cost.

Yulia: Yes, in SaaS companies the benchmark says number one, your first expense is the human power, your second expense is the cloud, and then there is,

Yishai: And do you know how much the ratio is between the first and the second?

Yulia: No, no one will tell you that either, maybe you know, Assaf?

Yishai: Roughly.

Asaf: can't say, like

Yishai: 10 times?

Asaf: No, no, no, absolutely not.

Yulia: I don't know, but I don't think so.

Asaf: No, it depends again, it depends on the maturity of the organization, but it is clear that spending on personnel is the most painful thing, it very much depends again, when the company was founded and how heavy it is. The cloud is the major pain point right after personnel, that's for sure, and it's massive, meaning it can be tens of percent of the budget, still personnel costs will always be the most painful thing.

Yulia: It's also supposed to be like this, in the end the people who use, who build the product, who do the optimization, that's the human power. The FinOps do not look at the world of power Adam. It is a problem that remains in the world of finance. The advantage of not having trouble, this challenge, is that it is a managed challenge that the organization already knows how to do. True, for years he has been dealing with understanding whether he is spending correctly, on how many people and so on. Most of the finance organizations already have models that tie it to pricing, after all, the pricing of that SaaS company is not just the cloud cost. It's obvious, but it's just a puzzle stone that's not there yet, that's still hard to deal with and it's the second largest, so it's quite heavy, it's the cloud and that's why there's such a world and such a domain.

Yishai: So I want to challenge what you said a little bit. On the one hand, I agree that spending on personnel is something old, old, know how to count it, know how to manage it on a finance level. I think that today it is very difficult for finance to link development personnel costs to products, to the catalog, to customers. Because the relationship between, for example, teams, HR is often managed in teams, and you have product teams and horizontal teams, wait, so my frontend team, which is multi-product, how do I load it on the different products? So? How much did the development of a certain feature cost?

Yulia: No, but here you are already entering into a discussion of the organizational structure of a development organization in relation to this. First of all,

Yishai: I'm just trying to say it's an unsolved problem. The organizational structure is changing and the ability of finance to say wait, it's really the cost of construction or even delivery, in the end there are DevOps people whose part of the cost is the cost of OPEX and this is part of the margin, it's not the investment but keeping it alive. How is it divided between my products? How is it divided among the Serbs?

Asaf: So this is an excellent question, when we talk about a FinOut, that is, about the vision of a FinOut, we are actually talking about establishing, my partner's formulation is the modern-day ERP. That is, the ERP systems in some sense are the systems you expect to give you an answer to what you are asking now. That is, they centralize all the organization's expenses and allow you to actually plan a budget and basically understand this world of your company in relation to all expenses. Now ok, you spend a lot on the cloud and you managed to divide it according to your organization and built a logical layer. But how much do I spend on personnel? How much do I spend on marketing by the way in product contexts? Where, how do I calculate ROI of products? So the difficulty is there and in my opinion the world will move there, that is if we are talking about a FinOut vision for the next years it is to connect to more data processors. It's understanding how much you spend on conference expenses, how much you spend on travel expenses, how much CS is invested in each customer in each region? How much does the product really cost me in terms of DevOps expenses, as well as R&D expenses. I think they will get there, I think we are on our way there. Because today, when we talk about the year '23, it is the year of the margin. To know margin you must divide the costs, all your costs. It's even at the cost level of your site. That is, not always the office, now it's fine, there is a division into COGS and non-COGS, everything is fine and dandy. But yes, it is a very difficult problem. I think it depends on the size of the organization as well. I mean, in the end, if the organization is not massive, it's not two thousand people, then you still manage to do it, but when you have development groups and they have to manage a budget and they have to reflect, like, what is their ROI on the, and we're talking here about groups of products And not so much groups of development of one product, but the whole product, how much does it cost me? Unequivocally we are going there, I think we are already there, just today we are doing it manually and using Excel, I don't know if it will ever be solved by using Excel, but maybe we can make this event a little easier.

Yishai: We begin to see, we are also involved in a more accurate work of mapping where my effort really went. I'm talking about the R&D effort, for which projects, for which capabilities, and in the end it also serves the visibility you describe of OK, 30, 40 percent of mine is the cloud coast. I manage this now in a smarter way, with FinOps tools, with teams, with analytics, I tend to think that it will develop so much because it is possible to influence with the help of code, I can optimize and the business will move. Changing things in the worlds of on-prem or in the worlds of HR is much more difficult, so it is also a significant cost that

Asaf: HR is very easy to optimize, I don't know if it's there,

Yishai: It's not that easy.

Asaf: It doesn't count, it's not exactly optimization either…

Yishai: Downloading RDS instance is easier than moving people or even moving people to projects,

Asaf: No, easy I say in quotation marks, yes? The solution is clear but no one wants to do it.

Yishai: True, but we see a shift to OK, let's understand our R&D cost and where they go, and then basically it goes to the same language of a moment, how it is loaded on a particular customer or on a product or on, in the end part of it goes to COGS part of it goes For investment, CAPEX, OPEX, etc., today organizations have to report, capitalize all their R&D costs, what is capitalized,

Yulia: It's not just today, again, I'm sorry, maybe because I come from Amdocs, it's a very strong company, as if the finance body is very strong in Amdocs as an organization in relation to the other internal organizations. It's not new, neither is society,

Yishai: It has been capitalizing for 20 years, and in most cases it is some engineering manager sitting or a collection of engineering managers sitting for a few hours.

Yulia: No, there are internal systems that were written and built and we tried all kinds of models that wasted more and less managers' hours, usually there is some group of managers who enjoy all this goodness so much. But yes, look, in the end, in Amdocs at least from what -, it's not one of the content worlds that I had too much contact with, but I always saw it from the side. In the end, the company would develop a product. It was a shipped product in the past, then there was the sale act and a huge delivery project was opened, which for the benefit of the product was actually woven into a team, a project and so on. So the company did know very well how to move people between projects, the company also knew very well how to classify and treat in general the situation where a person works on two projects. It also happens, and how do you report it and how do you manage it? So it's true, it's not perfect because at the end of the day humans, unlike my beauty and wonderful life in FinOps with the systems, I'm sitting on a pile of data whose production is automatic, I just need,

Yishai: Yes, for humans you have to put a chip in your head to get it out.

Yulia: Exactly, how do you know how many hours, like what, you're now starting to ask people to generate data for you, and then on this data, then it's true, it won't always be completely accurate, so in general I think that this division will never be completely accurate because there is no Go through or, I think I heard, Microsoft they really have such an internal productivity tool, that they kind of know what field they work in and should help them build the database at the end for the finance organization. But this is a problem that many companies have been trying to solve for many years. There is also the when it's good enough at the end, yes? Sometimes you need to stop. Like when there is no ROI to keep investing in it. Not a content expert in the field, absolutely, but from what I know it's a problem that has already been dealt with, I'm not sure it's something that's somehow going to reach the worlds of Cloud FinOps, yes, that's why we also mention Cloud FinOps.

Yishai: Yeah, you could really, it's hard to say whether that will fit in at the end or, as you look at FinOut's vision as something that centers that as well.

Asaf: The consolidation will come, the question is who will do it. Once again, that's why we said ERP's, it's also a completely different system, we're not talking about cloud management here, but cloud management simply needs to connect to a system that needs to provide an answer. When you manage a budget in a large organization, at the end they have to do some kind of projection, something, that's our approach, in the cloud it's much easier to do that at the moment because it's very easy to monitor it as Yulia said. But in the end you have to manage this budget and things will move faster than, we are not moving to a world where resources move slower, they move faster, and people also seem to move faster. Interesting, very interesting to see how the next two, three years will come together.

Yishai: What about SaaS tools as another expense that I want to track and link to, let's say DataDog costs me money, so besides it also serving me it costs me money, Logz costs me money and it is considered part of my cost. It's not Amazon.

Yulia: That's right, so a large part of the SaaS tools are purchased through the marketplace, of sorts, so they are already, everything in the marketplace already pretty much goes into the, already sits within the cloud FinOps categories. Here it's really a matter of maturity, with us beyond what's sitting in the marketplace and really as if the expenses of the large Lacaud Vandours, there are a few more licenses and really companies and tools that we use, which we chose to load and add in fact, to bring into this umbrella of the Cloud FinOps. Because it's really, it's things that are related, there I can measure exactly the same unit of economics and so on, so it connects and it makes sense, and it's like,

Yishai: You did it, you're FinOut, you see,

Yulia: They do it very nicely.

Yishai: see demand for,

Asaf: So the game here is not about the, as if the fact that it is SaaS is nice, the question is what is the pricing model. If I pay per user, it still remains in the worlds of finance, that is, or the worlds of those who, after the budget, have to buy X users, distribute it, etc. If I pay per usage, it's the, the word escapes me, it's the sweet spot. If I pay per usage, that is fine, I bought an account but I can get from there to the on demand rate very quickly. So here you need a lot more management, what is called having a hand on the pulse, etc., so let's say DataDog is a perfect example, an amazing tool, maybe the best on the market for this thing, maybe. But their pricing is crazy. We hear endless comments about this, but now let's take it to Confluent, to Kafka, and let's take it to Snowflake and suddenly there starts to be a problem. Now does this fall under what you are asking? Is it like managing Jira licenses? I don't know, that's all a question of who is responsible for it in the organization. The Jira licenses are probably the one who is responsible for this is the head of R&D or who is ultimately responsible because it is the number 1 tool for his organization. Now at the end it is injected, so it's like how much you want to monitor Jira's costs for him, I don't know, but at the end it's a number that he spends from his budget and he needs to know how to estimate his budget for the next quarter. And if his organization now grows by 30 percent, he will have to increase the amount of users, so we see movement, on the one hand they added native support to all the consumption tools that we will have to look at on a daily level,

Yishai: This you say is already happening, Github Actions and,

Asaf: It's been years, yes, two, three years, this is exactly what we talked about in the Corona movement, that consumption and price per hour, etc., but on the other hand there is also budget management. And finally they demand, let's say we are talking about R&D here, demand that R&D manage their budget and come up with answers that are not just a joke. It's like here, we've pretty much complied with what you told us, no, what's it all about? And how does he know how to anticipate what he will have to ask for next? And they want to put it into products like ours as well, so okay, you pay for it once a month, you only have like one cost or you pay for it once a quarter but you still have to somehow reflect it and see that it doesn't exceed, so yeah, so it is unequivocally

Yishai: Some are adjusted for size, even if it won't really be consumption, it's not just head count, I don't know, PagerDuty or the like, it's ultimately very related to

Asaf: how much do you use

Yishai: And if I have people who are, in their role, I don't know, SREs, then their price and their tolls are ultimately related to the size of the operation that I am,

Asaf: What about CI/C?D 

Yishai: Sure, Github Actions, this whole world.

Asaf: What about all the… is it COGS? No COGS? It's already coming in here, you know, everyone and the flip-flops they do with their budget, but I need to know how to perfect it and also in CI/CD I have an economy unit, how much will I pay per build, it's something that needs to be kept, now the FinOps

s He will never hold it, as if it doesn't interest him, it's also, good FinOps will hold it but most FinOps don't enter into the resolution of how much a child costs, and now some enter into the worlds of how many children they wanted, which team, on which technologies, is it even Related to tests.

Yishai: How long did the developers wait for the build, more expensive than how much it cost,

Asaf: Beautiful, excellent, it's crazy considerations and the beauty of this thing is that the world is moving in the direction of usefulness, usefulness, I want to pay for what I use, I don't want to buy something general now and I don't know how it's divided for me, I want the ability to play with the cards, and to do You need systems that will monitor it on a daily level, that's why Yulia also says observability is the basis, the basis, for everything.

Yishai: So in light of what I've heard, I see here two directions to this world of FinOps. One option, bring me all the data to some warehouse, as BI in the modern data stack works, everything internally, some transformations that in the end rely on knowledge of the domain. But give me the data and now I have analysts who know the company in depth, and everything is already in my Snowflake, now I can make insights and do all the processes beyond. In this world, the role of the FinOps tool is mainly collection and a little modeling.

Yulia: And there is the part of theamortization Let's call it, let's not forget, every company and the commercial, because it's such a big trouble, after all the contracts, especially the big ones, are strange contracts. You suddenly have a discount on a certain service and some kind of discount but you also have credits here and there, you also need in the end to be able to, it's called amortization in the professional language, as if to produce some kind of flat price, which a broker always costs 100 dollars and no, This project costs $100 but the other project costs $200 by mistake because the discounts didn't come in, so there is also this stage which is also a bit challenging at times and it's a bit build yourself or buy.

Yishai: But it's a model that says in the end bring me all the data aligned or who invests in aligning, how much is something I buy or build, but I treat it the same as I treat the rest of the BI world,

Yulia: exactly.

Yishai: Today at the end he will gather to bring me all the raw data to somewhere, on which I will straighten it out a bit and from here I have dashboards, I have standard tools in quotation marks to manage it, and the future is specialized tools that say I don't just stream you data to your warehouse, but I am the place where it actually takes place, I will give you insights at much more advanced levels And my tool is the UI and we won't say Tableau over the Warehouse.

Yulia: It's a bit, first of all anything is possible, it's always the dilemma of build or buy, right?

Yishai: Truth.

Yulia: I can probably any company that decides, there are also companies that decided and went and set up in-house FinOps teams, with development, that actually develop their own dedicated tools, with all the nuances of that company. What every company does after it has reached this state of OK, it has all the data, it has done its modeling, it knows how to understand the costs, now it wants to optimize. Now the optimization at the end is all kinds of conditions and scans and as we threw here the S3 that never, it has no read and only has write on it, or the RDS with zero connections or the EC2 with less than 20 percent. There are a lot of conditions here that are like the advantage of actually going to buy a product, assuming you did really good research and it's the product that suits you, for a large part of these products, or at least the ones I know, like FinOut that I work with (laughs), so it's knowledge that has been built up. So you are not now starting from scratch and building your entire stack up. Some of the information is available on the internet, I've also already tried ChatGPT. I was curious because relatively there is a lot of information on the internet, but no, there are still a lot of things that are missed and a lot of insights that take time to digest. . I see a large Hughes case I happened to win and it's actually the second Hughes case I've already met and they were both relatively large and developed but I don't feel like I've seen enough Hughes cases, that I can say oh, I knowEverything, I can build it from scratch, in-house.

Yishai: So the vendors actually bring this breadth of there are all kinds of use cases and we have already come across ideas whether we raised them, whether our customers raised them, it is worth checking the relationship between the KPI cost that I do here and what happens there.

Yulia: Ah-hem, there is cross-referencing here that I can enjoy thanks to the use of third-party tools. Plus I don't need to set up in-house developments, it's not that simple, they're still 30 people.

(transitional music)

Yishai: I want to finish by looking at the developers. In the end, developers are the ones who write the products that then have to measure them and understand their cost and ask what the FinOps are doing today or where it is going, in the enablement of the developers, what do I demand from the developers or what do I want to demand from them that I don't demand from them today, you are a bit You talked about accountability. What do you think FinOps can give them, talking about a type of shift left or how do I know that the change I am making now in the code is good, it is correct, it brings the desired goal in terms of unit of economics, where do you see it going?

Asaf: Wow, great question.

Yishai: can i ask where you take it

Asaf: So at the end of it all she asked if you created a common conversation for them. I mean, we said, looking at the invoice as it is, it's on the border of meaningless, maybe some insights can be gained. If you create a dialogue with the development teams in which they understand that they are not just looking at graphs but that this is the graph you are responsible for, it can be created with the help of unit economics, it can be created only with the help of costs, it doesn't matter. And we managed to get to the point where they treat it like it's an SLA and we have it once every X amount of time, I don't know, it all depends on the speed of the company's development, a real review of this situation in each of the teams, they also create for them the tools with which they can do it quickly, If it's dashboards, if it's alerts tailored to them, to their Slack Channel, around their costs, this is the best possible starting point. After that we can talk about where the world is going, the world is going in the direction of connecting it as much as possible and quickly checking the code you are deploying, there are companies that today do it in an amazing way for performance. So once again, hypothetically there is no problem connecting this to the worlds of costs, we had a conversation here earlier as well how it starts to get into very, very complex nuances because you really need to simulate a run in production, and it's not just any workload that runs on the server, it's what discounts he got and at what time Run and there is a whole world here. But once again, it's better to start with something than to do nothing, so connect it as much as possible to their ability to slow down the run. And above all to reach a situation where if we have something that is out of line for us and following this common language it will be relatively simple to produce this anomaly or to produce this exception, to bring into the awareness that we had a spike, whether it is a production event or not a production event. There isn't a developer who hasn't come to him and told him listen, there are a lot of incidents in your service, not, in his career, has this happened to every developer. And then the conversation begins of do we want to fix it or do we not want to fix it? Is this error rate okay for us or do we postpone it until next month because there is nothing to do, it is not important enough. Or we will install more instances, every problem can almost certainly be solved with more money, it's the same kind of thing. That is, if this jump in costs is a dollar a day and that's why, and if I put up another service that will cost me another dollar, then the developers will stop getting up at night because they get alerts about Cost. I'm willing to bet that every R&D vp would do it, but if it's a jump of a thousand dollars that suddenly affects my margin now, and Yulia, let's say, for that matter, knows how to reflect, listen, it's very nice, all the games here, but this new feature is going to so-called destroy I have the margin down the quarter, now it is a decision of the VP R&D whether he wants to take it upon himself or not or it may be that at the CFO level he will force R&D to align. If this discourse is produced, this is the way to do it, how then do they check it, etc.? Every company is a whole world, but for me it's like the basics.

Yulia: I’d even take it a step further, even before we wrote the first line of code. Usually some kind of spec from the product arrived, we want to make A, B, C, stunning. Every organization has this conversation going on, a product is asking for something today, most of the time R&D gives them some kind of a turn, maybe, it's the design plus minus, that's what you'll get, certain limitations, and they add some, what will be the report, right? Because every product wants to know how many resources it will consume. Add another number, what will be the cost of this, cost of build, like building it for the first time, testing, developing, blah-blah-blah, and ongoing cost, and this is in the initial stage, obviously this is an estimation, right? But as soon as we are already at such a preliminary stage, we ask the developers to start thinking about how much it will cost me, then it usually starts to seep right from the design stage as well, and of course they put as if it is a preliminary estimate and then really determine according to the feature whether he needs it or No, more points of validation testing and following it up in production.

Yishai: So it also requires the product to define what kind of traffic is there, what kind of, what will it really require, not only,

Asaf: It's like that in performance,

Yulia: Yes, these are questions that in principle the product should know, as if to know how to answer them, and if it did not know how to answer, and R&D did not ask, then it will appear in the performance. After all, operational, performance, DevOps, FinOps, we work together. Yes, there is some here, as if someone once told me, but my KPIs are against your KPIs, as if I want as much stability as possible and you want as little as possible, and I completely agree with that, there should be a sweet spot,

Yishai: There is a balance, yes.

Yulia: Exactly, there is a balance, you find it, the advantage is that you look at it correctly and find the balance, so many times the FinOps find performance problems. Find production problems. Because as soon as something suddenly changes with some KPI, I tell them guys, pay attention, something like, it doesn't make sense, something in the numbers, like I have a KPI that jumps out at me, I have an alert. And it doesn't make sense. And when we look suddenly we find that we have an auto-scaler that stopped working, or,

Yishai: Or it’s going wild.

Yulia: Yes, or going wild, and so on, and we often find either someone made a manual change and didn't return it, many things, we often find, that we find information security risks sometimes (laughing) it's very nice.

Yishai: Sometimes you have to reach a situation where a product is given a budget, part of the definition of the feature, okay, it has to run to a thousand users a day. Here is the cost I approve for this, for example I already know the margin I want to meet, that's the cost, find me financing that meets the cost. If it does not meet the cost, as in performance, you can say I want this thing to cost the user within half a second, above that, it is not acceptable. Is it possible to do the same on a budget?

Yulia: Yes, they don't do that today. I think the reason not is that the cloud budget often sits in R&D or operations and not in the product. If you transfer the budget of the cloud to the product, you will see them doing it well. I think I heard about one of the companies that they put the FinOps in the product. And it has a lot and besides, it has a lot of advantages. After all, it's a bit of a strategic decision where you put the FinOps. It can be, we mentioned earlier, it can be in many places, where you put it depends a little on the culture that will be created around it, but I agree,

Yishai: Because if the developers said okay, it will cost $3 a day, then someone comes and gives feedback on it and says good, not good.

Asaf: So set a budget in advance, say,

Yulia: That's it, so today we simply reflect to the product how much it will cost, and when sometimes it seems to us that maybe the product is overlooking a figure that might be disturbing, then we add more stakeholders like finance that can be relevant to this conversation. But yes, there is a collection of stakeholders here, you need to know how to manage them.

Yishai: To finish, I would like everyone to give a tip to the company or to the VP R&D or whoever is responsible for it, who wants to start messing with FinOps, a company that is not doing it to this day and has no title, no owner, where to start? What's the first thing that goes into it?

Asaf: Wow, what a question. The first thing, first of all to decide who the person is who owns it. I mean, it's perfectly fine not to hire FinOps out of the gate, but that means that the Head of Platform or the Head of DevOps someone has to be the owner, okay? Someone should come and say this is my KPI, I took ownership of it, I'm studying the field, now start to understand like if they want to recruit FinOps, they don't want to recruit FinOps. Now as long as we are a company in Hyper Growth, and no matter what I do, it doesn't matter to the company, we are going through a business change, no one will prioritize optimization projects, visibility, no matter what, it's perfectly fine to come and say okay, I'm not there right now, and that does not interest me. Always have your hand on the pulse, understand at least how much my monthly expenses are, see that it doesn't increase by 30, 40 percent in one fell swoop, but everything is fine and dandy. So produce ownership. That's the first thing, someone that's his job, I don't think that VP R&D should be his job, he should be there to be asked questions and able to give answers. For me, this is the number one, like if I really, really boil it down to something basic, it's do you want to get into it and who is responsible for it, after that you can start to get into whether there is a conflict of interest here, as Yulia said, that is, we need a function that is a little more horizontal, etc. And if I also go into tip number 1 that I think should also be given to whoever is responsible for it, and Yulia will now laugh at me, in the last few weeks the token fell to me that the first thing to do is to start demanding more from your providers. I mean I manage a budget, I'm a big company or a small company, it doesn't matter what, this budget is a significant part of my expenses. To come to Amazon, Azure and GCB and tell them listen, I'm spending 30 percent of my budget on you, give me a discount, what is this thing? I undertake the expenses here, give me something. The number of companies we know that made a massive discount in one fell swoop just because they opened this dialogue with the providers may not be successful from the first moment, but there is a great deal of pressure today on the providers that people will not switch between organizations, that they will not lose costs. And they want to make you happy, now that they own the entire organization, yes, your entire infrastructure in Amazon, it doesn't matter, discounts will be required, help will be required, whatever will be required, this is my number one tip, it's like it's unbelievable what miracles can be done with This thing, it sounds a bit like a trade, but in general it is a trade and there is no other way to write it.

Yulia: It's not trading, it's negotiation, it makes sense, it's a thousand points of any operations and procurement organization and so on, it's perfectly fine and it's absolutely true. It doesn't take away the headache of what we spend the money on, I would really at first focus on what the money is spent on. And most cloud providers have a great set of basic out of the box recommendations. Yes, it's the basic ones, they're not the most sophisticated, they don't have all the insights I talked about before this. But it's a start, it's a nice place to begin, and there is a lot of information on the net, there is a beet of the FinOps Foundation. There's a lot of information there and there's like after you see the FinOps for Dummies - what the hell that is... like how to do basic optimizations, there's a lot of information, it's easy stuff, there's a lot of quick wins, which is what you can do and focus on at the beginning While you study and understand this field and try to understand how it meets you in the relevant company.

Yishai: Excellent, so we already have two links to put together with the podcast, FinOps Foundation and FinOps for Dummies.

Yulia: (Laughs) Not sure if this link exists.

Asaf: And the last thing, specifically, this is also in Hebrew, so the community in Israel is a very warm community, very verbose, very easy to reach FinOps people with experience in Israel, ask, just ask what you would do, how would you start, who is worth it, how to start, as if DevOps people are talking Endless. There is no reason why they should not also talk financially with each other endlessly, have you used this tool, how was it, does it suit you, does it not suit you, be, don't be ashamed to share. Because we're all in the same boat in the end, everyone does the same thing, just call it ingestion and call it index and call it parsing, it doesn't matter, in the end we take JSON, put it in some good and consume it from there and you have to know how to manage it at scale, which is beautiful, It's just beautiful how everyone helps each other.

Yishai: Excellent, so it's also a great tip to lean on the community. Yulia, Assaf, thank you very much for coming.

Yulia and Assaf: Thank you very much, it was fun.

Yishai: Thank you.

(transitional music)

Visit devInterrupted.com to subscribe, you can also find all our episodes in English there. I remind you that we at LinearB are growing rapidly, recruiting for a variety of positions in all fields. Come to linearb.io/careers to find your next challenge. I'm Yishai Beeri, we'll hear from you in the next episode.

(closing music)

Links to the nifty tools and resources mentioned in the episode:

• Finout
• Logz.io
• FinOps Foundation
• FinOps for Dummies
• Amazon Cost Optimization
• Azure Cost Optimization
• Google Cloud Cost Optimization
• DataDog
• CloudHealth
• Cloudability