New Approach to API Management – Emile Vauge, Traefik Labs

This is Techstrong tv. Hey guys, thanks for the throw. We're here with Amil Voj, who's c e O for Traffic Labs, and we're talking about API I management and the rise of application networking.

Amil, welcome the show. Thank you for inviting me. We have been attempting to manage APIs for the better part of a decade, and with mixed success.

So from your perspective right now, where are we in the evolution of the management of APIs? What challenges remain where you are seeing more APIs by the day? Or are we just getting overwhelmed?

I mean, clearly, uh, uh, the, uh, API market is still, uh, growing crazy fast. Uh, I mean, even though today, uh, uh, the, uh, API is, uh, dominating the, uh, uh, the traffic, the internet traffic, like, uh, today 80% of the internet traffic is API based. Uh, uh, but the thing is, uh, the API market is today 5 billion and will grow to 40 billion, uh, up in uh, 20, I mean, since today to, uh, 2030.

So the, the, the API market is growing extremely fast. We already have API management solution that are well, uh, in, I mean, um, well built. But the thing is, uh, since, uh, a few years we've been, uh, seeing a revolution in the, uh, uh, software industry, which is containers, which is Kubernetes in two worlds cloud native.

And, uh, today, cloud native is the, uh, standard and, uh, the, the, we need to adapt the API management, the API market, to this software revolution. And there is still something to something to be done in that space. So what exactly is the challenge?

Cuz every microservice has its own api and we're updating the microservices and we're also updating the APIs. Is it just that the previous solutions were built more for a slower pace monolithic mindset, or what, what's changed? Yeah.

Yeah, exactly. I mean, basically, uh, uh, previous solutions, previous API solutions were built with, uh, a previous, uh, uh, philosophy, uh, mon, a monolithic world, a VM world. Uh, and now everything is, uh, is, uh, deployed on communities.

Everything is microservices. Uh, the scale is completely different. Everything is multi-region, uh, multi-cloud.

Uh, so basically we need to adapt, uh, the tooling, uh, and we need it. We, we, I mean, many tools have been, uh, adapted to, uh, this new cloud native world, uh, and the api, API I, uh, tooling needs to be adapted to. So, uh, that's, that's what we've been, uh, working on.

There seems to be a lot of confusion as to what to use when we hear phrases like proxy software. Then there's API gateways, and then there's service meshes. So what exactly do I use to manage APIs?

In what types of use cases? So, indeed, there is some, uh, overlap, uh, technically between, uh, an ingress c control between, uh, a reverse proxy, a load balancer, an API gateway. Uh, technically there is some mobile app.

Uh, every solution, uh, does some load balancing at some point, does some basic routing, this kind of stuff. But, uh, api, uh, an API gateway solution is clearly focusing on the, uh, uh, API use case, which is a bit different, uh, a bit specific compared to, uh, to the reverse proxy use case. So, uh, when you expose an api, it has to be part of one or several portals.

Uh, there is a, a dimension of documentation associated to this api. There is some test associated associated to this api. There is some, uh, um, access control associated to this api.

Uh, which users from which team can access to this API, can test it, can publish it. So there is a woo lifecycle associated to an api, which is not part of a basic reverse proxy that has to be part of an api, uh, solution, an API platform. So that's, that's the basic, uh, uh, I would say the basic difference Is the way we think about managing, networking and security changing as we kind of move to this API driven world.

And we hear the phrase application networking a lot, but is that becoming something that is managed more by a development team or a DevOps team on the layers two through seven? Or, um, what is the relationship between application networking and traditional networking? I mean, BA basically, uh, we, we still need, uh, uh, sre, we still need ops.

We still need, uh, uh, I mean the, uh, the humans to, uh, to, to handle this part. But the thing is, with the cloud native, uh, uh, with cloud native platforms, uh, usually it goes, uh, on a new scale. When you deploy something on a new cloud native platform, uh, the scale is way bigger than it used to be before.

So basically it implies that, uh, uh, most of the things have to be automated, uh, have to be, uh, GI UPS ready. Uh, and that's exactly, uh, the big, the big change. Uh, we used to do, uh, uh, many, uh, manual operations, uh, 15 years ago.

It's not the case anymore. Today. It's not an option today.

Uh, today everything has to be, uh, auto, everything is all about automation, gi, ups, uh, uh, auditability, repeatability, rollback, et cetera. And that's, that's clearly, uh, uh, the central, uh, central focus of, uh, uh, cloud native solutions. So do you think as we move down this cloud native path that network operations becomes more of an extension of DevOps?

I mean, it seems like for the longest time, uh, the net NetApps people lived in their own world that no matter what the DevOps world did, which still took three weeks to provision Yeah. Some sort of service somewhere along the line. Yeah, I mean, uh, and it's, it's the sense of history, right?

I mean, we, uh, I mean, when we compare developers from, uh, uh, 30 years ago to today, it's not the same job. Uh, today, developers are reusing, uh, many components that are, that are already existing, uh, playing scripts, uh, uh, are using, uh, uh, ID that are extremely complex and generating a lot of codes. Uh, so, you know, everything is evolving.

Uh, it's the sense of history. So yes, network operators or operators in general are, are, are using automated tools, and that's, uh, that's what needs to be done, right? Because it's avoids, uh, the human error, uh, uh, as much as possible.

So that's, that's, that's the woo point. What does it take for someone to have the realization that they need a different approach? Do I, you know, wake up one morning and discover that there are thousands of APIs and I need to do something about it?

Or is there a more proactive way of thinking about this? I mean, it depends, but usually, uh, uh, uh, uh, it depend on the use case, right? Uh, you have basically, uh, uh, two big different use case, uh, the large company, uh, which has, uh, which already has, uh, uh, hundreds of different APIs, uh, deployed on different environment with different toolings, and they have to, uh, uh, they, they don't have any, uh, central, uh, uh, dashboard central overview of all those API and a central, uh, uh, way of managing those, all those API central access control, all, all what you need, uh, in a centralized way.

They don't have that. So that's the first use case. And the second use case is, uh, yeah, I, I'm building a, a project from scratch, a new project.

I know it'll be a a hundred percent based on api, because that's, that's what you need to do, uh, today. Uh, and, uh, and, and of course, I'm, I'm looking for an API management solution, uh, because it'll make things way easier than doing it, uh, manually. So, uh, they, they, they are two, uh, two different big use cases in the, uh, in the API world, I guess.

Mm-hmm. And you guys just launched a hub offering. So walk us through how you're approaching that whole centralization management challenge.

Yeah, yeah, exactly. So, so we've been, uh, I mean, we've been in the world of api, api, uh, for quite some time, uh, uh, uh, traffic proxy, uh, uh, which has, which is one of the, uh, uh, uh, most used, uh, API gateway away, uh, uh, in the world, uh, uh, have been existing for quite some time already. And, uh, and we have Traffic Enterprise, which is an enterprise API gateway that we have been, uh, commercializing for quite some time.

And yes, as you said, uh, we, we, we, we think the API market is growing very fast, uh, and we think, uh, we do think though that, uh, we needed to create, uh, fully, uh, es ready Cub es native API management solution. Uh, so that's what we've been doing with Traffic Hub that we just announced. Uh, so it's a es uh, native, uh, API management solution.

Uh, and it's the first of its kind. Uh, it has such a deep integration with es, uh, that it's, uh, that it's kind of, uh, using all the standards, all the good, the, the, the good practices, uh, uh, uh, uh, um, behind it. Uh, it is extremely lightweight.

Uh, the idea is that you just deploy one small agent, uh, on all your clusters, and then you connect this agent to a centralized, uh, control plane, and you are good to go. You don't have any database to, uh, to deploy. You don't have, uh, any KV store to deploy anything else.

It's just one binary. Uh, and the other, uh, uh, great aspect is that, uh, you don't, I mean, we are against vendor looking. We, we want, uh, our customers to use any communities dis distribution, uh, any cloud provider, any region, uh, and, and more importantly, any ingress controller.

Uh, not only it works with, uh, uh, traffic proxy, uh, of course, but it's also, it also works with ang EngineX, which is widely used as an ingress controller or any other ingress controller, invoice based, or a proxy based, uh, whatever. And that's clearly the philosophy of it. Uh, uh, lightweight, do like UNIX tooling, right?

Do it, uh, I mean, uh, do it, uh, do one thing, but do it well, and no vendor locking. It's open based. Uh, and so if you already have, if you are already using engineers or a proxy or both of them, uh, and traffic, you don't need to change anything in your existing infrastructure.

So that's, that's a new way of, uh, uh, um, redefining, uh, uh, API management. Uh, and of course it comes with, uh, all api, uh, management features you need, uh, around access control around developer portal, uh, around user management, around, uh, uh, um, documentation, uh, uh, generation, et cetera. Uh, it, it comes with all, uh, api, uh, management features, but package into, uh, a super innovative way, uh, uh, which is the, the way of doing, doing things today.

This may come as a shock to some folks, but there are these things called rogue APIs and zombie APIs that people create. So no one seems to know they exist. So how do I go about discovering all these things that developers have just decided to go and do and not tell anybody?

So that's, uh, that's a, that's a good question. And, uh, uh, of course, we can't, uh, avoid, uh, I mean, we can't force people to, uh, to, uh, to use one tool. Uh, it's, uh, it's, uh, it's, uh, it's, it's a bit complex.

So the idea is that, um, um, uh, usually it's difficult to, uh, to send, I mean, to gather all API from one company, uh, which is large in one tooling. Uh, and, and the complexity comes from the fact that it's, uh, uh, that developers don't like the product, right? Uh, usually, uh, API management solution are imposed or forced on mandatory by one team or whatever it is it comes from.

And, uh, and, and developers don't want to use it because it's not, you know, it's not integrated with their tooling. It's not, it's not, uh, working well. Uh, but here we have been, uh, uh, uh, I mean, we have been building this, uh, with a complete opposite philosophy, right?

It's a developer, developer centric, uh, API management solution, uh, uh, well integrated into, uh, today's standard, uh, uh, stacks. Uh, and, uh, that's, that's completely new in this world, uh, uh, compared to, uh, to, uh, what ex what is existing in the competition. Uh, so with that, uh, it's a very good way to, uh, to, um, encourage, uh, all your teams to, to, uh, publish their api, uh, in, in that product, because it, it's just integrated by, by design.

Uh, so that's super easy, alright? You cannot walk down the street these days without somebody talking about ai. So let me ask you, can we apply AI to API management?

Is that something we should be thinking about? I mean, I mean, why not? I mean, uh, I, I'm not the one who think, uh, a AI will solve everything.

Uh, and I, I don't want to add buzzword everywhere to, uh, just use buzzword, but of course, uh, uh, one thing, for example, is to use ai, uh, to, uh, troubleshoot automatically, uh, uh, something that, that is going wrong with some APIs. Uh, if you, if one API is going into, uh, is giving many errors, uh, during a certain amount of time, uh, AI could, uh, help fa uh, troubleshooting this, uh, this, um, uh, problem, uh, and, and give some, uh, um, um, clues, uh, to an operator, uh, and, and, and get back to the, uh, root cause of this, uh, issue. But I don't think AI will, uh, will do everything in that space, sadly.

All right. Well, folks, you heard it here. It's the same old story, you know, and you can't manage what you can't see.

So the first step is to figure out where all those APIs are, and then you can start figuring out where your strategy's gonna be for what is arguably the new network. It's all driven by APIs. Hey, Emil, thanks for being on the show.

Thank you for inviting me for the pleasure. And back to you guys in the studio.