>> Narrator: From theCUBE studios in Palo Alto in Boston, connecting with thought leaders around the globe, these are Cloud Native Insights. >> Hi, and welcome to another episode of Cloud Native Insights. I'm your host, Stu Miniman. And when we talk about Cloud Native of course, it's not just moving to the cloud as a location, but how do we take advantage of what's happened in the cloud of the changes that need to happen. And this is not only from a technology standpoint, it's an organizational standpoint. And we're also going to touch on the financial implications and something you've probably heard about FinOps, relatively new last couple of years as a term. Of course, the financial engineering cloud has been around for many years and how that ties into DevOps and to help us understand this movement, what's going on really thrilled that we have a practitioner in this space. I want to welcome Sasha Kipervarg. He's a head, the head of Global Cloud Operations in special projects with LiveRamp. Sasha, thanks so much for joining us. >> Thanks very much too, happy to be here. >> All right, so why don't we start off first for those that don't know LiveRamp, I'm sorry, you're in the ad tech space. Maybe just give us a little bit about, you know, the organization and what your team does there? >> Sure, so LiveRamp is in the advertising technology space, and we help connect companies to their customers and send targeted advertising to them. We're based in San Francisco and have engineering teams across the globe, primarily New York, London, China, all over the map, really. And we're a fast growing company, we've gone from perhaps 400 to maybe 12, 1300 employees over the last year and a half. >> Well, you know that whole space is a whole separate discussion. I like when I looked up a little bit about LiveRamp the discussion point is, you know, cookies for eating not for following you, in looking where are you going all over the company. So your role inside LiveRamp, though. Tell us a little bit... You know, we're cloud bits in New York? >> Sure, so I'm responsible for the engineering teams that help other development teams operate in the cloud. So whereas on premise, it would have been a traditional operations team in the cloud. It's basically an engineering team that are experts in all the different areas that other engineering teams need us to be in so that we can express good practices and help them deliver products. >> Great, you actually had a real forcing function for cloud. You know, right now during the global pandemic we've seen lots of acceleration of people looking at cloud, if you could briefly just bring us back as to one of the things that helped push LiveRamp, you know, to go much heavier into cloud. >> Yeah, so we had some initial plans and we were exploring. But what really pushed us over the edge was we had a three to four day outage at our data center here in San Francisco during a heatwave. And during that time, the data center couldn't control their temperature. We had unusually warm temperatures in San Francisco, they weren't that warm. It was like maybe in the, you know, mid 90s. But for the Bay Area in the summertime, you know, where it's usually 70, it was a big deal. And so we had racks of servers going down because it was too hot. And so if we weren't quite convinced before that we certainly were after that, and that made us realize that there were lots of good reasons to be in the cloud. And so we did it. We put together a migration and over the course of a year, we not only containerized but we migrated our environment into GCP. >> I wonder if you could just bring us inside a little bit that move to the cloud, you talk about adopting containerization. You know, your applications, you know, how much of it did you just kind of move there? How much did you build new? Where there some things that you just said, hey, I can kind of, you know, adopt a SAS equivalent, you know, how did your application portfolio look? >> Yeah, so it's probably good to think of them in terms of the infrastructure services that we use in the cloud, and then the customer facing applications themselves. And what we try to do is essentially containerize all of our infrastructure applications. Actually, let me rephrase that. We took the customer facing applications, and we containerize those. Now the applications themselves, did not change but they swapped out their underlying infrastructure for containers, running on the GCP native container service. On the back end of things we use the native services in GCP up as much as possible. So if we were using a database on premise, we tried to use the native database service in the Cloud with Google. I think the one interesting exception to that which we're changing now, in fact, was we decided to run our hundred petabyte Hadoop cluster in the Cloud using our own native service because of some price concerns. Those price concerns have gotten better since time and we're now migrating to Dataproc, which is Google's native Hadoop service. >> Yeah, it's fascinating when you think about just how fast things change in the cloud, new services can become available and as you're alluding to the finances can change significantly over you know, a couple of months or a quarter. Overall, how's the experience been? You know, moving to cloud, though? >> Well, it's been fantastic in some ways, painful in others because, you know, you discover and maybe this is begin to touch on the FinOp stuff like, you discover that you've gone from quarterly planning cycles where you opt to purchase a whole rack of servers, and you implement them over the next quarter or something like that, to making by the second decisions, to spin up resources via command line by developer and spend unlimitless operating expenses. So, it's quite a big shift. And I think a lot of companies are caught, you know, flat footed by it. We certainly work for a little bit. And there's some financial pain that gets expressed. And you know, the question that I would pose to the audience when they think about the cloud is, you know, we think of the migrations and we only think about their technical success, but if you migrate to the cloud and you do it technically and you containerize and it's on schedule, but then you blow your budget, was it really a success? Because ultimately, you know the business needs to be profitable in order for things to work. >> Yeah, absolutely Sasha. So what I've heard you talk about this before is in the pre-cloud model, you met with the budget team quarterly, and it was mostly a look back function. And of course, when you think about leveraging the cloud, things are changing on a fairly regular basis. And are you able to understand what decisions you're making and what the impact will be on you know, next month and next quarters, billing? So bring us inside a little bit as to, you know, that interaction and what that meant to your teams and how they had to think about you know, engineering and finance together? >> Yeah, it's a fantastic question. So, I guess the first thing is, let me let me zoom out for a moment and just make sure that the audience understands that you know, typically it's just engineering leadership, and a fairly small number of maybe high level developers, maybe an architect that get together with finance once a quarter and have a conversation about what they want to spend and how much they want to spend, and where it should be implemented. And that is a fairly regular thing that's been going on for many years. When you move to the cloud, all of a sudden that decision needs to happen on a real time basis. And typically, companies are not set up for that kind of a conversation. There's usually like a large wall between finance and engineering. And it's because you want the engineering teams to be engineers and the finance folks to be doing finance related things. And the two don't really mix all that often. But when you give a developer an API to spend money essentially right, that's what you've done. They don't just spend up resources, they spend money by API. You need to have a real time conversation where they can make trade offs, where you can track the budget, and those expenses shift from something called CapEx to OpEx. And that's treated in a very different way, on the books. Where we are today is we've created what a team, we call it a FinOps practice. But it's a team that's cross functional by nature that sits within engineering that's made up of a FinOps practitioner, person dedicated to the role. And then members of the finance team. And then many other members of engineer and they work together to first, express the cost by helping developers understand what they're actually spending and where they're spending it. And then the system also makes, recommendations about how to optimize and then the developers absorb that information and figure out what they should optimize, do that work. And then the system re-represents the information for them, and lets them know that their optimizations make sense or not from a financial perspective. The way that we've talked to developers, we've discovered that they care about efficiency. They care about efficiency in different ways. They care about CPU efficiency, they care about RAM efficiency. And it turns out, they care about how efficient their application is from a cost perspective to, right? And you can either tell them directly to care about it, or help them become aware. Or you can use proxies, like what I just mentioned about CPU, RAM, disk, network. If they understand how efficient their application is. They have a natural instinct to want to make it better on a daily and weekly basis. It's just sort of baked into their deep engineering persona. And we try to harness that. We try to position things in such a way that they can do the right thing, because most developers want to do the right. >> Yeah, it's really interesting to me Sasha I remember back, you know you go back seven, eight years ago and I looked at cloud models, and how cloud providers were trying to give more visibility and even give guidance to customers as to how they could adjust things to make them more financially reasonable. I've come from the infrastructure side, when I think about you know, deployments in a data center. It was very well understood you had systems engineer work with a customer, they deploy something, they understand what the growth of is expected to be, and if you needed more, more computer, more storage, what the cost of that would be, you understand the you know, how many years you will be writing that off for, but everything's well understood, and as you said, like developers often they've got, n minus one technology, okay, here's some gear you could work on. But finances were clearly written, they were put into some spreadsheet or understood as opposed to the cloud. There is much more burden on the user to understand what they're doing. Because you have that limitless capability as opposed to some fixed asset that you're writing it off. We're huge proponents of ledger than the cloud. And often there are, cost savings by going to the cloud. But it feels like they're also some of this overhead of having to do the financial engineering is an overhead cost that might not be considered in the overall movement to the cloud. >> Yeah, and maybe now is a good time to swing back to the concept of DevOps, right? Because I want to frame FinOps in this concept of having the budget overhead and I want to link it to the Agile, okay. So, part of the reason we moved to DevOps which is an Agile movement that essentially, puts the responsibility of owning infrastructure and deploying it into the hands of the engineers themselves. The reason that it existed was because we had a problem deploying, we had two different teams typically operations and engineering. And one of them would write the code, and they would throw it over the wall to the operations team that will deploy the code. And because they were two different teams, and they didn't necessarily sit together or sometimes even report into the same leadership, they had different goals, right. And when there was a problem, the problem had to cross both of the team boundaries. And so it was slower to resolve issues. And so, people had the bright idea to essentially put the teams together, right. And allow the developers themselves to deploy the code. And of course, depending on the size of the company was structured--or it is structured slightly differently this idea of DevOps. And, essentially what you had was a situation that worked beautifully because if you had two separate teams that all of a sudden became one team that was fully responsible for writing the code, writing the tests and deploying the code, they saw each other's pain, they understood the problem really well. And it was an opportunity for them to go faster, and they could see the powerful thing. And I think that's essentially what made the DevOps movement incredibly successful. It was the opportunity to be able to control their own destiny, and move faster that made it successful. I view FinOps in a similar fashion. It is an opportunity for developers to understand their cost efficiency and deploy in the cloud by API, and do it in a fully responsible way. Everything that we've been talking about related to DevOps, there is a higher goal here. And that is the goal of unit economics, which is figuring out precisely what your application actually costs being deployed and used by the consumer on a unit basis, right. And that is the thing we're all trying to get to. And this FinOps gets us one step closer to that sort of financial nirvana. Now if you can achieve it, or even if you can achieve the basics of it. You can structure your contracts in a different way, you can create products that take better advantage of your financial model. You can destroy certain products that you have, that don't really make sense to operate in the cloud. You can fire customers. You can do a whole variety of things, if you know what your full costs are, and FinOps allows us to do that. And FinOps allows developers to think of their applications in a way that perhaps they never have in a fully transparent, holistic way. Like there's no sense to build a Ferrari, if it costs too much to operate, right. And FinOps helps you get there. >> It's such an important point Sasha. I'm so glad you brought that up, back in the traditional infrastructure data center world, we spent decades talking about Showback and Chargeback and what visibility you had? And of course for the most part, it was, oh well you know, that sunk costs or something that facilities takes care of. I'm not going to work at it and therefore, we did not have a clear picture of IT and how it really impacted the bottom line of business. So FinOps as you said, help move us towards that ultimate goal that we know we've had for years. I want to tease on that thing that you mentioned there, speed. We understand that, absolutely speed is one of the most important things, how do we react to the business? How to react to the customer, as close to real time as possible? How do you make sure that FinOps doesn't slow things down? If I'm an engineer, and I need to think about oh, wait. I've been told that, the best code to write is no code. But, I have to constantly think about, am I being financially sound? Am I doing that? How do we make sure that this movement doesn't slow me down, but actually enables me to move forward faster? >> Yeah I mean, let me mention a couple of things there. The first is that, what I alluded to before, which is that if you don't think about this as a developer, it's possible that the finance folks in the company could decide well hey, operating the cloud doesn't make financial sense for us. And so we're not going to do it and we're going to go back to data center and you maybe that's the right business move for some businesses who aren't growing rapidly, for whom speed and flexibility isn't as important. Maybe they stay in the data center or they go back to a data center. And so like, I would think a developer has stakes in the game, if they want to be flexible, if they want to continue to be flexible. And from a company perspective, like we... You know, this idea still being sort of fleshed out and even within the FinOps movement, like there is a question of how much time should a developer spend thinking about costs stuff? I'll tell you what my answer is, and perhaps I can touch on what other people think about it as well. My answer is that it's best to be transparent with developers as much as possible and share with them as much data as we possibly can, the right kind of data, right? Not overwhelm them with statistics, that help them understand their applications and applications efficiency. And if when you are implementing a FinOps practice within your org, if you get the sense that people are very touchy, and they're not used to this idea of talking about cost directly, you can talk about it in terms of proxies, right. And as I mentioned before, CPU, RAM, disk, network. Those are all good proxies for cost. So if you tell them hey, your application is efficient or inefficient on these different dimensions, go do something about it, right. Like, when you build your next architecture for your application, incorporate efficiencies across these particular dimensions. That will resonate and that will ensure that developers don't feel like it's hampering their speed. I think the cultural shift that FinOps emphasizes is key. This, helping developers get the high level understanding of why we're doing what we're doing and why it's important and embedding it into their not only their architectural design, but their daily operations. That is the key, like FinOps has multiple pieces to it. I think it's successful because it emphasizes a system that's made up of governance practices, rules that tell you how you should behave within the system. Tools like a CMP, and we can talk about that in a bit. But essentially, it's a cost management platform which is a tool that is designed to figure out what you're spending and express it back to you. It's designed to create anomalies and there's a whole segment in the marketplace of these different kinds of tools. And then of course, the cultural shift. If you can do all three at your organization whether you want to call it a FinOps or not, you're going to be set up for success and it will solve that problem for you. >> So Sasha, one of the things I've really enjoyed the last decade or so is it used to be that IT organizations thought what they were doing was, the differentiator and therefore, they were a bit guarded about what they would share. And of course, these days leveraging cloud leveraging open source, there is much more collaboration out there. And LiveRamp, not only is using FinOps, but you're a member of the FinOps Foundation, which has over 1500, individual members participating in that oversaw by the Linux Foundation, maybe bring us in a little bit as to, why LiveRamp decided to join this group. And, for final word on really kind of the mission of the FinOps Foundation. >> Yeah, I mean as members of the audience might know, the FinOps Foundation recently moved to the Linux Foundation, and I think part of that move was to express the independence of the FinOps Foundation, it was connected to a company in a CMP space before and I think J.R and the team made a wonderful decision in doing so. And I wanted to give a shout out to them. I'm very excited about the shift, and we look forward to contributing to the codebase and all the conversations. In terms of how we discovered it. I was feeling the pain of all these different problems of being, over my budget in the cloud. And, I had arrived at like this idea of like, I needed a dedicated person, a dedicated team that was cross-functional in order to solve the problem. But, on a whim, I attended a FinOps course at a conference and Mike Fuller, who was the author or one of the authors of the FinOps book, along with J.R. was teaching it and I spent eight hours just in like, in literal wonder thinking holy crap this guy and whoever came up with this concept put together and synthesized all of the pain that I had felt and all the different things I thought about in order to solve the problem in a beautiful, holistic manner. And they were just presenting it back to me on a platter, back to everyone on a platter and I thought that was beautiful. And the week that I got back to work from the conference, I put together a presentation for the executives to position a FinOps practice as the solution for LiveRamps budgetary cloud pain. We went for it, and we... It's helped us, it's helped lots of other companies. And, I'm here today partly because I want to give back because there's so much that I learned from being in the Slack channel. There's so much that I learned by reading the book, things that I hadn't thought of that I hadn't experienced yet. So I didn't have the pain. But you know, J.R and Mike, they had all interviewed, hundreds of different folks for the book, got lots of input, and they were talking about things that I hadn't experienced yet, that I was going to. And so I want to give back, they clearly want to give back. And I think it's, a wonderful, a wonderful practice, a wonderful book, a wonderful Slack channel. I would recommend that anyone facing the budgetary challenge in the cloud, join the organization There is a monthly conversation, where someone presents and you learn a lot from doing it. You learn problems and solutions that you perhaps wouldn't have thought of, so I would highly recommend it. >> All right, well Sasha thank you so much for sharing your story with our community and everything that you've learned and best of luck going forward. >> Thanks very much Stu. It's great to talk. >> Alright, and if you want to learn more about what Sasha was talking about, Linux Foundation it is this finops.org is their website. Linux Foundation, of course theCUBE. Cloud Native, big piece of what happens and what we're doing will be at theCUBEcon, CloudNativeCon shows this year. Look for more interviews in this space. I'm Stu Miniman. And look forward to hearing more about your Cloud Native Insights. (upbeat music)