 Well, good day and welcome back to theCUBE as we continue our segment featuring AWS Startup Showcase. And we're with now Mike Bilodeau who's in Corporate Development and Operations at Comm. Mike, thank you for joining us here on theCUBE and particularly on the Startup Showcase. Nice to have you and Comm represented here today. Thanks for having me, John, Grace Beater. You bet. All right, first off, let's just tell us about Comm a little bit and Comm Connect, which I know is your feature program. Service, I love the name, by the way. But tell us a little bit about Comm and then what Connect is all about too. Sure, so Comm as a company really came about in the past five years. Our two co-founders came over from Italy in the late, in the late aughts, early to 20 teens and had a company called Mash-Aid. 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 Mash-Aid as a marketplace at the time. So connecting developers to different APIs so that 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 Comm 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 to microservices, it started to have more distributed technologies. And so what Comm 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 Comm Connect. And now that we've started to have Kubernetes, the birth and the nascent space of ServiceMesh, Comm 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 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 tech, 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, you know, 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 that 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 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 security as a really big component. You know, if you have a huge monolithic app, it can become very challenging to actually secure that. If somebody gets into kind of that initial, into the initial app space, they're really past the point of no returning 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 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 kind of all at once for malicious attackers. Yeah, you bring up security. And so, yeah, to me, it's almost in some cases and it's counterintuitive. I think about, if I got this monolithic app and I've got a big perimeter 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 I don't have to castle anymore. I've got all these villages. I have to build walls around all these villages, right? 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 this religious, right? And you might, if you have one castle and somebody gets inside, they're gonna be able to find whatever treasure you may have 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 kind of cybersecurity, the ability to secure a monolithic app is typically not all that different from what you can do with a microservice or with once you get past that initial point. Instead of thinking of it as, 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 creating more difficult ways of accessing information for attackers as well as just more layers potentially of security that they need to get through. But what do you do to lift that burden then from the customer? Because like you said, that's a concern they really don't want to have, right? They want you to do that, they want somebody to do the core of 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 away these different tasks that people don't really want to do when they're managing how API, 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 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 ConConnect 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 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 data dogs, the octaves of the world, who provide a 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 way to make it easy to add this, these policies and this logic into each one of these different services. So 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 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 bath out with the baby, all the water here, but just making sure it all works, right? 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 of where building on Kubernetes makes the most sense. The key thing that we want to 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 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 everything down to kind of the oldest bare metal servers, to VMs, to containers across the board. And we've had that mindset with every product that we've brought to market. So thinking about our service mesh, for instance, Kuma is the open source project that underpins now our 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 it had first class support for virtual machines. At the time, that wasn't something that was commonly done at all. Now, there's more people moving in that direction because they do see it as a need, which is great for the space. But that's something where we understand that the important thing is making sure of 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 app applications, older potentially environments even. I might have data centers, I might have 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 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 problem. You've been talking about cloud deployments, obviously AWS comes into play there and 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 kind of work 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 a 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 want to be able to support. 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. 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 for us, we have a little bit of backstory with AWS because Jeff Bezos was an early investor in Com. That didn't hurt, did it? Yeah, yeah, exactly. I mean, the whole memo that he wrote about build an API or your 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 software that could be reused and was composable. And so that's something that we look at and kind of carrying forward and we've been building on that momentum ever since. So let's just kind of take a, again, of a high level, look at this in terms of microservices and how it's changing in terms of cloud connectivity. I 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'd 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 modelists, 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, again, 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're gonna handle connectivity coming in from the edge in looking at a Kubernetes environment of where you're gonna 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 this is just a 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 probably makes sense to go with the shortest path at the same time, if you're trying to run 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 of where, 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 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 can get watching this, can perhaps relate to that experience and maybe give them a reason to think a little more about Com and ComConnect. Absolutely, there's a number that come to mind, but certainly one of the customers that I spent a lot of time with, become almost friends with the different, with a couple of the practitioners who work there is a company called Cargill. It's a shared one with us in 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 is, 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. They had a, it's an old, it's a century and a half old company. It has a really storied kind of 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 they were, the challenge that was put in front of them was looking at really modernizing, again, 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 CI CD process for really being able to ship 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 make sure that the services that they deployed performed in the way that they expected them to, we were 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 to handle scale again, we were 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 kind 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 on the sense fake in some cases because they were able to, I think like something around the order of 20x the amount of new APIs and services that they were building over a six month period, really kind of crazy numbers. But it is something of where the, 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, the scale of a couple hundred thousand person company. Yeah. Talk about a win-win was, yeah, 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 wish you well on down the road. Thanks for joining us, Mike. Thanks, John. Thanks for having me. And speaking with Mike Belladon from Kong, he is in corporate development and operations there. I'm John Walls and you're watching on theCUBE the AWS startup showcase.