Hey, what's up everyone. We are live on another episode of Adventures in DevOps. I'm your host today, Will Button and joining me in the studio, Punit, Gupta and Beat. I like, one of the things I like instantly about this is you've said that your professional work and your personal hobbies collide, which is exactly how I ended up doing this. You know. I remember way back in my career someone was like, hey, can you fix this server for me? Or can you build this website for me?
And I'm like, yeah, sure, here you go, and then they said great, thanks, what do I owe you? I was like, wait, I can make money doing this, and you know, thirty years later, here we are. Yeah. So, Perni, welcome to the show. You are the CEO and co founder of amber dot Io. Right, Amber Flow, Amber Flow. Sorry, that's the beauty of doing live is now all of a sudden everyone gets to hear how often exactly I screw up in these podcasts. So tell me a little bit about your background,
how you ended up starting your own company. Which is three years in for a startup, which is kind of like a significant milestone, like if you make it past a three year point, things start to get you get a little confidence at that at that stage. Yeah, no, sure thing. You know, great to be with you. Thanks for having me on your show, come forward to it and yeah maybe I just you know, by the ways of introduction, and I think you can. I love to also
unpack, you know how sort of the hobbies and brooklit. I have my own story there and you know it's kind of evolved over over a period of time. But yeah, just by the rays of sort of quick background, you know, Amber float dot io we enabled businesses to charge and track on usage that we provide a cloud meeting and usage based pricing and building platform. I'm sure we'll have a chance to dive into that a little bit more.
And uh yeah, Amber flow at io. We're now about three years in and the company was started actually I think what was being called for a period of time, born in the COVID. So we're one of those and I think you know that's uh, that's a good part of our story. Uh. And what that means is when we started the company, we were in the lockdown back in forty twenty and we raised a seed round. We we did not get to meet our investors face to face for about another year.
The whole round was done on zoom online. Oh wow, you know, so uh some interesting you know artifacts and built of that lockdown era. But you know, the lockdown I think served in some unique ways, interesting ways actually beneficial to start up like us. So anyways, there's stuff there. But yeah, the company is about three years old. We're nure Back. We raised two rounds of funding, a seed round, and then earlier this year we had raised in the around, so we've got about twenty million dollars
in funding. But yeah, like you said, you know, after a good start, after a decent start, a lot of things have to connect in the journey of a startup, especially early. As you called out, you know, you had three years in I think, you know, there's
a momentum building. We'd like to say we're seeing some tailwinds on our backs, and I extributed that, you know, just feel good, healthy combination of you know, maybe a few things that we got right, but also a lot of things that the market is that are happening in the market organically, markets turning in this direction, and we're definitely benefit from that. Right
on. Yeah, you know, I've spent pretty much my entire career working for startups, and one of the things that I've learned about startups in that period is that for most of the startups that are successful in the long term, the product that makes them successful is not actually the product that they start
with. And I love using the aviation industry as an example of this because it's it's something that's a new enough industry that we can kind of visualize what the beginnings were like, but it's also been around long enough that we can see what happens at scale over time, you know. And if you think about like when the Wright Brothers launched their first airplane and was it like nineteen oh three, I think they probably didn't have any idea of what modern aviation
would look like and how it's iterated and how it's just impacted everyone. So they had to in the industry as a whole, had to pivot along the way. So have you seen that in your company, Like what was your
initial idea versus what's what's working for you right now? Yeah? You know that's uh, yeah, You're gonna take us down a little bit of from memory lane and also a little bit of sort of the founding founding pisis that we had, which uh, you know, which was I guess it's still obviously pan out, but I want to say it's somewhat contrariant to the typical startup lends that perhaps you might see outside and looking inside Silicon Valley. So
yeah, let's let's go into that. And now I'll certainly index on that. So, uh, you know, we'll talk a lot a lot about you know, like like I said, you know that we feel that the world is shifting. There's a there's a change in business model. Uh how in the business models of businesses, right, so monetization model, how companies are increasingly selling their products and service. They're shifting to what we call a usage based model versus a seat base. And that's a foundational shift. Like
I like to say, business models don't change very often. Well, you know, and we can. We can look back from the dawn off software you know whatever that is sixtally seventy years ago. I think at best, maybe if you had one people refer back to the subscription model, and I would even challenge that. I think there was more financial optics change rather than a full on technology business model change. This one is going from something that
was fixed and recovering to a full on metered usage based model. That's the foundational shift. Okay, how does sort of this play back to, you know, how we looked at things and how things have evolved. So what I was referred to earlier, I don't know. I you know, I maybe off, but I think generally one of the things that has sort of been less exciting in the world of startups and Silicon Valley is I think there's sort of this templatized approach where go pick find a niche you know, almost
like a feature. Maybe the transition point is that it already existed on prem and you figure out a way to deliver it in the cloud, and you put the company and a product behind it, and off you go. And then it's a race to ar R and m r R and then you know, in ten years you aim to get two hundred million in ARR and yourself a couple of billions in Kumbaya. Okay, that's and obviously you know, nothing wrong with that. I mean, you know that itsell takes you know,
sweat and blood and whatnot. Our view is slightly different, you know, we just we dreamed to imagine a little bit bigger than that, and some of that was just a function of what we saw. So I think, you know, maybe I'll put some credibility into the statement you're looking across, you know, across the screen. You know, I'm a little bit
of an old hand at technology. I've been around the block. It's just as you have twenty five years under my belt and before I decided to drop everything and go do the startup, so it wasn't just trying to chase a wave. And this is what we're doing here at Amber Flow. I call it sort of as a labor of love because it's all passion driven, it's all vision driven, and this is kind of going into them the question you asked. So we first saw that we like, this is sort of in
the fullness of time. So already, you know, kind of taking a long term view, and the fullness of time is at least five years out, more like ten years out, you know, if you want to talk about you know, THESS ten years out. That's the comfort zone for me.
So because as we said, if there's a shift in the modernization business model, this is going to play out over a period of time, you know, and then the going in and flip a switch and change a business model is going to ripple through every functional area of your business, and maybe the confidence comes from you know, personally, I've been a little bit lucky.
I've spent some time at AWS at Amazon. I think it's one of the companies that is credited and known for some long term thinking, and I think it's it's evident for how they have played out the last in a couple of decades. So got to be you know, in that environment, so comfortable with that thinking process. I think maybe I've drawn like contiments from there, and then a function of I think what we see in the market, like if this is the change that's happening, then well there is a lot
of opportunity here over the next part. So that is the starting point. Now it goes to your question. Okay, so if that's how we're looking at it, then we still have to build a business. We still have to go to market. So then what is the launch pad? But we are looking at it from that lens. We have a very specific, well understood or well projected view of the long term. We're here in this for
the long term five years out. We see a technology stack. I think that's going to evolve, that's going to adjust, that's going to commulate, and we see tremendous levels of opportunity for am flow. The play into that transition starting point is you know, as a startup you kind of have to gravitate where at least in the narrative is so you can make the dots fine product market fit and you know, start to build the business and start to and Okay, so for us, the big opportunity that we saw was in
building a new platform technology artifact that we called metering. However, not many folks, at least three years ago we're talking much about metering. Oh for sure. Yeah, it's a brand new concept to me. Yeah. Right, So so there you go. Right, so somewhat ourthog, I mean, we are motivated by what metering is and what metering can do today and out five years and ten years. That is really what gets up us up in the morning. And usage based pricing and building is then simply an artifact
is sort of a means to an end if you view right. So it's just one of the benefit forwards of me drin. If you want to get you like to say, you know, if you want to get usage based pricing and building right, you must first get metering. Right, So that's sort of our view. So we we spend really sort of the first year
of our existence just hits down nothing but building the metering service. And metering is a heavy lift part if it is not that well understood, as you said, you know, called out, they're not that many blueprints of how they effectively build a metrink service at scale. Uh, what are some of
the design tenets and pieces? As it is a heavy lift. We spend a year building a metering service, then we layered an application on top of metering that people building out the usage based pricing and billing, and that's a little market motion today. So we feel that this approach we're going to continue to expand we don't consider ourselves a single product company. We're going to be a multi product company. YI is fire design and that's the foundation we make
right on. So help me understand what like if I if I want to think about things from a metering perspective, what am I am I looking at? That? Does that translate to like figuring out how to spend or how to how to track how much time someone spends in my application or what actions they're taking and turning that into a monetized metric. That is precisely that, but there's more to it. Okay, so that is certainly so, so think of metering, you know, it is really sort of the spised army
knife. Actually, don't even take a step back. So one is you know, why isn't there that much level of awareness. I mean we're about, you know, ten fifteen years into the Clower journey and you know we're now talking about Yeah, okay, I've heard of it, but you know, but yeah, let me sort of comfortall circle and then you know, we can unpacked out of the Swiss army knife. You know, why is this such a poor piece? First? I'll maybe just start off by some
against some evidence. If you look at all the companies out there today who have achieved a level of scale in the cloud, and of course I'm not just talking about the three four large cloud providers, but you know, the next batch of companies like Twilio, Data Breaks, Mango, a Snowflake, right, and then increasingly on. I think, go and study those companies, you'll find that they have over time built and in house metering services. So what I'm getting at is, you know, once you find that you
are native in the cloud. You're achieving a level of scale in the cloud you cannot do without this construct. And I would even profess to go as far as saying that I think they, perhaps many of them, if not all of them, discovered this after the fact, and then they hurry to kind of get this instrumentation, this metering infrastructure put in place, and most of them have built themselves. By frankly, there wasn't one available off the
shelf at the time, right, So what is it? Right? This thing about metering, well, metering the term of course we all grew up with. I mean, it's the utility meter that's on the back of our homes. You know, it's metering our usage. So there you go, usage metering. But but let's take a step back. So why is it such an important construct in cloud and why has it gone unnoticed for so long? Okay? First is, you know, let let's look at We all
know cloud is elastic. Okay, that's you know, that's a no brainer. Everybody understands that, which basically means that you can dial up and dial
down your back end resources or resources. Okay, Then the question is, you know, if the back end is elastic, if I'm building in the cloud, which in the fullness of time, everybody is h and you are building on a foundation, you know, foundation platform that is elastic you know, I almost almost envision like a you know, sort of a quicksand like you know, it's it's a you know, it's a it's a little bit wobbly, right, it can go up and down, right, it can
shift. Okay, So how do you tame elasticity because eventually you're going to have to build something that is solid. So usage elasticity and the artifact to tame elasticity is metering. Okay, So what is metering? By definition? Metering is metering tells you what is being used by whom? Then? What were how much? That's it put a box around it, right, nothing to do with pricing and building. Just yet, what is used in my cloud infrastructure by whom? When? What weear? How much? That is
the job of a meeting service. It is the owner of that construct, meaning it is the source of true It is the system of record for what is being used by whom? When? What were how much? You have to if you wish to scale and build a company in the cloud, you have to treat this box as sacro sancta. You cannot you know, this is not a data leg or a data warehouse or a munget with this, or can I throw this in there? Or can I throw that in there?
You need to get this right, because if you don't and you try to do it through some other ways, then inevitably, when somebody asks that question inside your company, and it will come from all functional areas, different
function areas, what is being used by whom? Sales wants to know, Product wants to know, Engineering wants to know, Support wants to know, Finance wants to know, Accounting wants to know when they're going to ask that question if they ask a follow up question, Hey, is this data accurate? My friend? You do not have a meeting service in place. Therefore, all of these companies over time woke up to the fact that, you
know, we got to solve this. We got to solve this once and for all, and there needs to be a system of truth system a record for consumption data, for usage and consumption data that I can tap into, and there should not be a following up question is this accurate or is this correct? Right? And the reason why you can then tackle that question because then you you know because you treat it as a separate artifact, You give
it due diligence, you put the right infrastructure. You're not trying to balance it as a combination of observability or monitoring or logging or throwing it into a data lake and trying to you know. So we can also untage a little bit more on the architecture side, but that is the starting point. So you are an elastic back in infrastructure. The only team elasticity is to put meuterrain in a place so you can see what is being used by hum when
work how much. Now for companies who have been in the cloud for a while, as we say, sort of in this fullness of time, you will find and then what is this genesis of usage based pricing and venting? Companies are discovering that you know, if my back end is elastic, its down usage. My front end also has to be elastic. What I mean by that my front end is how then you sell your products and services also will need to be elastic so that you can align your front end use your
back ends uh infrastructure. And that's basically the cloud, well, I mean the optics of the cloud. So that is what led to usage based pricing in the first place. You know, it is a heavy left. You have to put this instrumentation in the place. Uh, there's a lot of you know, product and engineering work. So unlike traditional seat based pricing plans, right just after the fact, come up with some arbitrary number that's high enough that gives you a margin ratio. Okay, but off you go.
No, here, you have to do this instrumentation. You'll have to know what is what is it that you're continuing in the back customers and consuming on the front, and the alignment and that disability needs to be there. I
gotcha. I kind of feel like there's a light bulb going off over my head because this is a problem that I faced at several of the startups that I worked with, where we have our infrastructure and we tracked you know, monthly active users and then have the question posed to us by the next round of investors of you know, does this scale? What is your your revenue and your profit margin look like at that scale? And to be honest, in many cases we just took a wild guest and said, oh yeah,
it's it's definitely scales and margins will look like this. But metering is actually the simple math calculation that allows you to accurately predict what your infrastructure cost will be at a given level and what your prices have to be at that point to be turning a profit totally. Well, in fact, you know, just for your audience, I don't even take my word for it, I think you they will find credibility in this. You know, one of the
the hidden sort of the secrets of the success of AWS. Certainly the pioneered leader in the cloud is on the backs of the metering service, right. I mean, if you know, I was there in the early days as a GM, had a chance for the team to build and launch a couple of tier run WS services. This you're not running a cloud business unless you have a meting service out putting this data on a daily basis, pretty much
on a real time basis. And that is what I'm you know, why the company continues to grow and was on such a rapid pace of innovation. Let me actually give another anecdote between pirical data for your audience. So I'd like, you know, for all these folks to think about this, I don't know what, maybe two hundred plus different AWS services over the last ten years fifteen years. You are not going to find a single one, not a single one where they had to retrack the pricing model for that they didn't
get it right at the outset. Oh that's a fair point. That's a really good point. Typically you can count on AWS pricing going down over time, but I can't recall a single instance where prices have actually increased. Well, not just saying it's what I'm saying is, you know, to get the model like, you know, they sort of had a mea kupa oops, you know, this is not what we intended. We didn't think it through. We're going to charge it not this way, but this way.
So they have consistently every time gotten the model correct whatever new service that they're brought on, and they're innovating up and down the stack, right infrastructure platform as a service, you know, more and more increasingly applications. Right. So what I'm getting at is it's not an accident. You know, it's not like you know, they've got all the smart people under the sun and
things like that. No, there's a framework, there's a methodology. Knee Drink service is basically bubbling up the intelligence, the data, and they're constantly looking at that eye vaws. You know, all managers, gms and people who are building new things and existing artifacts are constantly looking at this data and data is informing what is your customer facing price points? Where should we dive that up? And is it time to now give a discount? What are
the usage patterns? Like I said, what is being used by whom? When? World bear how much? So? Meeting is the backbone for cloud operations right on? So my background infrastructure based, you know, I typically think about scale and utilization in terms of you know, CPU memory, network bandwidth, all very foundational compute metrics. What's the what's the shift there to go from thinking about traditional infrastructure to metering based What different things you have to
start thinking about and start tracking? Great question. Yeah, so this comes up also quite a bit. Okay, so almost everybody will have you know, you open your eyes. You want to start writing for second lines of code for whatever iety application, business building. You know, there's a checklist
of things. You know, you're going to drop in some kind of a monitoring tool, You're gonna drop in some kind of a logging tool, and maybe soon thereafter you're gonna look to maybe get some kind of an observability the moment you stand up some infrastructure. Okay, all of that based stuff needed. Here's the thing, right, So because meterining hasn't quite caught up to that checkbox, as we said, you know, inevitably and at the end
of the day, it is also a event ingestion pipeline. So in that regard it is a close cousin to the artifacts of observability on monitoring because it's basically the event ingestion. But here's the kicker, here's the difference. So here's why again, all these companies ended up building a meeting service, certainly at AWS and other large block providers and others that we discussed metering events. Meter has to have attribution to who is it on? Whose behalf is this
event for? Okay, so you know, unlike let's say logging, which is of course you're at tracking your functions and your data execute, and what are metering is about usage. So meter events will by design have to have an attribution this meter, this usage event is on behalf of this person, customer, partner, system, cluster, whatever that is that you want to
attribute that to. So that sort of has to i'd like to say, sort of levels it a little bit further up the stack, right, because at the logging level you may not always have that attribution, and logging, you know, function a lot of times, you know, like observability or APM, you know it's done on the back end, just pushing through the Java stack. So metering is a little bit of a higher level artifact.
You need to have that attribution. So then it puts you into the SDK and API layer and you have to put it into your stack where either as part of your control plane or as part of your data plane, so you can attribute whose behalf this is happening. Let me give a little bit more clarity to this. So you know, there's a whole fringe economy that has stood up on the backs of the plug provider's bill, which is now cloud cost management. So you know, the the intention is good, right,
but I would challenge that one. The problem has not been fully solved, and I think the methodology is fundamentally flawed. Further highlight this distinction between metering and some of the other observability. So, uh, a whole bunch of you know, I quite trying to get I'm interested in seeing if there's one out there, but I think all the companies that I've seen cloud cost management. The first thing they'll have you do is log into give them your cloud
provis commercials. It's something the bill and you know, let's start parceling in and all of that. Uh, I'll put this instead of pieces forward. At least when I was at a WS and I think, I think this is fact. This is how it is even today and plausive before I got there. Uh. And this is general knowledge Amazon a W is in particular Nico about costs, saving costs, uh, operational efficiency. Right, This was not you're working about it. They talk about it. It's part of
their culture, part of their leadership. And supposes pretend every year when you come in and you present the plan for the next year, you have to have a chapter in your AH I how you to take operation to become more efficient? I can categorically tell you. Will you think I used to wait for my bill, you have to show up and then to the course of that and uh, with my strategy and how I'm going to take costs out
of my cloud? No, probably not, that's right. I had a metrink service that I could leave on that what is being used by whom when work were how much. I don't need to go to anybody in accounting. I don't need to go to anybody in finance. I don't need to be for the bill to show up. I had a meet Drink service, and the mee Drink service is a data warehouse, and I can tap into the grad data warehouse based on existing artifacts, dashboards and my own access into that.
And I had visibility even before the salespeople knew who was usually work on my service. That is cloud operations for you. Well notice in the context of business, right, so yes, we uh, this is not a need are I mean? Our engineering teams of course have logging and monitoring and visibility as you like you rightfully said, there's a need for that. You know, observability will track are you up? Are you up? Are you down? Are you down? That yes, they will tell you okay,
how hot are you running? Are you ninety percent percent? What's the need for that? Me? During is telling me this user logged in, stayed on this instance for this long. This user not the instant for this while they're logged out and shut it down? Right. I have that cor relationship too. That is what kne DRNK is answering right, and that basically drives forward as a business, I leverage that into my operations to be extended. So it literally is the electrical meter on the back of your house, so
the electric company can see exactly which household used how much service. It's exactly that you know, and that's and you know that's that's magical because yeah, that's where the term me drink comes from. You know, it's not something that cloud providers in minted. It's not something it is the term you know, me drain. Yes, this is an infrastructure. As we said, it's elastic. It will go up and down. People will dial it up
and down. We cannot be flying blind on this. We a w as themselves need to know first and foremost who is using what and how much before they can do anything and go anything further or build anything on top of it. So for them, this is the first class citizen. So this right metering. If there's a hiccup on the metering service inside it as one, there will never be I mean, the house will come crashing down. It's like seve one. There's a beacon that shows up like a red beacon that
starts to spin. Internal dashboards you know, so you know, which basically tells you that, yeah, open up your sleeping bag, you're not going home. Okay, So but yeah, it is it is that critical everything,
and so it's precisely that. And therefore and now you think about, okay, so how come then we have come along this far ten fifteen years into cloud And of course, you know, many businesses have built successful businesses and some maybe today do not have meeting services and they're doing reasonably well. I called out, you know, the ones who really achieved a level of skill ultimately have built a meeting service, but there are many if not.
And I think the reason for that is, well, I think you know why it has gone on for so long, but why from day one? Cloud providers had it because they had no business if they didn't have Meetrink service started on day one. A couple of things. One is I think that the business context was perhaps missing, right, So of course, ultimately everything is driven inside an organization, particularly started you know as a classical resource allocation
discussion of good priorities. While you could do a lot of things, what
are the things that we do first? So the business narrative was perhaps missing, and the business narrative comes in the form of usage based pricing incoming right, So that is the wake up call because you may be running a large cloud business today, but you know, if your go to market is not usage based, then the business need, like I said, the business operational need for what is being used by whom when what were how much never really
came to the surface. And therefore the injuring and product teams never built or needed to build meeting service, and therefore they have gone on this long even though they're running successful businesses in the cloud without having a meeting service the moment, so the business context was missing. Now in the world of AWS and other cloud providers, some already had the foresight, so they dated from day one and they have grown with it because they knew that they could not do
it otherwise. Because they're pricing plans for a usage based from day one. So you will find that any company that launched day one on usage base, this is guaranteed, well, you will find a meeting service there. Okay, So the ones now who are shifting to the model of usage basis, they are going to discover and I think we're seeing increasingly when I said, we've got tailwinds. We're finding more and more people are sort of nodding their
head, yeah, i'd need this artifact. In fact, some are asking for it by name now, so still relatively early, but give it another year, two years, three years, this becomes a checkbox site for a cloud native system. Yeah, just thinking through like the evolution of software, I think I see how this becomes the path because if we go back, you know, twenty years ago, if you needed a copy of Microsoft Office,
you went down to the local computer store and you bought. You know, if you're old enough, you bought, you bought it and brought the floppy disk back to your computer. And then when modern technology hit, you went and bought the CD. And then whenever they went to an online business model, it's still the same business model for them, where you're paying for
a seat of Microsoft Office. But now with everything available on demand, a lot of companies are seeing increased competitors because the ability to launch competitor, or the barrier to launch a business is so much lower now, and so you have to find different ways to be competitive. And one of the ways is to accurately price your product based on utilization, and how do you measure utilization.
Well, that seems that's the metering aspect of it. So to me, it feels like there's a natural path to this totally, and you know, and companies will spare by it like I would. You know, I think if you take anybody from aw's leadership, take them aside and say, hey, you know, tell us, you know, what are some of the core things that you got right in the early days, you know,
it's inevitable. You know they'll say we got metering right, you know we because you can be flying blind and and just on a whim and how to grow in business. So yes, and I think the other things why we are still bullish, but I think more than that now there's ample evidence and data that's sort of backing the pieces. So the shift to usage based pricing and building, I think you actually just kind of going down that path,
right, So how do you stay competitive? It's cloud computings obviously level the playing field in terms of being access to technology infrastructure or do you needed five million dollars just to kind of buy Oracle and a bunch of other things to even get started. So it's been a great level or I mean a couple of guys in the garage can put out just as much, you know, in any other companies. So it's all about time to market ideas. So
in that realm, how do you stay competitive? And I think people are finding that it's given that you're going to have competitors, others are going to come into your space. So within that, how do you bubble to the
top. And there's this whole thing being talked about called PLG product led growth or basically taking friction out from user adoption from customer adoption, right, making that whole process a little bit more more and more streamlined, more and more easy, and sort of the right combination of cell service and kind of getting the customer situated to a point where you know, and they know that,
yeah, this is the right product for me. And then maybe in sales and you kind of take it forward from a cross sell up sell perspective. So this thing is loosely being talked to by that in the realm of POG product growth. And this is again how you know all of this is and going in the realm of competitive getting out ahead. Customers have a lot of choices because they have a lot of choices, but they don't have a lot
of time. Everybody has still twenty four hours in the day, but the choices are many, so companies will have to figure out how do you how do you put yourself in the in the shoes of your customers are users, They're only going to have limited time in terms of giving trying to evaluate your product as there's five others that need to look at. So how do you make it easy? And again, metering is the underlying foundation if you want
to successfully build a PLG motion think about it. And again, you know this is well so obvious, but sometimes not intuitive. I like to see with Joe, who's the biggest PLG provider on the planets? Right? Sometimes people say, yeah, well, you know my product is not conducive to a PLG motion. You know it needs sales team right from the get go. I don't know. I mean I look at three hundred services under their umbrella and c I aws up and down the stack, and there's so many
complicated service there services there own PLG motion. Right, you get customers in, get them to start using something, give them a good experience. And the whole idea is is uh usage based pricing and linning. The ideas you take friction points out as they start to fail. Give them a path to grow. I mean, why you want to get in the way if they
are naturally organically growing, Just let them grow and then art. The fact that will allow you to do that is it's a usage based model, right, So it's not a seat based because seat based has these step functions. Somebody has to call somebody to go from ten users to twenty users. But if it's a usage base, Okay, you know, I like your product, I'll keep using them, inviting others in the company, right, just
start using it. Later you can come in with the sales team and maybe offer a longer term contract or to do some promotion discountant kind of get Yeah, so that's how do you enable this. You got to have a meterrink artifact that is tracking again the customers using how much where are they in my feet here a free trial, and then there's the usage foot friends and so it's really the backbone for sort of modern business models and business. Yeah.
And from a product perspective, like the metering data to me seems like it would be really really useful in understanding what parts of your product are resonating with your users, because that's one of the challenges of a startup is you build your product and then you have to figure out like one of the things I frequently say is, when you launch your product, you have to figure out what the difference between what you built and what the customers thought you built was
and closed that gap. And metering seems like, if done correctly, it's good to just point that out like a beacon. Totally correct. In fact, you know a little bit of a good segue. So, but the name Amber Flow, let me tell you how how sort of that came about.
I think your audience might find this intriguing. A so what I grew up or you know, for the time I was at WS, the way I sort of internalized, you know, when I got understood you know, meat ring and how we were building services, and then how we launched and the whole usage based business model, how it drove organic growth and adoption. The vision I had in mind is, you know, if you think about meter I guess we've talked about and we talked about that it is essentially an
event stream, right, But it's an event stream. Those events are really your points of gold. It's it's like a liver river of money that's flowing, right, because what is being used by whom, when, where how much? So the term amber flow comes from embers of the color of gold. By the way, amber is also the bright sky and sensfort and the flow is the river. So that's sort of how, you know, just
the concoction kind of came together, because that's really what it is. Metering is that river off your business, your goal, your money, your usage, and how can you operate without having without giving it it's too It's true diligence and resources and making sure that it's intact and scaling a yeah right,
I love that analogy. You can just reach down into the amber flow and scoop out however much you want, that's right, yeah, right so, And that's frankly, that's how it is with most you know, all cloud providers. It is this is the service that tracks and whether your product, service, customer team, they're all leveraging this this data set. Yeah, like the like the You've mentioned a couple times that most companies end up building
their own metering service because a service didn't exist. But I can only imagine the number of questions that you have to answer to get the metering service right. So in terms of amber Flow, like what's the what's an onboarding experience look like? There? What? What what is a potential user of amber flow need to know in order to onboard with amber Flow? Yeah, yeah,
I have a great question. So, uh, let me actually just I thought of something back to further sort of distinction, because I'm sure, okay, if you are an engineer product or engineering side, okay, you think you got but okay, I still have questions. Why cannot I still do it through monitoring? Why can't I ask it observably? Because you know, we grew up that way, right, So, and one of the things as well, you know, as humans, it's how's the best way
to say that? You know? Sometimes you know, we just like to think see things from the lens that we're comfortable with, right So we've grown up with so and you know what, That's just how it is. So anytime you're going to come across something new, you're going to right away try to see Yeah, but you know, do I really need it? Isn't
really that different. So there's a period of where anytime you launch something new, we as the company or the institution that is bringing that, you know, you have to be prepared to be misunderstood for some period of time. That's totally okay. And I think if you look back at any times. You know, also there's a great adage that I've read somewhere. You know, all inventions seem impossible until they're invented, and then they seem inevitable.
I just this one. I just you know, I lean on this quite a bit. I think that's just how things are. But anyway, so one of the things about metering is and also you know, answer our question, so how do we onboard customers and what they ask for? We do still get asked, Hey, look, I already have an ingestion pipeline.
You know, I'm doing it through logging, or I'm doing it through monitoring, I'm doing it through X, y Z, and fair enough, I can even try to get it so I can try to catch the attribution aspect of it, and I can have just this and whatnot. Here's the problem with that, and this resonates. See if we align on as we did, what the job of metering is to give you that insight what has been used by whome, whin, what where, how much? But also to
do it accurately and consistently. Okay, now let's work our way backwards to how we can guarantee that accuracy and the reason why. Then you need to have a separate meeting service. See from the time where the event originates that you wish to track, could be an IoT event, could be a system event, could be an EC two event, could be a storage event,
could be an API event. From wherever the event is originating, if the event has done multiple hops by the time it gets to your monitoring logging service, and then within that service it has done multiple hops, and then you say, yeah, I have the event, use it for pricing and building, you may be able to get by for a little bit until somebody on the other end says, I don't trust this bill. Tell me unpack the events that got me to this meter. Bill. Now you have a problem
because who is going to take ownership of that remediation. This is very typical. We see this all the time, and companies trick over this unfortunately, even after the fact that they've decided to go use in place pricing, and then until they encountered their first coutage or this first kick up, and then you scramble. You know, one person from finance, and one from accounting, and one from product and one from support and one from engineering. And
okay, what what happened? Well, we don't know what. We went to this system and then from this system, and when this system it came into the data warehouse, and then we did et L and then it went to relational and then we did this somewhere the event got dropped. You have lost lineage. Okay, if you have lost lineage your your you have you
cannot back credibility after the metering guarantees you that lineage. Therefore, the design thesis and the deployment model foring is with metering clus as possible to where the original event is originally get there event as strictly as directly into the metering services, and you eliminate these cops because guarantees you if somebody's offering the meeting service
as a as a as a product. After taking down with that page, walking through how you guarantee me accuracy you know some of the things that I'm out planning now that yeah, this is what we do. Yeah, so in the like in the past, we would we would do things like annotate the logs, you know, annotate them with a guid and that good could
be associated with a specific sequence of actions. But then even whenever it comes time, like you said, to prove it, you have to go to all of these disconnected systems and search for that guid and and hope it was there and that you know, nothing, nothing happened, and that it's it's able to be stored in a format where you can parse and search by that.
And so the mating service is a completely different shift, so that it's an external thing, that its sole job is to just store that data so you don't have to try and annotate it at every piece of your infrastructure along the way, exactly. And you do it once and you're set for life. And because therefore the reasons why and then again you know why you went down the path of guid and all that, and why you didn't think of
a meeting service because the business demand was not there. You know, maybe once in a while that request came out, right or once in a while, you know, and then it was really more engineering request and a support request rather than a customer accounting revenue rec issue. Right that has to be you cannot just charge somebody around the amount that is just in fact, you know, we get called out for that, right that's you know, so
you know you have to do accurate billing. You can only charge for for what is out to you. So you know, those are federated, you know, federally mandated statutes. So therefore, now there's this onus that is coming down to product in engineering teams. This may not be just a one off thing that we might hear once in every six months or something, and it's okay, we can scramble some resources and do that, you know. I mean, some customers might just want to ask, hey, I give
me visibility into did I actually use this much? And amber Flow system will give you the full lineage of the entire meter bill, track it all the way back, and you want to send them a list of those events that aggregated into the invoice. Have at it. It's right there at your disposal right on. That's cool. That's cool. And so I'm assuming that Amberflow,
the pricing model of that is a metered service. Yeah, so you know we do, like I said, you know, so we have We're proud of this fact, the world's most rich, full feature fully managed cloud metrink service at scale. Yeah, we're proud of the fact, you know, one of our larger customers today already sending US four billion meter events a day. Okay, And because they get it, like you know, they are shifting lock stock and barrel everything their entire product portfolio to usage based pricing
and billing. It starts with accurate metering. Accurate accuracy is key. So events come into Amber flow raw events, they get aggregated, they get sliced over timestream, and now you have a system of usage or what is being used by whom, when, what wear how much? So that is our metering service. We view a meeting service as a platform, horizontal platform service, and then on top of that we offer you what we call our billing cloud, which is what we consider an application that sits on top of the
metering platform. Our billing cloud then gives you all the customer facing artifacts for you to build flexible usage based pricing plan. You want to charge on APIs, you want to charge on a peered model, you want to and then charge on prepaid, you want to charge on commits, you want to do promotions, discount and our billing cloud then generates on demand real time metered invoicing and building. So that's how the platform comes together. Wow, that's cool.
That's super impressive. Yeah, and you know it's taken a while, you know, and therefore, like you know, we started talking about three years in and you know, we were at least for about a year and a half just in core development. I mean, this is something that uh credit to my early investors. We were front with them about this that he as I was selling yearly about sort of the Silken Valley story that you know, this is not a fly light night thing, you know, and not
in four months. You know, don't don't come asking us, you know, what is the arr It's going to take us a while to be and you know this is you know, this is like, ah, I'm really kind of wrapped up around this because I think a lot more in a could be happening as I think if it's just the Silkon Valley was perhaps a little bit more open to It takes time. It takes time to build something that
is differentiated, that is sustainable. And I say that again you know, look that's the GM for Amazon Cloud Search, one of the services, and then later our team also launched Amazon Elastic Search, which is now called Amazon open Search. Cloud Search took two and a half years to build before we saw the light of day, before we got a first data customer. Wow, that's an Amazon scale will Yeah. Red Shift my good friend, you
know, and Ra Gutta who is also running a startup. Red Shift to over three years before it saw the light of day, and you know, and therefore these are now multi billion dollar businesses and sid ws. You know, you want to think you want to do something big, it takes time, you know that, it takes time to think this thing through and build that full set of capabilities that will be differentiated, that will be meaningful.
So anyhow, so that's sort of been our story of glad to say that we found alignment in the lester that we got who understood and I was willing to play a little bit of a different, you know, playbook than the traditional is great. Up. Yeah, congratulations for sure on that, because that is not your average investor who's willing to invest for a long investment or
a long payoff like that. It's it's something we've gotten spoiled with over the last I don't know, twenty years, and I think I think that's very short sighted. Like you mentioned, you know, some of these products take a long time to build, and you you have to be very disciplined and focused in what you're trying to build to commit to holding back the release date until you have the product that does what you know it should be doing.
That's right, bro. Yeah. And you know, and I think especially in tech, particularly in software, right because you know, there are a few things that if you don't get it right from the outset, you just
cannot go back and revisit. Right. You know this better than anybody else, right, So that is the thing, And that's why it's a combination of you know, right, environment, support from leadership, because if you feel pressure to just go, I gotta logic, I raise money, I gotta go and start showing some R and forty six, you're gonna shortcut on those choices, yes, and you can never go back and revisit them.
And one of the things that we wanted to do, I know, I'll share this sort of with your audience a little bit of our sort of internal ip and thesis. So you know, we talked about the whole lineage of the events and all of that. Right now, you know what, well, so well, I've given you the pictures. I'm offering as a vendor a metering service, right, And it's basically a like anw quote unquote black box. Yeah, I guarantee you send me the raw event and outcome.
I'll send you the aggregated view, and we are the system of record and you can lean on my service and you can hold us accountable for the accuracy. Okay, we make that guarantee. Now, if you are for a moment inside my company and you're in our product and engineering discussion as well,
we still have the same problem to solve internally, right. I mean, if if my architecture is ten different things and things are going, you know, there's different artifacts, I still have to manage this lineage and an audit trail of the event. So what is that architecture? Right? And uh? And that's why you know, having the right ecosystem partners, investors,
team technology, product and engineers, it's really that unique combination. So what else share with you is, look, you know you can put some very smart engineers together and say hey, let's go a detective metering service. Right now, you come from technical background and say, okay, so what is a metering service? Well, it's an invent ingestion system. So I'm going to need a cofa Okay, so let's put a coffea in place. Well, there's data flowing and so I'm going to need a data warehouse, Okay,
so let's let's put that in place. Well, there's some state management and then there's a few other things that I'm going to have to kind of connect. So I'm going to need to have a relational database work sort of quick response. I'm going to put a relational database in place, okay, and you know, and you would come up with a pretty good meterrink service. Well, I can share with you that we don't use any of that, and there's a reason for it, right And it's not just you know,
put a chick on my shoulder. But what is it that you are after? What is it that you're designing? So this is what I'm referring to. What is the quartino? Is that design? He says, what is your ultimate long term goal? Our ultimate long term goal is what I've already applied with you and your audience that you know we we are going to be the metrink service with this, you have a metrinks need for a metrink
service. I am telling you right now and if I fall short of this, you can just callow me out of anyone of your audiences going to write to me, we are going to be the best most features, the best price performance metrince service you can find on this project. Yeah, you know your your passion in that when you were when you were talking about that, just like your passion just like really came through and it was that was very very cool to see because there's no disputing, like you can just hear it
in your voice. There's no disputing what you said. You can just tell that you believe it with every cell in your body. But another thing that stood out to me there was one of the challenges a lot of companies face is your engineers building your product have to actually use that product to see it as your customers would see it. But that's just built into your business model, Like you are one hundred percent dependent on your own product for success as
a company because that's yours. You know, it's not only how you make your money, but it's how you bill your customers to make your money. That's a that's again a very astute observation on your part. One hundred percent yes, by the way, and this was also something that was part of the excitement of starting this company. You know, I thought this to, hey, we're going to be amber Flow and Amberflow that's how we call it. So uh and you know, I'll also sort of connect to that squad
again, one of those things very obvious. Maybe some companies just kind of lucky in that regard, but I'll tell you where that awareness was there even before starting the company. It's easy to say, oh, we knew that, but I'll actually even bring some credibility to that. When I got hired into AWS back in twenty eleven, we were my charter was to build Amazon
cloud Search, which arguably was probably our first quote unquote pass service. Everything else was infrastructure you think about it, red compute storage, you know, e C two. So search is a little bit a little bit further up the stack. And so cloud Search, internally we were referring to cloud Search was sort of the first pass service built natively, that was built first past
eight WS service that was built using a WS. Okay, so underneath cloud Search maybe different now, but you know, back in the day, I think we were using travel thirteen different eight WS services to build that. That's why's going on behind the scenes and cloud search. So this concept of you
know, uh, first AWS service using AWS. Uh you know, so I had some awareness that and the same thing here so Amber phone, amberfo, we are we started a day with our own daily dashboards that are being delivered to us from my Metrix service on what has been used by whom then want to wear how much from our customers? Oh that's so cool. And
just to comment on open search real quick, I was. I was very excited when that product released because I had spent years prior to that managing my own elastic search clusters and you know, running the JA the JMX metrics, monitoring the heap stack, waiting for that node to crash so that I could detect it and replace it, and then trying to avoid the split brain and maintain availability so to be able to just pay AWS money to get out of
that business. I I couldn't hand over my credit card fast enough. Go Yeah, yeah, I know. That's you know, that's been the foundation for any of the service. I mean, that's one of the template at AWS and and other cloud providers, right open source and then basically wrapping it into the cloud ecosystem right on. Yeah cool, Well we are just crossing an hour here. So if if our listeners are interested in learning more about metering or want to get in contact with you, what kind of resources have
you got for them? Yeah? Sure thing, Well, so best decided tote you to just land on our website dot amberflow dot io and a lot of information there. We have a full set of documentation docs that are available to you. You can ready quit the unpack. What are these artifacts? What are some of the design patterns? How to engage with them? But please you know, as you're on the website, look around, drop us
a note. Love to connect with you if you are thinking about usage based pricing and building those things attached, I'm always happy to compare, share some notes lessons learned if you're already down the path of usage based pricing and building. Happy to compare some notes if you're running into some friction areas and how you might streamline it. But yeah, welcome you to come back on a website. Awesome. Well, this has been a really exciting conversation for me.
It's been insightful, eye opening, and I've really enjoyed it. So thank you for taking the time out of your day to join me here. Oh my pleasure Will. It was very exciting for me, just I'm just kind of went by, all right. Thank you and thanks for listening everyone, and we will see all in the next episode.