 From the CUBE 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 am 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 happening in the cloud, all 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 the 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 the space. I want to welcome Sasha Kippervarg, he is the head of global cloud operations and special projects with LiveRamp. Sasha, thanks so much for joining us. Thanks very much Stu, 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 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, that whole space is a whole separate discussion. I like when I looked up a little bit about LiveRamp, the discussion point is cookies for eating, not for following you and looking where you're going all over the company. So your role inside of LiveRamp though, tell us a little bit where cloud fits 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. 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 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 heat wave 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 mid 90s but for the Bay Area in the summertime 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 moved to the cloud. You talk about adopting containerization, your applications. How much of it did you just kind of move there? How much did you build new? Were there some things that you just said, hey, I can kind of adopt a SaaS equivalent? 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 tried to do was essentially containerize all of our infrastructure applications. Actually, let me phrase that. We took the customer facing applications and we containerized 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 used the native services in GCP 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 100 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 is 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 a couple of months or a quarter. Overall, how has the experience been moving to cloud though? Well, it's been fantastic in some ways. Painful in others because you discover and maybe this is where we begin to touch on the FinOps stuff. 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 unlimited operating expenses. It's quite a big shift and I think a lot of companies are caught flatfooted by it. We certainly were for a little bit and there's some financial pain that gets expressed and the question that I would pose to the audience when they think about the cloud is, 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 contain our eyes and it's on schedule, but then you blow your budget, was it really a success? Because ultimately 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 budget, 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 next month and next quarters billing. So bring us inside a little bit as to that interaction and what that meant to your teams and how they had to think about engineering and finance together. Yeah, it's a fantastic question. So I guess the first thing is let me zoom out for a moment and just make sure that the audience understands that 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 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, that's what you've done, they don't just spin 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, a person dedicated to the role and then members of the finance team and then many other members of engineering 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 did 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 too 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'd come from the infrastructure side when I think about, you know, deployments in a data center, it was very well understood. You had, you know, systems engineer work with a customer, they deploy something, they understand what the growth of is expected to be and if you needed 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, you know, here's some gear you could work on but, you know, finances were, you know, clearly written, they were, you know, put into, you know, some spreadsheet or, you know, 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. You know, we're huge proponents of ledger in the cloud and often there are, you know, cost savings by going to the cloud but it feels like there are also some of this overhead of having to do the financial engineering is an overhead cost that might not be considered in the overall, you know, 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 and this concept of having the budget overhead and I want to link it to Agile, okay, so part of the reason we moved to DevOps, which is an Agile movement that essentially, you know, puts, you know, the responsibility of owning infrastructure and deploying it into the hands of the engineers themselves, right. 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, you know, depending on the size of the company, it 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, right, 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, that's 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, helped move us towards that ultimate call that we know we've had for years. I want to tease on a 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 if 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. 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 a data center. And 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 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, this idea is still being sort of fleshed out. And even within the Phenomps movement, there is a question of how much time should a developer spend thinking about cost 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 their applications efficiency. And if when you are implementing a Phenomps 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. 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 Phenomps emphasizes is key. 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. Phenomps 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 Phenomps or not, you're going to be set up for a success and it will solve that problem for you. Yeah, 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 garden about what they would share. Of course, these days, leveraging cloud, leveraging open source, there was much more collaboration out there and LiveRamp not only is using Phenomps, but you're a member of the Phenomps 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 Phenomps Foundation. Yeah, I mean, as members of the audience might know, the Phenomps Foundation recently moved to the Linux Foundation and I think part of that move was to express the independence of the Phenomps Foundation. It was connected to a company in the CMP space before and I think JR 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 code base 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 this idea of 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 Phenomps course at a conference and Mike Fuller who was the author or one of the authors of the Phenomps book along with JR was teaching it and I spent eight hours just 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 Phenomps practice as a solution for LiveRam's budgetary cloud pain. We went for it and 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 JR and Mike, they had all interviewed hundreds of different folks for the book, gotten 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 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 on everything that you've learned and best of luck going forward. Thanks very much, it was great to talk. All right, if you want to learn more about what Sasha was talking about, Linux Foundation, it is just thinops.org is their website, Linux Foundation, of course, the cube, you know, cloud native, a big piece of what happens and what we're doing will be at the kubecon, cloud native con shows this year, look forward, more interviews in this space. I'm Stu Miniman and look forward to hearing more about your cloud native insights.