KubeCon 2023: Kubernetes Docker Infrastructure
Mitch Ashley: Hey everybody, welcome back to KubeCon here, 2023 in Chicago. More great conversations. Speaking of which, my new best friend who I just met, Puneet Gupta, welcome from Amberflo.
Puneet Gupta: That’s right. So nice to meet with you.
Mitch Ashley: Nice to meet with you. Fellow entrepreneur. Love your story. Coming out of your last 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. Tell us a little bit about what you’re up to.
Puneet Gupta: Yeah, sure. Maybe 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. So Amberflo.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.
Our platform is called cloud metering and usage based pricing and billing platform. This is, I think I’m sure you’re seeing it all across, back three years ago when we started the company was most of the folks were still on the fence whether businesses are going to shift towards usage-based pricing and billing model. But I think now the cat’s out of the bag, more and more companies are going down that way. Of course that itself intersects the Kubernetes docker infrastructure. I’m sure we’ll get into that, so we enable those companies either you 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 enable them to do that.
Mitch Ashley: 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, 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 going to be, or you just step in when it’s kind of out of control, bring it back in line?
Puneet Gupta: Yeah, it’s a little bit of a mixed bag, usually it’s a function of what we’re seeing as kind of company, the type of company, if you are a platform oriented company or your applications oriented company. Then second, just sort, I would sort of call them maturity curve in the cloud. Those are the two functions that determine where they are on that trajectory and how they’re looking at it, both in terms of opportunity or the pain point.
I think increasingly though we’re seeing things starting to converge where wherever 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, particularly just in the last six months, this 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, 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. We can unpack it some more, so that’s sort of what we’re seeing. I think it is definitely was maybe right now I would say 2023 could itself be sort of that inflection point where it was should we, should we not 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.
Mitch Ashley: Do you think maybe of both, but do you think we need to move it too quickly to do something in our own environment and spin it up, or do you think it’s more we just don’t have the resources and don’t know that we want to take the time to go buy whatever hardware environment to do this?
Puneet Gupta: Yeah, I think it is one of those things. If you look at, again, just overall, I call the maturity curve in the cloud. 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 going to arrive at a conclusion that this is best suited to outsource and get a vendor. Here’s the reason why, not just of course the fact that we offer a solution, but there is reason we’re offering this solution because we…
Mitch Ashley: The reason why you’re doing what you’re doing.
Puneet Gupta: The reason we’re doing it. Because we see a market for a couple of reasons. One is, it is, and part of the reason also plays to your earlier question, yes, it is a little bit of a heavier lift than just sitting down in back of the envelope coming up with a hundred dollars per user per month. That’s easy to do and it didn’t require a level of infrastructure to do that because it’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 a long while. Usage-based pricing and billing does require some upfront investment in infrastructure.
Now the question is where do we start? Some of this has been a function of where the market has been. There weren’t that many solutions out there, third party. Most companies ended up building, if you look at 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 10 years back, Twilios of the world, Databricks, MongoDB, Snowflake, all of these guys had to build this infrastructure because there wasn’t anything out there. 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 they’re solutions available, so it’s one of those build versus buy conversation.
Mitch Ashley: Ironic, it’s almost like the do I want to build another data center back in that generation. So you’re specifically in the Kubernetes space or a little broader than that?
Puneet Gupta: We are a horizontal platform. When we say metering and usage-based pricing and billing, let me outline, what are the constructs of metering? It is a horizontal platform, but it is particularly suited also for Kubernetes and Docker infrastructure, and I’ll unpack that. Metering basically at its base level is a usage instrumentation framework. Now, 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.
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 who are my profitable customers, who are not. Everybody wants to have that visibility. 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 come to a level of visibility on, okay, what is being used?
Mitch Ashley: Some kind of an allocation mechanism…
Puneet Gupta: Exactly.
Mitch Ashley: Based on some labels and tags.
Puneet Gupta: So now here’s the thing…
Mitch Ashley: Still that’s pretty imprecise.
Puneet Gupta: It is, it is, right? Okay. But here’s the thing, and 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. If you look at anything that you’re going to 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, so you try to layer all these things, tagging and 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 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.
Mitch Ashley: It’s too late, too late that cows out of the barn or whatever.
Puneet Gupta: Exactly right. Metering is that artifact which was designed to do usage instrumentation purposely, singularly accurately at scale, at price performance. You can see when you look at the data structure for metering, it is designed precisely for that, gives you the level of flexibility. Metering is the foundation, and once you put this metering foundation, now whether it’s a Kubernetes cluster, or it’s an EC2 form of servers, or anything custom that you build it’s the same artifact. What is being used by whom? Where, how much?
Mitch Ashley: So let me ask, if you can peel back the covers without giving away too much. Is there 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 used.
Puneet Gupta: Yeah, precisely. That is the job of a metering service. If you’re going to go out there and evaluate a metering service, look for that. The service answers that question, not just today but into the future. Today you have X amount of workloads, you have a Kubernetes docker infrastructure maybe or something else, but over time it’s going to grow. You’re going to 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? In this case, you want an instrument of my docker cluster, which application is using which part of my docker framework, which containers are being spun up, which ones are being torn down, which ones are being scaled out horizontally? All of that is instrumentation that metering gives you the flexibility to whatever extent you want to meter that. 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.
Mitch Ashley: I mean, it sounds like if I got this right, you’re literally going from a bill, you’re trying to dissect, slice and dice and figure it out, to really a real-time stream data stream that’s then being analyzed and assign to whatever attributes. It also sounds like, let me see if I’m guessing this right, it sounds like you’re an abstraction layer to that data. I got to imagine not every service has the same APIs for gathering that metering telemetry kind of information. Are you sort of abstracting that to make it so you’ve got a common API to pull that data from whatever service?
Puneet Gupta: Yeah, so it is an abstraction layer in the sense that it is a developer tool. Unlike bill, where you are relying on 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. 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 don’t work your way backwards from pricing and billing into metering. You work your way forward from metering into pricing and billing.
Mitch Ashley: I like to do it that way, right.
Puneet Gupta: Exactly right. 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. Back to, so it is a layer of abstraction, but in that realm, it’s much like how you would deploy a logging system or a monitoring system. There’s an API, you have flexibility in the data structure that you want to 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. Metering by design, Mitch, is designed to be accurate. So things like item potency, data deduplication, these are core design pieces, design tenants of a metering service. Basically what it means is set it and forget it. You’re going to 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. Send the events and set it and forget it. One more 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, accuracy matters. Data lineage and audit trail matters. Somebody downstream is going to raise their hand, be it internal, external, Hey, I don’t trust this invoice, I don’t trust this bill.
Mitch Ashley: How did that get?
Puneet Gupta: Okay, you’re going to have to walk your way backwards all the way to the raw event to know exactly what happened. If you’re not doing it through a metering infrastructure, you’re going to pull a team from finance, you’re going to pull a team from product, from QA, from engineering, and you’re going to go into a remediation exercise, not scalable. This is the infrastructure framework that puts you on that path.
Mitch Ashley: Yeah, you know that’s going to happen. The first budget meeting or first QBR, right?
Puneet Gupta: Yeah, exactly.
Mitch Ashley: All right, great number, but how you get that number? Well, 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. 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 implemented into whatever instrumentation I have? Or do you also have a UI that people can use?
Puneet Gupta: Yeah, great question. 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. If they’re going to say, first, let’s check if it’s a platform oriented service and if they’re going to say it is, and as you’re asking, so there’s a sort of a pretty common checklist that you’re going to ask if somebody’s claiming to be a platform oriented service, okay, make it easy for me to get events into your service. 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 are APIs, but if you’re building in Python, or Java, or whatever, then having native SDKs are helpful because they can do a lot of the heavy lifting for you. 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 sells price on a usage model, so you can start…
Mitch Ashley: So your pricing is on a usage model too, so I have to meter the metering.
Puneet Gupta: There you go. It’ll be hard.
Mitch Ashley: Watch watches the watchers, right?
Puneet Gupta: That’s right. Yeah.
Mitch Ashley: You watch…
Puneet Gupta: Imagine that, if we are propagating, you should shift the usage-based pricing and billing and we are also than us.
Mitch Ashley: Might lose a little credibility if you’re like, yeah, we can’t meter our own stuff to be here.
Puneet Gupta: 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, I think you’re speaking out of both sides of your mouth.
Mitch Ashley: 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 going to do what I want it to do, solve the problem for me, not make the job more work, but hopefully less. How do people, what’s the user experience to use a developer experience kind of label?
Puneet Gupta: It’s pretty seamless. If we hold the bar on what is a good developer experience, some of the things we already talked about. It’s very straightforward if any of the developers have worked with any kind of 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.
As these events are emanating, 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.
Mitch Ashley: Okay, so I think I understand better now that API is really what lets the customer decide what we’re going to meter, right?
Puneet Gupta: Exactly.
Mitch Ashley: Here’s all the data flowing into it. Here’s what I care about. Might be a lot of attributes that this level don’t mean anything, but I do want to track what transactions cost per user, whatever it is.
Puneet Gupta: Exactly. Yeah. That’s why, so domain agnostic like we are, and you asked earlier also the intersection with Kubernetes adopter. 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 want to track how many times the wheel rotates. Obviously Kubernetes clusters, containers, EC2 storage, API calls how high the bird fly, doesn’t matter. Meter is a meter.
Mitch Ashley: Okay. I’m still trying to parse the meters, metering the meter and what meters that, but that’s a whole other problem. Hey, it’s great meeting you.
Puneet Gupta: So nice to chat with you.
Mitch Ashley: Thanks for coming. Folks can find out more. Tell them Amberflo.io, right?
Puneet Gupta: Yeah, sure thing. So yeah, if you guys want to check it out, Amberflo.io, come visit our website. We are also here at KubeCon with a booth. Stop by our booth and yeah, I’d love to engage with you. Not a sales pitch per se, but if you’re even on the fence, or wanted to just learn about some best practices around the shift to usage based pricing and billing. Happy to have a chat with you.
Mitch Ashley: Great. Turn your developers loose.
Puneet Gupta: Absolutely.
Mitch Ashley: Get that information you’ve always wanted to have. All right, have a great show. Thanks.
Puneet Gupta: Awesome, Mitch.
Mitch Ashley: Coming to talk with us. Wish you great success.
Puneet Gupta: Yes.
Mitch Ashley: 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 get that detail. We’ll talk to you in just a minute with our next guest.