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