Run Your AI and APIs Anywhere with Traefik Labs

I am sad Goswamy, I'm the CEO of Traffic Labs, and today we're going to cover three different broad topics. Uh, the first one, I'm gonna just do a quick introduction on traffic labs, just to level set, uh, what we do, but really the three main topics of the day. Uh, the first one we'll talk about this concept of unified application intelligence.

Second, uh, I think no talk's gonna be complete without ai, so we'll talk about what we're doing to accelerate AI in the enterprise. And then the last, uh, this is a theme that I think we're hearing at this CubeCon even more so than what I have seen in the past. This notion of being able to run anywhere and having this freedom of choice.

So not just public cloud, but on the edge in your per personal environment, air gap environment and so forth. So with that, let's go ahead and get started. Um, some of you already know traffic.

For those of you watching this online, uh, traffic is one of the most downloaded API gateways on the planet. Uh, if you look on Docker hub, we have the most downloads, uh, in this particular space. 4 billion and, and going, uh, we have incredible community of contributors to our open source project, uh, which is called Traffic or Traffic Proxy for some of, uh, some of you guys that already are familiar, we have over 800 plus contributors and this number continues to grow.

6. And you'll, if you go look at that release note, you'll see there's, uh, amidst the contributions that we make as an employee of Traffic Labs to that particular project. There is a plethora of features that the community has delivered, uh, this time as well, and that continues to grow.

So I'm very happy to hear that. Um, a lot of stars on GitHub. I mean, sense, uh, in an essence, what all of this is really saying is that, and the users continue to tell us this, that we are one of the most intuitive platforms, intuitive ingress and API gateway out there.

We're very easy to use, very powerful. Everything is fully declarative. You can deploy us as infra as code.

The key personas, uh, that we cater to, I think the first two columns really represent the, the user base, the people that would be using traffic. They are your DevOps engineers or your platform teams, your SREs. They are the prime users and advocates of traffic.

And then we also have, uh, the, the C-suite who they report to. And, uh, they see value in traffic as well. From a, uh, being able to, uh, achieve security in an agnostic way, not be vendor locked in.

They can drive innovation. They have the level of compliance. And increasingly we're starting to see more and more the security team and the AIOps team also start to embrace traffic.

And what they care about is, you know, having security with the level of agility and the user experience. Uh, you know, with these multiple types of AI workloads that are now entering the enterprise. This is, uh, in a nutshell, uh, what our entire portfolio represents.

You look at the base, uh, you have traffic hub as the foundation, and we have three core product offerings. We have our open source, then we have our API gateway and API management. And then the extensions to those are, are a few different things on the open source.

We're one of the only ones in the space that provide enterprise support on our open source. Many of the other players in this space, uh, almost kind of push users to go to the paid offerings where we have a large user base that is very happy using our open source in, in production, but they just want that peace of mind with enterprise support. And we offer that, you know, that's our first offering.

And then as users move over to the API gateway and to the API management layer, you have different types of use cases that are possible. You can deploy us as a waf, you can deploy us as an AI gateway. You can also, we've just launched MCP Gateway not too long ago.

You can deploy us as an MCP gateway and then if you're really serious about API governance, you can also deploy us as a full lifecycle API runtime management. The beauty of this is the API gateway and the API management are all contained in one single binary. So through licensing you get to, uh, use the different feature set.

So you have, so essentially our entire portfolio is composed of two binaries. You have one binary that says the open source, you don't wanna mess with that, you know, you keep that as is. And then you have the second binary, which is the paid, uh, functionality, which is your second and third kind of, you know, the pillars here.

And if you, um, this is one slide that's on our website as well. io/pricing, you'll see some of the key, um, features in each of them. So that's what I was saying.

The second and the third column here, they are essentially one single binary. And through licensing, you get to use, uh, what you pay for. Uh, just going back here one second, like if you look at the differentiators, this is really what differentiates us from our, uh, peers in the industry.

And this kind of permeates through the entire portfolio. Uh, we have a great documentation system that makes it easier for our users to learn. We are not just cloud native, but we're also cube native.

That allows a much easier experience integrating us into the environment. We have a intuitive UI as well, makes people easier to start with. But the real magic for us happens when users are scaling with us.

And this is where us being fully declarative allows them to embrace the GI ops model, the CICD pipelines. And we're heavily focused on day two ops because there are many types of infrastructure that you can stand up quickly, but the, you start to really see the cracks when you're really pushing the boundaries and you're scaling them. And this is where we are focused on day two ops.

I think being fully declarative is a almost a prerequisite. And then you build on top of that, uh, to make it a fully deployed as code experience because then you can do change management. And that's what day two ops is really about is how do you embrace change?

How do you handle change as it happens, you know, whether change that you wanna introduce into the environment or change that just happens, uh, and you're reacting to it. And then the last but least, uh, is the pricing model. We're also differentiated from a pricing model standpoint.

Uh, many of the peers in the industry, uh, the pricing model, it's, uh, based on call volume. So a number of API calls that you push to the system, we have taken a very different approach where we make it more of a cluster based or an instance based. So we don't care, like, you know, how many calls you're pushing through it, as long as you're licensed for it, you put it on the right metal, the right kind of, you know, the, the CPU memory characteristics and you can scale as much as you want.

We don't get in your way and it's much more predictable that way. So that's why some customers call this like the CFO friendly, uh, pricing model because it's easier to predict, easier to model in their, you know, budgeting. And uh, also it's very user friendly.

So you don't have any kind of tho those sudden spikes, uh, that you might see, you know, maybe at the end of this month, black Friday, you get all this spike and then now you have to pay more. You know, they don't want to be in that predicament. Quick Question is Colin and Hendricks Parker six feet up on the pricing model, how does that handle autoscaling?

So as you add more nodes into the cluster? Yeah. So, uh, you know, if you're using Kubernetes, uh, that already has that autoscaling functionality built in.

So when we license it, we give you room in terms of the number of replicas that you can use, and that allows you to control, uh, the number of like the auto scaling characteristics, scaling up or scaling down. So it doesn't matter how many nodes get it added into that cluster, that's gonna be based on pod replication. It's the pod replica concept.

Okay. So most of our users, like, you know, they have different kind of configurations. So let's say they have a really ultra ha configuration where they need three availability zones and they may need two instances in each availability zone.

Well, that's six replicas. So we would license it based on a six replica set. And there's, you know, and it's not a hard and fast rule, you know, there's, Okay, so someone, if you get a burst and you're using, uh, carpenter to autoscale across nodes, you could, we could burst up to Yep.

Double, triple, and then come Back. Yeah. We give you a safe zone that you can burst up and come down.

Yeah. Thank you. We don't penalize you for it.

Yeah. I hate to be like, my licenses ran out. Yeah, No, and, and then everything got shut down.

Yeah, right. We don't want that. Yeah.

We we're trying to align more closely with how the users would deploy this infrastructure and what flexibility they would have at their fingertips to be able to scale up and down. So is your, your gi up support for deployment, is that part of what that scaling looks like? If I want to dynamically scale up another instance of a cluster or clusters, I can do it that way also.

Yeah. Yeah. Once you're licensed, so you would have, let's say you have X number of licenses that you're using, and that essentially means how many instances you can deploy.

Once you have that, then you can use, get to deploy as many as you want. Yeah.