Gain Unified Application Intelligence with Traefik Labs

So what do we mean by application intelligence? And I'm sure many of us in the room and, and people watching probably have a notion, but I wanted to just make sure everybody's on the same page. Best way to understand application intelligence is by kinda looking at traditional networking and application networking and, and what do they represent?

Typically, traditional networking is something that is just based on IP addresses and ports, right? You are really optimizing for moving packets around from point A to point B, and you're just routing connections, right? So the two pieces of, let's just say intelligence that goes in is the IP address and port, and maybe you can throw DNS in here as well.

Uh, whereas application networking is more looking at it from the application perspective. It's application centric, it understands the users and it's driving outcome for the user. Maybe there is an SLA that a particular class of users want, and it's making sure that you're able to deliver that SLA, it's actually routing business and not packets.

And what it needs is two things, right? It needs the identity and it needs the context. And we'll talk more about like exactly what do we mean by that.

But those are the two things that represent this application networking and this application layer intelligence. Uh, why is it important? I think, and we'll go through some details now.

Uh, the first thing is you are able to route based on a business context. What do I mean by that? That means you're able to do all the different things, like when you're routing the incoming traffic to an application, you are able to route by the user and the kind of user.

So let's say if it's an admin user coming in and you know this how you know this through the credentials because when you get authenticated, uh, and you know, whether you're using OIDC or any kind of standard protocols, once you get authenticated, you now have the identity of the user that's trying to access the application. That identity in it captures who the user is, what their role is. Maybe they are a particular customer with a particular tier.

Where are they trying to go? Are they going into, in this example to your checkout application or to your reports application? You're also able to see where they're coming from with geo, what device type they're using, uh, and also what API version they're hitting.

You can route based on all of these characteristics that you're typically not able to when you're simply operating at a IP address in a port layer. This also helps you get to faster incident response with, uh, layer three, layer four. You know, traditionally IP networking, you know, it takes a lot longer to diagnose, whereas with layer seven, uh, and more application networking, uh, troubleshooting, we're able to pinpoint the problem much faster.

Uh, because you're really going into the application, uh, troubleshooting from from the very beginning. Uh, this is kind of what I was talking about, security at the application layer. So it's, uh, based on the zero trust principle principle lease privilege, where every application request gets authenticated and gets authorized, right?

And through Jot, like the j json web tokens, you're able to decode, uh, right at the first layer who that person is and what they're trying to do and what they're allowed to do. And then you have this complete audit trail throughout. Once you have already decoded, like, you know, who is this user?

You have a policy and then you're able to act on that policy throughout. And then also for, uh, operational efficiency, let's say you end up getting a lot of load, uh, your P 95 or P 99 start to spike up, and then you have to decide like, okay, which users do I shed? Uh, with application networking and application intelligence, you're very quickly able to say, okay, well I'm gonna shed maybe my free tier users or, and give more priority to my premium users.

For example, you can also do canary deployments where with instant rollback, so with Canary you can say 80% of my traffic goes to this class of users. My premium class 20% goes to my other class and I can quickly roll back, uh, you know, uh, very, I can, you know, adapt to any kind of live situation that is happening. And also this gives you that freedom, uh, of this portability in the infrastructure because if you have this and you have this routing characteristics, it's not dependent on a particular infrastructure that you're using.

Excuse me, Mitch, Mitch Ashley again. How, how are you doing the user identity audit trail? Um, especially if it's, you know, uh, machine to machine or app to app API calls, or do you do it not for some things but not others?

Yeah, so when you're able to, so you still, uh, the assumption here is that you are, you have a way of authenticating whether it's a machine trap, you know, machine communicating with you, a user communicating with you, agent communicating with you, you have to have the authentication layer. And if the authentication layers based on open principles and open standards like OIDC and OAuth, right? Then you get that information in the metadata.

Okay. And then that starts with User identity doesn't mean end user, it's whatever the user of the agent or Correct. Alright.

Whoever the user is. Yeah, that's coming in. Great, thanks.

Yeah, I wanna follow up on that. Um, yeah, at ance. Um, so it seems like it needs access to a lot of metadata and then to match that metadata to what it actually means for traffic routing.

So where is that information defined? Like how do I know that this JWT equals an admin which should have access to this particular endpoint? Yeah.

Uh, so there's two parts to that question. One is where do you write the rule? Where do you enforce the rule?

Mm-hmm. Uh, and also maybe third part is where is that data even kept? Yeah.

So let's assume for this one, and typically what happens is this data is kept in an IDP in an identity system of some sort, right? Let's say Okta or key cloak or just take your pick, right? Any of the ones that speak that open standard, that's where the data is kept.

Mm-hmm. And the identity platform, what whatever that ends up being. Okay.

And then the gateway, so what traffic does is the API gateway is going to connect to that into, we already have the integration. So we authenticate user comes in, we ask the IDP, Hey, here's what the credentials the user is presenting, tell me is this allowed or not? And then you, whatever the IDP metadata that the IDP provides, it comes to the gateway.

And then at the gateway you're writing the rules to the, your point. Exactly. It's like, okay, well this user can only do this, or this user should route to this and that.

And then the end gateway is doing real time enforcement, uh, based on that policy, Right? So the customer tier, uh, example, that tier would be assigned based off of maybe a group membership from Exactly. Groups could be one way to groups, could be a proxy for that.

Mm-hmm. Or your IDP might have even richer metadata where you have identified even gone down to, uh, at a subgroup level. And as long as the IDP is giving you that metadata, you can act on that metadata.

Okay. So it's parsing whatever JSON comes back from Exactly. And going, okay, I found this field and it matches this rule.

So I apply this policy, We have a very efficient parser engine and a rules engine that's at the gateway level. Mm-hmm. But the data comes from the IDP and whatever the customer has, I imagine that could add some potential latency to the response time.

Yep. So I'm sure you'll get into it somewhere, how you reduce that latency to the minimum. So we have caching concepts.

I don't have anything particular on that, but it's the standard, like what's, uh, best practice in any API gateway, uh, because this, uh, authentication workflow is a very standard workflow mm-hmm. Where a request comes in, the gateway goes to the IDP authenticates, the user gets the Jot token. So that's a pretty standard one.

Now, if you're getting more than that, yes, there's some added latency and stuff, but you know, and what we are talking about here is milliseconds. Mm-hmm. Okay.

Thank you. Yeah. That includes, you said the session token, so you know, active user Yeah.

And you can cash locally, you know, for a certain amount of time and so forth. And are you, are you proxying all the API calls then on behalf of Yes. Okay.

On behalf of the the user, Everything's proxying. Yes. Okay.

So that brings me to this, uh, reality today where we have this fragmentation, uh, and the fragmentation really happens. So this application intelligence that we talked about, depending on what your workload type is, each environment, uh, almost mandates that you do it a a different way. So if you have VMs, I know this is CubeCon, but, uh, the reality is, uh, there's still many, many VMs out there.

VMs are not gonna go anywhere. So this assumption that we're baked into this is VMs and containers are gonna coexist. So the reality today is with VMs, the way you drive the application level policies is done one way using a combination of routers, load balancers and waf.

If you are dealing with Kubernetes, that is done through a different way where you have this concept of an ingress class now and a gateway, API being becoming the new standard and API gateways. And then if you have serverless workloads, then it's very much dependent on the serverless, uh, the runtime environment. You know, if you're using a AWS Lambda, you have to do it a certain way.

If you're doing Google Cloud run, you have to do it a certain way. So this is the reality that we're all dealing with, and this is what traffic has, uh, solved effectively. And that's what we kinda launched today.

Um, we had already kind of solved some of this in the past and, and today, uh, what we launched today is our support for K native. Um, so traffic supported, you know, traffic is a Kubernetes native platform. So we were already deeply integrated into the Kubernetes ecosystem today.

We launched K native support. So now you can actually deploy containers and, um, serverless workloads, unified control through traffic. And we also recently launched our support for native VMs as well.

So this is what, you know, just looking at a more architectural picture in this, uh, reference architecture, you would have traffic running inside of each of these environments inside a virtualized environment with VMs inside a cube cluster and inside a cube cluster running K native. So you address all three workloads and then traffic is running at the top. And this becomes, uh, you know, back to the question I was asked is like, okay, where do you write the policies and all that?

You would write the policies at the core layer that allow you to direct traffic into different environments? You know, because the reality is you have H two TP traffic coming in, it doesn't care whether it goes on a VM or, you know, a container or a server list. It's still HUDB traffic.

So you want to have this level of architectural freedom to be able to route things anywhere that you want, but define the policy once. So, you know, in that, uh, IDP integration that I talked about before, where you are authenticating the user, uh, and getting the metadata, you do it once at the top layer and that's it. And then you have all the rich metadata on which you can act and you can route things differently.

So your dual, uh, your dual traffic, sir, API gateway, so those for load balancing failover, both, uh, namespace splitting Both. I mean, you can, you can decide. I just put two just to show ha.

Okay. Like, uh, and you know, in Kubernetes you can just do the replica set and you would deploy a minimum of two. Um, you know, So you can do load balancing with it all set.

Yeah, You can. Uh, now we have, you know, we have an A LB, we're known for being an A LB and application load balancer. Uh, many of our customers put an NLB in front of it.

So let's say if you're deploying on a public cloud, you would have their NLB in front, and then you would have our A LB behind it. Yep. For Ference.

And so this is focusing on north south traffic, correct? No, east West, correct. Good question.

Yeah. Yeah. Any other questions on this?

And what we've also launched, uh, is a reference architecture for this with Nutanix. And so what we did with them, uh, not too long ago is we have integrated with the Nutanix A HV with flow networking. So this is their, like this is the best answer to people who are migrating off of VMware, is they need to, you know, ESX plus NSX, you know, if they need a alternative to that.

Uh, Nutanix, A HV is the answer, uh, with flow networking. So we have integrated into that environment. We can auto discover the VMs, uh, and we can provide the full traffic kind of routing benefits that we just talked about.

We're already integrated with Nutanix and KP, which is their Kubernetes platform. So this is a great reference architecture today available to customers, um, that are already taking advantage of this unified application intelligence. And with K native support that we just launched, uh, today, uh, that would seamlessly work inside of NKP.

Because it's a Kubernetes native platform, uh, you can run both microservices, always on microservices, plus also you can run, uh, the, uh, let's say scale to zero type of workloads with serverless. Okay. So in a nutshell, for this, uh, part of the presentation, just wanna talk about three things, right?

That you're getting with application intelligence, uh, unified application intelligence across VMs, containers, and serverless, you're able to really unify your routing, your security, and your observability. So you get one policy layer that will work everywhere consistently, regardless of these different environments. You get one enforcement model and you get that consistency of protection.

And also you can get, uh, we support open telemetry. Uh, we have one of the richest open telemetry support. So with that, you can actually have one dashboard with, you get visibility across all the different environments.

I, Any questions on this? Um, in terms of the observability piece, um, you're supporting O Hotel. Fantastic.

Good to hear. Um, do you integrate with any of the other network layer, um, pieces on Kubernetes thing, like C LIUM or EVPF or those components? Or are you strictly operating at the application layer?

Yeah, We are operating at the application layer. So we are agnostic to those things that are running. Mm-hmm.

Uh, we have, you know, we have had discussions on, you know, do we want to integrate down into that layer? I think it's an open discussion. Uh, we're not opposed to it, but where we're adding the value is, we're saying, saying, as long as the layer three network is available, our value is the layer seven, which is we're adding value on top of that.

Right. I'm thinking from a troubleshooting standpoint, trying to determine where an issue is. Yeah.

Get a more holistic view of the traffic across my cluster. Right. Um, I would do that through o the o hotel data that's streaming off of both solutions.

Yeah. I wonder if there was an integration or a dashboard that you've seen people put together to assist with that? Our customers do that.

Mm-hmm. Because they're taking their network ops team and their, you know, their dev ops team, putting them together and creating that. And as long as they have open standards, this is what allows you to create these Grafana dashboards.

Or, you know, we have integration with das zero, with, uh, you know, with others honeycomb. Mm-hmm. So you're able to quickly triangulate with layer seven where the problem might be, and then you go deeper with the layer three.

Mm-hmm. And to go pinpoint. Okay, Great.