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.