 Hi, this is Oscar Glimpartia and welcome to a brand new episode of TFI Let's See or Demo. And today we have with us Sudeep Goswami, Chief Revenue Officer at Traffic Labs and Nathan for the Solutions Architect at once again Traffic Labs. Sudeep, Nathan, it's great to have you both on the show. Great to be here. Likewise. Of course, Nathan, you're here to show us a demo. But before we jump into demo, we would love to talk a bit about Traffic Labs, Traffic Hub. We talked about that, you know, when you folks announced at KubeCon also. Sudeep, if you're here, I would love to just, you know, remind our viewers what is Traffic Labs all about. Traffic Labs has been born in the cloud native era. What we offer is three different products. We offer a cloud native ingress controller, a cloud native API gateway, and most recently a Kubernetes native API management solution. All of these with a single goal, which is to help our customers and organizations expose their applications, their APIs and their microservices to the outside world. What are some of the challenges and limitations of traditional API management, which kind of leads to why Traffic Labs was created? I think if you look at the existing API management space, there are many, many different vendors and the common challenges that we see across all of them. One is they tend to, most of them have been born in the pre cloud native era. So their architecture tends to be monolithic and therefore they are limited to do many different things that a modular and an open cloud native architecture will allow you to do. So first of all, you have to do an all or nothing consumption model. You cannot take certain pieces of those stack and use them while discarding the rest. So it's an all or nothing thing. You also have to install many different types of applications into that big monolith to make them work. And second, they are mostly, if you look at the operational model for them, they're mostly built on UI based workflows. So to do DevOps becomes much more challenging in that environment. And then I will say the last limitation that we see with them, they tend to be very opinionated in terms of their deployment environments. And most of the traditional solutions really require you to have an on-prem presence. So you cannot do multi-cloud strategies. That becomes challenging. And especially when you're doing edge cloud strategies, that also becomes very challenging. And now let's talk about how traffic hub or traffic labs is tackling these challenges and limitations of traditional API management. Yeah. So I think our approach and the conviction that we have gotten being in this market for many years is, number one, the traditional API management solutions do not scale as we just highlighted, the other reasons that we mentioned. And then some of the more newer solutions that are cloud native are not enough. And we say that because in the API management world, the Kubernetes has become the standard operating model now. I think there's no doubt about that. That is the de facto standard through which people are deploying applications, I should say. And that is what gives people the application agility for their digital transformation initiatives. So if Kubernetes is the standard operating model, you can't just be cloud native and apply the same model. So we believe at traffic labs, the approach that needs to be taken, which is what we have done, is a Kubernetes native approach to API management. And it is the first in the industry. And that is the approach with which we have launched traffic hub, which is our API management solution. I can also kind of explain, I mean, of course, you talked about why part, but how is, you know, your API management Kubernetes native? Maybe I can shed some light on what do we mean by being Kubernetes and how is that different from being cloud native? So there you can look at almost like three different categories or three different pillars on being Kubernetes native. The first and foremost is having a deep services awareness. So the language of Kubernetes is understanding services and understanding how to deploy those services in a highly available manner. So by being Kubernetes native, an API management solution automatically gets this deep services awareness. So you know, right off the bat, where all of your services are running, the auto discovery of services is the first primitive through which you start your operational model. And once you do that, then it becomes a very simple API to services mapping. And what that allows you to do, which is next, is high availability and security are kind of almost built in. Now there are multiple layers to security, which we can talk about. But if you just look at what auto discovery allows you to do, there's a lot of talk in API security about phantom and rogue services running and no one knows where they're running. Now if you apply a Kubernetes native model to this, you auto discover every service. So there are no more rogue or phantom services. And then you get to decide how you want to treat that service from an exposure standpoint. Do you want to keep them limited to your internal visibility? Do you want to expose them as a web application with certain authentication parameters? Or do you now want to expose them as APIs? So it really starts with visibility, and then the operator has full control of how they want to treat that. And also within Kubernetes native, high availability is almost given, you know, through the use of replicas, services can go up and down, they can scale up and down depending on demand. So you are right into like leveraging that functionality. So you know exactly how your high available infrastructure looks like. And then the third thing, by being Kubernetes native, you can elevate your GitOps experience. With Kubernetes, CRD has now become a first class citizen. And CRD is just, you know, think of it as like a way of being able to create a multi-object model, and you can have a manifest that you can fully automate. So even if you're doing a UI point and click operation, so you go to the user dashboard and you click something and you create something, on the back end is translating that into manifests that you can apply directly to GitOps. So somebody who's new to Kubernetes and they're trying to learn Kubernetes, this type of an approach makes it very, very easy for them to do an operation through a UI and directly see what the result of that is on the back end Kubernetes. And there's also for advanced users that want to start with code to begin with and take it further. Excellent. Thank you so much. And now it's time to get, you know, made them on stage and let's have a demo of traffic hub. Today I'm going to walk you through traffic hub. Traffic hub is the industry's first Kubernetes native API management solutions for publishing, managing and securing APIs for traffic proxy, as well as third-party ingress controllers, including Nginx. Traffic hub dashboards, it's quite intuitive, can quickly give you an overview of the number of agents currently managed. Number of services currently running across all your clusters. Number of access controls currently defined, and you give you a quick overview of number of services currently published across all your clusters. From cluster agents, you can see that we have multiple Kubernetes cluster currently managed that are resides on across multiple cloud providers and edge. This gives you the freedom of hosting your APIs anywhere you want. You should be able to publish, manage and secure your APIs quite easily through hub. You can see that we have Kubernetes cluster hosted on Google with Nginx as an ingress controller, another Kubernetes cluster on AWS with the traffic as an ingress controller. We also have one on Azure with the traffic as an ingress controller, and finally we have an edge deployment using Rancher K3S that is running by default a traffic proxy as an ingress controller. If we select one of the agents, we get a full visibility of the cluster. We are Kubernetes native, so we integrate directly with the Kubernetes API server, so whatever the API server can see, we should have full visibility. We also can get a full list of APIs that's published through this cluster. If you click on one of these APIs, you will get more information about this specific API in the backend application, or you can quickly publish an application that is running on this cluster through the dashboard, which give you a quick time to value if you want to test an API quickly. For better manageability of these APIs, you basically can bundle these APIs into a collection using labels. This allows more flexibility and reusability when referencing these APIs. From the portal view, we can also apply an API access control policies or an RBAC, which basically restrict access to these APIs to specific user groups. Only authorized users or groups should be able to have access to these APIs. We offer also an API developer portal. If we log into the API developer portal using one of the authorized accounts, we should be able to interact with these APIs directly. Once we log into the portal, you will see that we have access to all the APIs that is allowed for this specific account, in this case is the collection that we've created. We should be able to interact with the APIs and all these various endpoints. All APIs by default are protected using JWT to prevent unauthorized access to these APIs. The user, once it logs in, they can generate a token and use this token to authorize and interact with these APIs to confirm functionality. Everything that we have done through the dashboard can easily be implemented using GitOps. Since Traffic Hub is a Kubernetes native, everything that we define through the dashboard it get translated into CRDs or custom resource definitions. What we need to do, you just need to define your API definition file, then define your API collection for better manageability and reusability of these APIs, define your API access policy to restrict access to the API to a specific user in group, and then define your API portal definition file so you can interact with these APIs. Once you have all these definition files ready, you can use your preferred GitOps solutions like Argo CD or Flux CD, and then you can deploy, publish, and manage your APIs in seconds. So that's pretty much a quick walkthrough of the Traffic Hub. I want to emphasize one point that maybe one thing that made them show it, I probably want to stress when he was showing through Traffic Hub you're able to see multiple different clusters and those clusters could be running the Ingress Controller from Traffic, which is Traffic Proxy, or it could run a third-party Ingress Controller, which is the first in the industry that an API management solution is allowing multiple third-party Ingress Controllers to be part of that stack. What you have seen with all of the existing vendors is they will pick a particular Ingress Controller, usually their own, or they will take an open source and then create their wrapper around it, and that is the only one you can use. So this architecture gives you a lot of flexibility. Let's say you have an environment that is running InginX as the Ingress Controller, and now they want to start publishing APIs. They can keep their InginX Controller and just install Traffic Hub on top and are able to see all of the benefits that made them just show to you. Another example could be an environment that's running HF Proxy. Now, if you look at the market, I think between Traffic Proxy and InginX, I mean that represents 90% of the market. So this is a very, very compelling solution in the first in the industry that will allow you to do API management independent of the Ingress Controller. So Dave, Metham, thank you so much for taking the time out today. Not only talk about Traffic Labs, Traffic Hub, and also give us a demo. And as usual, I would love to chat with you folks again. Thank you. Thank you. It was a pleasure. I appreciate it.