 Welcome back to theCUBE as we continue coverage here from AWS re-invent 22. It's day three of our coverage here at the Venetian in Las Vegas and we're part of the AWS Global Startup Showcase with me to talk about what Kong's up to in that regard is Marco Paladino, who's the CTO and the co-founder of Kong. Marco, good to see you. Well, thanks for having me here. Yeah, I was going to say, by the way, you've got a beautiful exhibit down on the show floor. How's the week been for you so far as an exhibitor here? It's been very busy. This year we made a big investment at AWS re-invent. I think this is one of the best conferences in the industry. There is technology, developers, but it's also business-oriented. So you can learn about all the business outcomes that our customers or people are trying to make when adopting these new technologies. So it's pretty good so far. Good, good to hear. So in your world, the API world, it used to be, we had this giant elephant, now we're cutting down into little pieces, right? That's right. Micro now these days. That's right. Talk about that trend a little bit, what you're seeing, and we'll jump in a little deeper as to how you're addressing that. Well, I think the industry learned a long time ago that running large code bases is actually quite problematic when it comes to scaling the organization and capturing new opportunities. And so we're transitioning to microservices because we want to get more opportunities in our business. We want to be able to create new products faster. We want to be able to leverage existing services or data that we've built like an assembly line of software, picking up APIs that other developers are building and then assemble them together to create new experiences or new products enter new markets. And so microservices are fantastic for that. Except microservices, they also introduce significant concerns on the networking layer, on the API layer. So this is where Kong specializes by providing API infrastructure to our customers. So more about the problems, more about the challenges there because you're right, opportunities always create, you know, big upside and I don't want to say downside but they do introduce new complexities. That's right. And introducing new complexity, it's a little bit the biggest enemy of any large organization, right? We want to reduce complexity, we want to move faster, we want to be more agile and we need an API vision to be able to do that. Our teams, you know, I'm speaking with customers here at ReInvent, they're telling me that in the next five years the organization is going to be creating more APIs than all the APIs they've created up until now, right? So how do you support? That's a mind-boggling number, right? It's mind-boggling, yeah, exactly. How do you support that type of growth? And things have been moving so fast, I feel like there is a big dilemma in, you know, with certain organizations where, you know, we have not thought a long-term strategy for APIs whereas we do have a long-term strategy for our business, but APIs are running the business, we must have a long-term strategy for our APIs, otherwise we're not going to be able to execute and that's a big dilemma right now. Yeah, so how do we get the horse back in front of the cart then? Because it's like you said, it's almost as if we're reprioritizing, you know, incorrectly or inaccurately, right? You're getting a little bit ahead of ourselves. Well, so, you know, whenever we have a long-term strategy for pretty much anything in the organization, right, we know what we want to do, we know the outcome that we want to achieve, we work backwards to, you know, determine what are the steps that are going to bring us there. And the responsibility for thinking long-term in every organization, including for APIs, at the end of the day, always falls on the leaders and on the shoulders of the leadership and the C executives of the organization, right? And so we're seeing, you know, look at AWS, by the way, look at Amazon. This conference would not have been possible without a very strong API vision from Amazon and the CEO himself, Jeff Bezos. Everybody talks about wanting to become an API-first organization and Amazon did that with the famous Jeff Bezos mandate. Today, AWS, it's $100 billion revenue for Amazon. You see, Amazon was not the first organization with an e-commerce, but it was the first one that married a very strong e-commerce business execution with a very strong API vision, and here we are. So, yeah, here we are, putting you squarely in a pretty good position, right, in terms of what you're offering to the marketplace who has this high demand. You see this trend starting to explode, the hockey sticks headed up a little bit, right? You know, how are you answering that call? Specifically, how are you looking at your client's needs and trying to address what they need and when they need it and how they need it because everybody's in a kind of a different place right now, right? That's exactly right. And so you have multiple teams at different stages of their journey, right, with technology, some of them are still working on legacy, some of them are moving to the cloud, some of them are working in containers and microservices and Kubernetes. And so how do we provide an API vision that can fulfill the needs of the entire organization in such a way that we reduce that type of fragmentation and we don't introduce too much complexity? Well, so at Cong we do it by essentially splitting the API platform in three different components. One is API management, whenever we want to expose APIs internally or to an ecosystem of partners, right, or to mobile, then there is a service mesh. You know, as we are splitting these microservices into smaller parts, we have a lot of connectivity. All, you know, across all the services that the teams are building that we need to manage. You know, the network is unreliable. It's by default not secure, not observable. There is nothing that works in there. And so how do we make that network reliable without asking our teams to go and build these cross-cutting concerns whenever they create a new service? And so we need a service mesh for that. And then finally, we could have the best API infrastructure in the world. Millions of APIs and millions of microservices. Everything is working great. And with no API consumption, all of that would be useless. The value of our APIs and the value of our infrastructure is being driven by the consumption that we're able to drive to all of these APIs. And so there is a whole area of API productivity and discovery and design and testing and mocking that enables the application teams to be successful with APIs, even when they do have the proper API infrastructure in place that's made of meshes and management products and so on and so forth. Can you give me some examples? I mean, at least with people that you've been working with in terms of addressing maybe unique needs because again, as you've addressed, journeys are in different stages now. Some people are on level one, some people are on level five. So maybe just a couple of examples of clients with whom you've been working. Yeah, so listen, I was talking with many organizations here at AWS re-invent that are, of course, trying to migrate to the cloud. That's a very common transformation that pretty much everybody's doing in the world. And how do you transition to the cloud by de-risking the migration while at the same time being able to get all the benefits of running in the cloud? Well, we think that we can do that in two ways. One by containerizing our workloads so that we can make them portable. But then we also need to lift and shift the API connectivity in such a way that we can determine how much traffic goes to the legacy and how much traffic goes to the new cloud infrastructure. And by doing that, we're able to de-risk some of these transformations that can be quite complex. And then finally, API infrastructure must support every team in the organization. And so being able to run on a single cloud, multi-cloud, single cluster, multi-cluster, VMs, containers, that's important and essential. Because we want the entire organization to be on board because whenever we do not do that, then the developers will make short-term decisions that are not going to be fitting into the organizational outcomes that we want to achieve. And we look at any outcome that the organization wants to achieve. The cloud transformation, improving customer retention, creating new products, being more agile. At the end of the day, there is an API that's powering that outcome. Right, right. Well, and there's always a security component, right, that you have to be concerned about. So how are you raising that specter with your clients to make them aware? Because sometimes, I wouldn't say it's an afterthought, but sometimes it's not the first thought. And obviously with APIs and with their integral place in the system now, security's got to be included in that, right? API security is perhaps the biggest, biggest request that we're hearing from customers. You know, 83% of the world's internet traffic. At the end of the day, runs on APIs. That's a lot of traffic. As a matter of fact, APIs are the first attack vector for any malicious store party whenever there is a breach. APIs must be secured. And we can secure APIs on different layers of our infrastructure. We can secure APIs at the L4 mesh layer by implementing zero trust security, for example, encrypting all the traffic, assigning an identity to every service, removing the concept of trust from our systems because trust is exploitable, right? And so we need to remove the zero trust, remove the concept of trust. And then once we have that underlying networking that's being secure and encrypted, we want to secure access to our APIs. And so this is the typical authentication authorization concerns. You know, we can use patterns like OPA, open policy agent to create a security layer that does not rely on the team's writing code every time they're creating a new service, but the infrastructure is enforcing the type of layer. So for example, last week I was in Sweden, as a matter of fact, speaking with the largest bank in Sweden, one of our customers, and they were telling us that they are implementing GDPR validation in the service mesh on the OPA layer across every service that anybody's building. Why? Well, because you can embed the GDPR settings of the consumer into a claim in a JOT token and then you can use OPA to validate in a blanket way that JOT token across every service in the mesh. Developers don't have to do that, it just comes out of the box like that. And then finally, so networking security, API security for access and management of those APIs. And then finally we have deep inspection of our API traffic. And here you will see more exotic solutions for API security where we essentially take a subset of our API traffic and we try to inspect it to see if there is anybody doing anything that they shouldn't be doing and perhaps block them or raise the flag, so to speak. Well, the answer is probably yes. They are, somebody's trying to. Somebody's trying to. Yeah, you're trying to block them out. Before I let you go, you've had some announcements leading up here to the show. Just to hit a few of those highlights, if you would. Well, you know, CONG is an organization that is very proud of the technology that we create. Of course, we started with the API Gateway, CONG Gateway, which was our first product, the most adopted gateway in the world. But then we've expanded our platform with ServiceMesh. We just announced the BPF support in the ServiceMesh, for example. We made our CONG Gateway, which was already one of the fastest gateway. If not the fastest gateway out there, 30% faster with CONG Gateway 3.0. We have shipped an official CONG operator for Kubernetes, both community and enterprise. And then finally, we're doubling down on Insomnia. Insomnia is our API productivity application that essentially connects the developers with the APIs that they're creating and allows them to create a discovery mechanism for testing, mocking, debugging those APIs. All of this, we, of course, ship it on-prem, but then also on the cloud. And in a cloud conference right now, of course, cloud is a very important part of our corporate strategy and our customers are asking us that. Why? Because they don't want to manage the software. They want the API platform. They don't want to manage it. Well, now nobody does. Exactly. There are a few stragglers. A few, and for them, there is the on-prem platform. If I let them go, right? Exactly. If you want to make it a little quick and dirty, hand it off, right? That's exactly right, yes. Let Kong do the heavy lifting for you. Hey, Marco, thanks for the time. Yeah, thank you so much. We appreciate it, and again, congratulations on what appears to be a pretty good show for you guys. Yeah, thank you. Well done. All right, we continue our discussions here at AWS ReInvent22. You're watching theCUBE, the leader in high-tech coverage.