WEBVTT 1 00:00:14.320 --> 00:00:18.679 Hey, what's up everyone. We are live on another episode of Adventures in 2 00:00:18.960 --> 00:00:23.440 DevOps. I'm your host today, Will Button and joining me in the studio, 3 00:00:23.879 --> 00:00:29.800 Punit, Gupta and Beat. I like, one of the things I 4 00:00:29.879 --> 00:00:34.840 like instantly about this is you've said that your professional work and your personal hobbies 5 00:00:34.920 --> 00:00:39.320 collide, which is exactly how I ended up doing this. You know. 6 00:00:39.320 --> 00:00:44.679 I remember way back in my career someone was like, hey, can you 7 00:00:45.039 --> 00:00:47.880 fix this server for me? Or can you build this website for me? 8 00:00:47.920 --> 00:00:50.520 And I'm like, yeah, sure, here you go, and then they 9 00:00:50.560 --> 00:00:52.840 said great, thanks, what do I owe you? I was like, 10 00:00:53.079 --> 00:00:58.039 wait, I can make money doing this, and you know, thirty years 11 00:00:58.079 --> 00:01:02.280 later, here we are. Yeah. So, Perni, welcome to the 12 00:01:02.320 --> 00:01:07.200 show. You are the CEO and co founder of amber dot Io. Right, 13 00:01:07.959 --> 00:01:11.760 Amber Flow, Amber Flow. Sorry, that's the beauty of doing live 14 00:01:11.920 --> 00:01:17.040 is now all of a sudden everyone gets to hear how often exactly I screw 15 00:01:17.079 --> 00:01:23.280 up in these podcasts. So tell me a little bit about your background, 16 00:01:23.319 --> 00:01:27.439 how you ended up starting your own company. Which is three years in for 17 00:01:27.560 --> 00:01:32.719 a startup, which is kind of like a significant milestone, like if you 18 00:01:32.760 --> 00:01:38.200 make it past a three year point, things start to get you get a 19 00:01:38.239 --> 00:01:41.920 little confidence at that at that stage. Yeah, no, sure thing. 20 00:01:42.560 --> 00:01:45.439 You know, great to be with you. Thanks for having me on your 21 00:01:45.439 --> 00:01:49.640 show, come forward to it and yeah maybe I just you know, by 22 00:01:49.680 --> 00:01:53.280 the ways of introduction, and I think you can. I love to also 23 00:01:53.359 --> 00:01:56.560 unpack, you know how sort of the hobbies and brooklit. I have my 24 00:01:56.599 --> 00:02:00.120 own story there and you know it's kind of evolved over over a period of 25 00:02:00.120 --> 00:02:05.519 time. But yeah, just by the rays of sort of quick background, 26 00:02:05.519 --> 00:02:08.159 you know, Amber float dot io we enabled businesses to charge and track on 27 00:02:08.280 --> 00:02:14.080 usage that we provide a cloud meeting and usage based pricing and building platform. 28 00:02:14.400 --> 00:02:15.639 I'm sure we'll have a chance to dive into that a little bit more. 29 00:02:17.439 --> 00:02:22.639 And uh yeah, Amber flow at io. We're now about three years in 30 00:02:23.199 --> 00:02:25.840 and the company was started actually I think what was being called for a period 31 00:02:25.840 --> 00:02:34.039 of time, born in the COVID. So we're one of those and I 32 00:02:34.039 --> 00:02:38.000 think you know that's uh, that's a good part of our story. Uh. 33 00:02:38.560 --> 00:02:42.479 And what that means is when we started the company, we were in 34 00:02:42.560 --> 00:02:50.159 the lockdown back in forty twenty and we raised a seed round. We we 35 00:02:50.199 --> 00:02:53.439 did not get to meet our investors face to face for about another year. 36 00:02:53.560 --> 00:02:58.000 The whole round was done on zoom online. Oh wow, you know, 37 00:02:58.599 --> 00:03:05.159 so uh some interesting you know artifacts and built of that lockdown era. But 38 00:03:05.439 --> 00:03:08.680 you know, the lockdown I think served in some unique ways, interesting ways 39 00:03:08.840 --> 00:03:15.759 actually beneficial to start up like us. So anyways, there's stuff there. 40 00:03:15.800 --> 00:03:19.560 But yeah, the company is about three years old. We're nure Back. 41 00:03:19.599 --> 00:03:23.240 We raised two rounds of funding, a seed round, and then earlier this 42 00:03:23.319 --> 00:03:25.360 year we had raised in the around, so we've got about twenty million dollars 43 00:03:25.400 --> 00:03:29.400 in funding. But yeah, like you said, you know, after a 44 00:03:29.439 --> 00:03:31.919 good start, after a decent start, a lot of things have to connect 45 00:03:32.319 --> 00:03:36.120 in the journey of a startup, especially early. As you called out, 46 00:03:36.599 --> 00:03:38.840 you know, you had three years in I think, you know, there's 47 00:03:39.520 --> 00:03:44.879 a momentum building. We'd like to say we're seeing some tailwinds on our backs, 48 00:03:46.039 --> 00:03:47.960 and I extributed that, you know, just feel good, healthy combination 49 00:03:49.039 --> 00:03:51.520 of you know, maybe a few things that we got right, but also 50 00:03:51.560 --> 00:03:55.560 a lot of things that the market is that are happening in the market organically, 51 00:03:55.680 --> 00:04:01.280 markets turning in this direction, and we're definitely benefit from that. Right 52 00:04:01.319 --> 00:04:05.159 on. Yeah, you know, I've spent pretty much my entire career working 53 00:04:05.199 --> 00:04:11.800 for startups, and one of the things that I've learned about startups in that 54 00:04:11.879 --> 00:04:16.879 period is that for most of the startups that are successful in the long term, 55 00:04:17.199 --> 00:04:23.160 the product that makes them successful is not actually the product that they start 56 00:04:23.199 --> 00:04:27.439 with. And I love using the aviation industry as an example of this because 57 00:04:27.480 --> 00:04:32.639 it's it's something that's a new enough industry that we can kind of visualize what 58 00:04:32.680 --> 00:04:36.120 the beginnings were like, but it's also been around long enough that we can 59 00:04:36.199 --> 00:04:41.839 see what happens at scale over time, you know. And if you think 60 00:04:41.839 --> 00:04:46.680 about like when the Wright Brothers launched their first airplane and was it like nineteen 61 00:04:46.680 --> 00:04:53.839 oh three, I think they probably didn't have any idea of what modern aviation 62 00:04:53.959 --> 00:04:59.639 would look like and how it's iterated and how it's just impacted everyone. So 63 00:04:59.680 --> 00:05:03.279 they had to in the industry as a whole, had to pivot along the 64 00:05:03.279 --> 00:05:08.560 way. So have you seen that in your company, Like what was your 65 00:05:08.600 --> 00:05:13.879 initial idea versus what's what's working for you right now? Yeah? You know 66 00:05:13.959 --> 00:05:16.199 that's uh, yeah, You're gonna take us down a little bit of from 67 00:05:16.199 --> 00:05:21.759 memory lane and also a little bit of sort of the founding founding pisis that 68 00:05:21.839 --> 00:05:28.040 we had, which uh, you know, which was I guess it's still 69 00:05:28.079 --> 00:05:33.319 obviously pan out, but I want to say it's somewhat contrariant to the typical 70 00:05:34.399 --> 00:05:40.600 startup lends that perhaps you might see outside and looking inside Silicon Valley. So 71 00:05:40.680 --> 00:05:43.600 yeah, let's let's go into that. And now I'll certainly index on that. 72 00:05:45.680 --> 00:05:47.800 So, uh, you know, we'll talk a lot a lot about 73 00:05:47.800 --> 00:05:49.720 you know, like like I said, you know that we feel that the 74 00:05:49.759 --> 00:05:54.879 world is shifting. There's a there's a change in business model. Uh how 75 00:05:55.399 --> 00:06:00.720 in the business models of businesses, right, so monetization model, how companies 76 00:06:00.759 --> 00:06:03.279 are increasingly selling their products and service. They're shifting to what we call a 77 00:06:03.439 --> 00:06:09.959 usage based model versus a seat base. And that's a foundational shift. Like 78 00:06:09.959 --> 00:06:13.680 I like to say, business models don't change very often. Well, you 79 00:06:13.720 --> 00:06:16.040 know, and we can. We can look back from the dawn off software 80 00:06:16.240 --> 00:06:18.759 you know whatever that is sixtally seventy years ago. I think at best, 81 00:06:18.800 --> 00:06:23.680 maybe if you had one people refer back to the subscription model, and I 82 00:06:23.680 --> 00:06:27.800 would even challenge that. I think there was more financial optics change rather than 83 00:06:27.839 --> 00:06:32.839 a full on technology business model change. This one is going from something that 84 00:06:32.920 --> 00:06:38.560 was fixed and recovering to a full on metered usage based model. That's the 85 00:06:38.639 --> 00:06:43.920 foundational shift. Okay, how does sort of this play back to, you 86 00:06:43.920 --> 00:06:48.000 know, how we looked at things and how things have evolved. So what 87 00:06:48.079 --> 00:06:51.399 I was referred to earlier, I don't know. I you know, I 88 00:06:51.480 --> 00:06:56.399 maybe off, but I think generally one of the things that has sort of 89 00:06:56.480 --> 00:07:00.240 been less exciting in the world of startups and Silicon Valley is I think there's 90 00:07:00.240 --> 00:07:05.360 sort of this templatized approach where go pick find a niche you know, almost 91 00:07:05.399 --> 00:07:12.319 like a feature. Maybe the transition point is that it already existed on prem 92 00:07:12.360 --> 00:07:15.480 and you figure out a way to deliver it in the cloud, and you 93 00:07:15.560 --> 00:07:17.319 put the company and a product behind it, and off you go. And 94 00:07:17.600 --> 00:07:20.480 then it's a race to ar R and m r R and then you know, 95 00:07:21.240 --> 00:07:26.360 in ten years you aim to get two hundred million in ARR and yourself 96 00:07:26.399 --> 00:07:30.519 a couple of billions in Kumbaya. Okay, that's and obviously you know, 97 00:07:30.600 --> 00:07:33.639 nothing wrong with that. I mean, you know that itsell takes you know, 98 00:07:34.480 --> 00:07:40.279 sweat and blood and whatnot. Our view is slightly different, you know, 99 00:07:40.360 --> 00:07:43.680 we just we dreamed to imagine a little bit bigger than that, and 100 00:07:43.879 --> 00:07:46.240 some of that was just a function of what we saw. So I think, 101 00:07:46.240 --> 00:07:48.800 you know, maybe I'll put some credibility into the statement you're looking across, 102 00:07:49.079 --> 00:07:51.439 you know, across the screen. You know, I'm a little bit 103 00:07:51.439 --> 00:07:55.480 of an old hand at technology. I've been around the block. It's just 104 00:07:55.519 --> 00:08:01.519 as you have twenty five years under my belt and before I decided to drop 105 00:08:01.560 --> 00:08:05.079 everything and go do the startup, so it wasn't just trying to chase a 106 00:08:05.120 --> 00:08:07.759 wave. And this is what we're doing here at Amber Flow. I call 107 00:08:07.800 --> 00:08:11.879 it sort of as a labor of love because it's all passion driven, it's 108 00:08:11.920 --> 00:08:16.079 all vision driven, and this is kind of going into them the question you 109 00:08:16.160 --> 00:08:22.279 asked. So we first saw that we like, this is sort of in 110 00:08:22.319 --> 00:08:24.720 the fullness of time. So already, you know, kind of taking a 111 00:08:24.759 --> 00:08:28.680 long term view, and the fullness of time is at least five years out, 112 00:08:28.800 --> 00:08:31.199 more like ten years out, you know, if you want to talk 113 00:08:31.199 --> 00:08:33.000 about you know, THESS ten years out. That's the comfort zone for me. 114 00:08:33.159 --> 00:08:37.320 So because as we said, if there's a shift in the modernization business 115 00:08:37.320 --> 00:08:41.519 model, this is going to play out over a period of time, you 116 00:08:41.559 --> 00:08:43.919 know, and then the going in and flip a switch and change a business 117 00:08:43.960 --> 00:08:50.480 model is going to ripple through every functional area of your business, and maybe 118 00:08:50.200 --> 00:08:54.039 the confidence comes from you know, personally, I've been a little bit lucky. 119 00:08:54.039 --> 00:08:58.720 I've spent some time at AWS at Amazon. I think it's one of 120 00:08:58.720 --> 00:09:01.600 the companies that is credited and known for some long term thinking, and I 121 00:09:01.639 --> 00:09:05.159 think it's it's evident for how they have played out the last in a couple 122 00:09:05.200 --> 00:09:09.480 of decades. So got to be you know, in that environment, so 123 00:09:09.639 --> 00:09:15.440 comfortable with that thinking process. I think maybe I've drawn like contiments from there, 124 00:09:16.080 --> 00:09:18.200 and then a function of I think what we see in the market, 125 00:09:18.279 --> 00:09:20.720 like if this is the change that's happening, then well there is a lot 126 00:09:20.759 --> 00:09:26.519 of opportunity here over the next part. So that is the starting point. 127 00:09:26.600 --> 00:09:28.879 Now it goes to your question. Okay, so if that's how we're looking 128 00:09:28.919 --> 00:09:31.639 at it, then we still have to build a business. We still have 129 00:09:31.679 --> 00:09:35.600 to go to market. So then what is the launch pad? But we 130 00:09:35.639 --> 00:09:39.480 are looking at it from that lens. We have a very specific, well 131 00:09:41.759 --> 00:09:45.919 understood or well projected view of the long term. We're here in this for 132 00:09:46.000 --> 00:09:50.600 the long term five years out. We see a technology stack. I think 133 00:09:50.639 --> 00:09:54.000 that's going to evolve, that's going to adjust, that's going to commulate, 134 00:09:54.600 --> 00:10:01.159 and we see tremendous levels of opportunity for am flow. The play into that 135 00:10:01.240 --> 00:10:05.600 transition starting point is you know, as a startup you kind of have to 136 00:10:05.639 --> 00:10:11.360 gravitate where at least in the narrative is so you can make the dots fine 137 00:10:11.440 --> 00:10:15.960 product market fit and you know, start to build the business and start to 138 00:10:16.639 --> 00:10:22.440 and Okay, so for us, the big opportunity that we saw was in 139 00:10:22.519 --> 00:10:33.279 building a new platform technology artifact that we called metering. However, not many 140 00:10:33.360 --> 00:10:37.759 folks, at least three years ago we're talking much about metering. Oh for 141 00:10:37.799 --> 00:10:41.960 sure. Yeah, it's a brand new concept to me. Yeah. Right, 142 00:10:41.000 --> 00:10:43.879 So so there you go. Right, so somewhat ourthog, I mean, 143 00:10:43.960 --> 00:10:50.120 we are motivated by what metering is and what metering can do today and 144 00:10:50.240 --> 00:10:54.600 out five years and ten years. That is really what gets up us up 145 00:10:54.600 --> 00:11:01.879 in the morning. And usage based pricing and building is then simply an artifact 146 00:11:01.519 --> 00:11:07.080 is sort of a means to an end if you view right. So it's 147 00:11:07.120 --> 00:11:11.320 just one of the benefit forwards of me drin. If you want to get 148 00:11:11.399 --> 00:11:13.120 you like to say, you know, if you want to get usage based 149 00:11:13.159 --> 00:11:18.240 pricing and building right, you must first get metering. Right, So that's 150 00:11:18.240 --> 00:11:22.039 sort of our view. So we we spend really sort of the first year 151 00:11:22.240 --> 00:11:26.120 of our existence just hits down nothing but building the metering service. And metering 152 00:11:26.200 --> 00:11:30.360 is a heavy lift part if it is not that well understood, as you 153 00:11:30.399 --> 00:11:33.879 said, you know, called out, they're not that many blueprints of how 154 00:11:33.919 --> 00:11:37.000 they effectively build a metrink service at scale. Uh, what are some of 155 00:11:37.039 --> 00:11:41.519 the design tenets and pieces? As it is a heavy lift. We spend 156 00:11:41.519 --> 00:11:46.320 a year building a metering service, then we layered an application on top of 157 00:11:46.399 --> 00:11:52.759 metering that people building out the usage based pricing and billing, and that's a 158 00:11:52.840 --> 00:11:56.840 little market motion today. So we feel that this approach we're going to continue 159 00:11:56.879 --> 00:12:01.960 to expand we don't consider ourselves a single product company. We're going to be 160 00:12:01.000 --> 00:12:07.759 a multi product company. YI is fire design and that's the foundation we make 161 00:12:09.159 --> 00:12:11.919 right on. So help me understand what like if I if I want to 162 00:12:11.919 --> 00:12:16.360 think about things from a metering perspective, what am I am I looking at? 163 00:12:16.480 --> 00:12:20.240 That? Does that translate to like figuring out how to spend or how 164 00:12:20.279 --> 00:12:26.559 to how to track how much time someone spends in my application or what actions 165 00:12:26.559 --> 00:12:33.519 they're taking and turning that into a monetized metric. That is precisely that, 166 00:12:33.559 --> 00:12:37.039 but there's more to it. Okay, so that is certainly so, so 167 00:12:37.120 --> 00:12:41.000 think of metering, you know, it is really sort of the spised army 168 00:12:41.080 --> 00:12:45.559 knife. Actually, don't even take a step back. So one is you 169 00:12:45.559 --> 00:12:48.240 know, why isn't there that much level of awareness. I mean we're about, 170 00:12:48.240 --> 00:12:52.879 you know, ten fifteen years into the Clower journey and you know we're 171 00:12:52.919 --> 00:12:54.039 now talking about Yeah, okay, I've heard of it, but you know, 172 00:12:54.720 --> 00:12:58.919 but yeah, let me sort of comfortall circle and then you know, 173 00:12:58.120 --> 00:13:03.600 we can unpacked out of the Swiss army knife. You know, why is 174 00:13:03.639 --> 00:13:07.360 this such a poor piece? First? I'll maybe just start off by some 175 00:13:09.200 --> 00:13:13.679 against some evidence. If you look at all the companies out there today who 176 00:13:13.679 --> 00:13:16.120 have achieved a level of scale in the cloud, and of course I'm not 177 00:13:16.159 --> 00:13:20.000 just talking about the three four large cloud providers, but you know, the 178 00:13:20.000 --> 00:13:24.240 next batch of companies like Twilio, Data Breaks, Mango, a Snowflake, 179 00:13:24.360 --> 00:13:28.000 right, and then increasingly on. I think, go and study those companies, 180 00:13:28.000 --> 00:13:33.600 you'll find that they have over time built and in house metering services. 181 00:13:35.039 --> 00:13:37.480 So what I'm getting at is, you know, once you find that you 182 00:13:39.039 --> 00:13:41.960 are native in the cloud. You're achieving a level of scale in the cloud 183 00:13:43.039 --> 00:13:48.720 you cannot do without this construct. And I would even profess to go as 184 00:13:48.720 --> 00:13:50.039 far as saying that I think they, perhaps many of them, if not 185 00:13:50.120 --> 00:13:54.480 all of them, discovered this after the fact, and then they hurry to 186 00:13:54.519 --> 00:13:58.759 kind of get this instrumentation, this metering infrastructure put in place, and most 187 00:13:58.799 --> 00:14:01.639 of them have built themselves. By frankly, there wasn't one available off the 188 00:14:01.639 --> 00:14:05.200 shelf at the time, right, So what is it? Right? This 189 00:14:05.240 --> 00:14:09.480 thing about metering, well, metering the term of course we all grew up 190 00:14:09.480 --> 00:14:11.600 with. I mean, it's the utility meter that's on the back of our 191 00:14:11.600 --> 00:14:16.559 homes. You know, it's metering our usage. So there you go, 192 00:14:16.120 --> 00:14:20.480 usage metering. But but let's take a step back. So why is it 193 00:14:20.600 --> 00:14:26.120 such an important construct in cloud and why has it gone unnoticed for so long? 194 00:14:26.799 --> 00:14:35.519 Okay? First is, you know, let let's look at We all 195 00:14:35.559 --> 00:14:37.000 know cloud is elastic. Okay, that's you know, that's a no brainer. 196 00:14:37.000 --> 00:14:41.200 Everybody understands that, which basically means that you can dial up and dial 197 00:14:41.279 --> 00:14:50.679 down your back end resources or resources. Okay, Then the question is, 198 00:14:50.720 --> 00:14:56.080 you know, if the back end is elastic, if I'm building in the 199 00:14:56.080 --> 00:15:00.600 cloud, which in the fullness of time, everybody is h and you are 200 00:15:00.639 --> 00:15:05.039 building on a foundation, you know, foundation platform that is elastic you know, 201 00:15:05.480 --> 00:15:09.240 I almost almost envision like a you know, sort of a quicksand like 202 00:15:09.279 --> 00:15:11.960 you know, it's it's a you know, it's a it's a little bit 203 00:15:11.960 --> 00:15:15.000 wobbly, right, it can go up and down, right, it can 204 00:15:15.039 --> 00:15:20.960 shift. Okay, So how do you tame elasticity because eventually you're going to 205 00:15:20.000 --> 00:15:30.039 have to build something that is solid. So usage elasticity and the artifact to 206 00:15:30.159 --> 00:15:33.639 tame elasticity is metering. Okay, So what is metering? By definition? 207 00:15:33.759 --> 00:15:39.600 Metering is metering tells you what is being used by whom? Then? What 208 00:15:39.720 --> 00:15:43.799 were how much? That's it put a box around it, right, nothing 209 00:15:43.840 --> 00:15:48.360 to do with pricing and building. Just yet, what is used in my 210 00:15:48.440 --> 00:15:52.080 cloud infrastructure by whom? When? What weear? How much? That is 211 00:15:52.120 --> 00:15:56.840 the job of a meeting service. It is the owner of that construct, 212 00:15:56.919 --> 00:16:02.519 meaning it is the source of true It is the system of record for what 213 00:16:02.639 --> 00:16:06.200 is being used by whom? When? What were how much? You have 214 00:16:06.279 --> 00:16:08.960 to if you wish to scale and build a company in the cloud, you 215 00:16:10.039 --> 00:16:15.720 have to treat this box as sacro sancta. You cannot you know, this 216 00:16:15.799 --> 00:16:18.879 is not a data leg or a data warehouse or a munget with this, 217 00:16:19.080 --> 00:16:22.279 or can I throw this in there? Or can I throw that in there? 218 00:16:22.639 --> 00:16:27.879 You need to get this right, because if you don't and you try 219 00:16:27.919 --> 00:16:33.440 to do it through some other ways, then inevitably, when somebody asks that 220 00:16:33.559 --> 00:16:37.399 question inside your company, and it will come from all functional areas, different 221 00:16:37.440 --> 00:16:41.480 function areas, what is being used by whom? Sales wants to know, 222 00:16:41.840 --> 00:16:45.120 Product wants to know, Engineering wants to know, Support wants to know, 223 00:16:45.240 --> 00:16:48.000 Finance wants to know, Accounting wants to know when they're going to ask that 224 00:16:48.080 --> 00:16:52.679 question if they ask a follow up question, Hey, is this data accurate? 225 00:16:53.399 --> 00:16:59.039 My friend? You do not have a meeting service in place. Therefore, 226 00:16:59.120 --> 00:17:03.559 all of these companies over time woke up to the fact that, you 227 00:17:03.559 --> 00:17:04.599 know, we got to solve this. We got to solve this once and 228 00:17:04.640 --> 00:17:08.119 for all, and there needs to be a system of truth system a record 229 00:17:08.160 --> 00:17:14.000 for consumption data, for usage and consumption data that I can tap into, 230 00:17:14.160 --> 00:17:17.960 and there should not be a following up question is this accurate or is this 231 00:17:18.039 --> 00:17:23.920 correct? Right? And the reason why you can then tackle that question because 232 00:17:25.200 --> 00:17:27.559 then you you know because you treat it as a separate artifact, You give 233 00:17:27.599 --> 00:17:33.079 it due diligence, you put the right infrastructure. You're not trying to balance 234 00:17:33.119 --> 00:17:37.880 it as a combination of observability or monitoring or logging or throwing it into a 235 00:17:37.920 --> 00:17:41.440 data lake and trying to you know. So we can also untage a little 236 00:17:41.440 --> 00:17:44.839 bit more on the architecture side, but that is the starting point. So 237 00:17:44.920 --> 00:17:48.160 you are an elastic back in infrastructure. The only team elasticity is to put 238 00:17:48.240 --> 00:17:52.440 meuterrain in a place so you can see what is being used by hum when 239 00:17:52.559 --> 00:17:56.920 work how much. Now for companies who have been in the cloud for a 240 00:17:56.000 --> 00:18:00.240 while, as we say, sort of in this fullness of time, you 241 00:18:00.279 --> 00:18:03.759 will find and then what is this genesis of usage based pricing and venting? 242 00:18:03.839 --> 00:18:07.200 Companies are discovering that you know, if my back end is elastic, its 243 00:18:07.880 --> 00:18:14.359 down usage. My front end also has to be elastic. What I mean 244 00:18:14.400 --> 00:18:18.640 by that my front end is how then you sell your products and services also 245 00:18:18.640 --> 00:18:23.000 will need to be elastic so that you can align your front end use your 246 00:18:23.000 --> 00:18:29.759 back ends uh infrastructure. And that's basically the cloud, well, I mean 247 00:18:29.759 --> 00:18:34.440 the optics of the cloud. So that is what led to usage based pricing 248 00:18:34.480 --> 00:18:37.519 in the first place. You know, it is a heavy left. You 249 00:18:37.599 --> 00:18:41.400 have to put this instrumentation in the place. Uh, there's a lot of 250 00:18:41.039 --> 00:18:45.920 you know, product and engineering work. So unlike traditional seat based pricing plans, 251 00:18:45.960 --> 00:18:49.640 right just after the fact, come up with some arbitrary number that's high 252 00:18:49.720 --> 00:18:53.759 enough that gives you a margin ratio. Okay, but off you go. 253 00:18:55.200 --> 00:18:56.799 No, here, you have to do this instrumentation. You'll have to know 254 00:18:56.880 --> 00:19:02.559 what is what is it that you're continuing in the back customers and consuming on 255 00:19:02.599 --> 00:19:10.400 the front, and the alignment and that disability needs to be there. I 256 00:19:10.440 --> 00:19:14.119 gotcha. I kind of feel like there's a light bulb going off over my 257 00:19:14.240 --> 00:19:18.000 head because this is a problem that I faced at several of the startups that 258 00:19:18.160 --> 00:19:22.559 I worked with, where we have our infrastructure and we tracked you know, 259 00:19:23.160 --> 00:19:30.680 monthly active users and then have the question posed to us by the next round 260 00:19:30.720 --> 00:19:36.799 of investors of you know, does this scale? What is your your revenue 261 00:19:36.799 --> 00:19:41.839 and your profit margin look like at that scale? And to be honest, 262 00:19:41.000 --> 00:19:45.240 in many cases we just took a wild guest and said, oh yeah, 263 00:19:45.359 --> 00:19:51.359 it's it's definitely scales and margins will look like this. But metering is actually 264 00:19:52.039 --> 00:20:00.000 the simple math calculation that allows you to accurately predict what your infrastructure cost will 265 00:20:00.000 --> 00:20:04.599 be at a given level and what your prices have to be at that point 266 00:20:04.640 --> 00:20:08.480 to be turning a profit totally. Well, in fact, you know, 267 00:20:08.920 --> 00:20:11.680 just for your audience, I don't even take my word for it, I 268 00:20:11.720 --> 00:20:17.599 think you they will find credibility in this. You know, one of the 269 00:20:17.599 --> 00:20:22.920 the hidden sort of the secrets of the success of AWS. Certainly the pioneered 270 00:20:23.000 --> 00:20:30.839 leader in the cloud is on the backs of the metering service, right. 271 00:20:30.880 --> 00:20:33.880 I mean, if you know, I was there in the early days as 272 00:20:33.880 --> 00:20:36.319 a GM, had a chance for the team to build and launch a couple 273 00:20:36.319 --> 00:20:44.160 of tier run WS services. This you're not running a cloud business unless you 274 00:20:44.200 --> 00:20:47.720 have a meting service out putting this data on a daily basis, pretty much 275 00:20:47.720 --> 00:20:51.880 on a real time basis. And that is what I'm you know, why 276 00:20:52.279 --> 00:20:56.279 the company continues to grow and was on such a rapid pace of innovation. 277 00:20:56.960 --> 00:21:02.920 Let me actually give another anecdote between pirical data for your audience. So I'd 278 00:21:02.960 --> 00:21:06.720 like, you know, for all these folks to think about this, I 279 00:21:06.759 --> 00:21:10.200 don't know what, maybe two hundred plus different AWS services over the last ten 280 00:21:10.279 --> 00:21:15.880 years fifteen years. You are not going to find a single one, not 281 00:21:15.960 --> 00:21:22.039 a single one where they had to retrack the pricing model for that they didn't 282 00:21:22.039 --> 00:21:26.920 get it right at the outset. Oh that's a fair point. That's a 283 00:21:26.960 --> 00:21:33.920 really good point. Typically you can count on AWS pricing going down over time, 284 00:21:34.680 --> 00:21:40.359 but I can't recall a single instance where prices have actually increased. Well, 285 00:21:40.440 --> 00:21:41.680 not just saying it's what I'm saying is, you know, to get 286 00:21:41.720 --> 00:21:45.400 the model like, you know, they sort of had a mea kupa oops, 287 00:21:45.440 --> 00:21:48.720 you know, this is not what we intended. We didn't think it 288 00:21:48.799 --> 00:21:51.640 through. We're going to charge it not this way, but this way. 289 00:21:52.039 --> 00:21:57.359 So they have consistently every time gotten the model correct whatever new service that they're 290 00:21:57.359 --> 00:22:00.880 brought on, and they're innovating up and down the stack, right infrastructure platform 291 00:22:00.880 --> 00:22:04.759 as a service, you know, more and more increasingly applications. Right. 292 00:22:06.359 --> 00:22:08.799 So what I'm getting at is it's not an accident. You know, it's 293 00:22:08.839 --> 00:22:12.200 not like you know, they've got all the smart people under the sun and 294 00:22:12.240 --> 00:22:15.119 things like that. No, there's a framework, there's a methodology. Knee 295 00:22:15.200 --> 00:22:22.920 Drink service is basically bubbling up the intelligence, the data, and they're constantly 296 00:22:22.960 --> 00:22:26.880 looking at that eye vaws. You know, all managers, gms and people 297 00:22:26.920 --> 00:22:30.160 who are building new things and existing artifacts are constantly looking at this data and 298 00:22:30.319 --> 00:22:36.240 data is informing what is your customer facing price points? Where should we dive 299 00:22:36.279 --> 00:22:38.599 that up? And is it time to now give a discount? What are 300 00:22:38.640 --> 00:22:41.759 the usage patterns? Like I said, what is being used by whom? 301 00:22:42.079 --> 00:22:48.839 When? World bear how much? So? Meeting is the backbone for cloud 302 00:22:48.880 --> 00:22:53.880 operations right on? So my background infrastructure based, you know, I typically 303 00:22:53.920 --> 00:23:03.000 think about scale and utilization in terms of you know, CPU memory, network 304 00:23:03.039 --> 00:23:14.559 bandwidth, all very foundational compute metrics. What's the what's the shift there to 305 00:23:14.640 --> 00:23:19.319 go from thinking about traditional infrastructure to metering based What different things you have to 306 00:23:19.359 --> 00:23:23.359 start thinking about and start tracking? Great question. Yeah, so this comes 307 00:23:23.400 --> 00:23:27.359 up also quite a bit. Okay, so almost everybody will have you know, 308 00:23:27.920 --> 00:23:30.319 you open your eyes. You want to start writing for second lines of 309 00:23:30.400 --> 00:23:34.920 code for whatever iety application, business building. You know, there's a checklist 310 00:23:34.920 --> 00:23:37.599 of things. You know, you're going to drop in some kind of a 311 00:23:37.640 --> 00:23:41.680 monitoring tool, You're gonna drop in some kind of a logging tool, and 312 00:23:41.720 --> 00:23:45.200 maybe soon thereafter you're gonna look to maybe get some kind of an observability the 313 00:23:45.200 --> 00:23:48.599 moment you stand up some infrastructure. Okay, all of that based stuff needed. 314 00:23:48.960 --> 00:23:55.440 Here's the thing, right, So because meterining hasn't quite caught up to 315 00:23:55.599 --> 00:23:59.519 that checkbox, as we said, you know, inevitably and at the end 316 00:23:59.559 --> 00:24:03.759 of the day, it is also a event ingestion pipeline. So in that 317 00:24:03.920 --> 00:24:10.880 regard it is a close cousin to the artifacts of observability on monitoring because it's 318 00:24:10.920 --> 00:24:14.519 basically the event ingestion. But here's the kicker, here's the difference. So 319 00:24:14.559 --> 00:24:18.200 here's why again, all these companies ended up building a meeting service, certainly 320 00:24:18.559 --> 00:24:23.599 at AWS and other large block providers and others that we discussed metering events. 321 00:24:25.400 --> 00:24:30.799 Meter has to have attribution to who is it on? Whose behalf is this 322 00:24:30.880 --> 00:24:34.880 event for? Okay, so you know, unlike let's say logging, which 323 00:24:34.920 --> 00:24:38.039 is of course you're at tracking your functions and your data execute, and what 324 00:24:38.079 --> 00:24:45.559 are metering is about usage. So meter events will by design have to have 325 00:24:45.599 --> 00:24:49.559 an attribution this meter, this usage event is on behalf of this person, 326 00:24:51.359 --> 00:24:56.759 customer, partner, system, cluster, whatever that is that you want to 327 00:24:56.799 --> 00:25:02.799 attribute that to. So that sort of has to i'd like to say, 328 00:25:02.839 --> 00:25:07.119 sort of levels it a little bit further up the stack, right, because 329 00:25:07.519 --> 00:25:11.400 at the logging level you may not always have that attribution, and logging, 330 00:25:11.960 --> 00:25:17.960 you know, function a lot of times, you know, like observability or 331 00:25:18.160 --> 00:25:21.319 APM, you know it's done on the back end, just pushing through the 332 00:25:21.400 --> 00:25:26.119 Java stack. So metering is a little bit of a higher level artifact. 333 00:25:26.359 --> 00:25:30.000 You need to have that attribution. So then it puts you into the SDK 334 00:25:30.119 --> 00:25:33.599 and API layer and you have to put it into your stack where either as 335 00:25:33.599 --> 00:25:36.400 part of your control plane or as part of your data plane, so you 336 00:25:36.440 --> 00:25:41.880 can attribute whose behalf this is happening. Let me give a little bit more 337 00:25:42.880 --> 00:25:52.519 clarity to this. So you know, there's a whole fringe economy that has 338 00:25:52.559 --> 00:26:00.599 stood up on the backs of the plug provider's bill, which is now cloud 339 00:26:00.599 --> 00:26:07.359 cost management. So you know, the the intention is good, right, 340 00:26:07.440 --> 00:26:12.960 but I would challenge that one. The problem has not been fully solved, 341 00:26:14.480 --> 00:26:21.519 and I think the methodology is fundamentally flawed. Further highlight this distinction between metering 342 00:26:22.079 --> 00:26:26.480 and some of the other observability. So, uh, a whole bunch of 343 00:26:26.559 --> 00:26:30.720 you know, I quite trying to get I'm interested in seeing if there's one 344 00:26:30.720 --> 00:26:33.480 out there, but I think all the companies that I've seen cloud cost management. 345 00:26:33.519 --> 00:26:36.400 The first thing they'll have you do is log into give them your cloud 346 00:26:36.400 --> 00:26:41.319 provis commercials. It's something the bill and you know, let's start parceling in 347 00:26:41.319 --> 00:26:48.000 and all of that. Uh, I'll put this instead of pieces forward. 348 00:26:48.440 --> 00:26:51.839 At least when I was at a WS and I think, I think this 349 00:26:51.920 --> 00:26:53.799 is fact. This is how it is even today and plausive before I got 350 00:26:53.799 --> 00:26:59.880 there. Uh. And this is general knowledge Amazon a W is in particular 351 00:27:00.119 --> 00:27:07.400 Nico about costs, saving costs, uh, operational efficiency. Right, This 352 00:27:07.079 --> 00:27:11.400 was not you're working about it. They talk about it. It's part of 353 00:27:11.440 --> 00:27:15.519 their culture, part of their leadership. And supposes pretend every year when you 354 00:27:15.559 --> 00:27:18.960 come in and you present the plan for the next year, you have to 355 00:27:18.960 --> 00:27:27.000 have a chapter in your AH I how you to take operation to become more 356 00:27:27.000 --> 00:27:33.640 efficient? I can categorically tell you. Will you think I used to wait 357 00:27:33.680 --> 00:27:37.480 for my bill, you have to show up and then to the course of 358 00:27:37.559 --> 00:27:41.720 that and uh, with my strategy and how I'm going to take costs out 359 00:27:41.759 --> 00:27:47.519 of my cloud? No, probably not, that's right. I had a 360 00:27:47.559 --> 00:27:53.240 metrink service that I could leave on that what is being used by whom when 361 00:27:53.279 --> 00:27:56.960 work were how much. I don't need to go to anybody in accounting. 362 00:27:56.079 --> 00:27:59.920 I don't need to go to anybody in finance. I don't need to be 363 00:28:00.079 --> 00:28:02.839 for the bill to show up. I had a meet Drink service, and 364 00:28:02.880 --> 00:28:04.400 the mee Drink service is a data warehouse, and I can tap into the 365 00:28:04.400 --> 00:28:08.880 grad data warehouse based on existing artifacts, dashboards and my own access into that. 366 00:28:10.559 --> 00:28:14.440 And I had visibility even before the salespeople knew who was usually work on 367 00:28:14.480 --> 00:28:21.720 my service. That is cloud operations for you. Well notice in the context 368 00:28:21.720 --> 00:28:23.759 of business, right, so yes, we uh, this is not a 369 00:28:23.839 --> 00:28:27.160 need are I mean? Our engineering teams of course have logging and monitoring and 370 00:28:27.240 --> 00:28:30.680 visibility as you like you rightfully said, there's a need for that. You 371 00:28:30.720 --> 00:28:34.680 know, observability will track are you up? Are you up? Are you 372 00:28:34.720 --> 00:28:38.240 down? Are you down? That yes, they will tell you okay, 373 00:28:38.240 --> 00:28:42.039 how hot are you running? Are you ninety percent percent? What's the need 374 00:28:42.119 --> 00:28:48.559 for that? Me? During is telling me this user logged in, stayed 375 00:28:48.559 --> 00:28:57.319 on this instance for this long. This user not the instant for this while 376 00:28:57.599 --> 00:29:03.200 they're logged out and shut it down? Right. I have that cor relationship 377 00:29:04.119 --> 00:29:08.880 too. That is what kne DRNK is answering right, and that basically drives 378 00:29:08.880 --> 00:29:14.000 forward as a business, I leverage that into my operations to be extended. 379 00:29:15.119 --> 00:29:21.279 So it literally is the electrical meter on the back of your house, so 380 00:29:21.319 --> 00:29:27.720 the electric company can see exactly which household used how much service. It's exactly 381 00:29:27.759 --> 00:29:32.119 that you know, and that's and you know that's that's magical because yeah, 382 00:29:32.119 --> 00:29:34.319 that's where the term me drink comes from. You know, it's not something 383 00:29:34.359 --> 00:29:37.720 that cloud providers in minted. It's not something it is the term you know, 384 00:29:37.759 --> 00:29:41.319 me drain. Yes, this is an infrastructure. As we said, 385 00:29:41.359 --> 00:29:44.880 it's elastic. It will go up and down. People will dial it up 386 00:29:44.920 --> 00:29:48.279 and down. We cannot be flying blind on this. We a w as 387 00:29:48.359 --> 00:29:52.599 themselves need to know first and foremost who is using what and how much before 388 00:29:52.599 --> 00:29:56.200 they can do anything and go anything further or build anything on top of it. 389 00:29:56.759 --> 00:30:00.599 So for them, this is the first class citizen. So this right 390 00:30:00.759 --> 00:30:03.920 metering. If there's a hiccup on the metering service inside it as one, 391 00:30:03.960 --> 00:30:08.480 there will never be I mean, the house will come crashing down. It's 392 00:30:08.519 --> 00:30:11.119 like seve one. There's a beacon that shows up like a red beacon that 393 00:30:11.160 --> 00:30:18.119 starts to spin. Internal dashboards you know, so you know, which basically 394 00:30:18.160 --> 00:30:19.920 tells you that, yeah, open up your sleeping bag, you're not going 395 00:30:21.000 --> 00:30:29.960 home. Okay, So but yeah, it is it is that critical everything, 396 00:30:30.720 --> 00:30:36.640 and so it's precisely that. And therefore and now you think about, 397 00:30:36.680 --> 00:30:41.359 okay, so how come then we have come along this far ten fifteen years 398 00:30:41.640 --> 00:30:45.880 into cloud And of course, you know, many businesses have built successful businesses 399 00:30:45.920 --> 00:30:51.039 and some maybe today do not have meeting services and they're doing reasonably well. 400 00:30:51.519 --> 00:30:52.720 I called out, you know, the ones who really achieved a level of 401 00:30:52.720 --> 00:30:56.720 skill ultimately have built a meeting service, but there are many if not. 402 00:30:57.680 --> 00:31:00.799 And I think the reason for that is, well, I think you know 403 00:31:00.839 --> 00:31:04.400 why it has gone on for so long, but why from day one? 404 00:31:04.920 --> 00:31:08.400 Cloud providers had it because they had no business if they didn't have Meetrink service 405 00:31:08.400 --> 00:31:12.279 started on day one. A couple of things. One is I think that 406 00:31:12.400 --> 00:31:17.200 the business context was perhaps missing, right, So of course, ultimately everything 407 00:31:17.279 --> 00:31:22.799 is driven inside an organization, particularly started you know as a classical resource allocation 408 00:31:22.160 --> 00:31:26.119 discussion of good priorities. While you could do a lot of things, what 409 00:31:26.119 --> 00:31:30.640 are the things that we do first? So the business narrative was perhaps missing, 410 00:31:30.680 --> 00:31:34.559 and the business narrative comes in the form of usage based pricing incoming right, 411 00:31:34.640 --> 00:31:40.440 So that is the wake up call because you may be running a large 412 00:31:40.480 --> 00:31:42.079 cloud business today, but you know, if your go to market is not 413 00:31:42.240 --> 00:31:47.839 usage based, then the business need, like I said, the business operational 414 00:31:47.880 --> 00:31:53.000 need for what is being used by whom when what were how much never really 415 00:31:53.039 --> 00:31:59.000 came to the surface. And therefore the injuring and product teams never built or 416 00:31:59.079 --> 00:32:02.440 needed to build meeting service, and therefore they have gone on this long even 417 00:32:02.440 --> 00:32:08.000 though they're running successful businesses in the cloud without having a meeting service the moment, 418 00:32:08.960 --> 00:32:12.720 so the business context was missing. Now in the world of AWS and 419 00:32:12.759 --> 00:32:15.599 other cloud providers, some already had the foresight, so they dated from day 420 00:32:15.599 --> 00:32:20.160 one and they have grown with it because they knew that they could not do 421 00:32:20.200 --> 00:32:23.559 it otherwise. Because they're pricing plans for a usage based from day one. 422 00:32:23.799 --> 00:32:28.079 So you will find that any company that launched day one on usage base, 423 00:32:28.279 --> 00:32:31.160 this is guaranteed, well, you will find a meeting service there. Okay, 424 00:32:31.839 --> 00:32:37.759 So the ones now who are shifting to the model of usage basis, 425 00:32:37.920 --> 00:32:43.480 they are going to discover and I think we're seeing increasingly when I said, 426 00:32:43.480 --> 00:32:45.160 we've got tailwinds. We're finding more and more people are sort of nodding their 427 00:32:45.160 --> 00:32:49.599 head, yeah, i'd need this artifact. In fact, some are asking 428 00:32:49.640 --> 00:32:52.200 for it by name now, so still relatively early, but give it another 429 00:32:52.240 --> 00:32:55.720 year, two years, three years, this becomes a checkbox site for a 430 00:32:55.720 --> 00:33:01.440 cloud native system. Yeah, just thinking through like the evolution of software, 431 00:33:01.480 --> 00:33:07.200 I think I see how this becomes the path because if we go back, 432 00:33:07.880 --> 00:33:10.559 you know, twenty years ago, if you needed a copy of Microsoft Office, 433 00:33:10.599 --> 00:33:15.720 you went down to the local computer store and you bought. You know, 434 00:33:15.759 --> 00:33:20.200 if you're old enough, you bought, you bought it and brought the 435 00:33:20.240 --> 00:33:23.000 floppy disk back to your computer. And then when modern technology hit, you 436 00:33:23.039 --> 00:33:29.240 went and bought the CD. And then whenever they went to an online business 437 00:33:29.279 --> 00:33:32.359 model, it's still the same business model for them, where you're paying for 438 00:33:32.440 --> 00:33:39.880 a seat of Microsoft Office. But now with everything available on demand, a 439 00:33:39.920 --> 00:33:46.680 lot of companies are seeing increased competitors because the ability to launch competitor, or 440 00:33:46.720 --> 00:33:51.480 the barrier to launch a business is so much lower now, and so you 441 00:33:51.519 --> 00:33:55.400 have to find different ways to be competitive. And one of the ways is 442 00:33:55.440 --> 00:34:01.359 to accurately price your product based on utilization, and how do you measure utilization. 443 00:34:01.720 --> 00:34:06.480 Well, that seems that's the metering aspect of it. So to me, 444 00:34:06.519 --> 00:34:13.159 it feels like there's a natural path to this totally, and you know, 445 00:34:13.639 --> 00:34:16.000 and companies will spare by it like I would. You know, I 446 00:34:16.039 --> 00:34:20.519 think if you take anybody from aw's leadership, take them aside and say, 447 00:34:20.519 --> 00:34:22.280 hey, you know, tell us, you know, what are some of 448 00:34:22.280 --> 00:34:25.639 the core things that you got right in the early days, you know, 449 00:34:25.679 --> 00:34:30.320 it's inevitable. You know they'll say we got metering right, you know we 450 00:34:30.719 --> 00:34:36.159 because you can be flying blind and and just on a whim and how to 451 00:34:36.199 --> 00:34:42.480 grow in business. So yes, and I think the other things why we 452 00:34:42.559 --> 00:34:45.719 are still bullish, but I think more than that now there's ample evidence and 453 00:34:45.039 --> 00:34:49.840 data that's sort of backing the pieces. So the shift to usage based pricing 454 00:34:49.840 --> 00:34:52.519 and building, I think you actually just kind of going down that path, 455 00:34:52.639 --> 00:34:58.559 right, So how do you stay competitive? It's cloud computings obviously level the 456 00:34:58.599 --> 00:35:01.800 playing field in terms of being access to technology infrastructure or do you needed five 457 00:35:01.800 --> 00:35:05.320 million dollars just to kind of buy Oracle and a bunch of other things to 458 00:35:05.360 --> 00:35:08.119 even get started. So it's been a great level or I mean a couple 459 00:35:08.119 --> 00:35:10.360 of guys in the garage can put out just as much, you know, 460 00:35:10.920 --> 00:35:15.000 in any other companies. So it's all about time to market ideas. So 461 00:35:15.079 --> 00:35:17.760 in that realm, how do you stay competitive? And I think people are 462 00:35:17.760 --> 00:35:22.599 finding that it's given that you're going to have competitors, others are going to 463 00:35:22.840 --> 00:35:25.840 come into your space. So within that, how do you bubble to the 464 00:35:25.880 --> 00:35:31.199 top. And there's this whole thing being talked about called PLG product led growth 465 00:35:31.320 --> 00:35:37.239 or basically taking friction out from user adoption from customer adoption, right, making 466 00:35:37.239 --> 00:35:43.639 that whole process a little bit more more and more streamlined, more and more 467 00:35:44.519 --> 00:35:49.000 easy, and sort of the right combination of cell service and kind of getting 468 00:35:49.079 --> 00:35:52.400 the customer situated to a point where you know, and they know that, 469 00:35:52.480 --> 00:35:54.880 yeah, this is the right product for me. And then maybe in sales 470 00:35:54.880 --> 00:35:58.519 and you kind of take it forward from a cross sell up sell perspective. 471 00:35:58.559 --> 00:36:00.440 So this thing is loosely being talked to by that in the realm of POG 472 00:36:00.599 --> 00:36:07.000 product growth. And this is again how you know all of this is and 473 00:36:07.039 --> 00:36:12.239 going in the realm of competitive getting out ahead. Customers have a lot of 474 00:36:12.280 --> 00:36:15.519 choices because they have a lot of choices, but they don't have a lot 475 00:36:15.559 --> 00:36:19.280 of time. Everybody has still twenty four hours in the day, but the 476 00:36:19.400 --> 00:36:22.639 choices are many, so companies will have to figure out how do you how 477 00:36:22.679 --> 00:36:25.519 do you put yourself in the in the shoes of your customers are users, 478 00:36:25.920 --> 00:36:30.360 They're only going to have limited time in terms of giving trying to evaluate your 479 00:36:30.360 --> 00:36:34.039 product as there's five others that need to look at. So how do you 480 00:36:34.079 --> 00:36:37.800 make it easy? And again, metering is the underlying foundation if you want 481 00:36:37.840 --> 00:36:42.000 to successfully build a PLG motion think about it. And again, you know 482 00:36:42.039 --> 00:36:45.639 this is well so obvious, but sometimes not intuitive. I like to see 483 00:36:45.639 --> 00:36:51.920 with Joe, who's the biggest PLG provider on the planets? Right? Sometimes 484 00:36:52.280 --> 00:36:54.400 people say, yeah, well, you know my product is not conducive to 485 00:36:54.480 --> 00:37:00.159 a PLG motion. You know it needs sales team right from the get go. 486 00:37:00.800 --> 00:37:02.440 I don't know. I mean I look at three hundred services under their 487 00:37:04.039 --> 00:37:07.119 umbrella and c I aws up and down the stack, and there's so many 488 00:37:07.159 --> 00:37:12.079 complicated service there services there own PLG motion. Right, you get customers in, 489 00:37:12.800 --> 00:37:15.719 get them to start using something, give them a good experience. And 490 00:37:15.760 --> 00:37:21.039 the whole idea is is uh usage based pricing and linning. The ideas you 491 00:37:21.119 --> 00:37:25.559 take friction points out as they start to fail. Give them a path to 492 00:37:25.599 --> 00:37:28.519 grow. I mean, why you want to get in the way if they 493 00:37:28.519 --> 00:37:32.719 are naturally organically growing, Just let them grow and then art. The fact 494 00:37:32.760 --> 00:37:37.039 that will allow you to do that is it's a usage based model, right, 495 00:37:37.159 --> 00:37:39.239 So it's not a seat based because seat based has these step functions. 496 00:37:39.239 --> 00:37:44.239 Somebody has to call somebody to go from ten users to twenty users. But 497 00:37:44.400 --> 00:37:46.280 if it's a usage base, Okay, you know, I like your product, 498 00:37:46.320 --> 00:37:49.760 I'll keep using them, inviting others in the company, right, just 499 00:37:49.880 --> 00:37:52.199 start using it. Later you can come in with the sales team and maybe 500 00:37:52.280 --> 00:37:59.480 offer a longer term contract or to do some promotion discountant kind of get Yeah, 501 00:37:59.519 --> 00:38:02.440 so that's how do you enable this. You got to have a meterrink 502 00:38:02.480 --> 00:38:07.760 artifact that is tracking again the customers using how much where are they in my 503 00:38:08.400 --> 00:38:15.480 feet here a free trial, and then there's the usage foot friends and so 504 00:38:15.840 --> 00:38:22.239 it's really the backbone for sort of modern business models and business. Yeah. 505 00:38:22.280 --> 00:38:27.800 And from a product perspective, like the metering data to me seems like it 506 00:38:27.840 --> 00:38:34.119 would be really really useful in understanding what parts of your product are resonating with 507 00:38:34.280 --> 00:38:37.599 your users, because that's one of the challenges of a startup is you build 508 00:38:37.639 --> 00:38:43.760 your product and then you have to figure out like one of the things I 509 00:38:44.199 --> 00:38:47.800 frequently say is, when you launch your product, you have to figure out 510 00:38:47.800 --> 00:38:53.719 what the difference between what you built and what the customers thought you built was 511 00:38:54.000 --> 00:38:59.800 and closed that gap. And metering seems like, if done correctly, it's 512 00:38:59.840 --> 00:39:06.119 good to just point that out like a beacon. Totally correct. In fact, 513 00:39:06.119 --> 00:39:07.920 you know a little bit of a good segue. So, but the 514 00:39:08.000 --> 00:39:12.679 name Amber Flow, let me tell you how how sort of that came about. 515 00:39:12.719 --> 00:39:17.199 I think your audience might find this intriguing. A so what I grew 516 00:39:17.280 --> 00:39:21.800 up or you know, for the time I was at WS, the way 517 00:39:21.840 --> 00:39:27.840 I sort of internalized, you know, when I got understood you know, 518 00:39:28.039 --> 00:39:30.440 meat ring and how we were building services, and then how we launched and 519 00:39:30.480 --> 00:39:36.400 the whole usage based business model, how it drove organic growth and adoption. 520 00:39:37.880 --> 00:39:39.400 The vision I had in mind is, you know, if you think about 521 00:39:39.559 --> 00:39:44.079 meter I guess we've talked about and we talked about that it is essentially an 522 00:39:44.119 --> 00:39:47.440 event stream, right, But it's an event stream. Those events are really 523 00:39:47.480 --> 00:39:52.400 your points of gold. It's it's like a liver river of money that's flowing, 524 00:39:52.480 --> 00:39:55.000 right, because what is being used by whom, when, where how 525 00:39:55.119 --> 00:40:00.159 much? So the term amber flow comes from embers of the color of gold. 526 00:40:00.159 --> 00:40:04.000 By the way, amber is also the bright sky and sensfort and the 527 00:40:04.079 --> 00:40:07.880 flow is the river. So that's sort of how, you know, just 528 00:40:08.119 --> 00:40:12.000 the concoction kind of came together, because that's really what it is. Metering 529 00:40:12.159 --> 00:40:16.079 is that river off your business, your goal, your money, your usage, 530 00:40:16.880 --> 00:40:23.360 and how can you operate without having without giving it it's too It's true 531 00:40:24.920 --> 00:40:34.360 diligence and resources and making sure that it's intact and scaling a yeah right, 532 00:40:34.599 --> 00:40:37.679 I love that analogy. You can just reach down into the amber flow and 533 00:40:37.679 --> 00:40:44.840 scoop out however much you want, that's right, yeah, right so, 534 00:40:45.880 --> 00:40:49.679 And that's frankly, that's how it is with most you know, all cloud 535 00:40:49.679 --> 00:40:54.639 providers. It is this is the service that tracks and whether your product, 536 00:40:54.679 --> 00:41:00.400 service, customer team, they're all leveraging this this data set. Yeah, 537 00:41:01.079 --> 00:41:07.320 like the like the You've mentioned a couple times that most companies end up building 538 00:41:07.400 --> 00:41:13.920 their own metering service because a service didn't exist. But I can only imagine 539 00:41:14.599 --> 00:41:21.920 the number of questions that you have to answer to get the metering service right. 540 00:41:22.880 --> 00:41:28.280 So in terms of amber Flow, like what's the what's an onboarding experience 541 00:41:28.360 --> 00:41:32.000 look like? There? What? What what is a potential user of amber 542 00:41:32.079 --> 00:41:37.800 flow need to know in order to onboard with amber Flow? Yeah, yeah, 543 00:41:37.840 --> 00:41:40.480 I have a great question. So, uh, let me actually just 544 00:41:40.559 --> 00:41:46.320 I thought of something back to further sort of distinction, because I'm sure, 545 00:41:46.360 --> 00:41:50.920 okay, if you are an engineer product or engineering side, okay, you 546 00:41:50.960 --> 00:41:53.400 think you got but okay, I still have questions. Why cannot I still 547 00:41:53.440 --> 00:41:58.039 do it through monitoring? Why can't I ask it observably? Because you know, 548 00:41:59.119 --> 00:42:02.039 we grew up that way, right, So, and one of the 549 00:42:02.039 --> 00:42:07.119 things as well, you know, as humans, it's how's the best way 550 00:42:07.159 --> 00:42:15.639 to say that? You know? Sometimes you know, we just like to 551 00:42:15.639 --> 00:42:17.800 think see things from the lens that we're comfortable with, right So we've grown 552 00:42:17.880 --> 00:42:24.599 up with so and you know what, That's just how it is. So 553 00:42:25.159 --> 00:42:30.280 anytime you're going to come across something new, you're going to right away try 554 00:42:30.320 --> 00:42:31.199 to see Yeah, but you know, do I really need it? Isn't 555 00:42:31.239 --> 00:42:36.880 really that different. So there's a period of where anytime you launch something new, 556 00:42:37.159 --> 00:42:40.000 we as the company or the institution that is bringing that, you know, 557 00:42:40.039 --> 00:42:44.199 you have to be prepared to be misunderstood for some period of time. 558 00:42:44.679 --> 00:42:46.440 That's totally okay. And I think if you look back at any times. 559 00:42:46.960 --> 00:42:51.559 You know, also there's a great adage that I've read somewhere. You know, 560 00:42:51.599 --> 00:42:57.480 all inventions seem impossible until they're invented, and then they seem inevitable. 561 00:43:00.920 --> 00:43:04.320 I just this one. I just you know, I lean on this quite 562 00:43:04.320 --> 00:43:07.719 a bit. I think that's just how things are. But anyway, so 563 00:43:07.840 --> 00:43:12.559 one of the things about metering is and also you know, answer our question, 564 00:43:12.599 --> 00:43:16.480 so how do we onboard customers and what they ask for? We do 565 00:43:16.559 --> 00:43:20.519 still get asked, Hey, look, I already have an ingestion pipeline. 566 00:43:20.519 --> 00:43:22.119 You know, I'm doing it through logging, or I'm doing it through monitoring, 567 00:43:22.159 --> 00:43:25.719 I'm doing it through X, y Z, and fair enough, I 568 00:43:25.719 --> 00:43:32.599 can even try to get it so I can try to catch the attribution aspect 569 00:43:32.599 --> 00:43:37.519 of it, and I can have just this and whatnot. Here's the problem 570 00:43:37.599 --> 00:43:43.280 with that, and this resonates. See if we align on as we did, 571 00:43:43.719 --> 00:43:46.320 what the job of metering is to give you that insight what has been 572 00:43:46.440 --> 00:43:51.199 used by whome, whin, what where, how much? But also to 573 00:43:51.280 --> 00:43:55.920 do it accurately and consistently. Okay, now let's work our way backwards to 574 00:43:57.000 --> 00:44:02.000 how we can guarantee that accuracy and the reason why. Then you need to 575 00:44:02.079 --> 00:44:09.519 have a separate meeting service. See from the time where the event originates that 576 00:44:09.599 --> 00:44:13.920 you wish to track, could be an IoT event, could be a system 577 00:44:13.960 --> 00:44:15.639 event, could be an EC two event, could be a storage event, 578 00:44:15.679 --> 00:44:22.039 could be an API event. From wherever the event is originating, if the 579 00:44:22.159 --> 00:44:29.159 event has done multiple hops by the time it gets to your monitoring logging service, 580 00:44:29.360 --> 00:44:32.679 and then within that service it has done multiple hops, and then you 581 00:44:32.719 --> 00:44:36.840 say, yeah, I have the event, use it for pricing and building, 582 00:44:37.840 --> 00:44:42.000 you may be able to get by for a little bit until somebody on 583 00:44:42.039 --> 00:44:46.599 the other end says, I don't trust this bill. Tell me unpack the 584 00:44:46.599 --> 00:44:52.280 events that got me to this meter. Bill. Now you have a problem 585 00:44:52.480 --> 00:44:59.199 because who is going to take ownership of that remediation. This is very typical. 586 00:44:59.239 --> 00:45:01.480 We see this all the time, and companies trick over this unfortunately, 587 00:45:01.480 --> 00:45:05.079 even after the fact that they've decided to go use in place pricing, and 588 00:45:05.119 --> 00:45:08.440 then until they encountered their first coutage or this first kick up, and then 589 00:45:08.480 --> 00:45:12.400 you scramble. You know, one person from finance, and one from accounting, 590 00:45:12.400 --> 00:45:15.320 and one from product and one from support and one from engineering. And 591 00:45:15.840 --> 00:45:17.000 okay, what what happened? Well, we don't know what. We went 592 00:45:17.039 --> 00:45:20.800 to this system and then from this system, and when this system it came 593 00:45:20.880 --> 00:45:22.440 into the data warehouse, and then we did et L and then it went 594 00:45:22.519 --> 00:45:28.639 to relational and then we did this somewhere the event got dropped. You have 595 00:45:29.239 --> 00:45:35.679 lost lineage. Okay, if you have lost lineage your your you have you 596 00:45:35.760 --> 00:45:44.119 cannot back credibility after the metering guarantees you that lineage. Therefore, the design 597 00:45:44.199 --> 00:45:50.880 thesis and the deployment model foring is with metering clus as possible to where the 598 00:45:50.920 --> 00:45:57.920 original event is originally get there event as strictly as directly into the metering services, 599 00:46:00.400 --> 00:46:05.760 and you eliminate these cops because guarantees you if somebody's offering the meeting service 600 00:46:05.800 --> 00:46:10.400 as a as a as a product. After taking down with that page, 601 00:46:10.480 --> 00:46:17.440 walking through how you guarantee me accuracy you know some of the things that I'm 602 00:46:17.440 --> 00:46:21.159 out planning now that yeah, this is what we do. Yeah, so 603 00:46:21.400 --> 00:46:27.400 in the like in the past, we would we would do things like annotate 604 00:46:27.440 --> 00:46:30.559 the logs, you know, annotate them with a guid and that good could 605 00:46:30.559 --> 00:46:36.599 be associated with a specific sequence of actions. But then even whenever it comes 606 00:46:36.639 --> 00:46:38.239 time, like you said, to prove it, you have to go to 607 00:46:38.559 --> 00:46:45.760 all of these disconnected systems and search for that guid and and hope it was 608 00:46:45.760 --> 00:46:49.880 there and that you know, nothing, nothing happened, and that it's it's 609 00:46:49.920 --> 00:46:53.559 able to be stored in a format where you can parse and search by that. 610 00:46:54.000 --> 00:46:59.920 And so the mating service is a completely different shift, so that it's 611 00:47:00.159 --> 00:47:05.400 an external thing, that its sole job is to just store that data so 612 00:47:05.480 --> 00:47:09.199 you don't have to try and annotate it at every piece of your infrastructure along 613 00:47:09.239 --> 00:47:14.920 the way, exactly. And you do it once and you're set for life. 614 00:47:15.360 --> 00:47:19.920 And because therefore the reasons why and then again you know why you went 615 00:47:19.960 --> 00:47:22.320 down the path of guid and all that, and why you didn't think of 616 00:47:22.320 --> 00:47:24.360 a meeting service because the business demand was not there. You know, maybe 617 00:47:24.360 --> 00:47:28.679 once in a while that request came out, right or once in a while, 618 00:47:28.719 --> 00:47:31.239 you know, and then it was really more engineering request and a support 619 00:47:31.280 --> 00:47:37.320 request rather than a customer accounting revenue rec issue. Right that has to be 620 00:47:37.159 --> 00:47:42.280 you cannot just charge somebody around the amount that is just in fact, you 621 00:47:42.320 --> 00:47:45.639 know, we get called out for that, right that's you know, so 622 00:47:46.360 --> 00:47:50.400 you know you have to do accurate billing. You can only charge for for 623 00:47:50.440 --> 00:47:53.840 what is out to you. So you know, those are federated, you 624 00:47:53.880 --> 00:47:58.880 know, federally mandated statutes. So therefore, now there's this onus that is 625 00:47:58.880 --> 00:48:01.599 coming down to product in engineering teams. This may not be just a one 626 00:48:01.639 --> 00:48:05.000 off thing that we might hear once in every six months or something, and 627 00:48:05.000 --> 00:48:07.960 it's okay, we can scramble some resources and do that, you know. 628 00:48:07.119 --> 00:48:09.639 I mean, some customers might just want to ask, hey, I give 629 00:48:09.639 --> 00:48:15.599 me visibility into did I actually use this much? And amber Flow system will 630 00:48:15.599 --> 00:48:19.360 give you the full lineage of the entire meter bill, track it all the 631 00:48:19.360 --> 00:48:21.639 way back, and you want to send them a list of those events that 632 00:48:22.440 --> 00:48:25.599 aggregated into the invoice. Have at it. It's right there at your disposal 633 00:48:28.000 --> 00:48:34.159 right on. That's cool. That's cool. And so I'm assuming that Amberflow, 634 00:48:36.360 --> 00:48:39.920 the pricing model of that is a metered service. Yeah, so you 635 00:48:39.960 --> 00:48:45.480 know we do, like I said, you know, so we have We're 636 00:48:45.480 --> 00:48:50.559 proud of this fact, the world's most rich, full feature fully managed cloud 637 00:48:50.679 --> 00:48:54.280 metrink service at scale. Yeah, we're proud of the fact, you know, 638 00:48:54.840 --> 00:49:00.679 one of our larger customers today already sending US four billion meter events a 639 00:49:00.760 --> 00:49:07.239 day. Okay, And because they get it, like you know, they 640 00:49:07.239 --> 00:49:12.440 are shifting lock stock and barrel everything their entire product portfolio to usage based pricing 641 00:49:12.440 --> 00:49:17.920 and billing. It starts with accurate metering. Accurate accuracy is key. So 642 00:49:19.199 --> 00:49:22.719 events come into Amber flow raw events, they get aggregated, they get sliced 643 00:49:22.760 --> 00:49:28.440 over timestream, and now you have a system of usage or what is being 644 00:49:28.519 --> 00:49:30.280 used by whom, when, what wear how much? So that is our 645 00:49:30.400 --> 00:49:36.000 metering service. We view a meeting service as a platform, horizontal platform service, 646 00:49:36.840 --> 00:49:39.079 and then on top of that we offer you what we call our billing 647 00:49:39.119 --> 00:49:43.400 cloud, which is what we consider an application that sits on top of the 648 00:49:43.480 --> 00:49:47.280 metering platform. Our billing cloud then gives you all the customer facing artifacts for 649 00:49:47.320 --> 00:49:52.480 you to build flexible usage based pricing plan. You want to charge on APIs, 650 00:49:52.559 --> 00:49:54.840 you want to charge on a peered model, you want to and then 651 00:49:54.960 --> 00:49:58.800 charge on prepaid, you want to charge on commits, you want to do 652 00:49:58.920 --> 00:50:06.599 promotions, discount and our billing cloud then generates on demand real time metered invoicing 653 00:50:06.639 --> 00:50:13.559 and building. So that's how the platform comes together. Wow, that's cool. 654 00:50:13.800 --> 00:50:17.639 That's super impressive. Yeah, and you know it's taken a while, 655 00:50:19.280 --> 00:50:22.880 you know, and therefore, like you know, we started talking about three 656 00:50:22.920 --> 00:50:24.880 years in and you know, we were at least for about a year and 657 00:50:24.920 --> 00:50:30.000 a half just in core development. I mean, this is something that uh 658 00:50:30.360 --> 00:50:36.559 credit to my early investors. We were front with them about this that he 659 00:50:37.360 --> 00:50:39.480 as I was selling yearly about sort of the Silken Valley story that you know, 660 00:50:40.239 --> 00:50:44.000 this is not a fly light night thing, you know, and not 661 00:50:44.239 --> 00:50:45.639 in four months. You know, don't don't come asking us, you know, 662 00:50:45.679 --> 00:50:50.920 what is the arr It's going to take us a while to be and 663 00:50:50.960 --> 00:50:55.440 you know this is you know, this is like, ah, I'm really 664 00:50:55.480 --> 00:51:00.480 kind of wrapped up around this because I think a lot more in a could 665 00:51:00.519 --> 00:51:04.840 be happening as I think if it's just the Silkon Valley was perhaps a little 666 00:51:04.880 --> 00:51:08.320 bit more open to It takes time. It takes time to build something that 667 00:51:08.440 --> 00:51:13.840 is differentiated, that is sustainable. And I say that again you know, 668 00:51:14.280 --> 00:51:21.280 look that's the GM for Amazon Cloud Search, one of the services, and 669 00:51:21.320 --> 00:51:24.320 then later our team also launched Amazon Elastic Search, which is now called Amazon 670 00:51:24.360 --> 00:51:30.920 open Search. Cloud Search took two and a half years to build before we 671 00:51:30.960 --> 00:51:35.920 saw the light of day, before we got a first data customer. Wow, 672 00:51:36.400 --> 00:51:40.800 that's an Amazon scale will Yeah. Red Shift my good friend, you 673 00:51:40.800 --> 00:51:45.880 know, and Ra Gutta who is also running a startup. Red Shift to 674 00:51:47.960 --> 00:51:52.559 over three years before it saw the light of day, and you know, 675 00:51:52.599 --> 00:51:58.920 and therefore these are now multi billion dollar businesses and sid ws. You know, 676 00:51:59.000 --> 00:52:02.360 you want to think you want to do something big, it takes time, 677 00:52:02.440 --> 00:52:07.199 you know that, it takes time to think this thing through and build 678 00:52:07.239 --> 00:52:15.199 that full set of capabilities that will be differentiated, that will be meaningful. 679 00:52:15.239 --> 00:52:22.480 So anyhow, so that's sort of been our story of glad to say that 680 00:52:22.599 --> 00:52:30.320 we found alignment in the lester that we got who understood and I was willing 681 00:52:30.320 --> 00:52:34.679 to play a little bit of a different, you know, playbook than the 682 00:52:34.760 --> 00:52:37.400 traditional is great. Up. Yeah, congratulations for sure on that, because 683 00:52:37.400 --> 00:52:45.880 that is not your average investor who's willing to invest for a long investment or 684 00:52:45.880 --> 00:52:50.440 a long payoff like that. It's it's something we've gotten spoiled with over the 685 00:52:50.519 --> 00:52:55.400 last I don't know, twenty years, and I think I think that's very 686 00:52:55.440 --> 00:52:59.519 short sighted. Like you mentioned, you know, some of these products take 687 00:53:00.280 --> 00:53:07.159 a long time to build, and you you have to be very disciplined and 688 00:53:07.239 --> 00:53:12.639 focused in what you're trying to build to commit to holding back the release date 689 00:53:12.719 --> 00:53:15.440 until you have the product that does what you know it should be doing. 690 00:53:16.360 --> 00:53:20.159 That's right, bro. Yeah. And you know, and I think especially 691 00:53:20.199 --> 00:53:23.280 in tech, particularly in software, right because you know, there are a 692 00:53:23.320 --> 00:53:28.079 few things that if you don't get it right from the outset, you just 693 00:53:28.079 --> 00:53:30.920 cannot go back and revisit. Right. You know this better than anybody else, 694 00:53:30.000 --> 00:53:36.199 right, So that is the thing, And that's why it's a combination 695 00:53:36.280 --> 00:53:42.480 of you know, right, environment, support from leadership, because if you 696 00:53:42.559 --> 00:53:45.119 feel pressure to just go, I gotta logic, I raise money, I 697 00:53:45.159 --> 00:53:50.000 gotta go and start showing some R and forty six, you're gonna shortcut on 698 00:53:50.079 --> 00:53:53.800 those choices, yes, and you can never go back and revisit them. 699 00:53:54.280 --> 00:54:00.480 And one of the things that we wanted to do, I know, I'll 700 00:54:00.519 --> 00:54:02.920 share this sort of with your audience a little bit of our sort of internal 701 00:54:06.920 --> 00:54:12.480 ip and thesis. So you know, we talked about the whole lineage of 702 00:54:12.519 --> 00:54:15.360 the events and all of that. Right now, you know what, well, 703 00:54:15.480 --> 00:54:20.559 so well, I've given you the pictures. I'm offering as a vendor 704 00:54:20.599 --> 00:54:24.960 a metering service, right, And it's basically a like anw quote unquote black 705 00:54:25.000 --> 00:54:29.079 box. Yeah, I guarantee you send me the raw event and outcome. 706 00:54:29.280 --> 00:54:31.079 I'll send you the aggregated view, and we are the system of record and 707 00:54:31.119 --> 00:54:36.199 you can lean on my service and you can hold us accountable for the accuracy. 708 00:54:36.199 --> 00:54:40.280 Okay, we make that guarantee. Now, if you are for a 709 00:54:40.280 --> 00:54:45.280 moment inside my company and you're in our product and engineering discussion as well, 710 00:54:45.679 --> 00:54:47.079 we still have the same problem to solve internally, right. I mean, 711 00:54:47.079 --> 00:54:52.360 if if my architecture is ten different things and things are going, you know, 712 00:54:52.400 --> 00:54:57.360 there's different artifacts, I still have to manage this lineage and an audit 713 00:54:57.360 --> 00:55:00.840 trail of the event. So what is that architecture? Right? And uh? 714 00:55:01.880 --> 00:55:08.800 And that's why you know, having the right ecosystem partners, investors, 715 00:55:09.280 --> 00:55:16.519 team technology, product and engineers, it's really that unique combination. So what 716 00:55:16.639 --> 00:55:21.800 else share with you is, look, you know you can put some very 717 00:55:21.880 --> 00:55:23.960 smart engineers together and say hey, let's go a detective metering service. Right 718 00:55:24.000 --> 00:55:27.760 now, you come from technical background and say, okay, so what is 719 00:55:27.760 --> 00:55:30.800 a metering service? Well, it's an invent ingestion system. So I'm going 720 00:55:30.800 --> 00:55:32.880 to need a cofa Okay, so let's put a coffea in place. Well, 721 00:55:32.920 --> 00:55:36.400 there's data flowing and so I'm going to need a data warehouse, Okay, 722 00:55:36.400 --> 00:55:38.679 so let's let's put that in place. Well, there's some state management 723 00:55:38.800 --> 00:55:40.719 and then there's a few other things that I'm going to have to kind of 724 00:55:40.719 --> 00:55:45.000 connect. So I'm going to need to have a relational database work sort of 725 00:55:45.079 --> 00:55:47.960 quick response. I'm going to put a relational database in place, okay, 726 00:55:49.000 --> 00:55:52.000 and you know, and you would come up with a pretty good meterrink service. 727 00:55:53.079 --> 00:55:58.039 Well, I can share with you that we don't use any of that, 728 00:56:00.760 --> 00:56:04.039 and there's a reason for it, right And it's not just you know, 729 00:56:04.119 --> 00:56:06.719 put a chick on my shoulder. But what is it that you are 730 00:56:06.800 --> 00:56:08.800 after? What is it that you're designing? So this is what I'm referring 731 00:56:08.800 --> 00:56:14.199 to. What is the quartino? Is that design? He says, what 732 00:56:14.320 --> 00:56:17.000 is your ultimate long term goal? Our ultimate long term goal is what I've 733 00:56:17.039 --> 00:56:20.920 already applied with you and your audience that you know we we are going to 734 00:56:20.920 --> 00:56:24.400 be the metrink service with this, you have a metrinks need for a metrink 735 00:56:24.400 --> 00:56:29.119 service. I am telling you right now and if I fall short of this, 736 00:56:29.280 --> 00:56:30.679 you can just callow me out of anyone of your audiences going to write 737 00:56:30.679 --> 00:56:37.199 to me, we are going to be the best most features, the best 738 00:56:37.320 --> 00:56:40.679 price performance metrince service you can find on this project. Yeah, you know 739 00:56:40.760 --> 00:56:44.440 your your passion in that when you were when you were talking about that, 740 00:56:44.639 --> 00:56:47.760 just like your passion just like really came through and it was that was very 741 00:56:47.880 --> 00:56:53.119 very cool to see because there's no disputing, like you can just hear it 742 00:56:53.159 --> 00:56:55.760 in your voice. There's no disputing what you said. You can just tell 743 00:56:55.760 --> 00:57:00.960 that you believe it with every cell in your body. But another thing that 744 00:57:00.239 --> 00:57:06.320 stood out to me there was one of the challenges a lot of companies face 745 00:57:07.280 --> 00:57:12.760 is your engineers building your product have to actually use that product to see it 746 00:57:13.519 --> 00:57:19.159 as your customers would see it. But that's just built into your business model, 747 00:57:19.239 --> 00:57:22.639 Like you are one hundred percent dependent on your own product for success as 748 00:57:22.639 --> 00:57:27.840 a company because that's yours. You know, it's not only how you make 749 00:57:27.880 --> 00:57:32.239 your money, but it's how you bill your customers to make your money. 750 00:57:32.840 --> 00:57:37.800 That's a that's again a very astute observation on your part. One hundred percent 751 00:57:37.880 --> 00:57:40.840 yes, by the way, and this was also something that was part of 752 00:57:40.880 --> 00:57:45.440 the excitement of starting this company. You know, I thought this to, 753 00:57:45.519 --> 00:57:49.400 hey, we're going to be amber Flow and Amberflow that's how we call it. 754 00:57:52.000 --> 00:57:55.639 So uh and you know, I'll also sort of connect to that squad 755 00:57:55.679 --> 00:58:00.519 again, one of those things very obvious. Maybe some companies just kind of 756 00:58:00.599 --> 00:58:07.039 lucky in that regard, but I'll tell you where that awareness was there even 757 00:58:07.079 --> 00:58:09.039 before starting the company. It's easy to say, oh, we knew that, 758 00:58:09.039 --> 00:58:14.639 but I'll actually even bring some credibility to that. When I got hired 759 00:58:14.639 --> 00:58:19.880 into AWS back in twenty eleven, we were my charter was to build Amazon 760 00:58:19.920 --> 00:58:25.079 cloud Search, which arguably was probably our first quote unquote pass service. Everything 761 00:58:25.079 --> 00:58:29.079 else was infrastructure you think about it, red compute storage, you know, 762 00:58:29.159 --> 00:58:32.199 e C two. So search is a little bit a little bit further up 763 00:58:32.239 --> 00:58:37.760 the stack. And so cloud Search, internally we were referring to cloud Search 764 00:58:37.840 --> 00:58:43.719 was sort of the first pass service built natively, that was built first past 765 00:58:43.760 --> 00:58:49.360 eight WS service that was built using a WS. Okay, so underneath cloud 766 00:58:49.360 --> 00:58:51.519 Search maybe different now, but you know, back in the day, I 767 00:58:51.559 --> 00:58:59.760 think we were using travel thirteen different eight WS services to build that. That's 768 00:58:59.760 --> 00:59:02.199 why's going on behind the scenes and cloud search. So this concept of you 769 00:59:02.239 --> 00:59:08.639 know, uh, first AWS service using AWS. Uh you know, so 770 00:59:08.679 --> 00:59:12.320 I had some awareness that and the same thing here so Amber phone, amberfo, 771 00:59:12.639 --> 00:59:15.800 we are we started a day with our own daily dashboards that are being 772 00:59:15.840 --> 00:59:20.679 delivered to us from my Metrix service on what has been used by whom then 773 00:59:20.800 --> 00:59:24.079 want to wear how much from our customers? Oh that's so cool. And 774 00:59:24.599 --> 00:59:30.519 just to comment on open search real quick, I was. I was very 775 00:59:30.559 --> 00:59:36.559 excited when that product released because I had spent years prior to that managing my 776 00:59:36.679 --> 00:59:43.559 own elastic search clusters and you know, running the JA the JMX metrics, 777 00:59:44.159 --> 00:59:47.760 monitoring the heap stack, waiting for that node to crash so that I could 778 00:59:47.800 --> 00:59:52.400 detect it and replace it, and then trying to avoid the split brain and 779 00:59:52.440 --> 00:59:58.320 maintain availability so to be able to just pay AWS money to get out of 780 00:59:58.360 --> 01:00:02.039 that business. I I couldn't hand over my credit card fast enough. Go 781 01:00:02.400 --> 01:00:07.000 Yeah, yeah, I know. That's you know, that's been the foundation 782 01:00:07.079 --> 01:00:08.559 for any of the service. I mean, that's one of the template at 783 01:00:08.559 --> 01:00:15.079 AWS and and other cloud providers, right open source and then basically wrapping it 784 01:00:15.119 --> 01:00:22.880 into the cloud ecosystem right on. Yeah cool, Well we are just crossing 785 01:00:23.039 --> 01:00:28.840 an hour here. So if if our listeners are interested in learning more about 786 01:00:28.920 --> 01:00:31.159 metering or want to get in contact with you, what kind of resources have 787 01:00:31.239 --> 01:00:35.039 you got for them? Yeah? Sure thing, Well, so best decided 788 01:00:35.079 --> 01:00:42.639 tote you to just land on our website dot amberflow dot io and a lot 789 01:00:42.639 --> 01:00:46.360 of information there. We have a full set of documentation docs that are available 790 01:00:46.400 --> 01:00:50.760 to you. You can ready quit the unpack. What are these artifacts? 791 01:00:50.840 --> 01:00:53.519 What are some of the design patterns? How to engage with them? But 792 01:00:53.599 --> 01:00:57.400 please you know, as you're on the website, look around, drop us 793 01:00:57.400 --> 01:01:00.880 a note. Love to connect with you if you are thinking about usage based 794 01:01:00.920 --> 01:01:05.519 pricing and building those things attached, I'm always happy to compare, share some 795 01:01:05.639 --> 01:01:08.960 notes lessons learned if you're already down the path of usage based pricing and building. 796 01:01:09.280 --> 01:01:13.239 Happy to compare some notes if you're running into some friction areas and how 797 01:01:13.320 --> 01:01:15.280 you might streamline it. But yeah, welcome you to come back on a 798 01:01:15.320 --> 01:01:21.920 website. Awesome. Well, this has been a really exciting conversation for me. 799 01:01:22.159 --> 01:01:24.559 It's been insightful, eye opening, and I've really enjoyed it. So 800 01:01:24.599 --> 01:01:27.880 thank you for taking the time out of your day to join me here. 801 01:01:28.719 --> 01:01:30.480 Oh my pleasure Will. It was very exciting for me, just I'm just 802 01:01:30.519 --> 01:01:36.159 kind of went by, all right. Thank you and thanks for listening everyone, 803 01:01:36.159 --> 01:01:38.239 and we will see all in the next episode.