 Cloud is elastic, right? If you're building on cloud, your resources are elastic, you're consuming on an elastic basis, so your consumption can go up and down. And that really is the starting point. As more and more business shift their businesses to the cloud, building cloud-native application systems, they are going to have to align what their cloud resource consumption is and ultimately how they charge their customers. That alignment has to be there. Hi, this is your host Olim Bharti and we are here at KubeCon in Chicago and today we have with us once again Punit Gupta, CEO and founder of Emberflow. Punit, it's great to have you on the show. Great to see you in person too. I know we've chatted a few times before. Always great to meet in person. We are here at this event. Talk a bit about how has been the show so far for you? This has been amazing. Actually, this is my first KubeCon. Just the level of excitement, participation. I mean, you just see we're just kind of getting underway and already just the activity around the floors. Super amazing. You know, this is an ecosystem that's huge, vast, touches just about every developer. So great to be here. We have been covering Emberflow for a long time, but let's just refresh the memories of our viewers. What is Emberflow all about? Sure thing. Yeah, so Emberflow.io, we are a business that enables companies to charge and track on usage. And what we enable is businesses to do that, to charge and track on usage and then do metered billing on the back so that usage instrumentation. So we provide what we call the cloud metering and usage-based pricing and billing platform for businesses to usage instrument the cloud resources and then charge the customers on actual usage. When it comes to metering, developers are usually not involved with the process of pricing and charging. So why are we getting developers involved? What's there for them here? Yeah, you know, that's a good question. It comes up quite a bit. And I think, you know, at this point, I would think that I think most developers have kind of turned the corner on this that I think they're aware of the fact that they are ultimately responsible for keeping track, as we call usage instrumentation. And it kind of all started from the fact that, you know, if you think about cloud is elastic, right? If you're building on cloud, your resources are elastic, you're consuming on an elastic basis, so your consumption can go up and down. And that really is the starting point. As more and more businesses shift their businesses to the cloud, building cloud native application systems, they are going to have to align what their cloud resource consumption is and ultimately how they charge their customers that alignment has to be there. Okay. And that basically falls with the developers because that is usage instrumentation. So it's part of your technology stack. You can no longer just leave it to a third party team or a back office team that is simply saying, okay, you know, we're going to arbitrarily charge somebody $99 per user per month. That's no longer going to be the case because what a user, a customer could be consuming off your infrastructure could be very different from anybody else. So it's a developer artifact because you have to bake that into your IT stack, into your technology stack to use the instrument and developers are the ones to do it. That's a great point. We often talk about developers should have a great insight into what this business is all about, what the company is all about. And I feel that this gets them involved with their process. 100% because, you know, see, they're sort of, they go hand in hand. Cost allocation and billing, right? They're basically sort of, you know, cousins of each other if you think about it. Because as I talked about, you know, because cloud is elastic, first you have to tame as I call that elasticity and the tool to tame elasticity is metering. Developers have to first, independent of pricing and billing, have to get a handle on what their usage is and be able to track it in real time at a granular level, right? What is being used, by whom, where and how much. Independent of pricing and billing, developers have to be able to do that and only then they can first tame elasticity, control the cost spend, optimize the cost spend, sort of build that operational efficiency loop in their cloud infrastructure, okay? Now that you have that usage instrumentation put in place, that is the starting point. Now that you have a system of record for where you're tracking usage and consumption, now it opens doors to what kind of a chargeback you want to do. So internal cost allocation. You can use the same data and then build customer facing, metered usage based pricing plans and billing. So that's sort of how the dots connect. Can you talk about how getting developers involved kind of bring the cultural change that is needed within these organizations? You know, I'll share basically, you know, to that end, perhaps a personal story. You know, I spent a few years at AWS as a general manager. My team built a couple of tier one AWS services. So, and again in the world of cloud, developers are the starting point. They have to be the custodian. Back at AWS, it was a development team. It was the product and engineering team that was tasked by keeping, you know, an eye on cost and cost allocation and more importantly cost optimization. I couldn't enter the room on a yearly planning every year without having to have a story on how we are taking cost out of operations, how we are operationalizing it, how we are becoming more efficient. So it is a developer artifact and that is actually a change that came with the cloud. So that's part and parcel. Now the good thing is there are good tools available for developers, so they don't have to build this from the ground up. But it is a mindset. The sooner you get on this bandwagon, the better off you will be and the better off the organization will be. Now let's talk about the rule that Emberflow is playing in this space. Yeah, you know, as we're seeing, as we were talking about earlier, you know, just the number of folks and how the conference has grown year over year. I mean, Kubernetes, Docker infrastructure is you know, it's pretty much everywhere. It's ubiquitous. So increasingly, as more and more workloads shift to Kubernetes and Docker infrastructure, there are few things that are going to be imperative for companies to kind of put that into some kind of a virtuous cycle, cruise control, so they can continue to expand and grow and scale. And a couple of those artifacts are the ability to have accurate visibility into your usage, not just from a cost footprint from what my AWS bill is, not holistically of what my Kubernetes and Docker infrastructure is costing, but within that infrastructure, how much of it is being allocated to which user to which customer. So a tenant level, you know, visibility and having that level of instrumentation so I can see this customer is actually stretching my infrastructure much more than compared to others. So that is pretty much a given. You cannot really build and scale and continue to grow your business and operations without having that level of visibility. So that's one. Second is just part of, you know, operational footprint where if you don't have this visibility, you're essentially flying blind. Metering is the artifact that enables you to do that. You only have to do it once. And once you have this meter data, then it also opens doors to other things that you may want to layer down the path. We talked about that earlier as well, SAS is solving a lot of problems. Talk a bit about metering and SAS. Should all SAS applications have metering there? And what kind of burden it might create for developers? Yeah, fair enough. So two parts. One is I think it's inevitable. You know, as you said, when we first shattered maybe a couple of years ago, perhaps it wasn't that obvious there were a handful of companies or initial set of companies that were going down this path. But I think if you look around today, I think the cat's out of the bag. I think more and more companies are going down this path. And there's a reason for that, right? I mean, first and foremost, cloud, as I said, already is elastic framework. So if you're going to build something on top of cloud, most likely you'll probably have to follow the same pattern. So then you get full alignment. So that's kind of the thrust, the underlying thesis. The other thing that, you know, that is really propelling this push to usage-based pricing and building is actually a relatively new phenomenon that I sort of think about it has really been the catalyst to further drive this forward, which is, you know, everybody's talking about generative AI, LLM, right, this form of AI ML. And I guess, you know, you'd agree that there isn't a company on the planet that hasn't had a meeting internally and sit down and say, how are we going to bring in Gen AI or LLM into our product services? And there you have it because if you think about it, the moment you're going to bring in any form of AI ML, particularly Gen AI or LLM, you're down the path of usage-based pricing and building because any of those primitives, anything in the realm of AI ML, if you're consuming a third-party artifact from any one of the leading cloud providers or a layer above or a third party above that, all of them are going to be charging you on a usage model. So now if you have brought in a usage model into your development stack, you're going to have to meterate, you're going to have to instrument it, and you're going to have to basically put some boundaries around how your customers use it. And that's putting you down the path of usage-based pricing and building. Now let's talk about one of the hottest topic these days. And it's also a hot topic here at KubeCon. Genity AI. Talk a bit about Genity AI from the perspective of Amber Flow. Yeah. So first one for sure. Like I said, you know, you have to track what is being used off my generative AI LLM model because those models themselves are charging you, let's say, on a token basis based on queries, input parameters, output parameters. These are all usage-based vectors. So that's a given. If you don't have the infrastructure to meter that, you're essentially again flying blind. So that is one. And the other is, I think, how it is going to help GenAi or how GenAi is going to help usage-based pricing and building. I think, like I said, it's a huge catalyst. I think if there are companies on the fence out there who are not sure whether usage-based pricing or billing is the right model for you, and that was fine. You know, you could be on the fence or you could say that, you know, look, it doesn't apply to me. And maybe it was only a matter of time. You wanted to wait and see how others might have done it with that model. I would say the moment you're going to get generative AI LLM, don't wait till the end because as hard as you're going to work, try to bring this new technology, this new model into your application services, you're going to fast-track your roadmap to bring that in and go to launch. Believe me, the last mile is going to be the monetization aspect of it. So if you haven't thought about it from early on, I'd encourage you to think about it. It's not just simply bringing in GenAi LLM into my technology stack. It's how do I monetize it? And if you get ahead on that journey early on, I'll again continue to pay you dividends far into the future. In light of, you know, this generative AI LLM, one of the things we're launching is as more and more companies shift, and we're finding now, like I said, there's been a huge catalyst, more and more companies are shifting in this realm of usage-based pricing and billing. One of the new products that we launched is called a quoting cloud. So I mentioned to you earlier we have a metering cloud to do usage metering. We have a billing cloud to do usage-based pricing and billing. And now we are adding a quoting cloud, which is traditionally called CPQ, configure price quote. And think of it as basically three legs of the stool, right? If you are running in the cloud, building in the cloud, you're building on the backs of AI ML, then it all starts with presale activity where you're going to essentially present a quote to your customer on how much of their services they can consume. So we are providing a quote in cloud solution that is really built from the ground up to do CPQ for usage-based pricing and billing models. So that's the starting point. And then the ability to then operationalize those quotes, you need a metering and usage-based pricing and billing infrastructure. So it's basically a full loop from presales to post sales to enable companies to thrive in metering and usage-based pricing and billing. Every time I was asking a question about metering, I almost had a slip of tongue and I said, hey, what about cost cloud cost management? Can you talk about the difference between metering and cloud cost management? Yeah, this comes up quite a bit. And it's a valid question because there is a confusion out there. So one of the questions we get asked is how is metering different from cloud cost management or vendors who have solutions for cloud cost management? And I'll say maybe two or three things to really distill out that differentiation. So first is if you look at today the paradigm for cloud cost management, how it is being addressed, is primarily and universally pretty much parsing your cloud provider's bill. AWS, Google, Azure, they send you a monthly bill. You layer a cloud cost management solution vendor on top of that. They parse your AWS bill and they give you some insights. Now here's the irony if you think about it. See, you are what I would call is you are using a single tenant artifact to instrument a multi-tenant system. What do I mean by that? Bill is a single tenant artifact. Let me add some credibility to that statement. AWS generates the bill for you as a single company. We are Amberflow. We run an AWS. We get a monthly bill from AWS is addressed to Amberflow. AWS does not know which are my companies, my customers are running on my infrastructure. They don't have that visibility. So what have we done? We have sort of this whole fringe economy of tagging where the cloud cost providers will ask you to start tagging your systems. But that's building a layer again on top of a single tenant system trying to make it multi-tenant to give you that multi-tenant visibility. And then what else I would say is, okay, take a step back and ask the question, you know, if you're inside AWS as I was and I'm sure other cloud providers, how are those folks who are running services at scale, how are they doing cloud cost management? And I can tell you categorically that we are not using a third-party cloud cost management solution where we parse the AWS bill and then do our cost cloud management. We basically use a system called metering. Metering is what I have in my control. Metering sits ahead of the bill. Metering is in my technology stack. I usage instrument what I want to usage instrument. And metering has their granularity where I can meter on the behest of a customer, a user, a system, or event. And I can get real-time visibility into what is being used by whom, when, what, where, how much. So that's kind of the distinction between traditional cloud cost management and doing effective cloud cost management done right at scale accurately using metering. A few months ago, we talked about an amber flow capability feature functionality offering that also enables developers in monetizing from AI. Exactly. And that's why, you know, it is really that universal system. And again, you know, take what else can I say? Look around. I mean, fine, maybe even beyond just the large cloud providers. Look at the next generation of companies that came who thrived on the backs of this usage-based model like Twilio's, Databricks, MongoDB, Snowflake. All of these folks have built massive businesses, repeatable businesses on the backs of usage-based pricing and billing. And you will find that each one of those folks had to build a metering service to get ahead of this. Cloud cost management parsing your AWS build will not get you there. So once you have this infrastructure, then like I said, you can slice it. You can layer different value-added applications on top. One is, of course, usage instrumentation. Second is internal cost allocation. And then third is customer-facing pricing plans and billing. Puneet, thank you so much for taking time out today. And once again, talk about not only Emberflow, but great insight about the speeds. Thanks for your time today. And I look forward to talking to you again soon. Thank you. Very cool. Likewise, Swapnil. Always good to chat with you. And always, it was great to see you in person today.