Puneet Gupta, Amberflo | KubeCon + CloudNativeCon North America 2023

This is Textron tv. Hey everybody, welcome back to KubeCon here, 2023 in Chicago. More great conversations.

Speaking of which, my new best friend who I just met, pun Punit Gupta, welcome from Amber Flow. That's Right. So nice to meet with you.

Nice to meet with you. Entrepr, fellow entrepreneur. Love your story.

Coming, coming out of your last, doing a position, I guess with AWS and doing this company for a few years now. And you're in this Kubernetes space. So tell us, that's a pretty big space.

Yeah. Tell us a little bit about what you're up to. Yeah, sure.

Maybe, uh, you know, I'll just sort of give a quick intro about the company and then we'll certainly dive into how we are helping the Kubernetes docker infrastructure and the developer network there. io, I'm the founder. CEO company's about three years old.

We're venture backed, barrier based, and what we do is we enable businesses to charge and track on usage. Mm-Hmm. Okay.

So, uh, our platform is called Cloud metering and usage based pricing and billing platform. Okay. And this is, I think, you know, I'm sure you're seeing it all across.

Um, back three years ago when we started the company was kind of most of the folks who still on the fence whether businesses are gonna shift towards usage based pricing and billing model. But I think now the cat out of the bag, more and more companies are going down that way. And of course that itself intersects the Kubernetes docker infrastructure.

I'm sure we'll get into that. So we enable those companies, uh, either you are already down the path or you wanting to go down the path from a traditional model to shifting towards usage based pricing and billing. We provide the cloud metering, usage based pricing and billing infrastructure and, uh, enable them to do that.

You know, just having made my own transition years back, moving into cloud early in AWS days, but having that kind conversation with your financial people or budgeting, whatever it is, when you then you just didn't know you would find out once you got there. I don't know if that's still happening. It's like we kind of need to get there to know yet.

Or is that something you can help people do, kind of get an idea of what our pricing's gonna be? Yeah. Or you just step in when it's kind of out of control, bring it back in line.

Yeah, it's, you know, uh, it's a little bit of a mis bag. Usually it's a function of what we're seeing as kind of company, the type of company. Like if you are a platform oriented company or your applications oriented company, and then second sort of, you know, just sort of, I would sort of call them maturity curve in the cloud.

Those are sort of the two functions that kind of determine where they are on that trajectory and, and how they're looking at it on, on, you know, both in terms of opportunity or the pain point. But, uh, I think increasingly though, uh, we're seeing sort of things starting to converge. Where, where were the companies are on the landscape on that journey.

I would say just maybe in the last year or so, there have been few things. Um, particularly just in the last six months, this, uh, generative AI LLM wave that has been a huge catalyst. Whoever was kind of on the fence was not sure for whatever reasons, as you said, you know, yeah.

I don't have visibility. I don't like this model because my finance team don't have visibility. Everybody's just lock stock and barrels starting to capitulate that this is the model to go forward.

You know, we can unpack it some more. So that's sort of where we're seeing. I think, you know, it is definitely was, uh, maybe right now I would say 2023 could itself be sort of that inflection point where it was should we, should we not to becoming more mainstream where it's just you have to do it.

It's not a question of if, it's only a question of when Do you think maybe of both. But do you think it's, we need to move too quickly to do something in our own environment, um, and spin it up? Or do you think it's more, um, we just don't have the resources, uh, and don't know, don't know that we want to take the time to go buy whatever hardware Yeah.

Environment to do this? Yeah. You know, I think, uh, it is one of those things.

Um, if you look at, again, just overall I call sort the maturity curve in the cloud. And what I mean by that is if you're building your IT stack, your cloud native IT stack, and you look at the building blocks within that, I would say you are gonna arrive at a conclusion that this is best suited to outsource and get a vendor. And here's the reason why.

You know, not just, of course the fact that we offer a solution, but there is reason we're offering the solution. 'cause we, The reason why you're doing, why you're Doing the reason we're doing it. 'cause we see a market, uh, for a couple reasons.

One is, it is, and the, and part of the reason also plays to your earlier question, you know, yes, it is a little bit of a heavier lift than just sitting down and back up the envelope coming up with, you know, a hundred dollars per user per month. So that's easy to do. Uh, and it didn't require a level of infrastructure to do that.

'cause there's just a couple of guys in the finance in the back office, and you come up with the pricing plan and you can run with it for long while usage based pricing and billing does require some upfront investment in infrastructure. So now the question is where do we start? Uh, and some of this has been a function of where the market has been.

There weren't that many solutions out there. Third party. So most companies ended up building, if you look at the, certainly the first batch of companies, the cloud companies, AWS and others.

But I would say even the next layer of companies that came about, you know, 10 years back, 12 years of the world, Databricks, MongoDB, snowflake, all of these guys had to build this infrastructure in-house. 'cause there weren't, wasn't anything out there. But I would say today, if you're starting a company, if you're a startup, mid-market, even large companies, you really have to think about, do you really want to invest in this area?

Is this a core competency? Particularly now that their solutions available. So it's one of those build versus buy conversation.

Ironic, it's almost like the, do I wanna build another data center? You know, back in that generation. So you're, you're specifically in the Kubernetes space or, or a little broader than That.

Yeah, so we are a, a horizontal platform. Okay. And, uh, so when we say metering and usage based pricing in billing, let me outline, uh, sort of what are the constructs of metering.

So it is a horizontal platform, but it is particularly suited also for Kubernetes and Docker infrastructure. And I'll unpack that. So metering basically at its base level is a usage instrumentation framework.

Okay. Now, you know, the moment you say that, you right away start thinking, okay, well, observability and monitoring and something else, they're also sort of usage instrumentation. But metering is different.

Metering is designed to give you that level of granularity, that level of visibility on what is being used by whom, where, and how much. So, so if you think about it, why, as I mentioned, all of these other companies ended up building a metering infrastructure, despite the fact that there were other tools out there in the observability realm is because today, if you are wanting to get an idea about how much of my infrastructure is being consumed by which customer, that's the holy grail, right? Everybody wants to have that level of granularity, that visibility, because it plays into your margins, is my, am I operating my business profitably or you know, who am I profitable?

Customers who are not, everybody wants to have that visibility. So today, in the absence of metering, what most companies are trying to do is use a solution that parses your AWS bill or your cloud provider's bill, and then you get some insights and then you try to layer things on top of that maybe by virtue of tagging and try to kind of come to a, uh, level of visibility on okay, what is being used? So kind of an allocation Mechanism based on some labels tag.

So now here's the thing that's Still, that's pretty imp imprecise. It is, it is. Right?

Okay. But here's the thing, and uh, I think there's ample data and evidence that that model has not scaled. You have new companies that are coming up with the same approach and while people are using it, but I won't say that this problem has been solved.

Nobody's out there saying, yeah, I've kind of solved this soup to nuts. I know exactly at a granular level what my customers are using and what my margin analysis is. The reason is, and I think this is important, especially at this conference of Kubernetes Docker.

So if you look at anything that you're gonna do downstream on the backs of a bill, think about it this way. You are using a single tenant artifact bill. I call it a single tenant artifact to instrument a multi-tenant infrastructure.

AWS generates the bill for you as a single customer. It's a single tenant artifact. It has information about you as a customer.

AWS does not know who your customers are. No, not at all. So you try to layer all these things, tagging all that.

Try to get to that. Another simple way to look at this is ask yourself the following question. If you are inside any one of these large cloud providers, AWS Azure, Google, and, uh, I was running a couple of services over there, I can categorically tell you, for me to do my cost analysis, I was not waiting around for my AWS bill.

I had my own infrastructure. It's too late That late that cows out of the barn or Whatever. Exactly right.

So metering is that artifact, which was designed to do usage instrumentation purposely, singularly accurately at scale, at price performance. Okay. And you can see when you look at the data structure for metering, it is designed precisely for that gives you the level of flexibility.

So metering is the foundation. And once you put this metering foundation, now, whether it's a Kubernetes cluster or it's an EC two, uh, form of servers or anything custom that you build is the same artifact. What is being used by whom?

Where, how much? So let me ask if you can peel back the covers without giving away too much. Is there, um, data that most customers don't know is available in AWS or probably that, but also the knowledge of how to put it all together so you can start the instrument of saying these things belong to this app and that's how much free source of whatever kind they use.

Yeah, precisely. So, so that is the job of a metering service. If you are gonna go out there and evaluate a metering service, look for that, that the service answers that question.

Not just today, but into the future. Mm-Hmm. So today you have X amount of workloads, you have a Kubernetes docker infrastructure maybe or something else.

But you know, over time it's gonna grow. You're gonna build new applications, new systems, seek a metering service that provides you a standardized single API artifact to send you events into the metering service domain agnostic. Okay?

So in this case, you want an instrument of my docker cluster, which application is using which part of my docker framework, you know, which containers are being spun up, which ones are being torn down, which ones are being scaled out horizontally, right? All of that is instrumentation that give, that metering, gives you the flexibility to whatever extent you want to meter that. And the other output of a metering service then is real time ingestion, aggregation, slicing data over time stream and giving you those analytics back in a dashboard.

All of that contained in a box. Yeah, I mean, sounds like if I got this right, you're literally, literally going from a bill. You're trying to dissect, slice and dice and figure it out to really a, a real time stream data stream that's then being analyzed and assigned to whatever, uh, attributes.

And it also sounds like, let me, let me see if I'm guessing this right. It sounds like you're an abstraction layer to that data. 'cause I gotta imagine not every service has the same APIs for gathering that metering telemetry kind of information.

So are you sort of abstracting that to make it so you've got a common API to pull that data from whatever service? Yeah, so it is, uh, it is an abstraction layer in the sense that it is a developer tool. So unlike Bill, where you are relying somebody else to aggregate information for you and then give you a static file, and then you try to go back and read up the static file, you know, one of the things we used to say inside AWS when I got going and we were building the pricing for the services that my team launched is this thinking that you work your way.

You don't work your way backwards from pricing and billing into metering. You work your way forward from metering into pricing and billing. I like to do it that way.

Okay. Exactly right. So if you think about, but today what's happening is a lot of folks working their way backwards trying to instrument from a static bill.

So back to, you know, yeah. So it is a layer of abstraction, but in that problem, it's much like, you know, how you would deploy a logging system or a monitoring system. There's an API, you have flexibility in the data structure that you wanna send into that API.

But the API itself is in tune to ingest events at scale and also do a couple of things, which is a little bit technical, how they're different from some other monitoring framework. So metering by design, which is, is designed to be accurate. So things like item potency, data deduplication, these are core design, thesis design tenets of a metering service.

Basically what it means is, is set it and forget it. You're gonna invest in this once. You should invest in this only once and once ever put this infrastructure in place and it should work like magic today and into the future.

So send the events and set it and forget it. One more, you know, aspect further bring some clarity to this. So why still, why do it metering?

Can I get by with monitoring observability? No, because metering ultimately will feed data into pricing and billing, cost allocation, all of those things. Accuracy matters, right?

Accuracy matters. Data lineage and audit trail matters. Somebody downstream is gonna raise their hand, be it internal, external, Hey, I don't trust this invoice, I don't trust This bill.

How did that get, Okay, you're gonna have to walk your way backwards all the way to the raw event to know exactly what happened. And if you're not doing it through a metering infrastructure, you're gonna pull a team from finance, you're gonna pull a team from product, from qa, from engineering, and you're gonna go into a remediation exercise, not scalable. Right?

So this is the infrastructure framework that puts you on that path. Yeah. You know, that's gonna happen.

The first budget meeting or first, you know, QBR, right? Yeah, exactly. All right, great number.

But how get that number? Well, you know, I, I can think of so many times where I wish I would've been able to know instead of just coming up with a general allocation and who knows how close that really is. Um, so another question for you is it's accessible via API, is that the only way I have to build kind of a dashboard to it or in, in implemented into whatever instrumentation I have?

Or do you also have a UI that people Can use? Yeah, great question. So, uh, in fact, I would ask your audience, if you go looking for one metering, anybody who's offering you a metering service should present it as a platform oriented service.

So if they're gonna say, first, let's check if it's a platform oriented service, and if they're gonna say it is, and as you're asking, so there's a sort of a pretty common checklist that you're gonna ask if somebody's claiming to be a platform or needed service. Okay? Make it easy for me to get events into your service.

So API is starting a good starting point, but it needs to also make it further easy for you to do that. So SDKs are necessary, right? Because APIs or APIs, but if you're building in Python or Java or whatever, then having native SDKs are helpful 'cause they can do a lot of the heavy lifting for you.

So that's a good hallmark to see if somebody's claim to be a platform service that they have that APIs, SDKs, auto scalable, horizontally scalable price performance, it sell price on a usage model. Right? So you can start, so Your pricing is on a usage model too?

Yeah, it'll be a So I have to, I have to meter the metering. Yeah, There you go. It'll be hard.

Watch watches the watchers, right? That's right. Yeah.

You watch, imagine that, you know, if we're, you know, if we are propagating you should shift usage based pricing and building and we are also than us, you know? Yeah. Might Lose a little credibility if you're like, yeah, we can't meter our own stuff.

It has to be here be, it's a developer artifact, it's a platform service, it's in the cloud, it's cloud native. It has to be priced on a usage based model. Otherwise, you know, I think you're speaking on both sides of your mouth.

Yeah. So I, I don't know if this is the most important question today, but to me it'd be one I'd want to know is, so what does it take for me to see this, try this to know enough, it's gonna do what I want it to do, solve the problem for me, not make job more, more work. Yeah.

But hopefully less. How do people, what's the, what's the user experience? Yeah.

To use a developer experience kind of, yeah, label. It's Uh, you know, it's pretty seamless. So if we hold the bar on what is a good developer experience, some of the things we already talked about.

So it's very straightforward if any of the developers have worked with any kind of, uh, observability or monitoring tool or logging tool. It's basically in that realm, start off with the API start off with the SDK, just send the event and at least what we say to our customers, you send us the event and we take care of the rest. And we literally do.

So as these events are emanating, right, you have this instrumentation in your Kubernetes cluster. As containers are being spun up, workloads are being used, you will have in your technology stack the attribution data. It's there in the stack.

It gets lost by the time it gets to the bill. So right there in your technology stack, you basically create an event metering event based on our SDK or API send us the event metering service will persist it, we'll aggregate it, we'll slice it over time stream, we'll give you the aggregated analytics in real time with a built-in dashboard, you now have a system of record in place for usage instrumentation, the cloud start to part. And you can do many great things once you put this foundation in place.

Okay. So I think I understand better now that API is really what lets the customer decide what we're gonna meter, right? Here's all the data flow.

Exactly. Here's what I care about. Might be a lot of attributes that, that this level don't mean anything.

But I do want to track, you know, what transactions cost per user Exactly what whatever it is. Exactly. Yeah.

And that's why, you know, so domain agnostic like we are, and you asked earlier also the intersection with Kubernetes Docker. I mean the metering service should be that domain agnostic, meaning we as a provider look at meter as really your domain. I mean, as long as the event has a date and timestamp and you wish to aggregate and slice it over time stream, it's a candidate for meter.

You wanna track how many times the wheel rotates. Obviously Kubernetes clusters, containers, EC two storage, API calls how high the bird fly, doesn't matter. Meters a meter.

Okay. I'm still trying to parse the meters, metering the meter and what meters that, but that's a whole nother problem. Hey, it's great meeting you Mitch.

So nice to Chat with you. Thanks for coming. Yeah, folks can find out more.

io, right? Yeah, sure thing. So, uh, yeah, if you guys wanna check it out, um, yeah.

io, uh, come visit our website. We are also here at, uh, CubeCon with a booth. Uh, stop by our booth.

And uh, yeah, I'd love to engage with you. Uh, not a sales pitch per se, but if you're even on the fence or why don't you just learn about some best practices around, uh, the shift to usage based pricing in Berlin. Happy to, uh, have a chat with you.

Great. Turn your developers loose Abs. Absolutely.

Get that information you've always wanted to have. Alright. Have a great show.

Thanks. Awesome. Mitch, coming to talk with us and we look, what's your great success?

Yes, we will be back with more great interviews. Diversity, variety of topics we're talking about are all great things and whole finops space has been a big, big, big thing. So here's a way to, uh, kind get that detail.

We'll talk to you in just a minute with our next guest.