PostHole
Compose
Login
SE Radio 663: Tyler Flint on Managing External APIs
Tyler Flint, CEO of qpoint.io, joins host Robert Blumen for a conversation about managing external vendor dependencies, including several best practices for adoption. They start with a look at internal versus external services, including details such as the footprint of external services within a micro-services application, and difficulties organizations have tracking their service consumption, quantifying service consumption, and auditing external services. Tyler also discusses the security implications of external services, including authentication and authorization. They examine metrics and monitoring, with recommendations on the key metrics to collect, as well as acceptable error rates for external services. From there they consider what can go wrong, how to respond to external service outages, and challenges related to testing external services. The episode wraps up with a discussion of qPoint's migration from a proxy-based solution to one based on eBPF kernel probes.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Tyler Flint, CEO of qpoint.io, joins host Robert Blumen for a conversation about managing external vendor dependencies, including several best practices for adoption. They start with a look at internal versus external services, including details such as the footprint of external services within a micro-services application, and difficulties organizations have tracking their service consumption, quantifying service consumption, and auditing external services. Tyler also discusses the security implications of external services, including authentication and authorization. They examine metrics and monitoring, with recommendations on the key metrics to collect, as well as acceptable error rates for external services. From there they consider what can go wrong, how to respond to external service outages, and challenges related to testing external services. The episode wraps up with a discussion of qPoint’s migration from a proxy-based solution to one based on eBPF (extended Berkeley Packet Filter) kernel probes.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Robert Blumen 00:00:19 For Software Engineering Radio, this is Robert Blumen. Today I’m joined by Tyler Flint. Tyler is the CEO of qpoint, a firm that focuses on egress observability. Prior to qpoint, he was the co-founder of three other PAs companies and was a Software Engineer at Digital Ocean. Tyler, welcome to Software Engineering Radio.
Tyler Flint 00:00:42 Thank you. I really appreciate you having me on, Robert, it’s great to be here.
Robert Blumen 00:00:46 Happy to have you. Is there anything else about your background you’d like to cover?
Tyler Flint 00:00:51 I don’t know that my background is all that important other than just, it feels like I’ve been in this space for so long that I’ve watched the cloud grow up, and I do have a funny story about containers in the Linux kernel before they were a thing. But if it presents itself, I’m happy to tell that story.
Robert Blumen 00:01:06 Well, we’re all about staying on topic here, so I’m going to pass on that and get right to the main topic of our conversation, which is managing external API dependencies. Before we talk about managing external services, can you situate the problem? What type of systems or architecture are we talking about that have external dependencies?
Tyler Flint 00:01:29 Yeah, that’s a great question. So most applications today have at least one sort of external dependency. Most have dozens or hundreds or even thousands. And so dependencies can take the form of either internal service dependencies, like a microservice type of application, or really any application that has a vendor or third party, API dependency. And so almost every company that exists today has at least one dependency on billing API or some sort of management API that they depend on for critical functionality.
Robert Blumen 00:02:05 Give some other examples beyond the one.
Tyler Flint 00:02:07 Yeah, so there’s kind of two domains. One domain is this microservice architecture that we’ve seen proliferate in the last, you know, 15 years. And two, a particular service in a microservice app. Everything is a dependency. Every external service is an external dependency. And in a large organization, usually those services are run by isolated teams that pretty much act in a way as if they’re an external vendor. And so when we look at the actual vendor or third-party dependencies, there’s a lot of dependencies that are spread across billing APIs. There’s a lot of APIs across customer relationship management APIs, a lot of automation tooling or text phone, other audio platforms. There’s a lot of dependencies lately on external LLMs like OpenAI or Anthropic. And so what we have seen is that modern applications are really a sprawl of the service dependencies,
Robert Blumen 00:03:14 You know, large enterprise that’s operating a microservice architecture. You said just now that if I work on a team that implements service A, we’re responsible for that, service B may appear to us to be external, but surely there are differences between that and a service that we buy from another organization entirely where no one there works for the same boss at any level?
Tyler Flint 00:03:40 Yeah, absolutely. The levels of accountability are different, and the lines of communication are certainly different. So probably the biggest difference that you see is if you have an external vendor, third party dependency, then while yes, you have a contract and you’re trying to hold them accountable to the terms that they have presented to you, it is incumbent upon the team to ensure that the application is resilient to the uptime and performance of that third party vendor. Because at the end of the day, while you can go make some noise and you can try to influence their internal operation, you really have to accept the uptime and reliability of that vendor. Whereas an internal service, you can go get that other team in a meeting and you can say, hey, your SLA does not meet our SLO, we have to figure out how to compromise here or else we’re going to have some difficulty. So there is a fundamental difference with vendors, not so much, and you just kind of really have to be resilient.
Robert Blumen 00:04:41 Thank you for that. Another distinction I wanted to go into is, are external services necessarily paid or are there a lot of free services in the mix?
Tyler Flint 00:04:53 Yeah, there are a lot of free services. Well, and then there’s also with free tiers, something might be free to your team and you’re going to get one level of service and then when you start paying, you get a different level of service. But there are a lot of free APIs, but more particularly free tier usage.
Robert Blumen 00:05:13 I want to now start talking about what the footprint of these services is. You said the number of external services an organization have, it could be as few as one, but range up into the thousands. That was one of my questions. Are these services accessed from data center, from Public Cloud VPC or where is the origin of the access?
[...]