Speaker 1: And here we go another episode of Adventures in Dead Ops.
Speaker 1: Just in case you had this cup and you listening
Speaker 1: to your podcast player and a new episode popped up.
Speaker 1: This is Adventures and Dead Oops. I'm the host, Will
Speaker 1: Button joining me as always, Warren Parade, CTO of offers
Speaker 1: what's going on?
Speaker 2: Warren, Hey, thanks for having me back.
Speaker 3: Well like usual, I've really been struggling with a number
Speaker 3: of MDMs solutions out there.
Speaker 2: That are now just choosing this moment to have a problem.
Speaker 2: I mean, we have.
Speaker 3: Crowded before, and I think with Singapore Mobile Guardian just
Speaker 3: felt the need to make themselves known to the whole
Speaker 3: world as well by blocking out all their customer systems. So,
Speaker 3: you know, I think it really says something about mdm's
Speaker 3: maybe not the best solution for companies to be figuring
Speaker 3: out how to avoidicular security problems.
Speaker 1: I think it's Hollywood marketing theory. There's no publicity or
Speaker 1: no what's what's the phrase, I'm gonna butcher it now.
Speaker 2: It's no bad pr Yeah, that's the.
Speaker 1: One I was looking for. Thank you, because now everyone
Speaker 1: knows who those companies are, and so marketing is just
Speaker 1: having a blast with it. But today we are going
Speaker 1: to be talking about APIs because well, I'll save it.
Speaker 1: There's a lot to talk about there. But joining us
Speaker 1: in that conversation we have the co founder of Lunar
Speaker 1: dot Dev, which has been in the press a lot lately.
Speaker 1: I've been hearing y'all's name pop up a lot, and
Speaker 1: so I'm excited to have you on here joining us.
Speaker 1: Al Solomon, how are you.
Speaker 4: Man, I'm good, Thank you. Great to be here. Guys.
Speaker 1: I'm excited because APIs, you know, working from the infrastructure side,
Speaker 1: I'm never I'm never in anything other than awe at
Speaker 1: the number of external APIs. Our engineering teams managed to
Speaker 1: find somewhere on the internet creating account, get it in production,
Speaker 1: and then we never know about it until like we
Speaker 1: hit the free tier limit and then they're like, well, yeah,
Speaker 1: we need a paid account. It's like, wow, is that
Speaker 1: not something that we could have chatted about before production
Speaker 1: was down.
Speaker 4: Completely. I think that that's about like summarizing what the
Speaker 4: API economy is. I mean, sons of APIs, you get
Speaker 4: to go just connect, don't worry about it. I mean
Speaker 4: we'll meet later on in production and we'll see how
Speaker 4: things are doing. But this is like the essence of
Speaker 4: the API economy out there.
Speaker 3: That's an interesting perspective really, Like I'm not sure how
Speaker 3: much I've seen that, uh, but it really makes me
Speaker 3: think of that meme of a Chappelle with the math,
Speaker 3: whereas like I think it was cold, it was like,
Speaker 3: you know, you got any more of the you know
Speaker 3: free tr you know, really messing out there.
Speaker 1: For sure. Well we're going to dig into that a
Speaker 1: lot more. But first, give us a little bit about
Speaker 1: your background and what led you to co founding Lunar
Speaker 1: dot dev. Like what what decisions did you make in
Speaker 1: life it made you think that this is where you
Speaker 1: needed to be.
Speaker 4: Wow, that's that's a big question. This is me procrastinating
Speaker 4: and on all of my big, biggest decisions so far.
Speaker 4: That's a heavy one. But no, sol, I'm the co
Speaker 4: founder of Lunar Dev. I've founded Lunar with my close
Speaker 4: friends for the past thirty years, which is roy is
Speaker 4: the city of the company. We've been around since first rate.
Speaker 4: Actually the both of us are engineers and cybersecurity engineers
Speaker 4: in particular. This is like our background, low level understanding things,
Speaker 4: which is not exactly what Lunar does. But taking that
Speaker 4: mindset of cybersecurity, and you know, understanding the tool set
Speaker 4: that we got, we thought that there's like a lot
Speaker 4: of problems to solve when it comes to optimizing. At
Speaker 4: the beginning, you're thinking that, I mean, naturally, you're shifting
Speaker 4: towards optimize an infrastructure like the infrastructure that you run
Speaker 4: upon the cloud infrastructure. There's some cool startups in that direction.
Speaker 4: But I think that the signals that we picked up
Speaker 4: along the way is that listen, infrastructure, cloud infrastructure. That's cool,
Speaker 4: but me, as like a heavy consumer or third party APIs,
Speaker 4: this is what bugs me at the end of the day.
Speaker 4: This is what I'm trying to optimize on a monthly basis. Uh,
Speaker 4: this is like where my building sky rockets, and like
Speaker 4: hearing that sound and talking with other companies. I think
Speaker 4: that along the way we've connected the dots the dots
Speaker 4: and understand that, like the natural progression is that if
Speaker 4: companies move from on prem to the cloud and then
Speaker 4: they consume it in the in abundance, all that resource
Speaker 4: and that that resource needs to be managed and optimized.
Speaker 4: This is stage one, but as companies progress to be
Speaker 4: much more consumers of of APIs, like the subs perspective,
Speaker 4: of things that calls for another management and optimization here
Speaker 4: on top of it. So it kind of like led
Speaker 4: us like over month to the understanding. It wasn't like
Speaker 4: a one a ham moment that that like foreg our minds,
Speaker 4: but it was talking with different companies understanding that even
Speaker 4: though they're thinking that it's a different problem for each
Speaker 4: and one of them, it all boils down to the
Speaker 4: same problems, to the same type of middleware solutions. And
Speaker 4: then like the I think the inception of Lunar came
Speaker 4: to be that Okay, we can be that platform that
Speaker 4: can build that management and active control on top of
Speaker 4: your eCos, traffic, your the third pardies it as you're consuming.
Speaker 4: So that's like the story in a nutshell. Obviously we've
Speaker 4: done ap integrations, we've been optimizing them on our own,
Speaker 4: uh previously, but when we did it back then, we
Speaker 4: did the connect to dots. Only when talking with a
Speaker 4: lot of companies, we understood that, Okay, there's like a
Speaker 4: coming denominator among all of those companies.
Speaker 1: Yeah for sure. So like from my perspective, there's there's
Speaker 1: this array of APIs that's your application consumes. Each one
Speaker 1: of those has a separate building agreement, a separate tier,
Speaker 1: there's a PI keys that have to be managed for that.
Speaker 1: There's uh rate limiting. Each one, you know, may have
Speaker 1: different ways of showing that you're you're being rate limited,
Speaker 1: or how they return errors. You know, we won't even
Speaker 1: go down on the path of the APIs that return
Speaker 1: an HTP two hundred with a Jason blob that says
Speaker 1: error inside of it to let you know that there's
Speaker 1: an error. But like, those are all of the different
Speaker 1: things that you have to deal with when consuming the
Speaker 1: APIs for your application, and so it can be a
Speaker 1: lot of work. Like that's all work that is necessary
Speaker 1: for your application, but it's not really considered as part
Speaker 1: of building an application. I think a lot of us
Speaker 1: don't think about that.
Speaker 4: You know.
Speaker 1: We think about, oh, we've got to write our functions,
Speaker 1: we've got to build our Docker images, we've got to
Speaker 1: build the UI, and where should we put the button
Speaker 1: on the screen, you know, and we tend to overlook
Speaker 1: that until we have a production outage because of one
Speaker 1: of these API issues.
Speaker 3: He's really got some like past drama here.
Speaker 1: Right, this is we can just we can build this
Speaker 1: episode to my insurance company is therapy?
Speaker 3: I mean what I will really like even the two
Speaker 3: hundred with the error code and the body like, I'll
Speaker 3: take that over an API which does something either monetary related,
Speaker 3: physical related, or timeliness related and doesn't offer itempotency.
Speaker 2: Yeah, it's just and there's those there are those that
Speaker 2: are out there, and it's sort of ridiculous.
Speaker 1: You know.
Speaker 3: Can you go and talk to these companies and make them,
Speaker 3: you know, offer item potency, you know, automatic retries that
Speaker 3: don't double bill or don't send messages or emails to
Speaker 3: a user twice, Because I'd really like that.
Speaker 4: So you would imagine, right, I mean, if we can
Speaker 4: only talk with the entire API economy out there and
Speaker 4: and make sure that they're aligned in the same way
Speaker 4: so that companies will consume them better, which is one
Speaker 4: option that you can do. But the other option is saying, listen,
Speaker 4: this is a consumption problem. So let's put focus on
Speaker 4: the consumer another provider. Let's give active controls to the
Speaker 4: consumer and make the unified consumption layer or mediation there
Speaker 4: on top of it. I think, will you said it correctly?
Speaker 4: I mean most of the focus so far when it
Speaker 4: comes to third party APIs is around integrating with an API.
Speaker 4: We gotut tonnels of them. Either you're doing natively and
Speaker 4: you got or you doing with an iPads, you're doing
Speaker 4: with the marketplace. You got a lot of those solutions
Speaker 4: in place. They're been around for years, but there's not
Speaker 4: that much focus, if any, on the post integration side.
Speaker 4: Post integration is what happens when it's already running in production.
Speaker 4: Now there's a diff there's a difference between when you
Speaker 4: integrated with an API, with that API and now you're
Speaker 4: running production because in production, first of all, scale obviously,
Speaker 4: like immense scale that you couldn't test in staging, things
Speaker 4: tend to break and tends to break over time because
Speaker 4: scale get bigger over time, outages and the actual way
Speaker 4: that the API provider is behaving, you know, breaking changes,
Speaker 4: stuff like that. So that's something that you maybe maybe
Speaker 4: didn't encounter during development stage, but in production it's bound
Speaker 4: to happen. And I think there's less also less visibility
Speaker 4: and real time monitoring on the way that those APIs
Speaker 4: are interacting. You're interacting with those APIs, so there's a
Speaker 4: lot of unknowns and not a lot of focus on
Speaker 4: what it comes to do with managing those APIs in production.
Speaker 4: And this is where things begin to break. Companies begin
Speaker 4: to as as you described as you well describe it,
Speaker 4: I mean along the way when it breaks, you hear
Speaker 4: about it, and then obviously it takes time to understand
Speaker 4: does it something that has to do on the provider
Speaker 4: side or on my back end, So a lot of
Speaker 4: investigation over time, troubleshooting. It is a problem, and it's
Speaker 4: a problem that companies are like, you know, bearing with
Speaker 4: them along the way, and so it's mostly on their
Speaker 4: own trying to build those things on their own as
Speaker 4: they progress and as they grow. So definitely a problem.
Speaker 3: Yeah, I mean I totally get it though, because even
Speaker 3: with the ipass solutions or embedded eyepass, with the integrations,
Speaker 3: it's sort of this area where you see it as
Speaker 3: a blocker to start your project or start the integration
Speaker 3: to get the business value out. But it's just like security,
Speaker 3: I feel like it's one of those things where you
Speaker 3: can ignore it upfront and not think about it, and
Speaker 3: then later it's going to immediately bite you and take
Speaker 3: down your whole platform because the quote unquote project you
Speaker 3: started in your company to integrate with whatever that third
Speaker 3: party provider is is over.
Speaker 2: You know, maybe the team is gone.
Speaker 3: And so if you didn't start with the thought in
Speaker 3: mind of how are we going to make sure that
Speaker 3: this integration is successful over time, you're likely not in
Speaker 3: a very good spot where you can just do a
Speaker 3: little extra work and get the value out. You likely
Speaker 3: need a real tool to make the difference.
Speaker 4: I please agree with you, and I'll also refer to
Speaker 4: what you're saying in a term of resilience and availability.
Speaker 4: If you didn't thought in advance of okay, something is
Speaker 4: bound to happen with that third part API then, and
Speaker 4: you didn't thought of those retris in place, those circuit breakers,
Speaker 4: those fallback functions. So if one API goes down, you'll
Speaker 4: switch to the alternative. If you haven't thought about that,
Speaker 4: and by the way, most companies don't think about it
Speaker 4: until they encounter those things over time, then definitely, I
Speaker 4: mean things will be impacted. And the thing is that
Speaker 4: now these days, third party ap APIs SLA as a
Speaker 4: direct impact on your products. SLA. I mean, as we said,
Speaker 4: if there goes down, if they're malfunctioning, so does your product.
Speaker 4: So that's the mindset that we're trying to advocate to change.
Speaker 4: I mean, you need to think about your integrations, not
Speaker 4: in day one, but like in day one hundred when
Speaker 4: things will begin to scale and break, and what type
Speaker 4: of resilience have you put in place. That's the mindset
Speaker 4: that it's being active with the right integrations and with
Speaker 4: your maintenance over time.
Speaker 1: Yeah, and so one approach to this is you can
Speaker 1: do that yourself. You know, you can build in the monitoring,
Speaker 1: the alerting and and hope that you have the right
Speaker 1: error handling in place and do that for each API
Speaker 1: that your applications consuming. But I'm assuming that if we
Speaker 1: if I use something like Lunar dot dev, that I
Speaker 1: get a lot of that stuff for free just by
Speaker 1: using your platform.
Speaker 4: Right right, I mean worth maybe saying in a sentence
Speaker 4: about what we do and who we are. We're an
Speaker 4: API consumption management platform. We're giving that that tool or
Speaker 4: that platform for engineering teams to monitor, manage, and actively
Speaker 4: optimize their outgoing traffic. The way that the product works
Speaker 4: is basically by two components. So you got, first of all,
Speaker 4: the main thing, which is the egress gateway. This is
Speaker 4: where all of the API calls will run through or
Speaker 4: selectively the API calls that you want to manage. And
Speaker 4: you've got the component that will tunnel that traffic through
Speaker 4: the gateway instead of going to the actual provider. It
Speaker 4: will be tunneled or rerouted via the gateway. There's various
Speaker 4: methods to do so. You can do it with an
Speaker 4: SDK intersted of the traffic before encryption. You can do
Speaker 4: with you the company changing the URL and so it
Speaker 4: will be pointed to the gateway and at the head
Speaker 4: or on top of it. So there's like multiple ways
Speaker 4: of routing the traffic. But the main thing is that
Speaker 4: once the traffic is being routed to the Egress gateway,
Speaker 4: this is where you're seeing first of all, as you mentioned,
Speaker 4: visibility for the first time in real time. But what's
Speaker 4: important with visibility it's not just okay, those are my
Speaker 4: API calls. It's the actual performance performance understanding of how
Speaker 4: those APIs are interacting, Like what's their error, what's the latency,
Speaker 4: what's the duration that it takes for an API call
Speaker 4: to make it and make it back to your system.
Speaker 4: All of those things and much more. Those are the
Speaker 4: type of visibility there is lacking and you need that
Speaker 4: visibility to have all of those controls that we talked about,
Speaker 4: I mean, brasilience and keep track in terms of security,
Speaker 4: how much are you're enforcing security over your API interactions
Speaker 4: stuff like that. So the Egress gateway is there to
Speaker 4: provide it with visibility. But then on top of it,
Speaker 4: because the Egress gateway has actual controls over on request
Speaker 4: or response, you can have actual controls to modify the traffic,
Speaker 4: to change it, to shift it to orchestrate that traffic.
Speaker 4: And now you can enforce egress policies such as cashing
Speaker 4: API cost to throw party APIs for example, if you
Speaker 4: want to reduce some costs and avoid those redundant a
Speaker 4: PI calls, or maybe improve improve latency same aspect, or
Speaker 4: you want to define your own type of throubling mechanism,
Speaker 4: like the way that you're pacing, the way that you're
Speaker 4: making outgoing calls or queuing API calls by priority, all
Speaker 4: of those things which we can name as API middleware.
Speaker 4: Those are the things that once you're tunneling traffic via
Speaker 4: the gateway, you can have active controls upon so you
Speaker 4: can have better resilience as we talked about, you can
Speaker 4: reduce some costs, and you can have a better security
Speaker 4: and efficiency the way that you're interacting with those APIs
Speaker 4: without changing your existing infrastructure and your existing code.
Speaker 3: There's something about this that I really like because I
Speaker 3: feel like we've integrated with lots of platforms as a
Speaker 3: company and over my career, and something I keep getting
Speaker 3: back from support requests are, hey, can you send us
Speaker 3: your logs regarding that? And I'm like, our logs for
Speaker 3: calling your service? So that that thing that you're supposed
Speaker 3: to have, Oh yeah, we prone it after like two,
Speaker 3: three days or seven days. I'm like, I don't I
Speaker 3: don't know what to tell you, but like I'm not
Speaker 3: logging what's going on on your side, Like I don't
Speaker 3: have that ridiculous data. A matter of fact, you know
Speaker 3: of anything that's exactly the sort of thing that we're
Speaker 3: dropping intentionally unless there's a problem because I don't want
Speaker 3: to record unnecessary due look at.
Speaker 2: Data like that.
Speaker 3: Uh So you know, there's a there's a really interesting
Speaker 3: aspect here where you don't want it to be a
Speaker 3: first class application notion to have to care about storing
Speaker 3: these requestomer responses from a third party in a way.
Speaker 3: Either it's application data in which case you're storing in
Speaker 3: a different way in your database, or it's third party data,
Speaker 3: which like, don't you have that already that you can
Speaker 3: you know, use to validate whatever I'm talking about. So
Speaker 3: there is something huge here for support requests. And I'm
Speaker 3: wondering whether or not there's like a common offender that
Speaker 3: you find that like all your customers like, oh yeah,
Speaker 3: we use Lunar dot dev always with this platform or
Speaker 3: this platform, like there's a lot of mileage out of it.
Speaker 2: Can you talk about that?
Speaker 4: So I think that in terms of platform, I think
Speaker 4: that like the majority of our customers are interacting directly
Speaker 4: with the API provider because once again we can think
Speaker 4: about I mean, at least that's the pattern that we
Speaker 4: saw up until now. When it's a business critical API,
Speaker 4: you'll you want to have that direct connection. You don't
Speaker 4: want to be reliant on a third party that will
Speaker 4: tell you this and something brokes with your something has
Speaker 4: been broken with your API. So they're direct linkage with
Speaker 4: those API providers. I will say that the vast majority
Speaker 4: of the companies, I mean I'll shift the question a bit,
Speaker 4: the majority of them always want to start with visibility.
Speaker 4: I mean, first of all, let me understand what is
Speaker 4: happening out there. I mean, if there was sprawl, if
Speaker 4: there's lack give you discovery, give you catalog and give
Speaker 4: me an understanding in real time what is happening past
Speaker 4: that phase. You you'll be open to the understanding or
Speaker 4: the idea that those iterations might have problems and how
Speaker 4: can you remediate them. But I think that if there's
Speaker 4: lack a common ground among all the companies that we've
Speaker 4: seen is first of all, let me for the first
Speaker 4: time understand how my API calls are behaving, how that
Speaker 4: third party is interacting, so I can decide later on
Speaker 4: I want to actually want to shift and change and
Speaker 4: orchestrate the traffic so it can fit my business logic.
Speaker 4: I hope that answer to the question because I shifted
Speaker 4: it just yeah.
Speaker 1: I think visibility just can't be overstated enough because that's
Speaker 1: huge because that's the basis of your costs for APIs.
Speaker 1: It's it's consumption based pricing, and it's it's it's just
Speaker 1: critical to understand how often you're using these APIs, and
Speaker 1: it's really hard to do because if you have to
Speaker 1: implement it yourself client side for every single API that
Speaker 1: you consume, that's so much ated work. And if you
Speaker 1: try to get it to if you try to get
Speaker 1: it from the API provider, a lot of my experience
Speaker 1: with that has been that it's challenging to get you know,
Speaker 1: you're getting like four to twenty nine throttled, and so
Speaker 1: you log into their platform to see what's going on
Speaker 1: and they're like, yeah, you're getting throttled. I'm like, well,
Speaker 1: how much, how many requests are making? How long has
Speaker 1: this been going on? And that type of visibility is
Speaker 1: not there, and you've.
Speaker 4: Actually, i think stated not the worst use case, because
Speaker 4: those are API providers. They will give you some kind
Speaker 4: of an answer and understanding a dashboard to what is happening.
Speaker 4: You'd be surprised or not surprised how many APIs, I mean,
Speaker 4: how many APIs are not third party APIs meaning that
Speaker 4: the core offering of that company is not it's API.
Speaker 4: It's just something on the site, something that it has
Speaker 4: to do. Those are I mean I've heard someone, I've
Speaker 4: talked with someone just recently and he said, I'm going
Speaker 4: to classify the world of APIs into two sections. There's
Speaker 4: the APIs that you want to use, and the APIs
Speaker 4: are forced or must use. And those forced or must
Speaker 4: used those are probably poorly documented legacy APIs. I'm going
Speaker 4: to say, like a bad woord soap based APIs in
Speaker 4: some and those are APIs that it's hard to manage,
Speaker 4: it's hard to understand, like what is happening in real time?
Speaker 4: And and as you mentioned, it's it's it's an ongoing problem.
Speaker 4: And even if you did have a clear view among
Speaker 4: all of the API providers, like how much I'm a
Speaker 4: consuming real time when it's going to be when I'm
Speaker 4: going to hit those fourty nines, think about about the
Speaker 4: sheer amount of APIs that need to check each and
Speaker 4: every dashboard to get that understanding. I mean, it kind
Speaker 4: of goes show that you need to have active controls.
Speaker 4: You need to have that visibility from your side keeping
Speaker 4: track of it. I'm staying like, based on the tier
Speaker 4: that you've purchased, what is their usage over time when
Speaker 4: you're going to be bound by those forty nines And
Speaker 4: as we said, tech active controls upon that data. So
Speaker 4: if you know that like you're being bounded to hit
Speaker 4: those forty nine is like a week from now or
Speaker 4: maybe like a few minutes from now, then you want
Speaker 4: to change the pace or the order of outgoing API
Speaker 4: calls so you can prioritize your VIP customers. First, make
Speaker 4: those API comes first instead of the freemium customers for example.
Speaker 4: So visibility can go up to a certain degree from
Speaker 4: the provider side, and the vast majority of them are
Speaker 4: not giving me that full visibility. But then the controls
Speaker 4: of what happens and the actions that need to be
Speaker 4: taken upon that visibility, this is on you. This is
Speaker 4: the company, this is the consumer of the API. And yeah,
Speaker 4: this is like it is a thing. It is a thing,
Speaker 4: and it varies across the industries. You would imagine that
Speaker 4: maybe it's like just a subset of APIs. No freighting industry,
Speaker 4: travel tech industry, even like the companies that consume APIs
Speaker 4: on behalf of their customers. Think of all of the
Speaker 4: security posture management type of companies that they will do
Speaker 4: some kind of a scanning and posture management. Those are like,
Speaker 4: once again, another problem that is being opened up. Everyone
Speaker 4: has its own type of sickness and problems when it
Speaker 4: comes to consuming APIs, and everyone has been building their
Speaker 4: own top of mechanisms to deal with them and to
Speaker 4: gain that type of visibility so that they can act accordingly.
Speaker 1: For sure, I think the scale of this problem just
Speaker 1: gets more and more. I heard of a comment recently,
Speaker 1: and it's not one hundred percent true, but I think
Speaker 1: it resonates with some truth that we're not software engineers anymore.
Speaker 1: We're we just both differ and APIs together to get
Speaker 1: a different result.
Speaker 4: Someone told me that we're the some of all of
Speaker 4: the APIs were consumers. It's like being philosophical over here.
Speaker 1: That's great. I like that.
Speaker 4: Yeah.
Speaker 1: So in terms of working with with Lunar, what does
Speaker 1: it look like to use Lunar to solve this problem? Like,
Speaker 1: do you do all of your when you when you
Speaker 1: integrate with Lunar, do all of your API calls go
Speaker 1: to Lunar and then you relay them through there? Or
Speaker 1: or how does that? How does that work?
Speaker 2: Yeah?
Speaker 4: So, first of all, Lunar is a self hosted solution.
Speaker 4: We perceive ourselves as as a mediation there. So we're
Speaker 4: an infrastructure component. Companies are installing Lunar on their own
Speaker 4: managing it. You have the control plane. The control plane
Speaker 4: is as SaaS one, but the infrastructure itself, the egress
Speaker 4: and the routers of the traffic, those are self hosted.
Speaker 1: UH.
Speaker 4: Phase One of the of the product is saying okay,
Speaker 4: once you install the Egress product, the aggress gateway. Then
Speaker 4: you choose which APIs you want a tunnel. You can
Speaker 4: either choose to tunnel everything or from specific applications or
Speaker 4: just a subset of it. Once it's being tunneled, the
Speaker 4: first thing that you're getting is that discovery and that cataloging.
Speaker 4: That catalog has been is going to be filled up
Speaker 4: in real time based on the actual API calls that
Speaker 4: are making. The system can detect what type of API
Speaker 4: calls are being set outside based on the domain, uh,
Speaker 4: the way that domain looks like. And then once those
Speaker 4: API have been discovered, then you're getting that first of
Speaker 4: all visibility. You can either see it from the control
Speaker 4: plane that Lunar offers or from your data dog and
Speaker 4: whatever APM you're using. And on top of it, what
Speaker 4: we're doing this is like the next phase is on
Speaker 4: top of getting that visible in real time, we're saying, listen,
Speaker 4: we're detecting problems over here. We're seeing that I mean,
Speaker 4: you're surpassed a specific threshold of forty nine's for example.
Speaker 4: And then the active part of the system kicks in
Speaker 4: because now we can offer you policies we call them
Speaker 4: clows revidation flows that can have active controls based on
Speaker 4: that problem. If you're seeing a forty nine an, you
Speaker 4: want to paste the outgoing traffic in a way that
Speaker 4: you can define a R right limit policy. It can
Speaker 4: be a concurrency based, it can be a strategy based
Speaker 4: where you're holding a specific you know, pacing mind. So
Speaker 4: it can be also cache in some of those API calls.
Speaker 4: So every middleware that you can think of, we're implementing
Speaker 4: as we go into the system so that if you
Speaker 4: encountering a problem, the system will detect it over time
Speaker 4: and then can suggest you with a solution. A solution
Speaker 4: is just enforcing that policy on top of the gateway
Speaker 4: instead of actually writing it these days in code within
Speaker 4: your application. That's the way that like the system works,
Speaker 4: and people are onboarding additional APIs once they're gaining that
Speaker 4: trust with the system and then seeing additional problem with
Speaker 4: them enforcing them. Eventually, what we're seeing ourselves is that
Speaker 4: missing infrastructure layer too much needed. I think cloud native
Speaker 4: companies they're making API calls, they need something to manage
Speaker 4: and orchestrate that traffic. And this is basically lunar.
Speaker 1: I like the fact that it's self hosted.
Speaker 4: Yeah, I think that it's something that we grew upon
Speaker 4: I mean it grew on us. I mean I mean
Speaker 4: that maybe it was an easier decision to start us,
Speaker 4: but we understood that in terms of we don't don't
Speaker 4: want to deal with the cost of the outgoing API
Speaker 4: calls if it was a SAA solution, We don't want
Speaker 4: to have some kind of a risk in terms of
Speaker 4: PII being leaked outside like actually API cos of companies,
Speaker 4: and we want to have as low latency as possible.
Speaker 4: Obviously this call for a cell as solution, and this
Speaker 4: is like where the system and the product shifted towards
Speaker 4: right on.
Speaker 3: We had a similar discussion actually internally for our products.
Speaker 3: But since we're not a proxy, two requests, it's a
Speaker 3: sort of a second request that just goes somewhere else,
Speaker 3: and so in that regard, it's not a concern for
Speaker 3: us being a SaaS. But given that a model is
Speaker 3: having the request go through the gateway, you would need
Speaker 3: realistically the gateways as close to your customers, between your
Speaker 3: customers and their users everywhere those users are, which is
Speaker 3: even more ridiculous problem than what we realistically have. And
Speaker 3: I can definitely see that I have to ask it's
Speaker 3: not like you're hijacking tls sor it's to proxy the
Speaker 3: traffic you have like some sort of HHDP SDK that
Speaker 3: you use instead of whatever the default rest or HDP
Speaker 3: client or soap client is that the actual application is using.
Speaker 4: I guess that's right. I mean, if it's an est gate,
Speaker 4: we're's acting the traffic and then she depeat just before
Speaker 4: it's being equipted on that traffic, and then the ntail
Speaker 4: list will take place from the gateway to the third
Speaker 4: party appear.
Speaker 1: Good call out, Warren, it's man in the middle as
Speaker 1: a service.
Speaker 3: Well, I mean, you know, it's funny what you're talking about,
Speaker 3: because almost ten years ago, I feel like we were
Speaker 3: in this spot where all the problems you were talking
Speaker 3: about were exactly the things that we were dealing with.
Speaker 2: And it wasn't about production.
Speaker 3: It was like, we're calling out from our service to
Speaker 3: another service internally in our company, managed by a different team,
Speaker 3: and they can't handle the load that we need to
Speaker 3: support our customers. And so we added in a middleware
Speaker 3: in c sharp as it was to basically buffer the
Speaker 3: request going out to make sure we didn't hose them
Speaker 3: by sort of rate limiting ourselves and try to do
Speaker 3: some traffic shaping there, and like that was one of
Speaker 3: the things we did because they couldn't be trusted to
Speaker 3: handle real requests, which is just absolutely so ridiculous, And
Speaker 3: we open source that and like other teams started using
Speaker 3: it in the company, which is like the opposite of
Speaker 3: what you think when you want to deal with requests
Speaker 3: coming in and you're like, oh, well, you know, we
Speaker 3: want to rate limit them. We were like self rate limiting.
Speaker 3: And that wasn't the only time, Like, there were a
Speaker 3: couple other situations. The biggest one is, you know, I
Speaker 3: don't know how much I want to bring this up,
Speaker 3: but like one of our competitors in the off space
Speaker 3: they charge for individual client JWT token generation, and lots
Speaker 3: of times the application you have on your side of
Speaker 3: the service or micro service or whatever doesn't have a
Speaker 3: good idea of how to cash right. There's a lot
Speaker 3: of concurrency and separate containers being spun UF especially functioned
Speaker 3: as a service, and so internally there was a team
Speaker 3: at our company who wrote a proxy to like our
Speaker 3: now competitor to cash these requests and just return an
Speaker 3: outdated token if it was still valid. I'm just like,
Speaker 3: if you know you're running into these situations. You really
Speaker 3: have a couple of options here. Number one is, you know,
Speaker 3: please pick a different provider. Like you know, there's multiple
Speaker 3: third party providers. Some of them don't charge you for
Speaker 3: that ridiculous notion, while other than are. And obviously the
Speaker 3: second option is, you know, go build your something yourself
Speaker 3: to prevent making these calls. And the third one is,
Speaker 3: I guess you know, now just use lunar debt.
Speaker 2: That's an obvious answer.
Speaker 4: Thank you, Warrence, first of all, but I'm with you
Speaker 4: on that. I mean, first of all, what you're saying
Speaker 4: is really interesting to think the bigger companies that were
Speaker 4: spoken with that problem that lunar is position itself like
Speaker 4: active controls, the third party API conception. This is an
Speaker 4: internal problem because there's serving so many in like inner
Speaker 4: API calls that their services are being like they're having
Speaker 4: their own domains. They're like a third API to the organization.
Speaker 4: So that's like a thing. And I think that that pattern,
Speaker 4: as we talked just talking about it, this is like
Speaker 4: a common pattern. I mean, it's not it's not rocket
Speaker 4: rocket science in a way, but but the pattern is
Speaker 4: that companies have been building it on their own. Now
Speaker 4: we can discuss whether it makes sense to build it
Speaker 4: on their own. But I think that the main argument
Speaker 4: that I'm going to make is that why would you
Speaker 4: build it on your own? Yeah, you can build that
Speaker 4: type of gateway on your own. It's take it ticket proxy,
Speaker 4: choose whatever you want, choose engene x, choose a j proxy.
Speaker 4: You can build it. Question is why, though, I mean
Speaker 4: why building something to maintain third p d API integrations
Speaker 4: where your core purpose is innovative and like bring new
Speaker 4: value to the actual product that you're building, so that
Speaker 4: maintenance over time, it's it's something that it's like seamless
Speaker 4: to the I, but over time you're seeing that you're
Speaker 4: dedicating much more task force to manage that infrastructure, to
Speaker 4: make sure that it's scalable, that it's not a single
Speaker 4: point of failure. I mean, it becomes another thing on
Speaker 4: another animal on its own within your infrastructure. So we're
Speaker 4: saying in that build versus by dilemma, you should really
Speaker 4: think technical consideration, how much time will take you to
Speaker 4: build it and maintain and maintain it, and whether you
Speaker 4: need to do it as part of your core purpose.
Speaker 4: Like our claim is that you don't have to know
Speaker 4: and so you can you know, use it, you can
Speaker 4: work with us and as you go stuff like that.
Speaker 4: So yeah, I think that we're trying to shift it
Speaker 4: partim of you don't need to build it on your own.
Speaker 3: Nay, yeah, I mean one of the things that really
Speaker 3: comes to mind is that with larger companies, their products
Speaker 3: with well oiled APIs, and there's very few of them
Speaker 3: out there that I'm like, oh, that's a good API.
Speaker 3: I think one that comes to mind often is strip
Speaker 3: you probably maybe don't need a solution like this, But
Speaker 3: there's so many companies out there that are making APIs
Speaker 3: where it's not their core competency and they're not good
Speaker 3: and if they offer I can't believe I'm saying this.
Speaker 3: Some companies don't offer multiple API keys to interact with
Speaker 3: their APIs. And so if you have multiple like if
Speaker 3: you have a company a product that interacts with one
Speaker 3: of the chat services, they have an API and you
Speaker 3: only get one API key per chat bot, and so
Speaker 3: what would you do if you had multiple teams in
Speaker 3: your company that both needed to access that chatbot, you know,
Speaker 3: utilized services because you have maybe two pizza teams and
Speaker 3: micro services and so it's not even a matter of
Speaker 3: building the competency yourself. It's really like, are you going
Speaker 3: to build this chat bot application proxy just to communicate
Speaker 3: with that thing? And like what would go into that event?
Speaker 3: And so it's not like you just build something yourself.
Speaker 3: It's like you really need a core thing here in
Speaker 3: order for.
Speaker 1: It to work.
Speaker 3: And well, there's an open source solution to just go
Speaker 3: and cross that chasm right away without having to.
Speaker 2: I mean, you're not going to build this into your sort.
Speaker 4: There's no way you can.
Speaker 3: Split an apike into two services. Like that's not even
Speaker 3: an option, right, You're going to build a proxy.
Speaker 4: And some Sorry I like that. I mean, this is
Speaker 4: a truly interesting thing that we actually seen and because
Speaker 4: we've heard it from customers who developed it. And I'll explain.
Speaker 4: This is a problem where you have multiple consumers consuming
Speaker 4: the same API key. Now all those consumers are sharing
Speaker 4: the same quota. Yeah, it's so until you've hit that problem,
Speaker 4: if you want to rate limit based on a single key,
Speaker 4: I mean, you can do it rather easily by with
Speaker 4: code in your application. Once you need to distribute the
Speaker 4: quota among different consumers, you've got to have something in
Speaker 4: place which is like that that single point which is
Speaker 4: a proxy or gateway. Now what we've done in that
Speaker 4: perspective is saying, listen, if we're in possession of that
Speaker 4: API key, then we can generate subkeys or few or keys.
Speaker 4: Those sub keys can be find better find grade control,
Speaker 4: meaning that you can have a subset of the quota
Speaker 4: being assigned to every key. So first of all, you
Speaker 4: can have granular controls over that sub key. So now
Speaker 4: production and staging will consume eighty twenty percent based on
Speaker 4: your logic for example. But the thing that you're getting
Speaker 4: on top of it is also a security enhancement because
Speaker 4: now no longer will the developers will have or the
Speaker 4: threat of having the actual key in plain sight. You
Speaker 4: will have always that generated subkey that will be translated
Speaker 4: within the gateway to the actual key and make those
Speaker 4: API calls. So all of those mechanisms in place will
Speaker 4: have to take place with a proxy in the middle.
Speaker 4: And it's an it's like an it's a non issue.
Speaker 4: I mean, as you said, this is like chat what
Speaker 4: is one option, But we've heard it all across the board,
Speaker 4: so that's like, this is one of the interesting patterns
Speaker 4: that we saw along the way with API consumption problems.
Speaker 4: It varies across the industries by the way, first across
Speaker 4: company sizes. It's one of those interesting takes. And then
Speaker 4: adding on top of it, think that maybe you want
Speaker 4: to regulate the traffic based on a cue base, so
Speaker 4: staging will be prioritized more production than staging, so you
Speaker 4: want to pace that traffic. You can do all of those,
Speaker 4: all those type of middleworm manipulations. Was you got that
Speaker 4: proxy in place or that get way in place.
Speaker 3: I'm sparking a little bit because you said, you know,
Speaker 3: there's no there's no other way around this, and I'll
Speaker 3: tell you one because I've seen it in practice where
Speaker 3: all the services log their own usage and then export
Speaker 3: it to a third party system where they try to
Speaker 3: aggregate the usage backup to understand what's actually happening after
Speaker 3: the fact. And it just seems so nonsensical to try
Speaker 3: to log this data within the service because you're like
Speaker 3: it was bad enough before where you were sharing something,
Speaker 3: but now you're adding a lot of complexity to your
Speaker 3: logging an observability system just so that you can pull
Speaker 3: out this non application related metric that really has nothing
Speaker 3: to do with the application at all.
Speaker 4: And I will give you another method, actual method we've
Speaker 4: heard this is like a company I P O company,
Speaker 4: a big one same problem, one key, uh two consumers.
Speaker 4: They're sharing that data via mail, so they're establishing a
Speaker 4: protocol with email of saying listen, you will not surpass
Speaker 4: that threshold and I will take and if we'll have
Speaker 4: some kind of spillover, that will relate to you with
Speaker 4: another email message saying listen, I've got some of that
Speaker 4: quota left, so you can use it. This is the
Speaker 4: way that it works these days. I mean not these
Speaker 4: days it works for companies are not having that infrastructure mindset.
Speaker 4: It should it should be an architecture. I mean, this
Speaker 4: is what you're trying to advocate out there. So yeah,
Speaker 4: it can it can go. It can go rogue and
Speaker 4: worse pretty fast.
Speaker 1: I like the idea of issuing sub keys. That's pretty
Speaker 1: cool because it is very I don't I would, I
Speaker 1: don't know if the commons right word. But it's not
Speaker 1: unusual to see where you need to connect to the
Speaker 1: production grade API service to get the quality of data
Speaker 1: that you need. And so then you have a scenario
Speaker 1: where you have a dev application that they load test it,
Speaker 1: blue out your quota and now prod's dead for that.
Speaker 4: If I had if I had a nickel, I had
Speaker 4: a few nickels, right, I want to want to over exaggerate,
Speaker 4: but uh, yeah, completely agree with you.
Speaker 3: Yeah, I mean it's sort of ridiculous that these things exist, though,
Speaker 3: Like I would really like, Okay, you know, don't have
Speaker 3: to think about that. PROD and non PROD have different
Speaker 3: keys for different universes, and uh, there's no way that
Speaker 3: you could you could have a problem there and you
Speaker 3: would never need to share keys between different consumers because
Speaker 3: each consumer has their own key which has their own
Speaker 3: individual permissions there. Like that seems so table stakes to me.
Speaker 3: But I think I'm heavily influenced here because you know,
Speaker 3: we offer like API keys as a service within our
Speaker 3: own product, and I know not everyone's using it. Like
Speaker 3: I wish I could say, oh yeah, everyone's using everyone
Speaker 3: in the world using our products, so they have API
Speaker 3: keys as a service, you know, out of the box.
Speaker 3: But they're not like and these APIs like they're made.
Speaker 3: As you said, every industry has some technology which there's
Speaker 3: some way along the technology adoption curve for really API
Speaker 3: understanding like lax documentation or not even using JSON or
Speaker 3: binary format like compressed binary format to communicate, but they're
Speaker 3: using XML or SOAP or something else more ridiculous, just
Speaker 3: really unfortunately. I want to go back to under the
Speaker 3: rock that I you know, maybe live on der where
Speaker 3: it's a little bit nicer, where people aren't doing this.
Speaker 4: Yeah.
Speaker 1: So, you, Warren, you brought up the chatbot idea, and
Speaker 1: it made me think of the show prep notes that
Speaker 1: we had prior to the show, and in there you've
Speaker 1: got AI driven APIs. So can you elaborate on that
Speaker 1: phrase because I'm super curious to learn more about that.
Speaker 4: Yeah. So, first of all, I was looking at the
Speaker 4: and the counter of the of the recordings that we started,
Speaker 4: and it's minutes forty one since we brought up AI
Speaker 4: for the first time, which is like, which is cool. Yeah,
Speaker 4: I think that maybe like the way that that I
Speaker 4: want to approach that topic is not necessarily AI APIs,
Speaker 4: but the coupling that is now taking place and will
Speaker 4: take place with companies trying to embed some kind of
Speaker 4: an AI offering to them. So obviously, like the vast
Speaker 4: majority of them will are and will integrate with aiapis.
Speaker 4: I mean, you got a bunch of them these days
Speaker 4: competing over cost and accuracy. And the thing is that
Speaker 4: we can look at AI APIs like open AI and
Speaker 4: Gemini and whatnot as a subset of the problem that
Speaker 4: we've been talking about for the past forty minutes, which
Speaker 4: is like API consumption problems. But if you were to
Speaker 4: like dive a bit deeper, then we'll stand that even
Speaker 4: though there are another set of APIs, there's like something
Speaker 4: pretty unique to them. It's either the tokens that it's
Speaker 4: the currency that you're using. So every API cod being
Speaker 4: made with the prompt can be boiled down to a
Speaker 4: number of tokens, which will correlate with costs. And this
Speaker 4: is a problem on its own. I mean, how do
Speaker 4: you keep track over the tokens being consumed? How do
Speaker 4: you have active controls and regulation on API code based
Speaker 4: on the number of tokens the consumed and used. So
Speaker 4: this is like one aspect of it, and the second
Speaker 4: of second of an aspect of it is security, which
Speaker 4: is like we just I think stretching the surface. I mean,
Speaker 4: how do you make sure that you're not abusing that
Speaker 4: AI capabilities to extract something that you weren't meant to
Speaker 4: extract if you're I mean, if there's a malicious actor.
Speaker 4: How do you make sure that you're not like sending
Speaker 4: over those API calls sensorive data that you weren't supposed
Speaker 4: supposed to send. Those are like things that begins to
Speaker 4: be pretty unique with AI APIs that companies need to
Speaker 4: think upon. And I said that the last thing or
Speaker 4: maybe like the third thing is cost because those are
Speaker 4: cost the APIs. I mean you have to have active
Speaker 4: controls and predictions on how much will it cost you
Speaker 4: to consume those APIs, And then you need to do
Speaker 4: like the second phase, which is okay, if that's a
Speaker 4: cost the API, do I actually need to make that
Speaker 4: API call to cheat GPT like to GPT four, or
Speaker 4: maybe I can have it to maybe like a less
Speaker 4: expensive API, maybe like open source type of APM, maybe
Speaker 4: like hiding face or stuff like that. So a lot
Speaker 4: of consideration that needs to take place, which pretty unique
Speaker 4: to AI. And you need to regulate that traffic as
Speaker 4: you need to regulate it with other APIs out there.
Speaker 4: And I think that this is like the next phase
Speaker 4: of AI and APIs and the problems that associated with
Speaker 4: them and will only grow over time.
Speaker 3: I think you're underselling it here actually a little bit.
Speaker 3: If I think about it just a little bit longer.
Speaker 3: You actually have the capability of altering a hypothetical system
Speaker 3: prompt to restrict the responses back from AI enabled APIs,
Speaker 3: like hey, you know, prefects, whatever the prompt is that's
Speaker 3: being sent with, and your response should be less than
Speaker 3: one hundred characters or a hundred tokens long. And then
Speaker 3: you're sort of guaranteeing that extra security in there, which
Speaker 3: is something which isn't really necessary with non AI enabled
Speaker 3: ones where they don't usually count per tokens.
Speaker 2: It's usually maybe it's by data.
Speaker 3: Out, which isn't so common, but for sure way more
Speaker 3: common in the I space.
Speaker 4: Completely agreeing with you. Yeah, and you can also talk
Speaker 4: about hallucinations and stuff that really lacks sicknesses of AI
Speaker 4: APIs on their own and how you want to deal
Speaker 4: with it from the application that I mean, from the
Speaker 4: API calls perspective. So that's lack just the beginner of things.
Speaker 4: All we know that if you had to, if you
Speaker 4: had an infrastructure that will give you controls over requesting responses,
Speaker 4: and you can see that full visibility including the payload,
Speaker 4: which within the payload before it's been improveted, you can
Speaker 4: see the actual prompt and everything. Then you can have
Speaker 4: smart decisions that can take place from a security standpoint
Speaker 4: of view, you from catching a standpoint of view, you know,
Speaker 4: usage bay pattern stuff. So yeah, that's like another aspect
Speaker 4: to it.
Speaker 1: Yeah, that's crazy because when using uh an ai tech
Speaker 1: service like that, the scope of what you could send
Speaker 1: that is just limitless. And since there's direct costs associated
Speaker 1: with that, that's a whole new budgeting paradigm of evaluating
Speaker 1: is this the right use of this API or or
Speaker 1: should we do were doing something different there?
Speaker 4: Exactly. There's an ongoing debate whether over time you will
Speaker 4: need to shift between AI A PI, so let's say
Speaker 4: Gemini and open AI and Mistral because of accuracy and costs,
Speaker 4: you know, and based on your business logic, you will
Speaker 4: decide for those apichos, I want to have them vieah
Speaker 4: Opening Eye because it will be less expensive or maybe
Speaker 4: more accurate or the other alternative. This is like one
Speaker 4: aspect that maybe will unfold over time. But the other
Speaker 4: claim is that actually those AI APIs will converge and
Speaker 4: the best, like the big players out there, will kind
Speaker 4: of even out in terms of accuracy and cost, and
Speaker 4: then the only player that you have to play is
Speaker 4: with the niche. AI APIs those are that has been
Speaker 4: trained on a specific model. They will give you that
Speaker 4: fine brained offering to it. As I said, like, it's
Speaker 4: still the early days. We're not none of us know
Speaker 4: at that point of time what will be the way
Speaker 4: that companies will consume AI APIs at scale. All we
Speaker 4: know is that they will consume it at scale. They
Speaker 4: will have to regulate the traffic, have proper controls, see
Speaker 4: the prompt take actions accordingly, have visibility. So there's like
Speaker 4: a lot of things to be unfold. I think over
Speaker 4: time and I'll spark. Another thing here is that we're apatam.
Speaker 4: Now we've been talking about direct consumption of AI. I
Speaker 4: mean you're making some kind of a call and that
Speaker 4: has been streamed as an API called to to opening
Speaker 4: up for example. But the next phase that people were
Speaker 4: talking about and just starting to you know, unravel is
Speaker 4: those AI agents, which means that an agent will be
Speaker 4: able to make other API calls based on IS integrations
Speaker 4: with other systems that you have within the organization. So
Speaker 4: that AI agent will spark, like propagate a lot of
Speaker 4: API calls from other API integrations. Think about the sheer
Speaker 4: amount of API traffic that will be sent via that
Speaker 4: uncontrolled AI agent, that component that is not even like
Speaker 4: a human. This is like something that embedded within your
Speaker 4: own product, and now it was making all of those
Speaker 4: API calls, connecting so many places, making those I do
Speaker 4: you keep tracking it? So this is like another I
Speaker 4: think challenge on its own that will unfold over time.
Speaker 3: I mean, I think part of the struggle here is
Speaker 3: the value maybe not so clear, and so by the
Speaker 3: companies offering AIS as a service or APIs that give
Speaker 3: access to an AI as a service because otherwise they
Speaker 3: probably would charge by value and not by tokens. And
Speaker 3: then I think we'll get to a better state. But
Speaker 3: we've already gotten to the point where niches have popped up,
Speaker 3: things like sentiment analysis or image generation or so like.
Speaker 3: There are already this case where a single prompt may
Speaker 3: focus going into a different direction based off of whatever
Speaker 3: the sort of data that we're looking for. So I
Speaker 3: think both of your hypotheses are It's not a duality.
Speaker 3: Both of them are true. We'll get niches of AIS
Speaker 3: of having to select the appropriate model at the right
Speaker 3: time depending on the type of data that you're looking for.
Speaker 3: But we're already at the point. I think of the
Speaker 3: other fact as well, where individual companies are being more commoditized,
Speaker 3: like you like, oh, I don't care if I use
Speaker 3: Gemini or Opening Eye or Anthropics Claude model, like they're
Speaker 3: all like, you know, one's better than other.
Speaker 2: May be.
Speaker 3: I think those companies that have the most money, though,
Speaker 3: will be the ones that go forth and just do
Speaker 3: the Aw's better Rock thing, which is we're just going
Speaker 3: to call all the models from every company at once
Speaker 3: and use it to compare the results, because it offers
Speaker 3: a couple of different strategies.
Speaker 2: Actually.
Speaker 3: The first one is you know that the result is
Speaker 3: sort of higher probability to be right. The second one
Speaker 3: is that if one of the models has a security vulnerability,
Speaker 3: the other ones will actually refuse to return the same answer,
Speaker 3: so you'll know that there's a problem with the request
Speaker 3: of the prompt that's gone out there. So if you're
Speaker 3: just passing along the colors, you know, a data entry.
Speaker 2: But I think positioning.
Speaker 3: Yourself in this in this spot here does have a
Speaker 3: huge sort of untapped security aspect that I imagine today
Speaker 3: people may not even really be thinking about, but they
Speaker 3: should be.
Speaker 4: Yeah, an interesting perspective. What you said out there pretty cool.
Speaker 4: I mean I'm assuming that not of the not all
Speaker 4: companies will have the ability to just make a course
Speaker 4: to every API provider out there, But that's interesting. This
Speaker 4: This is also a way to, i think, to battle
Speaker 4: with hallucination in the way I mean take the answer
Speaker 4: of one model and then round the same like same
Speaker 4: thing on top of the other model and compare between them.
Speaker 3: I mean, if you're interested about this topic, there's a
Speaker 3: great GitHub repository that was created by Remy McCarthy and
Speaker 3: Clinton Gibbler of a TLDR where they went through like
Speaker 3: fifty different AI related papers, recent ones about how to
Speaker 3: deal with problem of the am models and real strategy
Speaker 3: is take the output from the model and pass it
Speaker 3: to the input of another model and say, hey, like
Speaker 3: regenerate the prompt and do this cycle or you know
Speaker 3: saying you know, split the the prompt into two pieces
Speaker 3: and run it against different models and then combining the result.
Speaker 3: And you do multiple of these things over and over again,
Speaker 3: and it sort of eliminates the possibility of malicious actor.
Speaker 3: So like, if this is an interesting topic, like there's
Speaker 3: there there's so many of these are like wow, you
Speaker 3: could really be doing a lot of interesting things in
Speaker 3: this space.
Speaker 4: That's really cool. Yeah, it is truly interesting.
Speaker 1: That's going deep down the rabbit hole.
Speaker 2: I gonna go deep down there.
Speaker 3: There's this article that came out that said that still
Speaker 3: no companies are making money from AI in any way,
Speaker 3: shape or form other than I guess in Nvidia right
Speaker 3: for selling the shovels.
Speaker 4: Yes, I think that every time that I'm speaking about
Speaker 4: like AI, AI, A P I is the future of
Speaker 4: it it all. Eventually it will sound like a Bacon
Speaker 4: Morphy episode along the way, and that's what I'm saying, Like, Okay,
Speaker 4: I gotta unfold, like I gotta go back, I gotta
Speaker 4: go back.
Speaker 3: I mean basically, there was that one episode where it
Speaker 3: was like the story worry within the story with the
Speaker 3: train dude, and the end of it was like a
Speaker 3: heist and he's like, that's what I want to do
Speaker 3: to think, That's what I want to do to think,
Speaker 3: and they were like just stuck at an infinite cycle here.
Speaker 2: That's that's for sure where we're going.
Speaker 4: Exactly unsubscribe. I'm one off.
Speaker 1: So I want to shift topics here real quick. Let's
Speaker 1: talk about running.
Speaker 4: Let's stuck about running. All right, let's do it.
Speaker 1: Yeah, so I take your runner.
Speaker 4: I am not a pro one, but it's something I've
Speaker 4: been doing for since since adolescence, right.
Speaker 1: On, Like long distance, you have a specialty, favorite thing
Speaker 1: to do.
Speaker 4: So I think I'm trying to keep the casual. I've
Speaker 4: been running like as much as I can, like two
Speaker 4: or three times a week and usually, so I'm going
Speaker 4: to go with the metric system. I can't relate it
Speaker 4: to miles fair enough, apologies and advanced to all of
Speaker 4: our audience. I don't apologize, but it's like between ten
Speaker 4: to fifteen and Kate. So yeah, this is like a
Speaker 4: way to clean your your mind and find teeing yourself
Speaker 4: and just like you know, really stress something I've been
Speaker 4: doing for a lot of time. It's like my own
Speaker 4: type of meditation. Yeah.
Speaker 1: I'm glad you went there because I did an experiment
Speaker 1: last year with running and that was one of the
Speaker 1: big unexpected learnings I had is that running really is meditation.
Speaker 1: And when I when I first started running, you know,
Speaker 1: I had music going and stuff, and then over time
Speaker 1: I just ditched everything because for two reasons. One because
Speaker 1: running long distance running was such a meditative experience that
Speaker 1: whenever you got done, it was like, wow, I feel
Speaker 1: so much better despite being physically hired. But the other
Speaker 1: thing I learned was like, there's actually a lot to
Speaker 1: keep track of while you're running. You know, you're focused
Speaker 1: on what's my run cadence? Look like, where am I
Speaker 1: landing on my feet? Is my is my stride? Right?
Speaker 1: What's my respiratory rate? You know, and there's so much,
Speaker 1: so many things that you need to focus on to
Speaker 1: do this effectively. That if you have music playing as
Speaker 1: a distraction, then you you're you're running quality suffers from
Speaker 1: it as well as you don't get that great meditative
Speaker 1: experience out of it.
Speaker 2: I agree, Yeah, sorry, go ahead.
Speaker 3: Sorry the you know, I used to do this and
Speaker 3: I had the arran thoughts like that would be like,
Speaker 3: oh oh no, like there is this bug in production
Speaker 3: somewhere that I would like, like I wrote code that
Speaker 3: you know is a problem, or I just thought of
Speaker 3: this thing that I have to like I have to
Speaker 3: write it down, Like I'd just be like an hour later,
Speaker 3: I'd be like, Okay, what was that thing that I
Speaker 3: figured out while I was meditating?
Speaker 2: Uh, you know, while running?
Speaker 3: And it was like a huge problem and I never
Speaker 3: really really got over that.
Speaker 4: So I think that if you were to multiply the
Speaker 4: duration of your run it was you, you will go
Speaker 4: past that. What was what was I thinking about? And
Speaker 4: it's like it doesn't matter. I mean everything is a
Speaker 4: federal in life. I mean, I mean it doesn't really matter.
Speaker 4: I mean it's okay exactly. Yeah, So I know, like
Speaker 4: I want to. I think that's the right time to
Speaker 4: surface it that you're saying. Like usually in your episodes,
Speaker 4: the person that it's making is being interviewed as some
Speaker 4: kind of recommendation to make, And I thought about what
Speaker 4: I want to want to recommend, and that's this. There's
Speaker 4: this book that I've read a few years ago, one
Speaker 4: of my favorites. It's called bon Bone to one right,
Speaker 4: and it talks have you heard about this one?
Speaker 1: I've read this one is such a great book.
Speaker 4: I love it. You heard about it? Robin?
Speaker 3: No?
Speaker 4: Actually, so this this, dude, it's like an actual story.
Speaker 4: It's not something fictional. It's fictional. It's not science fiction.
Speaker 4: He is pained by running, He want to gave up
Speaker 4: on that is a journalist and then he heard about
Speaker 4: this tribe in the in Mexico in Mexico, in rural Mexico,
Speaker 4: that they're running the long distance miles. I mean as
Speaker 4: a way of living. They don't have cars. They're just
Speaker 4: running for a living. And it goes out to this
Speaker 4: to this tribe and he like discovers that they're the
Speaker 4: ultimate ultra marathon runners. I mean they can run for
Speaker 4: miles over miles without getting tired. There actually can beat
Speaker 4: the vast majority of the pro ultramarathon runners. And then
Speaker 4: is investigated over time you understand that like people are
Speaker 4: actually born to run, I mean one of the old
Speaker 4: methods of hunting. And he founds like a tribe that
Speaker 4: actually still doing it in in Africa. They're running until
Speaker 4: they're like until that the cattle or the target is
Speaker 4: being you know, exhausted. Because humans as opposed to other
Speaker 4: most of the mammals can really have endurance over time
Speaker 4: because they have sweats so they can ventilate everything. Most
Speaker 4: animals will have to breathe to do so, and it's
Speaker 4: like breathe per gallop because there are four legged animals,
Speaker 4: so they can outpace you at any time. But eventually,
Speaker 4: like fifty k of running, they will crash down being
Speaker 4: exhausted and this is where you're going to stick your ar,
Speaker 4: you know, sphear and take take me down back home.
Speaker 4: So kind of saying that, like at the gist of things,
Speaker 4: people are born to run for long distance runners in
Speaker 4: our anatomy, and we just forget about it along the
Speaker 4: you know, over the course of years. Yeah.
Speaker 1: I really like that format of book because the author
Speaker 1: and I can't remember the author's name, but the way
Speaker 1: they broke the book up was it's an entertaining story
Speaker 1: in itself, but then they would break up the sections
Speaker 1: of the story and go into the science of why
Speaker 1: that part of the story was true or how that
Speaker 1: part of the story works. And so the book would
Speaker 1: switch back and forth between here's like an entertaining section
Speaker 1: of the story, here's the science behind that, here's the
Speaker 1: next part of the story, here's the science behind that.
Speaker 1: And so it was both entertaining and educational at the
Speaker 1: same time and just a fascinating read.
Speaker 4: Completely agree with you. By the way, this is the
Speaker 4: book that sparked the barefoot.
Speaker 1: Running trend, right, so do you run barefoot?
Speaker 4: No way, I'm not of the trend. I'm just like
Speaker 4: talking about the trends, but I'm giving my nikes and
Speaker 4: I'm good to go. No, it's too painful to try
Speaker 4: to adapt to Breft trying for sure.
Speaker 1: Agreed. Agreed. Now that's that was a cool book if
Speaker 1: even if you're not interested in running. It's just a
Speaker 1: really cool story because it talks about you know, humans
Speaker 1: historically and and how we how we survived up until
Speaker 1: this point. And then there's just the educational takeaways as well.
Speaker 1: Cool pick.
Speaker 4: Thank you, m Warren.
Speaker 1: What'd you bring for a pick this week?
Speaker 3: My pick is I didn't have something relevant, so it's
Speaker 3: it's gonna be uh, definitely separate. It's a book again,
Speaker 3: because you know I I go through my whole book
Speaker 3: lest and it's never split The Difference by Chris Boss Yeah,
Speaker 3: uh yeah. I mean it sounds like it's a book
Speaker 3: about negotiation. Uh and I don't think that's accurate. I
Speaker 3: really like it as a mindset shift for when you
Speaker 3: think there are only two computating outcomes for a situation.
Speaker 2: I like this salary negotiation as an example. It's like if.
Speaker 3: You say, oh, you know this, I want this much
Speaker 3: money and someone else says no, like you know, we
Speaker 3: can only pay you that much. It's sort of a
Speaker 3: not a smart way to approach the conversation. Instead, you
Speaker 3: want to attach every extra dollar, for instance, in a
Speaker 3: salary negotiation, to something concrete, like I'm worth this much
Speaker 3: more because of my experience. You know this money. Number
Speaker 3: of years of experience is worth this much. This many
Speaker 3: more years is worth that much, And then you're sort
Speaker 3: of agreeing or disagreeing about the relationship between something concrete
Speaker 3: and the money in a salary negotiation rather than arbitrary like, oh,
Speaker 3: you know, let's just throw out arbitrary numbers. I think
Speaker 3: that's really important because it's really gotten me to shift
Speaker 3: my focus when I feel like I may be in
Speaker 3: a negotiation situation about what we're actually talking about and
Speaker 3: where my value is personally or where the value.
Speaker 2: Doing something is.
Speaker 3: Especially like evaluating software products comes up a lot. It
Speaker 3: can be very difficult to evaluate, you know, which ones
Speaker 3: we want to use, which ones are good, And if
Speaker 3: people just get into a conversation of like, oh this
Speaker 3: one's better, you know, do this and not do that,
Speaker 3: it doesn't really come out that well. But if you're
Speaker 3: able to evaluate, okay, we will do that, if this
Speaker 3: or if we need that, it really has the extra mindset,
Speaker 3: and I think this book really helped me get there.
Speaker 1: And that's another one of those books where Chris Voss,
Speaker 1: the author, his background, he was a former FBI hostage negotiator. Yeah,
Speaker 1: and so the book format is very similar to Born
Speaker 1: to Run, where he'll tell you this cool story about
Speaker 1: this hostage negotiation scenario he was in, and then he
Speaker 1: breaks down the specific technical components of negotiation that he
Speaker 1: used in that scenario. So it's that two part thing,
Speaker 1: you know, where here's a really entertaining story, here's the
Speaker 1: educational component. Here's another entertaining story. Here's the educational component.
Speaker 1: Just that format is so cool to me.
Speaker 2: I bet you really like The Martian.
Speaker 1: I don't think I've read that.
Speaker 2: Oh no, like see the movie though.
Speaker 3: Oh okay, So there is this cult favorite story out
Speaker 3: there that's been out there for so long, So andy,
Speaker 3: where is the author? And it's called The Egg, I think,
Speaker 3: and it's it's like a philosophy on like what life is,
Speaker 3: and it's so old. And then I read The Martian
Speaker 3: and I'm like, this is great. And then I found
Speaker 3: out that I had actually read The Egg, which is
Speaker 3: just it's like translated into like thirty languages by people.
Speaker 3: It's a very short short story, but it definitely goes
Speaker 3: into it like it's it's very science based, but there's
Speaker 3: some story and then the main character is telling about
Speaker 3: the science of why they're able to do what they're doing.
Speaker 3: And so in the Martian he's stuck on Mars and
Speaker 3: he's in a precarious situation, and there's a second there
Speaker 3: where it's like, oh, I need to grow potatoes. It's like, okay,
Speaker 3: let me tell you about the science of growing potatoes.
Speaker 4: And then I did read this book.
Speaker 1: Yeah, I did read it.
Speaker 4: Yeah.
Speaker 1: I didn't recognize the name because that was the movie
Speaker 1: with Mark Wahlberg, right, No, made Damon. I think Matt Damon,
Speaker 1: Marky Mark and the Funky Bunch or whatever his name
Speaker 1: really is.
Speaker 3: Yeah, yeah, yeah, for sure. So I think it's really
Speaker 3: well done from that regard. Yeah, but my pick officially
Speaker 3: is going to be Never Spoke the Difference.
Speaker 1: Yeah cool. Both of those are great books though, Yeah,
Speaker 1: super cool. All right, So my pick, I'm going with
Speaker 1: a video slash music pick this week because the YouTube
Speaker 1: algorithm has figured out that I can't resist watching reaction
Speaker 1: videos to musical performances, and there's a YouTuber called the
Speaker 1: Charismatic Voice and the specific video I watched, I've watched
Speaker 1: a couple of them. The one that I most recently
Speaker 1: watched was her reaction to the Iron Maidens song The Trooper.
Speaker 1: And so she's a classically trained vocalist and she's watching
Speaker 1: this heavy metal video. You know, Iron Maiden is straight
Speaker 1: up heavy metal if you're not familiar with them, and
Speaker 1: reacting to it. But the cool the part that makes
Speaker 1: us cool is she just gets so into it because
Speaker 1: you can just see her passion and her enthusiasm, which
Speaker 1: makes watching the or listening to the song that much
Speaker 1: more enjoyable. So she just has a great personality. And
Speaker 1: then also same thing, you know, to watch part of
Speaker 1: the video and then stop and then give you the
Speaker 1: educational or the technical breakdown of that specific piece of it.
Speaker 1: I think I'm picking up on a pattern here of
Speaker 1: things that I like. But anyway, so YouTube the Chromatic Voice,
Speaker 1: the reaction to Iron Maidens The Trooper was really good.
Speaker 1: Or she did a reaction to the led Zeppelin song.
Speaker 1: Um shoot, I'm drawing a blank on the name of
Speaker 1: the song, but there was a she did a led
Speaker 1: Zeppelin song and she just lost her shit in that.
Speaker 1: I mean, she couldn't stop giggling. She was enjoying it
Speaker 1: so much so it was really cool to watch.
Speaker 3: I think you actually did the led Zeppelin song as
Speaker 3: a previous pick because of her.
Speaker 1: Could be yeah, very well, could be cool. All right,
Speaker 1: Well that's going to bring us to the end of
Speaker 1: our episode. To all of the listeners, thank you so
Speaker 1: much for listening. Be sure and let us know on
Speaker 1: LinkedIn X or whatever your social media platform of choice is,
Speaker 1: or if you Google for I don't know, probably forty
Speaker 1: five fifty seconds, she will find my email address. Feel
Speaker 1: free to shoot me an email as well. Like if
Speaker 1: if every scammer on Earth can find my email address
Speaker 1: and you can't, I don't want to hear from you anyway.
Speaker 1: I'm kidding. I am totally kidding. But thank you for listening.
Speaker 1: Hey all, thank you for joining us on the show.
Speaker 1: This has been a cool conversation. Appreciate having me on
Speaker 1: the show. Thank you so much for having me.
Speaker 4: It was awesome cool.
Speaker 1: Larren, as always, thank you for being here. Appreciate your
Speaker 1: added input and helping me out on the show. Yeah,
Speaker 1: of course, all right, and we will see y'all next week.