How'd you like to listen to dot net rocks with no ads? Easy?
Become a patron for just five dollars a month. You get access to a
private RSS feed where all the shows have no ads. Twenty dollars a month.
We'll get you that and a special dot net Rocks patron mug. Sign
up now at Patreon dot dot NetRocks dot com. Hey guess what, it's
dot net rocks. I'm Carl Franklin and I'm Richard Campbell here for another hour
of Meret Gordon Nurse. Yes, because we were talking about meat before the
show. Yes, yes, we were, as you do. So you
know, every time we end a show and it's like solid awesome, which
is most of them, Richard always says, well, that was an hour
of media goodness. Well, and we're digging into AP making APIs better,
then this is going to be all medi goodness for sure. Oh, it's
totally gonna be all medi goodness. Anthony Alaibe is here. We're going to
talk to him in a few minutes. But first I have some more goodness
from Microsoft for better no framework awesome. So I just saw this as a
blog post from Dan Roth. Yeah, introducing this experimental U tool or feature
components called smart components, and these are essentially AI wrapped edit controls. So
one of them is a smart paste, so it's takes the place of an
input textbox and by smart pace. You know, if you go to a
form and it's got all these fields name, address, phone number YadA,
YadA, YadA, credit card number YadA, well you could copy, like
text from notepad or something that has all those details arranged in paragraphs or whatever,
copy and then paste it into the form, and poof, everything goes
in the right place. Nice. Are you interested? I am? This
is really cool. No, no, you know, this is what I
figured all along. As these technologies mature, we're just going to incorporate them.
We're not going to make apps about them. We're just going to incorporate
them in our apps exactly. And that's what I love about this. It's
a great it's a great application of a high technology to make every day ordinary
things easier. Absolutely, and that's what They also have a text area,
so it will do sort of you put some details of things. You can
train it very quickly on just some sentences that are in the style of and
then it will suggest to you like autocomplete, you know, like Gmail does
when you're but with real details. And then there's also a combo box,
so when you're pasting components, it will pick the right value from a dropdown
combo box if one is there. Nice little things like that. So this
is all good. So we're gonna link to it. It's eighteen ninety one
dot pop, dot me, or you could just search for dot net smart
components. Daniel Roth and Steve Sanderson does a great demo. And by the
way, he is getting really animated lately in his videos, like he's turning
into like Joe actor, like he I was really like a used car salesman,
but not quite as not quite as catchy. But he's really selling it.
Oh wow, that's interesting because he's only so reserved. He's subdued most
of the time. I think that was Glenn Block, but yes, yeah,
he is a very reserved guy. But he's really excited about this and
it's good, such a good idea, it's very cool, fantastic. So
eighteen ninety one dot pop, dot me, go check it out. Who's
talking to us Richard gradyment of Show eighteen o two. So I went back
a bit that's July of twenty two when we were at ANC Lennon. We
talked to Victoria al Mazova, who we should talk to again because she's so
fishit and smart. That was the whole measuring of dev secops, which is
a bit of a non sequity of this comment from Rob Garner, one of
our longtime listeners. Hey Rob, thanks for commenting again, even though middlely
a couple of years ago, because I love what he said here. He
says, Okay, someone has to say it. It's bound to result in
the loss of cool points. But as youre sir, seems like it'd be
hard to use at times. Sometimes I don't think I was supposed to say
that, but I'm saying it. And my example is functions. They're supposed
to really the developer of the complexity of thinking about the structure of an API,
to free you to just write code. And the Microsoft examples were great
right up until you need to apply the repository pattern. Then you have to
use the pendency injection. They discover you'd be better using the correct dependency approach
for your version of functions or whether you're in or out of process, and
then you have to dig through all the examples to figure out what you're doing,
because the approach is change several sigiment ways for each version of Azure function.
And at that point you should be asking yourself, is a function really
what I want here? Yeah? You know, and because that's a code
smell right well. And it's the thing that made me jump, was like
not thinking about the structure API, because you should always think about the structure
API. Yeah. I think we're going to talk about that a lot today.
I think so. But Rob, you know, you said the thing
we're not allowed to say out loud. And part of this is just the
twitching of Azure right Like Microsoft still figuring out how to deliver these things to
us too, which makes it really makes it tough to write code against it
because you don't know what's going to happen next. And I don't know if
I'm put if I'm making that API available to more than just me, I
need to think a lot about making it right and what that looks like.
Indeed, So Rob, thank you so much for comment. To copy of
music code by is on its way to you. And if you'd like a
copy of music Code buy, I write a comment on the website at Donna
rocks dot com or on the facebooks. We publish it show there, an
if you comment there and I read on the show, will send you copy
of us to go by, and you can follow us on ex Twitter,
Twitter x or whatever the hell they're calling it these days. But the cool
kids are hanging out on mastadon. I'm at Carl Franklin at techob dot social,
and I'm Rich Campbell at mastadon dot social, and of course you can
find all the ways to get in touch with me at Carl Franklin dot com.
All right, let's introduce Anthony. This is his first time on dot
net rocks, so let me give them the formal introduction. Anthony Alaibe has
spent over a decade building software at companies like Opera, Parody, Polka Dot,
and Delivery Hero. He has faced his fair share of dealing with unreliability
and breaking changes and APIs, including losing over two million dollars in orders to
such API issues at Delivery Hero, which prompted him to build API toolkit dot
io to help companies navigate their back end and API landscape. He has an
academic background in medicine and it is currently based in Berlin. When he's not
writing code, you can find him binging an anime series or thinking about how
principles from the medical world can help us build software better. So from the
medical world, So you're saying we should measure software using the metric system.
Obviously the rest of the world does you guys need to catch up. Hey,
I didn't start the fire, Okay, I just live here, make
the freaking rules. In fact, I got an A on my metric test
in sixth grade in moose Humper. Okay, silliness. So, yeah,
what did you think of the comment that Richard wrote about functions being I think
I only read it. I didn't read it. Yeah, you wrote it
with your mouth kind of. I made noises about it. It's gonna be
one of those Yeah ahead, Yeah, I mean I think Richard said it
said a nice right, we want to use functions functions as much as possible.
You're small constrained, But then soon you want to access it that's a
base or you want to access access to the dependencies, and it doesn't work
out anymore because yeah, you need dependencies somehow. Pretty soon you're just holding
on to functions. Is for the purpose of having a function exactly, but
I mean so at the code level, I think when we can, you
know, functions can be pretty or I think they might preferred way you know,
to go when I can, just because they're constrained, you know exactly
what goes in here. You don't expect so much magic, especially if it's
like, you know, some kind of pure simple function. You know,
it's like maybe not gonna reach out to data days without extra Also, I
find that functions are best used when they're used a lot, so they don't
go to sleep. Yeah you know what I mean, Because when a function
goes to sleep and the next user comes around and wakes it up, they
gotta they might take the wrap is broken. Yeah, I what fund did
I be talking about? I think Azure functions. Functions? Yeah, okay,
okay, I was talking about beyond the functions somehow. Yeah, I'm
sorry, that's fine. So, yeah, we've done a bunch of shows
around the whole concept of the modular monolith, and to me, it's like
the function is where you put the the badly behaved piece of your monolith.
That it's the one that's being called all the time, and every time it
needs to change, it resonates the whole uh block a day of app like,
so you want to put it in its own wrap, or it's gonna
always be active or most of the time active. You need to scale independently
of everything else, Like why why I have to light up more instead of
app service when you could just have this noisy thing running in it in a
function exactly. Also when you want to when you're already dip in an ecosystem,
for example, when you want to you want to react to events,
say, you know, like streaming events, do something and do something else
and trigger something. Gain action functions are very good for that because they just
get caught when that event happens, especially if it's an event that doesn't happen
constantly. You know. Yeah, hey, can you tell us the delivery
hero story? Because I love hearing about people losing millions of dollars. I
know, I think the delivery hero story is not that. I think it's
a story most of us have experience, maybe you know, at different scales,
and what happened was that? Wait? Wait, what is delivery hero?
Because I don't know. This is a popular in the United States,
right, but elsewhere this is like this uber eats kind of thing. Yeah,
So deliver Hero is this company of companies. That's why the brand is
not as popular. But it's a company that owns I would say, most
of the food delivery brands outside of China. So if you think of Global
or food Panda, you know, depending on where you are food, but
they only deliver Hero sandwiches. No, most of the brands that are owned
by deliver here, Like there's an online pizza brand and I think they only
deliver pizza. But then the other regular Uber eats style right brands? Yeah,
yeah, and I see, like this is not North America, this
is South America, Europe, Africa, Middle East, Southeast Asia. Exactly.
Interesting, So what were the API issues that lost two million dollars?
That specifically was a migration, so it had to migrate. We were writing
a service, so we're writing just taking out a little bit of a monolith
to be a separate service. And this service was the sech and discovery experience
where you could set for food for most of these apps and get the list
of dishes. And so we implemented this. So my team then we implemented
this service like you would write, you know, we we tried to get
the specification of the endpoint that we're migrating. But you know, with legacies
services that documentation might not always be the best, so well, that's a
very polite way to put it. So yeah, so we of course did
the manual a way as well, which would be that you you know,
copy the request and maybe difits use that as as the infut to implement this
new service. And when it was time to roll out, we even went
to step further that we would we run both of them on staging and you
know, differing, so when a request comes, to send it to the
legacy service and also send it to the new service, and then put requests
together to make sure that you know, we was doing exactly what was right.
So you're you're literally just white boxing this. You can't see what the
original code is. You're just saying, if I do am I getting the
same outputs for the same input on the old one as the new one,
exactly. So this the old code was really it just it's just some I
don't like you said the word legacy, but it was one of these services
where most of the original authors were no longer in the company. They're gone,
Yeah, yeah, they're gone. Totally normal exactly, and it's difficult
to you know, to get dip into the weeds properly. But even with
this care, defering all the requests, writing as much tests as possible,
when we went to production, thinks they went crazy, you know, So
did you know right away there was a problem or did it just was losing
data missing things? So when we went to production, obviously we you know,
we have the deployments checklists, you know, check that things are still
working as expected in as many countries as possible, but we didn't check every
country because we were perating were at the time we were put it in fifty
five countries. You know, we're not gonna test fifty five countries. Yeah,
And so what happened was that in scandy In some of these countries,
specifically in Scandinavia, they have a leg lego we requirements that food delivery companies
have to include the dietary requirements of any dishes that they offer. Right,
none of us knew about this requirements, Like, I had no idea requirements
what requirements? So are these nutritional nutrition values all that kind of stuff,
exact cast whatever, and also allergies and things like that. Okay, yes,
but this was a requirement only in Scandinavia. The other countries couldn't curt
us. So everything worked perfectly in the other countries of course. So you
just you just turned off. So did it fail in Scandinavia or did you
not provide the data or did you get sued? Yes, we're just just
crashing in Scandinavia, so wine exactly. So a couple one hundred thousand people
didn't get their Ludificit deliveries. Yeah, So that that's basically what happened.
And it seemed like a selly thing, you know, just a couple of
missing fields. We had pretty good monitoring set up we have, you know,
we try to do things carefully with this migration, but that did not
prevent us from running into this trouble and maybe start thinking, you know,
why can't we automate catching you know, breaking changes or any kind of issues.
So that is basically what happened. You know, we most of us
have been there, so yeah, yeah, I know the pain. Maybe
not that much money, but I know the pain. Yeah, we have
to be very careful, do you like that's the whole point, Like,
be more careful next time. Isn't a good strategy? Like we should be
able to not be careful and we can't do harm. You know, what's
a good idea is to have a lunch and pass around the Arizona missions insurance
policy that your company has, and it tells you what you're on the hook
for. And you know, typically in one of those policies, it'll list
right there failure to prevent a denial of service attacks for example. So if
you're publishing an API and you don't have any kind of throttling on that API,
you could be sued for one of your downstream customers having a denial of
service attack. How about that? I'm just shocked at Jillie. That is
in a lot of contracts. Well, it's in an insurance policy. The
kinds of things that it would cover. Yeah, well, I mean first
problem with reading insurance policies is staying awake. Yeah. The second problem is
it will just strike you with fear at all the possible risks. You know,
but that's a good thing to know, Like, what what are the
things that the insurance companies are concerned about in terms of aris and omissions that
you should kind of you know, think about. Yeah, not the litigating
is ever is likely to provide a useful outcome. Now I don't want to
avoid that. Yeah, winning a lawsuits like winning an earthquake, right,
Like, there's no good outcomes there, right, So that the key is
to not get suited in the first place. Yeah, try and try and
work this out. So is was this the story that led you towards API
toolkit? Yeah, it is precisely this. But you know, all through
our careers, we've we've faced a lot of these little issues that kind of
stack up in the back of our minds before even a delivery. Here.
I used to work in a at a basically a digital bank, you know,
and with these digital banks we have, we still have to work with
dead parties. M So the dead parties could be other aps like MasterCard or
other banks. In this case, it was in Nigeria, so we had
to communic get with other bands and the national into band settlement system. And
it was very common that, you know, these tech parties would either just
go down or they would just introduce breaking changes. It could be something as
simple as we're naming a field, you know, maybe someone named the field
messages before and then some new engineer says, why is this messages it's always
one message and then changes it to a message harmlets from his perspective. But
you know, no one was prepared for that. I worked on a project
once where the architect had every field be an array instead of just a single
value. In the event that someday down the road, perhaps perhaps you might
want to pass two of those values instead of one. Yeah, that was
a lot of fun, to be fair, We don't know the trauma or
that experience before that made him do that. Yeah, that's that's but you
know, there's there's preparing for trauma, and then there's just common sense being
agile, right, all right, So we haven't really talked about what API
toolk io is. If you go the API toolk io, it says AI
powered API observability, quality assurance, and insights. So give us the elevator
pitch there. Yeah, that's a lot of words, but the whole idea
is, you know, we already have a lot we have our monitoring platforms
already, but can't we go step lower you the most monitoring platforms would catch
several issues, maybe some logs and any errors you put in your lugs,
maybe, but do we go step for them, actually analyze the payloads you
know, will requests body and response body that your customers are making to you,
but also that you are making to tear party integrations. And it is
and the reason is that and not every error is going to be an error
in your log or an exception that you can catch. Some errors could just
be you know, missing data, something was renamed, or an error that
is coming from a dependence. I can give a story about this dependency because
there's something that happened. A customer had to deal with a library. You
know, it is simple date library, you know, and this date library
was created by an American, so but the diffault but it diffaulted you know,
the US date formats, which is I think it's month day and then
yeah, and there was this very long conversation in this on this library jub
that hey, we should use the international default of the day a month year.
And it went on for I don't know, maybe with a for years.
Then the author gave in and said, okay, let's make this change.
And there was I think a six months depplication. Notice it's just a
live you know, everyone no one's reading the git hop issues of all the
libries they use. So when this update happened. Eventually, it caused subtle
changes were for some customers the date field, you know, was now like
the international dates type. But that is a hard thing to identify it because
some days of the year are basically the same on both the US date and
the international and like fest of General eleven eleven ten exactly. I'm really surprised
that out of that meeting didn't come the solution, which is to separate the
date into three arrays, one with the day, one with the month,
one with the ear because that's clearly the solution that might have walked you,
to be honest. But in any case, it was a breaking change and
it causes company quite some money. So it was not the kind of change
that you would blame a developer. You know, maybe some developer was working
on a completely different task, decided to update some dependencies and now there's an
incident that he has no idea where it came from. So those are the
kind of issues I was thinking, can we catch them at the level?
Wow? Yeah, IO eighty six O one exists for a reason. It's
year, month, day just at least, you know, however you want
to display it after that, knock yourself out story. It is year,
month, day, right, what could happen? Yeah, it's a classic
words. So you feel like you could catch this from at an API level
to say, hey, this API is measuring up dates. Now it's doing
something down with dates exactly. So what what what we're doing is, it's
imagine a middleware on your service that every time a request comes into your service,
it just takes a copy, so it doesn't really impact your run time
or whatever. It just copies it and then you know, sends it somewhere
and that in that somewhere, which is a kid m we're like just learning.
We build a model of the API, so we learn what all the
fields are, whether all the different permutations of fields that are possible on this
API. You know what at the type is this field supposed to be a
uu i D or is this some random number? And with this model a
lot of things become possible. For example, if this representation changes, if
some field used to be a uu i D and all of a sudden it's
just a number or it's a text, right, and someone gets notified and
say, hey, this fields changed. Was it what you intended? If
it was what you intended, then just acknowledge it, but sometimes it's a
bug and someone can fix it. But I like the idea of you just
snap this onto the system and let it run for a month and it should
build up a pretty good catalog of all the shape of API calls out there.
Like in a month, you're going to figure out if you misunderstood the
day, feel exactly exactly. And it's like it's it's open to the developers
because you can just go. You can go and see all your endpoints.
Pick one of the endpoints and see all the different ships. You know,
at the end of the day, most endpoints don't have quite so many ships.
You know, maybe there's a lot of different status codes and then different
responses. I'm sure eighty percent of them are fine. You know, they're
all the same, and maybe it's even ninety five percent of the fine.
It's all the edges that matter. Sometimes you've got Scandinavians that requirements just to
highlight that, hey, there's an additional chunk of data in anything. Going
to these end points would have been enough flag for you at least look to
know, oh that's something weird there. We should go look there. Yeah,
appreciate, So we basically did that, and along the way we realized,
oh, now we're analyzing and building this model, there's much more we
can do, for example, So when I started to think, okay,
what what can we do? For example, we can generate open API specifications
from this model that we have now. And the next step is we can
generate simplistic h kind of API tests. You know, because you understand the
users journey on the back end, sure you can say okay, use our
logs in. Then it does. I can just generate some tests that can
now be auto make it and say, okay, make this call, make
this synthetic monitor call every one hour, you know, just behave like a
user and check that everything is as it should be. That's basically it.
So it's the It's the thing I wish we had at delivery here. Yeah.
Yeah, absolutely, if it existed, you probably would have got that.
I guess the question is the overhead Can I can I feel it when
this thing's turned on as a number of requests per second go down just because
you this is going to cost me something, it will cost you something,
and that's something depends on the technology stock. So if you're using a stock
like PhD, the challenge with PhD is that it's it's single process. Every
request is processed in a single process, right, so we can't just you
know, just do something behind the scenes, although we try and use a
lot of different techniques. But if you're using phper used to pain anyway,
right, But but you know the other technology stacks, you'd almost you would
notice. It's like copying of request happens in nane a seconds, micro sequence
max. The sending of the data. It's like if you have any luck,
you know, any telemetry, it's basically the same. You know,
it's just a synchronous maybe you get you spend a little bit more memory.
I mean, I just like this from an observability perspective to see, Okay,
well what do you see about what my APIs are up to? Like
we've talked in the past about Azure API management, but that's mostly about you
know, something that Carl mentioned earlier on which was going and yeah, can
you deal with throttling when a runaway process is calling it fifty times a second?
Certainly the most popular feature. So the unilease say that one bad actor
can't knock everybody else down. Yeah, no, you guys are doing content
analysis, which I think is a much trickier problem. Yeah, exactly.
We can't go on an Arctic proxy unfortunately, so we can't we can't trottle
anyone. That's a different thing. Use APR management for that. Yeah,
exactly. Hey, guys, holding that thought for just a minute, while
we take a moment for these very important messages. We'll be right back,
and we're back. You're listening to dot net Rocks. I'm Carl Franklin.
That's my friend Richard Campbell. Hey, and that's my new friend Anthony aler
Rebe. And yeah, he's talking about APIs and observability and the AI part
of this, which is really content analysis as he was just talking about.
I'm really interested in how you use your medical training to write better software.
That's that's an interesting question. Something that I that I have been thinking about
that I think could learn from the medical world is s OPS or against We
like to call it everyone's books in our industry, but in medicine, there
is an ESPN s P Standard Operating prosidure, So there's a standard operating procedure
for pretty much everything. You know, if you if your doctor is gonna
open your hearts, he's not gonna be like, oh, I'm feeling crative
today. Let's just go for it idea. Yeah right, I remember just
opening from the down from from down this time, but no, let's go
through the button transplant. Yeah. So, but it doesn't mean there is
no creativity happening in the medical you know, there still is. But there
is creativity happens with constraints. You know, when all the the common problems
are solved, then you can like you know, you can get like small
things at the time. And actually, like in software, we're always inventing
the same pop the same things over and over and over. There's a lot
of blog posts. If I want to create an up today, it might
be different from how I created an up last morning. Well, and I
do think we have that problem in software where no two projects are ever the
same. One could be excused by, hey, the stacks are advancing,
but the other is that we are prone to wanting to play with the new
toys. So you know, the opportunity to go, oh, I want
to play with this stack now, which not many. You know, that's
kind of service to us rather than service to the customer. The rather to
go with the stack. I already knew as well. Instrumented. You know,
has the pipeline set up for just resists. It's okay to work within
the same stack. There's innovations that can happen inside there. Well said,
I think that is basically it that you know we have as engineers. We
want to expect events, want to try new things. But if we can
just agree on some standard I don't know, base layers, you could move
that innovation step further. So maybe instead of everyone creating one more and plus
one framework that is I don't know, almost the same as the other,
we can start I don't know, innovating at I don't know, you know,
some of the things that are actually different, like our business logics or
the problems you really want to solve our performance. Maybe apps can finally be
faster and we can only innovate on how to make things faster, et cetera.
But it's something that I'm thinking about. Have you seen more maybe a
question for you, like in your experience, how much have you seen one
books being used in internal organizations? I mean more? Uh? And you
know, and when I hear run books, I think chef right? Is
there really the ones who popularized that net names? As I said, A
cid CD pipelines. There's a bunch of different approaches, but it's automation.
It's about don't open a word document, right, don't it's code. H
You know, today we look at GitHub actions or as your DevOps, like
in the in the dot net world, where often just checking the code in
accepting the PR kicks off the process that begins all those integrations, decks,
the rum book is activated, and I definitely see more and more developers.
Was like, I don't want to think about this. I want to get
as far as it worked on my machine, it passed my unit tests,
I push it up as a PR, we go through the review process and
the rest isn't my responsibility. The whole team took care of that. And
I think there's a natural cycle that devs go through or dev teams where something
new comes out and it promises to you know, be a little more complex
upfront, but then save you time down the road, right, And this
happens over and over again, and most devs resist that because they don't want
to go through the initial pain of learning something new and changing moving your cheese
and you know, changing their routine. But then you know, then they
see somebody else, just like going at one thousand miles an hour and things
are just happening, you know, Like the first time we interviewed Mark Rendel
Richard and he told us all about like all these crazy processes that he had
in automation that he was doing, and it was all manual and stuff.
And the first my first thought was, oh my god, I'm never going
to do that. But then I thought about, wow, the you know,
from thought to implementation to publishing can just be instantaneous, and how powerful
is that? Right? And then you know, after a while, these
devs adopt these things, but it takes a while. I have customers that
are still you know, living without source control. Oh man, can you
believe that? And I have to educate them and how to use GitHub before
before we can even start working. I found that interesting. Just like you
said, I've seen that run books are most popular in c I CIT you
know, or in deployments. You know, let's have a run book for
how to roll out the new service. And because we have those run books,
a lot of evolution happened, like like anty Ball and optio, you
know, having Docker for example. Just the benefit we have in our industries
that if a lot of if things are done over and over, it might
be possible to just you know, box it up into Docker or into some
library or something. But I I feel like it can be run books,
or the idea of run books could be applied even further to more things,
you know, And I mean, I'm not going to pretend can do the
how. But assuming we had more maybe an industry wide agreed upon run books
for a lot of things like maybe how do I beld X y Z or
how do I you can onboard even the more junior developers and you can trust
them to do quite a lot of task without being afraid because they're really just
following a run book and then allowed the creativity just happen. Maybe in creating
new run books for example, are we dancing around? The main thing here
is which is part of that pipeline is testing, right in automated testing,
so that the junior can't write a piece of code that's going to cause a
problem because the test is going to kick it back. You're not you know,
I think too many people think about the pipeline as just deploy this.
For me, don't think right, it's really just the continuous deployment part and
the only part of a continuous integration that's in there is compile it, which
really real integration is is this code suitable to be integrated? I very much
agree with that. Yeah, well, I think the tool your building here
is about I have collected data for how this API has behaved in the past,
so I can generate the set of tests for you that become part of
the pipeline. So if your new code doesn't comply with what we know is
the current way that the API behaves, it's not getting integrated. Yeah,
exactly, it is exactly that you know that we can catch. And if
you consider how as developers we always know the ideal, we know what we
should be doing. We know we should all be writing tests. But every
time I speak with a developer, I ask them, you know, like,
how confident are you in all the tests you've written? Do you feel
like the software you maintained right now is perfectly tested? It always feels like
anybody who says yes is lying, right, like the the that's the old
are you a good man? Anybody says you question, it's like the correct
answer is I'm not sure, Like arguably it's not up to you, right,
are you perfectly tested almost certainly. Not am I sufficiently tested? Perhaps,
Like there's no absolutes here, just just for the just for as much
for as I have. You know, at least I'm tested enough for the
last incidents that we experienced. Yeah, I'm not likely to fail on the
thing that knocked the system down last week. I'm not even saying certain about
that. I'm not likely to fail on that. I was a betting man,
Yeah, I kind of. I took it on the head for that
one already. And I think I've written the test that that that would catch
that before it gets deployed. Now, well, let's go to the next
one. Let's see what happens again. I think the most important thing here
is this idea that stated period of monitor of observability with this tool builds a
test suite for you, because who likes writing tests? And then and here's
a joke, like I write those tests, then we rev the API,
so the tests are wrong and we got to go again. Right, So
the idea that you could regenerate them after that is pretty compelling to me.
Like that's a bunch of work nobody really wants to do in the first place.
Yeah, Actually, this idea. Half of it came from something we
did at Delivery Hero, which is we used to have this lot test that
we would like write, you know with like case six, you know,
write some general tests to show I don't know, a million requests a minute
at the seven right, But they were always wrong because we had very good
cushion, so pretty much all the steps would just get cushion and the great
I don't just want. We got better results when we actually recorded, like
there are lots of what reques production work exactly, and then just replayed that
well, And that's because humans are weirder than testers. I mean, testers
are pretty weird, but humans are weirder still, Like, yeah, they
do stuff you couldn't even imagine to think of. Just think of little Bobby
tables. Here you go. No, my favorite one was working on a
site that was barely hanging on, like it was overwhelmed by the load and
the reaction. And part of this problem was that the customers when the first
page wind load, opened another window and tried again, and opened the window,
tried again, and so it's like one ip looks like it's own DDoS
attack and you get multiplied by ten thousand of those people and you you know,
you designed your tests where each ip made one request, one page was
and that is just not what was happening exactly us Just yeah, no,
this this recording the workload and then being able to play, you know,
a Saturday afternoon football tournament workload a bad one. And you would hope that
whatever workload you run includes Scandinavian countries. I think that's gonna be important.
Hopefully maybe that week all of Scandinavia. I was like, they were on
vacation. You missed it. Yeah, they need to get their lutafisk on
time. Can we talk about pricing here? I'm looking at pricing and there's
a free uh tier, a plus tier for twenty dollars a month, I
think yeah, and an enterprise for police call and so for free you get
what twenty thousand requests per month, build monthly, one team member on the
last fourteen days of data retained. So you can get aready checking this out
without without you know, any pain. Why wouldn't you? So how do
you hook this in? Like? Is this code I compile into my app
and deploy it or is this a service? What does this look like?
Exactly? It isn't middleware that you you know, you just added line in
your code when we started out. You know, there's been a lot of
movement in this e BPF space, and that was originally what I was thinking
about, but then I realized that, you know, if you want to
really help develop us, we want to give them as much context as possible.
Sure, and that context includes things like, you know, when when
this customer made this request and it failed, these were the exceptions that happened
right in the code at that time. And when we do things with the
e b p F for out, we don't have that context. And what's
in the code, you know, we have just the HDTP Yeah, you
want to be in that process, so you see all those exceptions occur exactly.
So, so it's a middlewhere you log, you put it in the
code, and it copies the request. If there are exceptions of the errors,
it attaches the errors that happen to the to that particular users. I
don't know log you know, so you can see, okay, this user
with this IP address made this request and got this response, but there was
an error with this tackt traits and whatever that happened in the meantime and you
picked. So that line of code is then an invocation to a service you're
hosting on their behalf or could they run it themselves internally, So that line
of code is India code. It's in your application, you know, and
you can so what is it calling to? Like, it's it's there's an
open source SDK for most languages, which what the KID does is basically copy,
you know, get all of this information for some cost them as they
have sensitive data which they don't want to even live there save us in the
first place. So it's able to redact that sensitive data and then just put
put the data on, just send it to API to KID. For some
enterprise customers, they also just run it on prem in that case, so
there is an on prem option if you want to pay for it. Exactly
in that case, it is just a ducker image you're configuring and it just
sends it there. That's great, And exactly what I was thinking is like
it's in many cases. In some cases like I want to say, they'll
leave my data center or my assurance then so it's contained and it had to
happen. It had to happen because I built this, because I worked in
a bank in the digital bank and you know half of the problem came from
there. But digital but are not gonna trust well, they're under regulatory requirements,
like they'll lose their license exactly. So what's next for you? What
are you working on? What I'm working on is basically this is just making
especially the things around testing. I'm trying to see what context we can get.
And you know, it's like you have all of this data. Every
time you look at you you're like, oh, I could do this.
So it's just you know, how can we make the life of developments better
with the data we already get in anyway? Yeah, wow, if you
can help me write tests for my API so I don't break it in the
next rev you're my friend. Yeah, this is good stuff. Yeah.
And to start with a free tier just to see does this make sense for
me? And it's like, yeah, your first HiT's free, you'll get
addicted. Yeah. And I think probably the takeaway message from this interview is
that this is not an API management replacement. This is content. You're you're
you're testing content and you're looking for that and using AI for that. So
thanks Anthony, it's been great. This is a great product. Thanks.
Thanks go. Thank you're welcome, thanks for us beinging this hour with us,
and we'll see you next time on dot net Rocks. Than dot net
Rocks is brought to you by Franklin's Net and produced by Pop Studios, a
full service audio, video and post production facility located physically in New London,
Connecticut, and of course in the cloud online at pwop dot com. Visit
our website at d O T N E t R O c k S dot
com for RSS feeds, downloads, mobile apps, comments, and access to
the full archives going back to show number one, recorded in September two thousand
and two. And make sure you check out our sponsors. They keep us
in business. Now go write some code, see you next time. You
got jud Middle vans Man