[Music] hi I'm Peter Burroughs welcome to another cube conversation from our beautiful Studios here in palo alto california as we do with every cube conversation we come up with a great topic and we find someone who really understands it so they can talk about it we capture them for you so you can learn something about some of the new trends and changes in the industry and we've doing that today too the topic that we're talking about is how do you do a better job of mapping the costs that are being generated by the cloud or that informations coming out of cloud suppliers related to what you're using with the actual business activities that generate the differential capabilities that customers are looking for that's a tough tough challenge and to understand that better we're talking with junior Stormin who's a co-founder of cloud ability Jaron welcome to the cube thanks Peter good to be here so so let's talk about first who are you yeah so I am co-founder of cloud ability and credibility is focused around improving the unit economics of cloud spend so our customers tend to be those who are spending large amounts in AWS or Azure or GC P and we take their billing data their utilization data various metadata about their business and do machine learning and data science on top of it to help them get better visibility into sort of where that spend is going how they're using it but more importantly to give them some controls around how they want to optimize an optimize doesn't necessarily mean save money in a cloud world because most companies who are moving into cloud very heavily are doing that for the innovation for the speed so they can deliver you know better data faster but it's really about fine-tuning the conversation say okay here we want to save money here we want to move faster here we want to focus on quality and really providing a way for the the various groups that aren't normally talking the finance teams with the engineering teams with the procurement teams all these groups to come together and be able to take executive input to say okay how do we want to operate and how do we one improve those your economics as we go well I want to start with just quick comment on this notion of Union I can when people here historically hear the notion of unit unit economics they think of you know increasing scale so the average cost per unit goes down yeah I think you're talking about more than that right are you really also talking about a mapping of what spend is generating to the business activities that actually generate value and ensuring that you get the differential or the optimized Union economics unit cost yeah oh so the mapping is actually really interesting ly challenging in cloud it's hard enough in traditional IT if you look at somebody like AWS they have two hundred thousand SKUs different products you can buy and they now bill at a second level resolution so what this means is you've got all these engineers out there using cloud in a very good way to move quickly and of 8/2 little more features and they kind of have an unlimited credit card that they can go spend on as quickly as they need and they never see the statements they never see the bills and the other side you've got finance teams procurement teams who've sort of lost control of traditionally the power of the PIO that they have to actually rein that in and they're they're struggling just to understand what is the spend and then to the mapping question how do i allocate these hundreds and millions of charges that i have this month into cost centers and business units and getting that sorted in a world where engineers are focused on moving fast or not they're not tagging things based on cost and are typically so once you get that sort of mapping aspect sorted to the next point you brought as is in bringing the business value so how do we start to relate that back there's a concept a lot of you know IT has been a cost center and now it's sexual driver of value in a world where businesses are increasingly delivering their value through software so we need to start tying the spending mapping into the business and then tying that to the value delivered a great example of this I was sitting last week with one of the largest cloud spenders in the world there have been you know nine figures with their primary vendor and in the conversation with the executives we realized that nobody was looking at both sides of that equation you had the the finance people who were saying hey we're tracking the cost and we think I was happening there and then you had the the revenue generators looking at the money coming anyhow the cloud people with that but there wasn't this centralized view to say alright we want to have a conversation about what value I were getting to spend and the question that always comes up what that is I was doing the right amount well let me build on that because it's seat because IT is historically and this is one of the things that we've been doing over the last few years IT has historically done things on a project level yes all right so we had waterfall development we tried to change that with agile we had you know buy the hardware upfront and then deploy the application on a cloud changes that so this project orientation has led to a set of decisions about finance at the moment that the business asides to do it we've changed the practices that we use at a development level we've changed the practices that we use at an asset level is it now time to change the practices that we use at a finance level is that really kind of what's going on here it is that the project analogy is good because what we're seeing is they're shifting from a project basis to a productive basis and products that deliver value increasingly if you think about the change that's happened with DevOps it in the scene and cloud companies are delivering more of their value through software and they're not just using IT for internal projects right it's actually the driver of business how we interact with Airlines and banks and all these things so that's the shift to say okay now we've gotten good at DevOps moving fast and we've gotten good at deploying and building better data stores now we need to bring in this new discipline and the discipline is what the market is calling fin ops which essentially is combining financial financial operations but you simply combine technology applied specifically do a cloud roll and it only can really happen in cloud it can't happen in data centers because data centers have fixed spending right you have to wait to get resources once you make the investment it's a sunk cost there's months of lead time cloud introduced the removal of constraints which means you can get whatever you want as quickly as you want and DevOps meant it's all automated so instead of your collection of 60 servers you've got thousands that are coming up and down all the time so what you don't have to do is bring in all these groups engineers have to think about cost as a new efficiency metric they have to think about the impact of their business at this code this confirmation template they just wrote is going to have and the finance teams have to shift from this mode of I'm under report retro actively and at a quarterly granularity sixty days after it happened and block investment to be I'm going to partner with these teams report in a real-time fashion give them the visibility help forecast and actually bring them together to make better business decisions about the cloud spend so cloud has allowed development to alter practically agile has been around for a long time before the cloud predates the cloud but it became practical and almost demanded as a consequence of what you could do with cloud so cloud change development through agile it changed infrastructure management through DevOps where now you're you're deploying software infrastructure of code and know as code and what you're saying is the third leg of that stool cloud is now changing how you do financial management of technology financial management of IT and we're calling that fin ops yeah and you you you can't really have fin ops without cloud or without DevOps and if you have the two together you alter we need this new set of it's a new operating model the reason this has come to a head of late is you know if you look at going to the Amazon riemeck conferences a few years back it was like well how much is cloud gonna be a thing and okay clouds now gonna be a thing when's it gonna happen now it's about the how and how do we do this better cloud is hitting for the material spend levels now at bigger organizations I mean the you know see the the cloud projections where it's going I think it's now 360 billion the next few years and we're seeing CFO's at public companies look to say okay it's not my biggest line-item yet but it's the most variable and fastest growing cogs expense so it's actually start to affect our margins we needed a new set of process used to actually manage this so one of the things that's coming to market is this new group called the phenoms Foundation which is a non-profit trade association that initially has a few dozen of some of the largest cloudspinners of the world there's the Spotify as the alaskans the nation why it's Autodesk's and they've all come together as a set of best practice practitioners to start to codify this into something that can be you know scaled out in organizations so that group is gonna be putting out a user conference around this area there's a new o'reilly book that's coming out the end of the year that's going to be sort of the treatise and all this stuff pulled together because what we found in you know me is in code ability in the last eight years we bring in technology and platform to show the recommendations of visibility how to do this but the real challenge companies run into is they don't have the internal expertise their finance teams understand what they need to the engineers don't and so you know they came to us last year saying can you help figure out the processes can you educate us and that's really where you know the spin offs foundation is growing bringing together those people to define those processes so the the impact of cloud on each of these different groups on the development group on the infrastructure team and now on the finance team the interest the developer groups I think some of them resisted it but generally speaking it's gone okay and and eventually tooling from a variety different players came along that made it easy to enact best practices and software development through an agile mechanism in the last few years after significant battles within infrastructure teams about whether or not they were going to use software as code we've seen new products new tooling that has facilitated the adoption of those practices what kind of tooling are we going to see introduced that facilitates thin ops so that finance teams procurement teams move from a project orientation to a strategic management of the resource orientation I mean I think the first is on the engineering side is seeing costs become a first-class citizen of an efficiency metric that they need to look at so you know in their build processes baked in the CI CD looking to see am I properly sizing my compute request for the workload that it needs there's some research research just came out showing that I think it's like 80 percent of the market is not using the best discounting options the cloud providers offer you hear these horror stories it's too expensive we said overspend that's not actually a problem with the cloud providers that's a problem with the enterprises not using the tools offered the discounts the reserved ences the infrequent access door exactly so I think at the end of the day it's the first step in this is getting those checks in place to say are we using the things that help drive the right cost for our needs and the other side of that the finance team is really changing the way that they are interacting with their technology teams becoming partners becoming advocates in this versus a passive you know retroactive reporter down the line and this enables these sort of micro optimization discussions that can happen where data center world we bought it some cots is sitting there odd world we can make decisions today that impact you know the business tomorrow so let me make sure I got this so I have a client who who I was having a conversation with them they told me that their their Amazon there AWS bill is 87 gigabytes mm-hmm not that monthly that's 87 pages that's 87 gigabyte yeah so we get we bring this 87 gigabytes in and it's a story about what I consume out of Amazon it's not a story what my business utilizes to achieve its objectives so we're now entering into a world where we're trying to introduce those financial visit that financial visibility into how that spend can be mapped to what the business does so the finance group can look at a common notion of truth and the IT group can look at a combination of troop application owners can look at a common notion of truth and that's what is fin ops is providing if I got that right yeah absolutely and the eighty-seven gigabyte example is the exactly reason why it is fin option not just cloud financial management you can't have a person with a spreadsheet looking at that and trying to make decisions about it right it has to be automated its IT finances code it's got to be baked into the processes you know we we've seen organizations that have hundreds of millions of individual charges hitting them in a consumption based manner the other thing that's come in with the fin ops as a core tenant is we're now seeing a decentralization of accountability for that spend so if you look at the big cloud spenders out there maybe spending tens or hundreds mils a year some of them have thousands of cloud environments gone is the day of we have a centralized Group begins to say we're gonna turn this off turn this off we want to give each of those teams the ability to see there's just their portion of that bill in the right mapped way as you said and to be able to take actions on the back of that so that's changed and they you know you run it you maintain it you understand which shutdown what has sort of come back to the old centralized model is this notion and this is where procurements job is shifted to largely of we deal still want to centralize the rate reduction so engineers you go use less right essentially finance team procurement work together with the cloud vendors to get the best possible rates through reserved instances can be reduced discounts you know volume discounts negotiated rates whatever it is and they become sort of strategic sourcing just say you're gonna use whatever you're going to use and you're gonna watch that to make sure you're using the right amount will targets threshold we're gonna make sure we get the best rate and that's sort of the two sides of the coin well very importantly procurement has always been organized on episodic purchases where the whole point is to bring the price point down and now we're talking about a continuous services where you were literally you're literally basing your business on capabilities provided by a third party and that is a very very very different relation just-in-time purchasing right and it's and it's a new supply chain management process where you have so many SKU options and you are making these purchase decisions sometimes thousands a day and that impacts everything down the road excellent gr storm and co-founder of cloud ability talking about Finn ops and cloud abilities role in helping businesses map the cloud spend to their business activities for a better more optimal views of how they get what they need out of their cloud expenditures Jr thanks very much for being on the connects here and once again I'm Peter burrows and thanks for listening to this acute conversation until next time [Music] you

>> Live from Orlando, Florida, it's theCUBE. Covering .conf2018 brought to you by Splunk. >> Welcome back to Splunk's .conf2018. You're watching theCUBE, the leader in live tech coverage. I'm Dave Vellante with my co-host Stu Miniman. We're here in Orlando. Day one of two days of wall to wall coverage, this is our seventh year doing Splunk .conf, Stu amazing show, a lot of action, partnership is growing, ecosystem is growing. And we're going to to talk to one ecosystem partner, Gemini Data. J.R. Murray's here as the vice president of technical services. Welcome to theCUBE, thanks for coming on. >> Happy to be here. >> Yeah so when we first started this, Splunk ecosystem was really tiny and it's just sort of growing and growing and now is exploding. But tell us about Gemini Data what are you guys all about. What's your role? >> Sure, so my role is VP of technical services. I manage our sales engineers and professional services consultants as well as our managers services practice, based in the United States. So what I do is I go through and help make sure all the operations go pretty smoothly. And in terms of the company and what we do we've got a couple different things that we work on. Primarily our focus is around big data platforms and making them easier to deploy and manage. We offer a hardware appliances as part of that package and we also have an investigate software platform that we feed data into and it helps analysts jobs be a little bit more easier and quicker to do investigations. >> And you guys started the company three and a half, four years ago, is that right? >> That's right, that's right. >> Back when big data was and kind of still is a mess. >> That's right. >> Doug even said that in his conversations today. He said that we live in a world filled with change. The messiest landscape is the data. >> That's right. >> The bigger, the faster, the more complex the data, the messier it is. So you guys kind of started to solve a problem. Why did you start the company? What was the problem you were trying to solve? >> So really where we started is we focused on there's a problem with deploying big data platforms, customers have poor experiences in terms of it's too complicated, there are a lot of very technical details you have to worry about. And if you're a little bit lower on the maturity curve of technology solution implementation you might need some help along the way or if you are a little bit further along in the technical maturity curve you may actually need some help in getting something that's more turn-key in order to alleviate a lot of the challenges that go along with IT bureaucracy. You've got maybe something that you need that's purpose built because you've got something that's very central to your security strategy. You need to make sure that it's up and running, and reliable, and dependable. So that's where we come in. We have a platform that we allow you to implement. It's a turn-key solution, multiple systems get your Splunk deployment up and running. >> And when you do that on your website looking at, you support various technologies, I see Splunk on there, FireEye, Cloud Era, Service Now, Amazon, Azure, so those are sort of systems, RSA. I mean they've got a lot of products and a lot of cases it's cloud or, they've got a platform like Splunk. Will you actually do like bottoms up stuff with Hadoop and pig and hive or are you really focused on sort of that higher level helping customers integrate those platforms that they brought in. >> Right. >> Kind of helping them be a platform of platforms if you will, is it the former or the latter? >> Yeah so that's kind of the idea right? We come in and we go through and we say what are your actual goals here do you just want to go through and install Splunk or do you actually have a big data strategy that we can help you execute on. So it's kind of a cohesive holistic approach in terms of, what you need to deploy and how we help you get there. So if you need to deploy Splunk we help you install Splunk. If you want to do Splunk and have a Hadoop data role for example you can have hadub just alongside your Splunk all on the same platform. You can go through and manage that centrally and make it a little bit easier to manage via policy push out jobs centrally all the automation and orchestration is there and the under pendings for all those solutions. >> Yeah J.R. who who are you typically selling to? One of the things we look at data is pervasive in the company in companies but who owns it, I've talked to a number of people at this company that are like well I've got Splunk and everybody comes and asks me questions right now. So where do you fit in in the organization? >> So we've got a few different things going on. So in terms of who we sell to and where we focus, its kind of across the board we've got very large enterprises who are pushing tens of terabytes into the deployment, and we help them out with getting a solution that's going to be something that's a little bit more manageable. You've got a limited staff, the knowledge of Splunk is hard to hard to actually cultivate and then actually keep and retain folks that know Splunk. They are generally very well paid. So its easy for them to find opportunities elsewhere. You've invested a lot in these people, your success is very critical and they're a critical part of it. And it's important to keep those people around. So we've got a manage service to help with customers like that. We call it Gemini Care. We come in and we are actually able to have an automated monitoring and break fix type of resolution service that factors into those types of deployments. And as part of that we go through and offer some services and touch points throughout the month to make sure they're getting what they need from a value standpoint. I mean its one thing to have the platform and the deployment, and the data but in fact if you're not getting any value out of that what good is it? So if you don't have the talent the skills you're able to go through it and use us to implement some of those used cases and things like that. >> Yeah yeah one of the other things that changed a lot in the last 3, 4 years is the on the premises of course is where a lot of the customers are and a lot of data is but partner with the cloud, you partner with the Ager's and Amazon's in the world even if you start talking about edge that diversity of where my data lives. How how is that playing into your solution? >> So it's funny you mention that we came to arka we led with and applied base solution and we said customers that are having problems either getting hardware common thing is you want to put a box in or 10 or 20 boxes but you've got the storage team saying hey we need to hook up to our our sand we spent millions of dollars on this, we're going to get some use out of it and guess what Splunk you're going to be our biggest consumer of all of our storage internally on this brand new sand we got. A lot of times its not attractive to a lot of interim customers. You've got IOPS requirements, you've got all these other requirements. Folks don't understand you've got hard requirements for CPU's and and the band width there. So if you're using virtual solutions which a lot of customers are forced into doing you actually have a very difficult time getting reserved resources on those virtual hosts. So you get a bare metal box in there, you get a platform on it you have none of those issues. So in terms of where we pivoted from there the industry is obviously going towards cloud. So what we're trying to do is actually, we have a solution in the market today. Customers are really interested in us helping them on that journey so we've got plenty of customers who are on premise today they have a cloud strategy they want to get out of the data center business and they need to get into cloud. So what we're doing is we're helping them we've got equipment who in a code located data center and what we're doing is migrating customers over to that infrastructure as more of a subscription basis. So it's the same platform but now it's in the cloud. There are benefits to that. >> So I want to I want to actually let me follow up now, so the subscription basis >> Right. How does that work? So it used to be what sort of an upfront perpetual license and then here you go and then we'll you when there's another upgrade. >> Right >> And now how's it work I know 75% last quarter of Splunk's bookings or revenue I'm not sure which one. Were subscription based irratible and there was a big long discussion about whatever it was 606 and all the Wall Street guys trying to part through it. What does it mean for the customer? What does that transition like? >> Okay >> Is it like hey good news. >> Right >> We're not going to go through the spike cycles we're going to smooth things out for you. But what's that conversation like? >> We've got a lot of flexibility with customers. We've got the ability to do OPX or CAPX, we've got the ability to ship as an appliance kind of as an all in one solution. However what we've really migrated to as what the market has demanded is customer feedback. Is, "hey we can buy this box anywhere" and we're like, "you know what you're right. If you want to go right ahead here's the software subscription. So now we have the option to sell the appliance and the software subscription together as one package that's also partially subscription but what happens when you migrate that into the cloud, is now you've got a cloud based subscription infrastructure and that software license is sort of included in that. >> I want to ask you about use cases. You were talking a little bit before but if you pre go back before the term big data came to fruition, you kind of had the EDW was the so called data big data used case and you had maybe a couple of analysts that knew the decision support systems and could build a cube and they were like the data gods. So big data comes in and you had used cases like a cheaper EDW that was kind of a really popular one. Certainly fraud detection was one, precision marketing, ad serving, obviously Splunk and the security and IT operations base although Splunk never really used the term big data so its only sort of more recent and line of business analytics. So you see all these sort of new uses for data very complex as you pointed out. You guys started the company to sort of help squint through some of that complexity and actually build solutions. So the brief history of big data by Dave Vellante. So given all that how has your customers use of data changed over the last since you guys have started and where do you see it going? >> So we originally started, originally we had some customers that came over into this new business venture existing relationships and what not they were using a different sim platform. You one of our primary objectives were to was to get them all in to Splunk and that's something that we were able to do successfully. So they were doing security analysis, log retention, those were their primary goals and that's it. Maybe compliance, okay. So their really focusing on that. Now today we're doing entirely different things. We're focusing on as you mentioned anti-fraud. Huge opportunity in the space there with Splunk the tools in that space today are prohibitively expensive, very complex and we come in with Splunk we're able to take in data from all sorts of places and technologies really know really know understanding of the data at that point required yet and then we convert that into business value for the customer by means of services. Because there's very little in the way of precan used cases for that and frankly when it comes to the fraud space a lot of customers their requirements are all different. There aren't really many shops that are very much alike at all. So you've got to sort of manage around that. Now that's one way but we're also seeing folks who want to do executive reporting out of their Splunk data. You're talking about being able to go through and do year to year reporting how are we doing from a risk management standpoint. These are the things you are starting to see trickle up to the Csuite in terms of what does that mean for us and the way we need to make these business decisions. >> So I understand that. So really started out kind of hard core IT and certainly security used cases. What I'm hearing is Splunk is expanding into lines of business actually using data in in ways that perhaps others were trying to do in the past but not really succeeding. >> That's right >> What is it about Splunk that allows you to do that. We heard a lot about 7dot2 today, performance improvements, some efficiency in your granular storage and compute. I'm sure that Csuite doesn't know or care about that but being able to analyze more data is something that they probably would care about, mobile is probably something that they care about. >> Absolutely. So what is that Splunk's doing that maybe others aren't doing or can't do, architecturally or technology wise? >> Now a couple things stand out right off the top. So you've got the ability to scale, you've got horizontal distribution of data which means you can spread that load across many many nodes. We're able to go through and distribute that load and it makes things actually perform. So we get an acceptable user experience and that means everything to a customer, right? So that's one thing. The second thing with Splunk you've skemead read you're able to pull in as much data as you want for as long as you want without having to understand that data. You can actually come back through later and and parse, interpret, report on, and get value out of that data historically without having to necessarily having to understand it upfront. That's in my personal experience been a huge impediment right up front to onboarding data with other we'll call them legacy solutions. But there still some in the market today that require and depend on that is knowing the data upfront. We can't pull in this data unless we know exactly what its supposed to look like and can sanitize it and parse it into fields. >> So Stu I want to follow up if I may. So a lot of people in the big data world talk about no scheme on write or scheme on read >> Sure >> And what they do is they toss everything into a data lake. The big joke is the lake becomes a swamp, they got to go and clean it up. Why is that not the case with Splunk? What's different about Splunk and that they're able to, I forget exactly how Doug said it but essentially structure the data when you need it. >> That's right >> In the moment >> So the difference with Splunk is that you're able to you're able to foster and really pull together the community resources more or less crowdsourcing how to parse all these data sources. You no longer have individuals at every given company with a very specific data source say Windows event logs that might be universal to many other applications and organizations, needing to roll their own. So you're able to socialize and share those things on a place like Splunk base and then suddenly everyone's able to really capitalize on the data, so I see that as more like a force multiplier. You've got the entire community behind you helping you parse your data because they have the same data and that's really what I think makes the difference. >> Whereas the so called data lake would be like the big data metaphor for a god box where only a few people know how to get to the data, right? >> Basically yeah, thats right? And the amount of skill required, okay, that's another big piece when you're in Splunk everything is very well documented so if you need to write a search and its there are plenty of resources you've got the Splunk community, you've also got all of the documentation, you've got the quick reference sheets. Its not hard to get into its hard to become an expert but if you just need to do something very quickly it's not that difficult. >> Well if we look at where Splunk is going next you talk a lot about the AI and the ML and one of the tensions you hear out there is, "how much am I willing to let the system just take that action?" So I'm curious on your product line and working with Splunk what you hear how real people are, the advances that we're getting with AI, ML and deep learning and are users ready to embrace that yet? >> Yeah so that's a technology that's truly made leaps and bounds even over the past five years. Right. So what we're seeing is customers are able to use machine learning to go through and do predictive analytics and to be able to have the machines to sort of speculate as to and you can say predict but its really I think speculation more like what a given categorical value might be. Is it yes or no, maybe for the answer to a question based on what those events say, or is it is there an outage coming up that potentially you could predict based on different values. And there all sorts of applications for that and all sorts of platforms that are trying to do that. Now what Splunk's done is sort of bring that to the masses with machine learning toolkit and made that a little bit easier to really digest for the common person. What they haven't done at least until very recently from what my understanding is that they're doing is that they're actually taking more of that function out and making it more intuitive helping customers understand the most common challenges I'll say. So you're really lowering the bar in terms of the amount of information or knowledge rather and skills to be able to leverage some of these more advanced algorithms and computing resources to go through and get the types of results you expect out of machine learning. >> Well J.R. Murray thanks so much for coming to theCUBE. Really appreciate your time. >> Pleasure. Thank you >> Great to meet you. Alright everybody keep it right there Stu and I will be back with our next guest. You're watching theCUBE from Splunk .Conf18 in Orlando. We'll be right back.

>> 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)

(bright music) >> Hi, I'm Peter Burris. Welcome to another CUBE Conversation from our beautiful studios here in Palo Alto, California. As we do with every CUBE Conversation, we come up with a great topic and we find someone who really understands it so they can talk about it. We capture them for you so you can learn something about some of the new trends and changes in the industry, and we're doing that today too. The topic that we're talking about is, how do you do a better job of mapping the costs that are being generated by the cloud. Well that information's coming out of cloud suppliers related to what you're using with the actual business activities that generate the differential capabilities that customers are looking for. That's a tough, tough challenge, and to understand that better, we're talking with J.R. Storment, who's a co-founder of Cloudability. J.R, welcome to the CUBE. >> Thanks Peter, good to be here. >> So let's talk about... First, who are you? >> Yeah, so I'm co-founder of Cloudability, and Cloudability is focused around improving the unit economics of cloud spend, so our customers tend to be those who are spending large amount in AWS or Azure or GCP. And we take their billing data, their utilization data, various meta data about their business and do machine learning and data science on top of it to help them get better visibility into where that spend is going, how their using it, but more importantly to give them some controls around how they want to optimize. And optimize doesn't necessarily mean save money in a cloud world. Cause most companies who are moving into cloud very heavily are doing that for the innovation, for the speed, so they can deliver better data faster. But it's really about fine-tuning the conversation. Say, "Okay, here we want to save money. "Here we want to move faster. "Here we want to focus on quality." And really providing a way for the various groups that aren't normally talking, the finance teams with the engineering teams with the procurement teams, all these groups to come together, and be able to take executive input to say, "Okay, how do we want to operate? "And how do we want to improve those unit economics as we go?" >> Well, I want to start with just a quick comment on this notion of unit economics. Cause when people historically hear the notion of unit economics, they think of increasing scale so the average cost per unit goes down. But I think you're talking about more than that, right? Aren't you really also talking about a mapping of what spend is generating to the business activities that actually generate value and ensuring that you get the differential or the optimized unit economics or unit cost? >> Yeah, so the mapping is actually really interestingly challenging in cloud. It's hard enough in traditional IT. If you look at somebody like AWS, they have 200,000 SKUs, different products you can buy. And they now bill at a second level resolution. So what this means is you've got all these engineers out there using cloud in a very good way to move quickly, innovate, include more features. And they kind of have an unlimited credit card that they can go spend on as quickly as they need. And they never see the statements. They never see the bills. And the other side, you've got finance teams, procurement teams who've sort of lost control of traditionally the power of the PO that they have to rein that in. And they're struggling just to understand what is the spend. And then to the mapping question, how do I allocate these hundreds of millions of charges that I have this month into cost centers and business units, and getting that sorted in a world where engineers are focused on moving fast. They're not tagging things based on cost center typically. So once you get that sort of mapping aspect sorted to the next point you brought is is then bring in the business value. So how do we start to relate that back. There's a concept a lot of you know, IT has been a cost center, and now it's actual driver of value in a world where businesses are increasingly delivering their value through software. So we need to start tying the spending, mapping of the business and then tying that to the value delivered. A great example of this, I was sitting last week with one of the largest cloud spenders in the world. And they're up in, you know, nine figures with their primary vendor. And in the conversation with the executives, we realized that nobody was looking at both side of that equation. You had the finance people who were saying, "Hey, we're tracking the costs, "and we're figuring out what's happening there." And then you have the revenue generators looking at the money coming in, you know the cloud people with that. But there wasn't this centralized view to say, "Alright, we want to have a conversation about what value are we getting out of this spend." And the question that always comes up with that is are we spending the right amount? I don't know. >> Let me build on that, because IT is historically, and this is one of the things that we've been doing over the last few years, IT has historically done things at a project level. Alright, so we had waterfall development. We tried to change that with Agile. We had buy the hardware upfront and then deploy the application on it, cloud changes that. So this project orientation has led to a set of decisions about finance at the moment that the business decides to do it. We've changed the practices that we use at a development level. We've changed the practices that we use at an asset level. Is it now time to change the practices that we use at a finance level? Is that really kind of what's going on here? >> It is, the project analogy is good. Because what we're seeing is they're shifting from a project basis to a product basis, and products that deliver value. Increasingly if you think about the change that's happened with DevOps in the scene and cloud, companies are delivering more of their value through software, and they're not just using IT for internal projects, right. It's actually the driver of business. It's how we interact with airlines and banks and all these things. So that's the shift to say, okay, now we gotten good at DevOps moving fast, and we've gotten good at deploying and building better data stores. Now we need to bring in this new discipline. And the discipline is what the market is calling FinOps, which essentially combining financial operations. You're essentially combining-- >> Applied to a technology world. >> Applied specifically to a cloud world. And it can only really happen in cloud. It can't happen in data centers. Because data centers have fixed spending, right? You have to wait to get resources. Once you make the investment, it's a sum cost. There's months of lead time. Cloud introduced the removal of constraints, which means you can get whatever you want as quickly as you want. And DevOps meant it's all automated. So instead of your collection of 60 servers, you've got thousands that are coming up and down all the time. So what you now have to do is bring in all these groups. Engineers have to think about cost as a new efficiency metric. They have to think about the impact on their business that this code, this confirmation template they just wrote is going to have. And the finance teams have to shift from this mode of "I'm going to report retroactively at a quarterly granularity, "60 days after it happened and block investment" to be "I'm going to partner with these teams. "Report in a real-time fashion. "Give them the visibility and help forecast. "Actually bring them together and make better business decisions about the cloud spend." >> So cloud has allowed development to alter practically, I mean Agile has been around for a long time, pre-dates the cloud, but it became practical and almost demanded as a consequence of what you could do with cloud. So cloud changed development through Agile. It changed infrastructure management through DevOps. Where now you're deploying software infrastructure as code. And what you're saying is the third leg of that stool, cloud is now changing how you do financial management of technology, financial management of IT. And we're calling that FinOps. >> You can't really have FinOps without cloud or without DevOps, and if you have the two together, you ultimately need this new set of, it's a new operating model. The reason this has sort of come to a head of late is if you look at going to the Amazon re:Invent conferences a few years back, it was like well how much is cloud going to be a thing. And okay, cloud's not going to be a thing. When's it going to happen? Now it's about the how and how do we do this better. Cloud is hitting sort of material spend levels now at big organizations. You always see the cloud projections where it's going, I think it's now 360 billion in the next few years. And we're seeing CFOs at public companies look to say, "Okay, it's not my biggest line item yet. "But it's the most variable and fastest growing "cogs expense, so it's actually "starting to affect our margins. "We need a new set of processes to actually manage this." So one of the things that's coming to market is this new group called the FinOps Foundation, which is a non-profit trade association that initially has a few dozen of some of the largest cloud spenders in the world. There's the Spotifys, the Laciens, the Nationwides, the Autodesks. And they've all come together as a set of best practice practitioners to start to clarify this into something that can be scaled out in organizations. So that group is going to be putting out a user conference around this area. There's a new O'Reilly book that's coming out the end of the year that's going to be sort of the treatise and all this stuff pulled together. Because what we found and you know me, as in Cloudability in the last eight years, we bring in technology and platform to show the recommendations of visibility and how to do this, but the real challenge companies run into is they don't have the internal expertise. Their finance teams understand what they need to. The engineers don't. And so they came to us last year saying, "Can you help figure out the processes? "Can you educate us?" And that's really where this FinOps Foundation has grown out of, of bringing together those people to define those processes. >> So the impact of cloud on each of these different groups, the development group, on the infrastructure team, and now on the finance team. The developer groups, some of them resisted it. But generally speaking, it's gone okay. And eventually tooling from a variety of different players came along that made it easy to enact best practices in software development through an Agile mechanism. In the last few years after significant battles within infrastructure teams about whether or not they were going to use software as code. We've seen new products, new tooling that has facilitate the adoption of those practices. What kind of tooling are we going to see introduced that facilitates FinOps, so that finance teams, procurement teams move from a project orientation to a strategic management of a resource orientation? >> I mean I think the first is on the engineering side is seeing cost become a first class citizen of an efficiency metric that they need to look at. So you know in their build processes baked in the CICD, looking to see am I properly sizing my compute request for the workload that it needs. There's some research that just came out showing that, I think it's 80% of the market is not using the best discounting options that cloud providers offer. You hear these horror stories. Cloud's too expensive, we overspend. That's not actually a problem with the cloud provider. That's a problem with the enterprises not using the tools that offer the discounts, the reservances, the infrequent access. >> Caveat emptor. >> Exactly, so I think at the end of the day, the first step in this is getting those checks in place to say, "Are we using the things that help drive the right cost for our needs?" And on the other side of that, the finance teams really changing the way that they are interacting with the technology teams. Becoming partners, becoming advocates in this versus a passive, retroactive reporter down the line. And this enables these sort of micro-optimization discussions that can happen where data center world, we bought it at some cost, it's sitting there, cloud world, we can make decisions today that impact the business tomorrow. >> So let me make sure I got this. So I have a client who I was having a conversation with him. They told me that their Amazon, their AWS bill, is 87 gigabytes monthly. Not some 87 pages. That's 87 gigabytes. So we bring this 87 gigabytes in, and it's a story about what I consume out of Amazon. It's not a story of what my business utilizes to achieve its objectives. So we're now entering into a world where we're trying to introduce that financial visibility into how that spend can be mapped to what the business does. So the finance group can look at a common notion of truth. And the IT group can look at a common notion of truth. Application owners can looks at a common notion of truth. And that's what FinOps is providing. Have I got that right? >> Absolutely, and the 87 gigabytes example is the exact reason why it is FinOps, and not just cloud financial management. You can't have a person with a spreadsheet looking at data and trying to make decisions about it, right? It has to be automated. It's IT finances code. It's got to be baked into the processes. We've seen organizations that have hundreds of millions of individual charges hitting them in a consumption based manner. The other thing that's come in with the FinOps as a core tenet is we're now seeing a decentralization of accountability for that spend. So if you look at the big cloud spenders out there who are maybe spending tens or hundreds of millions a year, some of them have thousands of cloud environments. Gone is the day of we have a centralized group getting to say, "We're going to turn this off, turn this off." We want to give each of those teams the ability to see just their portion of that bill in the right mapped way, as you said, and to be able to take actions on the back of that. So that's changed in the you know, you run it, you maintain it, you understand what's shut down. What has sort of come back to the old centralized model is this notion, and this is where procurement's job has shifted to largely, of we do still want to centralize the rate reduction. So engineers, you go use less, right? Essentially, finance teams, procurement work together with the cloud vendors to get the best possible rates through reserved instances, can be deduced discounts, you know volume discounts, negotiated rates, whatever it is. And they become sort of strategic sourcing. To say you're going to use whatever you're going to use, and you're going to watch that to make sure you're using the right amount with target thresholds. We're going to make sure we get the best rate for it. And that's sort of the two sides of the coin. >> Well, very important, procurement has always been organized on episodic purchases, where the whole point is to bring the price point down. And now we're talking about a continuous service, where you are literally basing your business on capabilities provided by a third party. And that is a very, very, very different relationship. >> It's just in time purchasing. And it's a new supply-chain management process, where you have so many SKU options, and you are making these purchase decisions, sometimes thousands a day, and that impacts everything down the road. >> Excellent. J.R. Storment, co-founder of Cloudability, talking about FinOps and Cloudability's role in helping businesses map their cloud spend to their business activities for better, more optimal views of how they get what they need out of their cloud expenditures. J.R., thank you very much for being on the CUBE. >> Thanks, Peter. >> And once again, I'm Peter Burris. And thanks for listening to this CUBE Conversation. Until next time.