>>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.

(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, 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)