>>Welcome back to the Cube, as a continued coverage here from AWS Reinvent 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 to in that regard is Marco Palladino, who's the, the CTO and the co-founder of Con Marco. Good >>To see you. Well, thanks for having me >>Here. Yeah, I was gonna say, by the way, I, I, 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. You know, to this year we made a big investment at the WS reinvent. You know, 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, you know, customers or, you know, people are trying to make when, when adopting these new technologies. So it's very good so far. >>Good, good, good to hear. Alright, so in your world, the API world, you know, it used to be we had this, you know, giant elephant. Now we're cutting down the little pieces, right? That's right. We're all going 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, you know, we're transitioning to microservices because we want to get more opportunities in our business. We want to be able to create new products, fasters, we want to be able to leverage existing services or data that we have built, like an assembly line of software, you know, 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. And so this is where Kong specializes by providing API infrastructure to our customers. >>Right. So more about the problems, more about the challenges there, because you're right, it, opportunities always create, you know, big upside and, and I, I don't wanna 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, 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 taught 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 gonna be able to execute. And that's a big dilemma right now. Yeah. >>So, 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've, we're, we're reprioritizing, you know, incorrectly or inaccurately, right? You're, 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 gonna bring us there. And, and the responsibility for thinking long term in, in every organization, including for APIs at the end of the day, always falls on the leaders and the should on the shoulders of the leadership and, and to see 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 a hundred billion revenue for Amazon. You see, Amazon was not the first organization with, with an e-commerce, but if 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, in, 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 at how, how are you looking at your client's needs and, 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. Yep. Some of them are working in containers and in microservices and Kubernetes. And so how do you, 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 con, we do it by essentially splitting the API platform in three different components. Okay. One is API management. When, whenever we want to expose APIs internally or to an ecosystem of partners, right? Or to mobile, DRA is a service mesh. You know, as we're 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, to manage. >>You know, the network is unreliable. It's by default, not secure, not observable. There is nothing that that works in there. And so how do we make that network reliable without asking our teams to go and build these cross-cut concerns whenever they create a new service. And so we need a service match for that, right? And then finally, we could have the best AP 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 a, the proper API infrastructure in place that's made of meshes and management products and so on and so forth. Right. >>Can you gimme some examples? I mean, at least with people that you've been working with in terms of addressing maybe unique needs. Cuz 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 Yeah. Of clients with whom you've been working. Yeah, >>So listen, I I was talking with many organizations here at AWS Reinvent that are of course trying to migrate to the cloud. That's a very common common transformation that pretty much everybody's doing in the world. And, 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, of running in the cloud? Well, we think that, you know, we can do that in two, 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 deal with 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 your 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, 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 it, I wouldn't say it's an afterthought, but sometimes it's not the first thought. And, and obviously with APIs and with their integral place, you know, in, in the system now security's gotta 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, right? That's a lot of traffic. As a matter of fact, APIs are the first attack vector for any, you know, 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 L four 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 cut 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 op, op or 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 while our customers, and they were telling us that they are implementing GDPR validation in the service mesh on the OPPA 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 gel token, and then you can use OPPA to validate in a blanket way that Jo 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, 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, and perhaps block them or, you know, raise, raise, 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 'em out. Before I let you go, you've had some announcements leading up here to the show that's just to hit a few of those highlights, if you would. >>Well, you know, Kong is an organization that you know, is very proud of the technology that we create. Of course, we started with a, with the API gateway Con Gateway, which was our first product, the most adopted gateway in the world. But then we've expanded our platform with service mesh. We just announced D B P F support in the service mesh. For example, we made our con gateway, which was already one of the fastest gateway, if not the fastest gateway out there, 30% faster with Con Gateway 3.0. We have shipped an official con operator for Kubernetes, both community and enterprise. And then finally we're doubling down on insomnia, insomnia's, our API productivity application that essentially connects the developers with the APIs that are creating and allows them to create a discovery mechanism for testing, mocking the bagging, those APIs, all of this, we of course ship it OnPrem, but then also on the cloud. And you know, in a cloud conference right now, of course, cloud, right? Right. Is a very important part of our corporate strategy. And our customers are asking us that. Why? Because they don't wanna manage the software, they want the API platform, they don't, don't wanna manage it. >>Well, no, nobody does. And there are a few stragglers, >>A few, a few. And for them there is the on-prem >>Platform. Fine, let 'em go. Right? Exactly. But if you wanna make it a little quick and dirty, hand it off, right? Oh, >>That's exactly right. Yes. >>Let Con do the heavy lifting for you. Hey Marco, thanks for the time. Yeah, thank you so much. We appreciate, 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. Reinvent 22. You're watching the Cube, the leader in high tech coverage. >>Okay.

>>Well, good day and welcome back to the cube as we continue our segment featuring AWS star showcase we're with now Mike Bilodeau, who's in corporate development and operations at Kong. Mike, uh, thank you for joining us here on the cube and particularly on the startup showcase. Nice to have you and pong represented here today. Thanks for having me, John. Great to be here. You bet. All right, first off, let's just tell us about pong a little bit and, and, uh, con cadet, which I know is your, your feature program, um, or, um, service. Oh, I love the name by the way. Um, but tell us a little bit about home and then what connect is all about to? Sure. So, uh, Kong as a company really came about in the past five years, our two co-founders came over from Italy in, uh, in the late, in the late aughts, early 20 teens and, uh, had a company called Mashape. >>And so what they were looking at and what they were betting on at that time was that API APIs, uh, were going to be the future of how software was built and how developers interacted with software. And so what came from that was a piece of, uh, they were running that shape as a marketplace at the time. So connecting developers sit in for an API so they can consume them and use them to build new software. And what they found was that actually the most valuable piece of technology that they created was the backbone for running that marketplace. And that backbone is what Kong is. And so they created it to be able to handle a massive amount of traffic, a massive amount of API APIs, all simultaneously. This is a problem that a lot of enterprises have, especially now that we've started to get some microservices, uh, started to, to have more distributed technologies. >>And so what Kong is really is it's a way to manage all of those different API APIs, all of the connections between different microservices, uh, through a single platform, which is called connect. And now that we've started to have Coobernetti's, uh, the, sort of the birth and the, the nascent space of service mesh con connect allows all of those connections to be managed and to be secured and made reliable, uh, through a single platform. So what's driving this right. I mean, um, you, you mentioned micro services, um, and Coobernetti's, and that environment, which is kind of facilitating, you know, this, uh, I guess transformation you might say. Um, but what's the big driver in your opinion, in terms of, of what's pushing this microservices phenomenon, if you will, or this revolution. Sure. And when I think it starts out at, at the simple active of technology acceleration in general, um, so when you look at just the, the real shifts that have come in enterprise, uh, especially looking, you know, start with that at the cloud, but you could even go back to VMware and virtualization is it's really about allowing people to build software more rapidly. >>Um, all of these different innovations that have happened, you know, with cloud, with virtualization now with containers, Kubernetes, microservices, they're really focused on making it, uh, so that developers can build software a lot more quickly, uh, develop the, the latest and greatest in a more rapid way. >>A huge driver out of this is just making it easier for developers, for organizations to bring new technologies to market. Uh, and we see that as a kind of a key driver in a lot of these decisions that are being made. I think another piece of it that's really coming about is looking at, uh, security, uh, as a really big component, you know, do you have a huge monolithic app? Uh, it can become very challenging to actually secure that if somebody gets into kind of that initial, uh, into the, the initial ops space, they're really past the point of no return and can get access to some things that you might not want them to similar for compliance and governance reasons that becomes challenging. So I think you're seeing this combination of where people are looking at breaking things into smaller pieces, even though it does come with its own challenges around security, um, that you need to manage, it's making it so that, uh, there's less ability to just get in and cause a lot of damage kind of all at once. Often Melissa malicious attackers. >>Yeah. You bring up security. And so, yeah, to me, it's almost, in some cases it's almost counterintuitive. I think about, I've got the, if I got this model, the gap and I've got a big parameter around it, right. And I know that I can confine this thing. I can contain this. This is good. Now microservices, now I got a lot of, it's almost like a lot of villages, right. They're all around. And, and uh, I don't have the castle anymore. I've got all these villages, so I have to build walls around all these villages. Right. But you're saying that there that's actually easier to do, or at least you're more capable of doing that now as opposed to living >>Three years ago. Well, you can almost think of it, uh, as if you have this little just right, and you might, um, if you have one castle and somebody gets inside, they're going to be able to find whatever treasury may have, you know, to extend the analogy here a bit, but now it's different, uh, 50 different villages that, you know, uh, an attacker needs to look in, it starts to become really time-consuming and really difficult. And now when you're looking at, especially this idea of kind of cybersecurity, um, the ability to secure a monolithic app is typically not all that different from what you can do with a microservice or with a once you get past that initial point, instead of thinking of it, you know, I have my one wall around everything, you know, think of it almost as a series of walls where it gets more and more difficult. Again, this all depends on, uh, that you're, you're managing that security well, which can get really time-consuming more than anything else and challenging from a pure management standpoint, but from an actual security posture, it is a way of where you can strengthen it, uh, because you're, you're creating more, um, more difficult ways of accessing information for attackers, as well as just more layers potentially of security. >>But what do you do to lift that burden then from, from the customer? Because like you said, that that that's a concern they really don't want to have. Right. They want, they want you to do that. They want somebody to do that for them. So what can, what do you do to alleviate those kinds of stress >>On their systems? Yeah, it's a great question. And this is really where the idea of API management and, um, in it's in its infancy came from, was thinking about, uh, how do we extract a way these different tasks that people don't really want to do when they're managing, uh, how API, how people can interact with their API APIs, whether that be a device or another human, um, and part of that is just taking away. So what we do and what API gate management tools have always done is abstract that into a, a new piece of software. So instead of having to kind of individually develop and write code for security, for logging, for, you know, routing logic, all these different pieces of how those different APIs will communicate with each other, we're putting that into a single piece of software and we're allowing that to be done in a really easy way. >>And so what we've done now with con connect and where we've extended that to you, is making it even easier to do that at a microservices level of scale. So if you're thinking about hundreds or thousands of different microservices that you understand and be able to manage, that's what we're really building to allow people to do. And so that comes with, you know, being able to, to make it extremely easy, uh, to, to actually add policies like authentication, you know, rate-limiting, whatever it may be, as well as giving people the choice to use what they want to use. Uh, we have great partners, you know, looking at the Datadog's, the Okta's of the world who provide a pretty, pretty incredible product. We don't necessarily want to reinvent the wheel on some of these things that are already out there, and that are widely loved and accepted by, uh, technology, practitioners and developers. We just want to make it really easy to actually use those, uh, those different technologies. And so that's, that's a lot of what we're doing is providing a, a way to make it easy to add this, you know, these policies and this logic into each one of these different services. >>So w if you're providing these kinds of services, right. And, and, and, and they're, they're, they're new, right. Um, and you're merging them sometimes with kind of legacy, uh, components, um, that transition or that interaction I would assume, could be a little complex. And, and you've, you've got your work cut out for you in some regards to kind of retrofit in some respects to make this seamless, to make this smooth. So maybe shine a little light on that process in terms of not throwing all the, you know, the bath out, you know, with, with the baby, all the water here, but just making sure it all works right. And that it makes it simple and, and, um, takes away that kind of complexity that people might be facing. >>Yeah, that's really the name of the game. Uh, we, we do not believe that there is a one size fits all approach in general, to how people should build software. Uh, there are going to need instances aware of building a monolithic app. It makes the most sense. There are going to be instances where building on Kubernetes makes the most sense. Um, the key thing that we want to solve is making sure that it works and that you're able to, to make the best technical decision for your products and for your organization. And so in looking at, uh, sort of how we help to solve that problem, I think the first is that we have first class support for everything. So we support, you know, everything down to, to kind of the oldest bare metal servers to NAMS, to containers across the board. Uh, and, and we had that mindset with every product that we brought to market. >>So thinking about our service mesh offering, for instance, um, Kula is the open source project that under tens now are even, but looking at Kumo, one of the first things that we did when we brought it out, because we saw this gap in space was to make sure that that adds first-class support for and chance at the time that wasn't something that was commonly done at all. Uh, now, you know, there there's more people are moving in that direction because they do see it as a need, which is great for the space. Um, but that's something where we, we understand that the important thing is making sure your point, you said it kind of the exact way that we like to, which is it needs to be reliable. It needs work. So I have a huge estate of, you know, older applications, older, uh, you know, potentially environments, even. I might have data centers that might've cloud being, trying to do everything all at once. Isn't really a pragmatic approach. Always. It needs to be able to support the journey as you move to, to a more modern way of building. So in terms of going from on-premise to the cloud, running in a hybrid approach, whatever it may be, all of those things shouldn't be an all or nothing proposition. It should be a phase approach and moving to, to really where it makes sense for your business and for the specific problem >>Talking about cloud deployments, obviously AWS comes into play there in a major way for you guys. Um, tell me a little bit about that, about how you're leveraging that relationship and how you're partnering with them, and then bringing the, the value then to your customer base and kind of how long that's been going on and the kinds of work that you guys are doing together, uh, ultimately to provide this kind of, uh, exemplary product or at least options to your customers. >>Yeah, of course. I think the way that we're doing it first and foremost is that, um, we, we know exactly who AWS is and the space and, and, you know, a great number of our customers are running on AWS. So again, I think that first class support in general for AWS environments services, uh, both from the container service, their, their Kubernetes services, everything that they can have and that they offer to their customers, we want to be able to support, uh, one of the first areas of really that comes to mind in terms of first-class integration and support is thinking about Lambda and serverless. Um, so at the time when we first came out, was that, again, it was early for us, uh, or early in our journey as product and as company, uh, but really early for the space. And so how we were able to support that and how we were able to see, uh, that it could support our vision and, and what we wanted to bring as a value proposition to the market has been, you know, really powerful. So I think in looking at, you know, how we work with AWS, certainly on a partnership level of where we share a lot of the same customers, we share a very similar ethos and wanting to help people do things in the most cost-effective rapid manner possible, and to build the best software. Uh, and, you know, I mean, for us, we have a little bit of a backstory with AWS because Jeffrey's us was a, an early investor in, in common. >>Yeah, exactly. I mean, the, the whole memo that he wrote about, uh, you know, build an API or you're fired was, was certainly an inspiration to, to us and it catalyzed, uh, so much change in, in the technology landscape in general, about how everyone viewed API APIs about building a software that could be reused and, and was composable. And so that's something that, you know, we, we look at, uh, kind of carrying forward and we've been building on that momentum ever since. So, >>Well, I mean, it's just kind of take a, again, a high level, look at this in terms of microservices. And now that it's changing in terms of cloud connectivity. Thank you. Actually, I have a graphic to that. Maybe we can pull up and take a look at this and let's talk about this evolution. You know, what's occurring here a little bit, and, and as we take a look at this, um, tell us what you think those, these impacts are at the end of the day for your customers and how they're better able to provide their services and satisfy their customer needs. >>Absolutely. So this is really the heart of the connect platform and of our vision in general. Um, we'd spoken just a minute ago about thinking how we can support the entire journey or, uh, the, the enterprise reality that is managing a, a relatively complex environment of modelists different services, microservices, you know, circle assumptions, whatever it may be, uh, as well as lots of different deployment methods and underlying tech platforms. You know, if you have, uh, virtual machines and Kubernetes, whatever, again, whatever it may be. But what we look at is just the different sort of, uh, design patterns that can occur in thinking about a monolithic application. And, um, okay. Mainly that's an edge concern of thinking about how you're going to handle connectivity coming in from the edge and looking at a Kubernetes environment of where you're going to have, you know, many Kubernetes clusters that need to be able to communicate with each other. >>That's where we start to think about, uh, our ingress products and Kubernetes ingress that allows for that cross applic, uh, across application communication. And then within the application itself, and looking at service mesh, which we talked a little bit about of just how do I make sure that I can instrument and secure every transaction that's happening in a, a truly microservices, uh, deployment within Kubernetes or outside of it? How do I make sure that that's reliable and secure? And so what we look at is this is just a, uh, part of it is evolution. And part of it is going to be figuring out what works best when it, um, certainly if you're, if you're building something from scratch, it doesn't always make sense to build it, your MDP, as, you know, microservices running on Kubernetes. It probably makes sense to go with the shortest path, uh, at the same time, if you're trying to run it at massive scale and big applications and make sure they're as reliable as possible, it very well does make sense to spend the time and the effort to, to make humanize work well for you. >>And I think that's, that's the, the beauty of, of how the space is shifting is that, uh, it's, it's going towards a way of the most practical solution to get towards business value, to, to move software quicker, to give customers the value that they want to delight them to use. Amazon's, uh, you know, phrase ology, if that's, uh, if that's a word, uh, it's, it's something of where, you know, that is becoming more and more standard practice versus just trying to make sure that you're doing the, the latest and greatest for the sake of, of, uh, of doing it. >>So we've been talking about customers in, in rather generic terms in terms of what you're providing them. We talked about new surfaces that are certainly, uh, providing added value and providing them solutions to their problems. Can you give us maybe just a couple of examples of some real life success stories, where, where you've had some success in terms of, of providing services that, um, I assume, um, people needed, or at least maybe they didn't know they needed until, uh, you, you provided that kind of development that, but give us an idea of maybe just, uh, shine, a little light on some success that you've had so that people at home watching this can perhaps relate to that experience and maybe give them a reason to think a little more about calm. >>Yeah, absolutely. Uh, there, there's a number that come to mind, but certainly one of the customers that I spent a lot of time with, uh, you know, become almost friends would be with, uh, with the different, with a couple of the practitioners who work there is company called Cargill. Uh, it's a shared one with us and AWS, you know, it's one we've written about in the past, but this is one of the largest companies in the world. Um, and, uh, the, the way that they describe it is, is that if you've ever eaten a Vic muffin or eaten from McDonald's and had breakfast there, you you've used a Cargill service because they provide so much of the, the food supply chain business and the logistics for it. They had a, uh, it's a, it's an old, you know, it's a century and a half old company. >>It has a really story kind of legacy, and it's grown to be an extremely large company that's so private. Uh, but you know, they have some of the most unique challenges. I think that I've, I've seen in the space in terms of needing to be able to ensure, uh, that they're able to, to kind of move quickly and build a lot of new services and software that touch so many different spaces. So they were, uh, the challenge that was put in front of them was looking at really modernizing, you know, again, a century and a half old company modernizing their entire tech stack. And, you know, we're certainly not all of that in any way, shape or form, but we are something that can help that process quite a bit. And so, as they were migrating to AWS, as they were looking at, you know, creating a CICB process for, for really being able to ship and deploy new software as quickly as possible as they were looking at how they could distribute the, the new API APIs and services that they were building, we were helping them with every piece of that journey, um, by being able to, to make sure that the services that they deployed, uh, performed in the way that they expected them to, we're able to give them a lot of competence and being able to move, uh, more rapidly and move a lot of software over from these tried and true, uh, you know, older or more legacy of doing things to a much more cloud native built as they were looking at using Kubernetes in AWS and, and being able to support that handle scale. >>Again, we are something that was able to, to kind of bridge that gap and make sure that there weren't going to be disruptions. So there, there are a lot of kind of great reasons of why they're their numbers really speak for themselves in terms of how, uh, how much velocity they were able to get. You know, they saying them saying them out loud on the sense fake in some cases, um, because they were able to, you know, I think like something, something around the order of 20 X, the amount of new API APIs and services that they were building over a six month period, really kind of crazy crazy numbers. Um, but it is something where, you know, the, for us, we, we got a lot out of them because they were open source users. So calling is first and foremost, an open source company. >>And so they were helping us before they even became paying customers, uh, just by testing the software and providing feedback, really putting it through its paces and using it at a scale that's really hard to replicate, you know, the scale of a, uh, a couple of hundred thousand person company, right? Yeah. Talking about a win-win yeah. That worked out well. It's certainly the proof is in the pudding and I'm sure that's just one of many examples of success that you've had. Uh, we appreciate the time here and certainly the insights and wish you well on down the road. Thanks for joining us, Mike. Thanks, Sean. Thanks for having me. I've been speaking with Mike Villa from Kong. He is in corporate development and operations there on John Walls, and you're watching on the cube, the AWS startup showcase.

(upbeat music) >> Well, thank you for joining us here as we continue our Cube Conversation on the AWS startup showcase with Marco Palladino who is the CTO of Kong. And Marco, also a co-founder by the way, Marco, thank you for joining us here on theCUBE. It's good to have you with us. >> Thank you, John, for having me. >> You bet, absolutely. First off, for our visitors and our viewers who might not be too familiar with Kong, tell us a little bit about what you're up to and your core competencies, of which I know are many. >> Yeah, Kong is a cloud connectivity company. We provide the technology software that developers and enterprise organizations all over the world can use to connect securely their software, and their microservices, and their APIs together. So we're really executing here on being the Cisco of L4 and L7. >> Yeah, great analogy. A really good analogy. So when you are talking about microservices, obviously this is a pretty new space, or certainly a growing space, in terms of deployments and different technologies. How come, like where's this come from, basically the whole microservice notion and concept? >> Yeah, it's a very interesting concept. In 2013 and 2014 there was a market transition in the landscape. Docker was released in 2013. Kubernetes was released in 2014. And Docker and Kubernetes together really have unleashed a new era of microservices across pretty much every organization in the world. We know that if we are trying to grow a business we must iterate fast ship, new products faster. We must be reliable. We must be distributed decoupled. And to do that, monolithic applications, which is the previous way of building modern software, monolithic applications, doesn't really scale that well in a distributed world. And so with microservices, running on top of Kubernetes containerized with Docker, we can now decouple our software and run it in a faster, better, more reliable way across pretty much any cloud vendor in the world. And as a result of that, we can enter new markets faster. We can make our users happier by shipping fixes and features faster. And therefore we can grow the business. That's why microservices really have been adopted across the board. >> So let's dive into that a little deeper here in terms of the value proposition, because, just because you could do something obviously isn't what the reason why you should do it. There is value at the end of the day that you're delivering, a new value. So summarize that a little bit for, again, a perspective customer who might be watching right now, somebody that you want to talk to about these new services these new values that they can enjoy. Why they be thinking about Kong? Why should they be thinking about microservices? >> Yeah, you see, every organization in the world is becoming digital. And we've discovered that, a few years ago, with digital transformation 1.0, as I call it. And in that digital transformation, we have realized that in order for us to build a successful software, in order for us to grow our business, we really must be able to innovate quicker. We must be able to create and ship new products faster. We must be able to duplicate our workloads across multiple regions and cloud vendors so that we can target our users with low latency and with the quickest performance we can possibly get. Now, in order to do that the monolithic applications we used to build they don't do that that well. monolithic applications, as they grow, they become huge, hard to move, hard to scale, hard, to deploy, hard to innovate. And we, as an industry, have learned that if we can decouple those large monolithic applications into smaller components, like microservices, we can then ship and innovate faster. Now, of course, on one end, we ship and deploy faster. On the other end, we are introducing something that our monolithic applications never really had at this scale. And that is this massive connectivity across all the services that make up the final application. Being decoupled and being distributed really means that we are connecting them over the network with service connectivity. And if that service connectivity is not working well then the application is not working. So digital transformation 2.0 really is all about taking our digital business and transforming it, by decoupling it and distributing it, in order for us to build a stronger business. >> So you talked about the monolithic application and there's some simplicity to that though, isn't there? Because now we're introducing multiple layers and a lot of complexity in some respects. Which allows us to do a lot of things really well, but it also introduces challenges. So if you were talking to, again, a prospective customer and they said, "Hey, this all sounds well and good, but what if..?" There are a lot of what ifs out there. How do you address the different challenges or the questions that might be raised in terms of trouble that you're inviting by introducing this new complexity into the marketplace? >> Yeah, the key here is to abstract away all the things that we don't need to build for our business. The key is to focus on what drives our business and that's our users, our customers, the applications that we're building. Everything else that's not part of the core business should be delegated as part of the underlying infrastructure. Likewise, today, when we want to enter a new market we just leverage a cloud vendor. We don't go and build a physical data center from scratch. Likewise, when we build new modern applications, we don't want to build the orchestration platforms by ourselves. We don't want to build the connectivity stack by ourselves. But we want to abstract that away so that our teams can focus on what matters for the business. And that's the users, the customers, the application. It's not building the underlying infrastructure which can be given as a service to the application teams as opposed to asking the teams to build it from scratch. And there's going to be challenges, of course, but there's going to be benefits. And as long as the benefits are bigger than the challenges then it's worth while transitioning to microservices if that can help us scale faster and grow faster. And if anything, with COVID last year, we have learned how important it is for every organization to think about digitalizing in a faster way, in order to keep being in business, as a matter of fact, to keep winning against their competitors. And the organizations that can acquire good knowledge of the underlying tooling to allow them to transform this way, those are the organizations that are going to be succeeding moving forward. >> What do you think is the biggest shift in this paradigm then in terms of this legacy system that we had in place, that worked pretty well, to now We have a much more specialized, instead a much more distributed approach, that is providing these new values and certainly great benefits. But in your mind, what's the biggest shift there, you think, in terms of mindset and in terms of actual deployment? >> Well transitioning to microservices really involves three different transformations and that's why sometimes it can be challenging. It requires transforming our software to microservices. By doing so, it requires us to rethink the operations of how we deploy, run, and test our software. And the third aspect, the third component that it transforms it's the cultural component. And now we can build smaller teams that can work in a decoupled asynchronous way. And as long as they expose an API those teams are going to be very well integrated with the rest of the organization. Look at what companies like Amazon, Netflix, or Google have done. And that's a big cultural shift. Like any large transformation, it is not, there is not one secret ingredient. It's an entire mindset that has to change. Now, thankfully for us, this transition is also being driven by bottom up adoption and transformation that's being driven by open source software. So unlike the previous transformations, these ones, if you wish, it's a self service transformation. Open source ecosystem provides us with a self-service ecosystem of a landscape of tools and platform and technologies that the application teams and the infrastructure teams can go ahead and use in order to figure out what's the best formula for them to achieve their success. >> When you have the, so let's just say, you've got your operation in place and you have multiple communications going on amongst microservices, whatever. It's all well and good. Now you want to introducing yet another. And so are there, not concerns, are there challenges there in bringing a newcomer into that environment in terms of testing, in terms of deployment, because of the factors, the variables that come into play here? How one piece works with another piece won't be the same how it works with another piece, right? So how do you handle testing? How do you handle new deployments in this kind of an environment? >> This is perhaps the most critical cultural change and transformation that microservices bring. With a monolithic application, if the monolith was up and running the business was up and running. If the monolith was down the business was done. Simple, easy. It was clear. It's one-to-one clear to understand. With microservices we're effectively making ourselves comfortable of always running in a partially degraded system. Because there is so much more, so many more moving parts running at the same time they cannot possibly be all up and running at any given point in time. Some of them will be running. Some of them will be slow. Some of them will be not executing. And guess what? Our infrastructure is built in such a way that, even when that happens, the customer and the users will never experience any downtime. This is a chance for us to transition to microservices. It's a chance for us to accelerate the innovation in your organization. But also to accelerate the reliability of our applications and also accelerate the security of our applications. And these may sound counterintuitive. Many technology leaders they're like, "Wait, what do you mean by that? How can you transition to microservices and improve the security if you have so many moving parts in your systems running as opposed to a monolith?" But that's an opportunity for us to improve the security. Because now, unlike the monolith, where everything can consume and access everything else, with microservices we can set up a tighter security rules in place to determine what services can consume what other services and in what capacity? In a monolithic world, as long as the code base is accessible, anybody can do anything that the monolith can do. With microservices it's an opportunity for us to lock that down. And even the past year, we've seen how important that is. The reputational of an entire organization can be destroyed by a high profile breach or attack. And so it's very important for us to catch this opportunity so that we can implement zero trust security. We can implement a consistent, non-fragmented layer of security across all of our applications, not just the Kubernetes ones or the containerized ones, but even the virtual machine based ones. And all the connections that we're generating, that's the backbone of every modern architecture, that's the bread and butter of every microservice oriented application. And that connectivity has to be managed, and secure, and observed, and exposed to our partners, developers, and customers. If that connectivity fails, then our business fails. And so today we can not ask the application teams to build that connectivity for us. That's like asking them to go build an application, and as they're doing that, walking to the data center and physically connecting the switches and the routers to the server racks to build the underlying physical connectivity. We don't, we cannot ask them to do that. The connectivity as well has to be abstracted the same way we are abstracting the data center with platforms like Kubernetes. >> So just back again to security. Obviously, you pointed out, we've had some pretty high profile cases here of late. Well, actually it's probably the past four or five years, but certainly of late, state actors taking actions. So that security mindset that you're in right now it does seem counterintuitive to me. That you have multiple doors, right? In the monolithic environment you've got one big one, right? And you just have to crack the code, and you're in. But in this case, you've got a lot of different entry points but you're saying that you're actually, you can batten down that hatch, if you will. You can provide the protective barrier around all of these microservices in an effective way. >> It's an opportunity for us. I'm a big fan of when John Chambers, the ex CEO of Cisco said, "Whenever there is a threat, how can we think of that as an opportunity?" And really microservices gave us the opportunity to implement a new generation security model for all of our applications. That's tight, that cannot be breaked into. And so that zero trust security, OPA, across the entire organization for both North/South and East/West traffic, for both the gateways and the service meshes. That is, for us, the opportunity to secure our applications in a way that could not be secured before in a monolithic world. Microservices not only create a business advantage but they gave us also many, many different chances for us to improve all the other aspects of security and productivity within your organization. And securing it, that's one of the opportunities that we can not miss. >> Well, Marco thank you for the time. Fascinating work, it really is, revolutionary in many respects. And I wish you continued success at Kong. And thank you for joining us here on the startup showcase. >> Thank you so much. >> Great. John was here talking to the Marco Palladino Who is the CTO and co-founder of Kong. We're talking about the service mesh, that landscape. It is new. It is evolving. And it is certainly a fascinating wrinkle to our world. Thanks for joining us here on theCUBE Conversation. I'm John Walls. We'll see you next time. (upbeat music)

(upbeat music) >> Well, good day and welcome back to the Cube as we continue our segment, featuring AWS Startup Showcase and we're with now Mike Bilodeau who's in corporate development and operations at Kong. Mike, thank you for joining us here on the Cube and particularly on the Startup Showcase. Nice to have you and Kong represented here today. >> Thanks for having me, John. Great to be here. >> You better and first off let's just tell us about Kong a little bit and column cadet which I know is your feature program or service. I love the name by the way, but tell us a little bit about Kong and then what Kong is all about too? >> Sure, so Kong as a company really came about in the past five years. Our two co-founders came over from Italy in the late aughts early to 20 teens and had a company called Mashape. And so what they were looking at and what they were betting on at that time, was that APIs were going to be the future of how software was built and how developers interacted with software. And so what came from that was a piece of they were running Mashape as a marketplace at the time. So connecting developers to different APIs so they can consume them and use them to build new software. And what they found was that actually the most valuable piece of technology that they had created was the backbone for running that marketplace. And that backbone is what Kong is. And so they created it to be able to handle a massive amount of traffic, a massive amount of APIs, all simultaneously. This is a problem that a lot of enterprises have especially now that we've started to get some microservices, started to have more distributed technologies. And so what Kong is really is, it's a way to manage all of those different APIs. All of the connections between different microservices through a single platform which is Kong connect. And now that we've started to have Kubernetes the sort of the birth and the nascent space of service mesh. Kong connect allows all of those connections to be managed and to be secured and made reliable through a single platform. >> So what's driving this, right? I mean you mentioned microservices and Kubernetes and that environment which is kind of facilitating this, I guess transformation you might say. But what's the big driver in your opinion in terms of what's pushing this microservices phenomenon if you will or this revolution? >> Sure, and when I think it starts out at the simple active of technology acceleration in general. So when you look at just the real shifts that have come in enterprise to hack especially looking, you know start with that at the cloud but you could even go back to VMware and virtualization is it's really about allowing people to build software more rapidly. All of these different innovations that have happened with cloud, with virtualization, now with containers, Kubernetes, microservices they're really focused on making it so that developers can build software a lot more quickly. Develop the latest and greatest in a more rapid way. I think a huge driver out of this is just making it easier for developers, for organizations to bring new technologies to market. And we see that as a key driver in a lot of these decisions that are being made. I think another piece of it that's really coming about is looking at security as a really big component. You know we have a huge monolithic app. It can become very challenging to actually secure that. If somebody gets into the initial Ops space they're really past the point of no return and can get access to some things that you might not want them to. Similar for compliance and governance reasons, that becomes challenging. So I think you're seeing this combination of where people are looking at breaking things into smaller pieces, even though it does come with its own challenges around security that you need to manage. It's making it so that there's less ability to just get in and cause a lot of damage all at once from malicious attackers. >> Yeah, you bring up security and so, yeah to me it's almost in some cases it's almost counterintuitive. I think about if I got this model to gap and I've got a big parameter around it, right. And I know that I can confine this thing. I can contain this, this is is good. Now microservices, now got a lot of, it's almost like a lot of villages, right? They're all around. And I don't have the castle anymore. I've got all these villages. So I have to build walls around all these villages. But you're saying that that's actually easier to do or at least you're more capable of doing that now as opposed to maybe where we were two, three years ago. >> Well you can almost think of it as if you have those villages, right. And if you have one castle and somebody gets inside they're going to be able to find whatever treasure you may have you know, to extend the analogy here a bit. But now if you have 50 different villages that an attacker needs to look in it starts to become really time consuming and really difficult. And now when you're looking at, especially this idea of cybersecurity, the ability to secure a monolithic app is typically not all that different from what you can do with a microservice or once you get past that initial point. Instead of thinking of it as, you know I have my one wall around everything you now think of it almost as a series of walls where it gets more and more difficult. Again this all depends on that you're managing that security well which can get really time-consuming more than anything else and challenging from a pure management standpoint. But from an actual security posture it is a way of where you can strengthen it because you're you're creating more difficult ways of accessing information for attackers as well as just more layers potentially of security that they need to get them. >> But what do you do to lift that burden then from the customers because like you said that's a concern they really don't want to have. They want you to do that. They want somebody to do that before them. So what do you do to alleviate those kinds of stresses on their systems? >> Yeah, it's a great question. And this is really where the idea of API management in its infancy came from. Was thinking about, how do we abstract a way these different tasks that people don't really want to do when they're managing how people can interact with their APIs whether that be a device or another human? And part of that is just taking away. So what we do and what API game management tools have always done is abstract that into a new piece of software. So instead of having to kind of individually develop and write code for security, for logging, for routing logic, all these different pieces of how those different APIs will communicate with each other we're putting that into a single piece of software, And we're allowing that to be done in a really easy way. And so what we've done now with Kong connect and where we've extended that to is making it even easier to do that at a microservices level of scale. So if you're thinking about hundreds or thousands of different microservices that you need to understand and be able to manage that's what we're really building to allow people to do. And so that comes with being able to make it extremely easy to actually add policies like authentication, rate limiting whatever it may be as well as giving people the choice to use what they want to use. We have great partners looking at the Datadog's, the Okta's of the world who provide a pretty, pretty incredible product. We don't necessarily want to reinvent the wheel on some of these things that are already out there and that are widely loved and accepted by technology practitioners and developers. We just want to make it really easy to actually use those different technologies. And so that's a lot of what we're doing is providing a a way to make it easy to add these policies and this logic into each one of these different services. >> So what if you're providing these kinds of services and they're new and you're merging them sometimes with kind of legacy components? That transition or that interaction I would assume could be a little complex. And you've got your work cut out for you in some regards to kind of retrofit, right? In some respects to make this seamless, to make this smooth. So maybe you shine a little light on that process in terms of not throwing all the bath out with the baby or the water here, but just making sure it all works. And that it makes it simple and takes away that kind of complexity that people might be facing. >> Yeah, that's really the name of the game. We do not believe that there is a one size fits all approach in general to how people should build software. There are going to be instances of where building a monolithic app makes the most sense. There are going to be instances where building a Kubernetes makes the most sense. The key thing that we wonna solve is making sure that it works and that you're able to make the best technical decision for your products and for your organization. And so in looking at how we help to solve that problem, I think the first is that we have first-class support for everything. So we support everything down to kind of the oldest bare metal servers, to IBMs to containers across the board. And we've had that mindset with every product that we brought to market. So thinking about our service mesh for instance Kuma is the open-source project that all depends now on an enterprise one. But looking at Kuma, one of the first things that we did when we brought it out because we saw this gap in the space was to make sure that they have first-class support for virtual machines. At the time that wasn't something that was commonly done at all. Now more people are moving in that direction because they do see it as it need which is great for the space. But that's something where we understand that the important thing is making sure your point you said it kind of the exact way that we like to which is it needs to be reliable. It needs to work. So I have a huge estate of older applications, older potentially environments even I might have data centers, I might have cloud been trying to do everything all at once. Isn't really a pragmatic approach always. It needs to be able to support the journey as you move to a more modern way of building. So in terms of going from on-premise to the cloud, running in a hybrid approach, whatever it may be, all of those things shouldn't be an all-or-nothing proposition. It should be a phased approach and moving to really where it makes sense for your business and for the specific product. >> You've been talking about cloud deployments obviously. AWS comes into play there in a major way for you guys. Tell me a little bit about that. About how you're leveraging that relationship and how you're partnering with them and then bringing the value then to your customer base. And how long that's been going on and the kinds of work that you guys are doing together ultimately to provide this kind of exemplary product or at least options to your customers. >> Yeah, of course. I think the way that we're doing it first and foremost is that we know exactly who AWS is in the space. And great number of our customers are running on AWS. So again, I think that first-class support in general for AWS environments, services both from the container service, their Kubernetes services, everything that they can have and that they offer to their customers we wonna be able to support. One of the first areas really that comes to mind in terms of first-class integration and support is thinking about Lambda and serverless. So at the time when we first came out with that, again it was early for us or early in our journey as product and as company, but really early for the space. And so how we were able to support that and how we were able to see that it could support our vision and what we wanted to bring as a value proposition to the market has been really powerful. So I think in looking at how we work with AWS certainly on a partnership level of where we share a lot of the same customers we share a very similar ethos and wanting to help people do things in the most cost-effective rapid manner possible and to build the best software. And I mean for us we have a little bit of a backstory with AWS 'cause Jeff Bezos was an early investor in Kong. >> That didn't hurt really. Yeah exactly, I mean the whole memo that he wrote about build an API or you're fired was certainly an inspiration to us. And just it catalyzed so much change in the technology landscape in general about how everyone viewed APIs about building a software that could be reused and and was composable. And so that's something that we look at and kind of carry it forward and we've been building on that momentum ever since. >> So I'm going to just kind of take, again a high level. Look at this in terms of microservices and how that's changing in terms of cloud connectivity. Think you actually have a graphic too that maybe we can pull up and take a look at this and let's talk about this evolution. What's occurring here a little bit and as we take a look at this tell us what you think these impacts are at the end of the day for your customers and how they're better able to provide their services and satisfy their customer needs. >> Absolutely, so this is really the heart of the connect platform and of our vision in general. We've spoken just a minute ago about thinking how we can support the entire journey or the enterprise reality that is managing a relatively complex environment of monoliths, different services, microservices, serverless functions, whatever it may be as well as lots of different deployment methods and underlying tech platforms. If you have virtual machines and Kubernetes whatever it may be. But what we look at is just the different design patterns that can occur in thinking about a monolithic application. Okay, mainly that's an edge concern of thinking about how you going to handle connectivity coming in from the edge in looking at a Kubernetes environment of where you going to have many Kubernetes clusters that need to be able to communicate with each other. That's where we start to think about our ingress products and Kubernetes ingress that allows for that cross application communication. And then within the application itself and looking at service mesh which we talked a little bit about of just how do I make sure that I can instrument and secure every transaction that's happening in a truly microservices deployment within Kubernetes or outside of it? How do I make sure that that's reliable and secure? And so what we look at is part of it is evolution. And part of it is going to be figuring out what works best when. Certainly if you're building something from scratch it doesn't always make sense to build it. Your MDP as microservices running on Kubernetes it probably makes sense to go with the shortest path. At the same time if you're trying to run it at massive scale and big applications and make sure they're as reliable as possible it very well does make sense to spend the time and the effort to make Kubernetes work well for you. And I think that's the beauty of how the space is shifting is that it's going towards a way of the most practical solution to get towards business value to move software quicker to give customers the value that they want to delight them to use Amazon's phraseology if that's a word. It's something that is becoming more and more standard practice versus just trying to make sure that you're doing the latest and greatest for the sake of doing it. >> So we've been talking about customers in rather generic terms in terms of what you're providing them. We've talked about new services that are certainly providing added value and providing them with solutions to their problems. Can you give us maybe just a couple of examples of some real life success stories where you've had some success in terms of providing services that I assume people needed or at least maybe they didn't know they needed until you provided that kind of development. But give us an idea, maybe just shine a little light on some success that you've had so that people at home and are watching this can perhaps relate to that experience and maybe give them a reason to think a little more about Kong and Kong connect. >> Yeah, absolutely, there's a number that come to mind but certainly one of the customers that I have spent a lot of time with, become almost friends with a couple of the practitioners who work there, is company called Cargill. It's a shared one with us and AWS. It's one we've written about in the past but this is one of the largest companies in the world. And the way that they describe it as is that if you've ever eaten a McMuffin or eaten from McDonald's and had breakfast there, you've used a Cargill service because they provide so much of the food supply chain business and the logistics for it. You know, it's a century and a half old company. It has a really story and a legacy and it's grown to be an extremely large company that's still private. But they have some of the most unique challenges, I think that I've seen in the space in terms of needing to be able to ensure that they're able to kind of move quickly and build a lot of new services and software that touch so many different spaces. So the challenge that was put in front of them was looking at really modernizing a century and a half old company. Modernizing their entire tech stack. And we're certainly not all of that in any way shape or form but we are something that can help that process quite a bit. And so as they were migrating to AWS as they were looking at creating a CICB process for really being able to shape and deploy new software as quickly as possible. As they were looking at how they could distribute the new APIs and services that they were building, we were helping them with every piece of that journey by being able to to make sure that the services that they deployed performed in the way that they expected them to. We're able to give them a lot of confidence in being able to move more rapidly and move a lot of software over from these tried and true older or more legacy ways of doing things to a much more cloud native build. As they were looking at using Kubernetes in AWS and being able to support that handle scale, again we're something that was able to kind of bridge that gap and make sure that there weren't going to be disruptions. So there are a lot of great reasons of why their numbers really speak for themselves in terms of how much velocity they were able to get. Saying them out loud will sound fake in some cases because they were able to, you know, I think like something around the order of 20 X the amount of new APIs and services that they were building over a six month period. Really kind of crazy, crazy numbers. But it is something where, for us we got a lot out of them because they were open-source users. So Kong is first and foremost an open-source company. And so they were helping us before they even became paying customers. Just by testing the software, providing feedback, really putting it through its paces and using it at a scale that's really hard to replicate. You know the scale of a couple of hundred thousand person company, yeah. >> Talk about a win-win. That worked out well. Certainly the proof is in the pudding and I'm sure that's just one of many examples of success that you've had. We appreciate the time here and certainly the insights and I wish you well on down the road. Thanks for joining us Mike. >> Thanks John, thanks for having me. >> Been peaking with Mike Bilodeau from Kong. He is in corporate development and operations there. I'm John Walls and you're watching "On the Cube" the AWS Startup Showcase. (soft music)

(upbeat music) >> Well, thank you for joining us here as we continue our Cube Conversation on the AWS startup showcase with Marco Palladino who is the CTO of Kong. And Marco, also a co-founder by the way, Marco, thank you for joining us here on theCUBE. It's good to have you with us. >> Thank you, John, for having me. >> You bet, absolutely. First off, for our visitors and our viewers who might not be too familiar with Kong, tell us a little bit about what you're up to and your core competencies, of which I know are many. >> Yeah, Kong is a cloud connectivity company. We provide the technology software that developers and enterprise organizations all over the world can use to connect securely their software, and their microservices, and their APIs together. So we're really executing here on being the Cisco of L4 and L7. >> Yeah, great analogy. A really good analogy. So when you are talking about microservices, obviously this is a pretty new space, or certainly a growing space, in terms of deployments and different technologies. How come, like where's this come from, basically the whole microservice notion and concept? >> Yeah, it's a very interesting concept. In 2013 and 2014 there was a market transition in the landscape. Docker was released in 2013. Kubernetes was released in 2014. And Docker and Kubernetes together really have unleashed a new era of microservices across pretty much every organization in the world. We know that if we are trying to grow a business we must iterate fast ship, new products faster. We must be reliable. We must be distributed decoupled. And to do that, monolithic applications, which is the previous way of building modern software, monolithic applications, doesn't really scale that well in a distributed world. And so with microservices, running on top of Kubernetes containerized with Docker, we can now decouple our software and run it in a faster, better, more reliable way across pretty much any cloud vendor in the world. And as a result of that, we can enter new markets faster. We can make our users happier by shipping fixes and features faster. And therefore we can grow the business. That's why microservices really have been adopted across the board. >> So let's dive into that a little deeper here in terms of the value proposition, because, just because you could do something obviously isn't what the reason why you should do it. There is value at the end of the day that you're delivering, a new value. So summarize that a little bit for, again, a perspective customer who might be watching right now, somebody that you want to talk to about these new services these new values that they can enjoy. Why they be thinking about Kong? Why should they be thinking about microservices? >> Yeah, you see, every organization in the world is becoming digital. And we've discovered that, a few years ago, with digital transformation 1.0, as I call it. And in that digital transformation, we have realized that in order for us to build a successful software, in order for us to grow our business, we really must be able to innovate quicker. We must be able to create and ship new products faster. We must be able to duplicate our workloads across multiple regions and cloud vendors so that we can target our users with low latency and with the quickest performance we can possibly get. Now, in order to do that the monolithic applications we used to build they don't do that that well. monolithic applications, as they grow, they become huge, hard to move, hard to scale, hard, to deploy, hard to innovate. And we, as an industry, have learned that if we can decouple those large monolithic applications into smaller components, like microservices, we can then ship and innovate faster. Now, of course, on one end, we ship and deploy faster. On the other end, we are introducing something that our monolithic applications never really had at this scale. And that is this massive connectivity across all the services that make up the final application. Being decoupled and being distributed really means that we are connecting them over the network with service connectivity. And if that service connectivity is not working well then the application is not working. So digital transformation 2.0 really is all about taking our digital business and transforming it, by decoupling it and distributing it, in order for us to build a stronger business. >> So you talked about the monolithic application and there's some simplicity to that though, isn't there? Because now we're introducing multiple layers and a lot of complexity in some respects. Which allows us to do a lot of things really well, but it also introduces challenges. So if you were talking to, again, a prospective customer and they said, "Hey, this all sounds well and good, but what if..?" There are a lot of what ifs out there. How do you address the different challenges or the questions that might be raised in terms of trouble that you're inviting by introducing this new complexity into the marketplace? >> Yeah, the key here is to abstract away all the things that we don't need to build for our business. The key is to focus on what drives our business and that's our users, our customers, the applications that we're building. Everything else that's not part of the core business should be delegated as part of the underlying infrastructure. Likewise, today, when we want to enter a new market we just leverage a cloud vendor. We don't go and build a physical data center from scratch. Likewise, when we build new modern applications, we don't want to build the orchestration platforms by ourselves. We don't want to build the connectivity stack by ourselves. But we want to abstract that away so that our teams can focus on what matters for the business. And that's the users, the customers, the application. It's not building the underlying infrastructure which can be given as a service to the application teams as opposed to asking the teams to build it from scratch. And there's going to be challenges, of course, but there's going to be benefits. And as long as the benefits are bigger than the challenges then it's worth while transitioning to microservices if that can help us scale faster and grow faster. And if anything, with COVID last year, we have learned how important it is for every organization to think about digitalizing in a faster way, in order to keep being in business, as a matter of fact, to keep winning against their competitors. And the organizations that can acquire good knowledge of the underlying tooling to allow them to transform this way, those are the organizations that are going to be succeeding moving forward. >> What do you think is the biggest shift in this paradigm then in terms of this legacy system that we had in place, that worked pretty well, to now We have a much more specialized, instead a much more distributed approach, that is providing these new values and certainly great benefits. But in your mind, what's the biggest shift there, you think, in terms of mindset and in terms of actual deployment? >> Well transitioning to microservices really involves three different transformations and that's why sometimes it can be challenging. It requires transforming our software to microservices. By doing so, it requires us to rethink the operations of how we deploy, run, and test our software. And the third aspect, the third component that it transforms it's the cultural component. And now we can build smaller teams that can work in a decoupled asynchronous way. And as long as they expose an API those teams are going to be very well integrated with the rest of the organization. Look at what companies like Amazon, Netflix, or Google have done. And that's a big cultural shift. Like any large transformation, it is not, there is not one secret ingredient. It's an entire mindset that has to change. Now, thankfully for us, this transition is also being driven by bottom up adoption and transformation that's being driven by open source software. So unlike the previous transformations, these ones, if you wish, it's a self service transformation. Open source ecosystem provider us with a self-service ecosystem of a landscape of tools and platform and technologies that the application teams and the infrastructure teams can go ahead and use in order to figure out what's the best formula for them to achieve their success. >> When you have the, so let's just say, you've got your operation in place and you have multiple communications going on amongst microservices, whatever. It's all well and good. Now you want to introducing yet another. And so are there, not concerns, are there challenges there in bringing a newcomer into that environment in terms of testing, in terms of deployment, because of the factors, the variables that come into play here? How one piece works with another piece won't be the same how it works with another piece, right? So how do you handle testing? How do you handle new deployments in this kind of an environment? >> This is perhaps the most critical cultural change and transformation that microservices bring. With a monolithic application, if the monolith was up and running the business was up and running. If the monolith was down the business was done. Simple, easy. It was clear. It's one-to-one clear to understand. With microservices we're effectively making ourselves comfortable of always running in a partially degraded system. Because there is so much more, so many more moving parts running at the same time they cannot possibly be all up and running at any given point in time. Some of them will be running. Some of them will be slow. Some of them will be not executing. And guess what? Our infrastructure is built in such a way that, even when that happens, the customer and the users will never experience any downtime. This is a chance for us to transition to microservices. It's a chance for us to accelerate the innovation in your organization. But also to accelerate the reliability of our applications and also accelerate the security of our applications. And these may sound counterintuitive. Many technology leaders they're like, "Wait, what do you mean by that? How can you transition to microservices and improve the security if you have so many moving parts in your systems running as opposed to a monolith?" But that's an opportunity for us to improve the security. Because now, unlike the monolith, where everything can consume and access everything else, with microservices we can set up a tighter security rules in place to determine what services can consume what other services and in what capacity? In a monolithic world, as long as the code base is accessible, anybody can do anything that the monolith can do. With microservices it's an opportunity for us to lock that down. And even the past year, we've seen how important that is. The reputational of an entire organization can be destroyed by a high profile breach or attack. And so it's very important for us to catch this opportunity so that we can implement zero trust security. We can implement a consistent, non-fragmented layer of security across all of our applications, not just the Kubernetes ones or the containerized ones, but even the virtual machine based ones. And all the connections that we're generating, that's the backbone of every modern architecture, that's the bread and butter of every microservice oriented application. And that connectivity has to be managed, and secure, and observed, and exposed to our partners, developers, and customers. If that connectivity fails, then our business fails. And so today we can not ask the application teams to build that connectivity for us. That's like asking them to go build an application, and as they're doing that, walking to the data center and physically connecting the switches and the routers to the server racks to build the underlying physical connectivity. We don't, we cannot ask them to do that. The connectivity as well has to be abstracted the same way we are abstracting the data center with platforms like Kubernetes. >> So just back again to security. Obviously, you pointed out, we've had some pretty high profile cases here of late. Well, actually it's probably the past four or five years, but certainly of late, state actors taking actions. So that security mindset that you're in right now it does seem counterintuitive to me. That you have multiple doors, right? In the monolithic environment you've got one big one, right? And you just have to crack the code, and you're in. But in this case, you've got a lot of different entry points but you're saying that you're actually, you can batten down that hatch, if you will. You can provide the protective barrier around all of these microservices in an effective way. >> It's an opportunity for us. I'm a big fan of when John Chambers, the ex CEO of Cisco said, "Whenever there is a threat, how can we think of that as an opportunity?" And really microservices gave us the opportunity to implement a new generation security model for all of our applications. That's tight, that cannot be breaked into. And so that zero trust security, OPA, across the entire organization for both North/South and East/West traffic, for both the gateways and the service meshes. That is, for us, the opportunity to secure our applications in a way that could not be secured before in a monolithic world. Microservices not only create a business advantage but they gave us also many, many different chances for us to improve all the other aspects of security and productivity within your organization. And securing it, that's one of the opportunities that we can not miss. >> Well, Marco thank you for the time. Fascinating work, it really is, revolutionary in many respects. And I wish you continued success at Kong. And thank you for joining us here on the startup showcase. >> Thank you so much. >> Great. John was here talking to the Marco Palladino Who is the CTO and co-founder of Kong. We're talking about the service mesh, that landscape. It is new. It is evolving. And it is certainly a fascinating wrinkle to our world. Thanks for joining us here on theCUBE Conversation. I'm John Walls. We'll see you next time. (upbeat music)

>>Welcome back everyone to the cubes coverage here in Seattle, Washington for the Avis marketplace seller conference, part of the APN partner network merging with the marketplace to form the Amazon partner organization. I'm John furrier, host of the cube Walter Wall coverage today, Christian Gor cash, who is the VP of alliances at Kong Inc. Welcome to the cube. Thanks for coming on. >>Thank you. Thank you, John. Really glad to be here. Corke exactly. Yeah. It's awesome. >>So Kong we've been following you guys for while Docker Kong cube. You've been part of our cube conversation. Also part of our, our startup showcase fast growing startup, you know, working on stuff that everyone loves APIs. I mean, APIs are so popular now that they now a security concern, right? Yeah. So like it gets squat there everywhere. I won't say API sprawl, but APIs are the connections and that are, is the web. That is the cloud. Okay. Now with cloud native developers who are now in the front lines have taken over it, everyone knows DevOps dev SecOps is now the new it and it's the developers security and data they're below they're the new ops, right? So, so this is where microservices come in, open source service MES new automation is coming down the pike. That's super valuable to businesses as they look at cloud native architecture, what are you guys doing in there? Take a minute to explain Kong's value proposition, the hot products, and then why you're here. >>Yeah. So, you know, I joined Kong now or three years ago, you know, we were still just reaching our hundred employees, mark, which is very important, very startup, but even back then, you know, Kong was relatively well known in industry, you know, so we have one of the most, well the most popular open source project in API gateway area. So con API gateway, you know, we cross now 300 million downloads, even more important is just the scale it, which the product's been used. So between our open source community and enterprise customers, we are now crossing like 11 trillion transactions per month. Now just give you comparison. Like this is like 18, 19 times more than Netflix per month. You know? So for any company that has a technology that operates it at scale, you need to hit few things outta the park. You know, as he mentions cloud data developers, they want simplicity. You know, they want automation. They also want performance and scale and security, which are all critical, you know, to how Kong, you know, start as opensource project. Now, of course we have the whole suite of enterprise products. We also have our con service mesh offering as well as our cloud offerings. >>Yeah. And this is how open source is doing it now, obviously, you know, I, I still remember, I still tell the story to the young startups. Hey, I, there was proprietary software when I was in college. Open source is now everything. Now you've got, got cloud scale. So the dynamic between open source, which has become the software industry open source success doesn't mean it's it's game over. It's the beginning. The commercialization that you guys have gone through is super important. Trillions of transactions. Now you have enterprises working with you. What's the big advantage of the seller relationship that you have with Amazon? Why are customers using it? What are they buying it for? Give the pitch of con for the marketplace customer. >>Yeah, it's actually, we are relatively new in AWS marketplace. You know, so our first transaction that we ever done was actually in July and 2021. So we are just over a year, you know, that journey, you know, when I look what Chris gross talked today, he was talking about, you know, Hey, just publishing marketplace, not enough. You know, you need to understand what's your value proposition. You need to make sure your operations already, your sales is ready. Everything is, is set. And we kind of did this for the first year and a half is spend a lot of time improving our integration with AWS overall, all the first party services relevant to con we also understood, well, what does it take to kind of fine tune our value proposition? We have like three specific sales place. And you know, when we launch our flagship product con connect enterprise and got our first transaction, that was great milestone for, for star like Kong. But then what we've seen is just that work that we've done before really paid off. I mean right now, >>Like what we'll give example. >>Yeah. So, you know, we are focusing on as measure three sales place. Money is we are focused, specific on helping customers who are modernizing and, and their application going to the cloud. And you have a lot of these, you know, lifting shift and are rearchitect and modernized, but most of the attentions on the workloads, what about the connections? You know, so a monolith application had to authentic all the users understand wheres the network and so on. When you build those, when you now decouple this built like 1,000 thousand microservices, you don't want to repeat this for every microservice. So that's where K brings the whole suite from, you know, service match to the API gate to help manage the journey and really support this environment. And we spend a lot of time to just fine tune that message. So that customers understood where, you know, how can we help them on their journey beyond what, for instance, cloud native or AWS API gateway offers them. So we can really help them from day one on the journey and accelerate. And >>I think I it's a no, it's a no braining for a customer to buyer or to come into the marketplace and say, click, I'm gonna buy some data analytics services. I'm gonna buy gateway through Kong. But when they start getting into these microservices, this automation opportunity there, there's more behind the curtain for them with Kong. So I have to ask you with the keynote we heard from Chris, the leader of the marketplace. Now he said that he wants the ISVs to be more native in the cloud. That probably resonates with you. You, >>You guys well with con's relatively simple because we were built at cloud native, you know, so very briefly the whole story of Congo. This is before Ajo, our founders were actually running the, the very popular API exchange col mesh shape. And they had to build their own gateway just to handle the scale and was built on cloud native technologies. And then when everybody's calling you, what are you using to running? This are using PGS. And so else, no, we built ourselves, oh, how can we get our hands on? That's how con actually >>Came to. And that's how the big winners usually happen too. They start build their own, solve their own problem because it's a big scale problem. Exactly. No one's had that problem. >>Yeah. And what we have seen, especially what was very, you know, through, through the pandemic, what we have seen. And it's interesting, you know, being in a startup doing pandemic is like, whoa, will the life just shut down or what we're doing? You know? But actually what we have seen customers prioritize the new business capability. For instance, you have a large parental companies that overnight, they have to understand where the assets are. Yeah. Or banks who are like 45 days of, you know, approving process for the loans. They need to reduce it for a day or two. >>Yeah. And they're adding more developers, too, exactly. To build the modern application. So they need to have that infrastructure as code aspect. Correct. >>And they >>Need in place. >>Yeah. I need to like you have, you know, I don't think that many customers still have waterfall cycles, but they have, have pre pretty long developers development cycles. And now you need to, you know, do this multiple times a day. That's >>Interesting. We talked to a lot of cloud architects and C CIO C says, and you know, the executive just hire more developers take that hill, build. It just don't build a new app. It's not that easy boss. When, when the cloud architect says we have to be fully operationally ready with cloud native infrastructure's code. So with that, you're seeing a lot more enterprises come in now that are more savvy. They getting better. We're seeing Kubernetes more and more. You're seeing containerization. You're seeing that cloud native enterprise acceptance. What does that mean for you guys in the marketplace, as you look at the value proposition, how are you guys working with the marketplace today and where do you see customers buying in the future? >>Yeah, so we as mentioned, you know, we, we are now a year into that journey. We already seen tremendous benefits just in terms of reducing the friction. You know, the whole procurement, you know, you come as a startup with some, some of the largest companies in the world, they used to buy five, 10 billion in software and they have all these processes and you're like, well, but we only have like two people in finance. Sorry. How can you, and where marketplace can really, really helps us is, you know, improve this experience, both sides because they understand like we are fast moving company. They, they want us because of our speed and, and innovation that we, the product's strong. Yeah. They don't want us to get bogged down in all these pro procurement processes either. And so, so that's the first benefit. We also are working very hard to make sure that the customers can provision Kong in AWS and automate across the board. So essentially reducing their time to value dramatically. Yeah. And another thing that we found tremendously beneficial for us is a startup is the whole concept of a standard marketplace contract. Yeah. So instead of us coming with our little MSA or come like 50 page MSA from companies, we now have a middle ground. So we can just agree. You know, there's some differences, some specifics to qu software and it's tremendously reduced costs on both sides. >>Great. For you guys great for the buyers. Yeah. You get deployed services. They're not just buying, they're managing and deploying. Yeah, >>Exactly. Great. >>Quick, final question. Put a plugin for the company. What are you working on now? What's the big news. What's the con update? >>Well, that's an interesting part because I can't tell you because next week we have our con summit. Oh right. In San Francisco. The cubes not so 28, 20 ninth. Yeah. We, we we'll, I think we are gonna fix that in the future. But anyway, this is the first time after pandemic to do this in person, we have number of very exciting announcement, our Kong products, as well as you may hear some news about our AWS partnership, >>We like con we believe that DevOps has happened. Dev sec ops, whatever you gonna call it, dev is now the developers they're in the front lines. They're in the C I CD pipeline. They're shifting left. That's the new they took over it. That's what DevOps does. It's not a title. Now you have security and data ops behind the scenes. That's gonna be middleware. That's gonna have tons of microservices. So more, more, more action coming, all API based. >>Exactly. And the more, you know, the more complexity we can take away from that, the better we, you know, the >>Whole community. Thank you. Spending the time to come on the cube here at the, a us marketplace seller conference. What do you think about the APN merging with the marketplace formed the P the Amazon partner organization. Thumbs up, thumbs down. What's your heard? >>It's excellent. We have a great friend in AP, a great friend, us marketplace. Now both of them work together with huge. >>Fantastic. Yes. Thanks for okay. Cube coverage here in Seattle. I'm John furier APN marketplace together. APOs the new organization making it easier. Of course, we got all the coverage here. Thanks for watching.