Gateways for Event-Driven Applications with Marco Palladino

Hey guys, thanks for the throw. We're here with Marco Paladino, who's CTO for Kong, and we're talking about event driven architectures, APIs, and maybe in the need for some gateways to simplify this whole thing. Marco, welcome to the show.

Yeah, thanks for having me. As long as I can remember, event driven applications were among the hardest to build. They're difficult, they require a lot of challenge, uh, and yet in the modern world, just about everything we do is event driven.

Now it seems like we have, uh, processes that everybody wants to run in real time versus batch. And so the nature of the applications that we're building is changing. Is there some way to approach this now that would make it simpler for people to kind of build and deploy and manage event driven architectures?

Uh, no. Sure, there sure is. Uh, like you just said, events are a critical component, a critical, uh, protocol that organizations are using to build modern applications.

You know, of course not everything that we do, it is necessarily service to service. That's, you know, what, traditionally we think of microservices. Usually we think of service to service connectivity.

Some of this connectivity happens asynchronously through events. So we're publishing events to topics. We're consuming these events.

Uh, this is great if we have large batch processing. If we are lots of data that we need to process at scale, it is great if we want to pick up events where we left off in case our services are down, it can happen with high availability. So events truly, truly are a very important part on how we're building applications in 2025 and beyond.

And of course, like every other type of connectivity that we're building, whether it's single connectivity, whether it's service mesh, microservices, connectivity, whether it's AI connectivity or not, events also are part of the picture. And so at COG, we believe that events also should not be left outside of the platform that we use to govern our traffic, to secure it, to observe it, uh, to manage it. And we should instead bring events on top of that platform so that the organization has both the ability to control that flow of traffic, apply the right level of security, the right level of governance, but also developers, uh, can start sending and consuming events in a much quicker way without having to build the underlying infrastructure to process these at scale.

So, uh, we believe that, uh, events therefore have an opportunity to be simplified, uh, and there is an opportunity to also allow us to build applications that are built on events a lot faster. So now today you guys launched, uh, your own event gateway. Uh, we've had multiple types of gateways in the past.

Most people are familiar with API gateways. What exactly is an event gateway and how does it kind of take that concept and make it simpler for everybody else to kinda access? 'cause I feel like maybe it's a higher level of abstraction for events.

Well, the event gateway effectively gives us the right level of infrastructure to be able to, uh, enforce security observability of events that are in flight from one application to another. And it also gives us the opportunity to implement the capabilities like protocol mediation in such a way that we can use events in more and more places. Uh, even the ones that perhaps cannot send a, an event directly by the need to do that only after, uh, providing the right level of authentication, the right level of authorization, only then they can send those events while we're giving that infrastructure in such a way that events come out of the box within the organization as yet another tool set that they can use.

But they don't have to worry about that security, that access tier level of control, uh, about that protocol mediation around that observability, because that effectively comes out of the box from the underlying infrastructure. You know, you may know Kong because, you know, Congo of course started many years ago. We spoke many years ago and you know, we started with our API management solution.

But then, you know, as we looked at how to support different types of connectivities, API management is one way to do it. But then there is also service meshes. We also have announced an AI gateway, uh, recently, and then of course, events are the last missing piece of the overall picture.

So in our pursuit of managing all connectivity for the enterprise, of course events were one big remaining component that we didn't support until now. We're now also events. Uh, we can give them that unified control plan we're giving to every other API or microservice that we process in the organization.

Now, events as well have that level of governance, security, observability, and quite frankly, ease of consumption and ease of publishing in any topic that's backed by technologies like Apache Kafka, for example. As we think it through for a minute, is there gonna be like one super API gateway or will there be multiple events, gateways, API gateways and multiple different things that I need to kinda deploy alongside each other and kind of, uh, create something that feels like a fabric? Well, the key is to unify and centralize the governance because if we decentralize the governance, we are adding complexity.

We're not reducing complexity. So centralized governance, but federated run times for managing events, for managing APIs that we can deploy across each team, across each application, across, across each, uh, cloud vendor that we may be using in such a way that although the governance, it is centralized, how we actually process the events or the APIs or the AI traffic that can be federated and decentralized so that we can bring it very close to the applications. Now, that would be very hard to do without the right technology in place.

And this is where our platform connect comes into play. Connect is that unified control plane that allows the organization to create virtual control planes where we can provision event gateways, API gateways, service meshes and AI gateways for our teams that can also self-service their policies so that the platform team doesn't become the bottleneck, but whatever they're doing, it's still going to report back to this unified control plane, which becomes the source of truth of all of the API connectivity that we're generating across the board. And when you think about API connectivity events, ai, APIs and microservices, I mean, this is really the foundation that allows us to create new products faster that allows us to expand into new markets that allows us to onboard new partners quicker.

And so effectively owning the these new strategic asset, which is the connectivity that we generate, including events coming with this announcement, while that is going to allow us to build an innovation factory on the business on top of our business, that's going to be much better and more powerful than it used to be before when everything was decentralized and we had no visibility whatsoever on what the developers were doing. So historically, event-driven applications were a small percentage of the total number of applications that people were running. Are they now gonna be a much larger percentage and uh, will they eclipse fat join it or will they be deployed alongside each other?

How will this all play out? I believe that they're going to be deployed alongside each other. I think that we're going to be using different types of connectivity and organizations are doing this today, by the way.

I mean, organizations are already, if you will look at the top Fortune 500 stock, global 5,000, they have an incredible amount of event traffic that's flying from one place to another within their systems. And so is it going to be the solution to every connectivity problem? Of course not.

It is a another tool in our toolbox where for certain use cases, events, especially at scale, especially when we have batch processing, especially when we want to make sure that we don't miss those events in case our services go down, um, you know, events can be a better technology solution for this type of, uh, high usage, high volume use cases. Now, of course, events are going to be working alongside all the other types of connectivity that we have service to service, of course, uh, as well as the connectivity that we're now generating using AI models, which is also this new breed of connectivity that now we're infusing in pretty much every business process and application that the organization is creating. You know, all of these have their own place in a modern enterprise architecture that we're developing in 2025 and beyond.

So events very important part of a broader picture that also includes other connectivity types and which is why it's important to make sure that we don't treat each one of these different connectivity types, um, as being fundamentally different worlds. They are all part of one piece, and that is how we manage connectivity across the organization. It's not, um, a siloed concern.

It is, uh, different types of connectivity under one concern. What makes it possible to do all this now? Because we've been kind of talking about these issues for a while.

So what's changed that I can now create an event gateway? Well, I think, uh, that what's changing, it's not just, uh, the products that are getting more mature, but it's also, um, the mindset of the organizations is a little bit changing right now. You see, for many years, organizations have been delegating, uh, to each individual team the choice on how they are going to be managing their connectivity.

And then over time what happened was a sprawl of APIs, duplicate APIs. Many organizations don't even know what these APIs are doing. Every time we need to build a new use case, instead of treating the API as a product that we curate and we make better over time, we keep building new APIs for, you know, specific point to point integrations that we want to build or point to point partnerships that we're developing and so on.

And so over time, fast forward, you know, to these days we have like thousands of APIs. Nobody knows what they're doing, nobody knows why they're needed, nobody understands why this, the organization has built three or four different, I dunno, KYC systems, you know, for different applications instead of working on one and making sure that they can use that across all of their applications. And what has changed is that these, in these overall increase of complexity over time reached a breaking point.

I mean, organizations, they cannot build fast enough, they cannot ship fast enough because fundamentally they don't know what APIs they can use to assemble into new products, into new customer experience that they want to deliver. And likewise, today we use one HR system to manage all the employees in the company, or we use one endpoint security system to manage all the, you know, uh, endpoint security across the employees. Why are we using 50 different technology software, you know, for technologies, for managing our connectivity at the software level?

It makes no sense. And so what Kong is doing is unifying this connectivity under one umbrella that is our connect platform that yes, allows us to run gateways and now events and AI and service meshes. But it allows us to do that by owning this connectivity layer, which arguably it's one of the most important strategic asset that the organization has because it doesn't matter what we build and what we produce, what matters is how we can use it and to use it, we need an API or we need an event.

And this is exactly what our vision is. Now with event Gateway, we're expanding our platform offering to introduce support for events as well. And with this new capability, we can basically cover 90% of the overall enterprise software connectivity that's being generated across all the applications, all the use cases, whether they are in the cloud on Kubernetes or on virtual machines.

Kong can see and manage and govern the traffic. Now In your point about application connectivity, um, it's never been clear to me at least like who's in charge of that? Is it the development team or the networking team or somebody else?

And now we're hearing about the rise of these platform engineering teams and maybe they'll take responsibility for this. Well, that's a great question you're asking because if you ask many organizations out there who owns this, many will tell you, oh, we don't really know. Uh, you see, uh, historically this has been owned by the developer teams, but the application teams, you know, are building products, they're building customer experiences, they'll build the connectivity one and then forget about it.

And, uh, when there are problems with security, when there are problems with observability, you know, typically these teams are not prepared to address them. So over time we have been seeing, you know, we're working with more than, uh, 800, 900 enterprise customers, you know, the largest organization in the world in pretty much any vertical insurance, banking, uh, transportation, retail. And what we're seeing is that the leaders of the organization are taking ownership back of the connectivity and putting it into the platform team, the, the platform team that exposes this type of connectivity as a core service to the other teams in such a way that the other teams don't have to go build infrastructure anymore.

They can start using infrastructure and build their products, which allows them to now focus on generating the product outcomes they're building instead of reinventing the wheel with connectivity over and over again. Now, one of the biggest challenges that prevented this from happening is the fact that typically the platform team would become a bottleneck to every request, which is why it's very important that the teams themselves are being given some degree of self-service to self-serve, their connectivity policies to self-serve how they want their events to be managed, yet at the same time being able to do that without escaping the guardrails, the governance guardrails that your organization can enforce stop down using the platform. And so that combination of uh, that fine balance between yes, we want them to solve serve, but self-serve within these boundaries, it is, uh, what allows them to now fully take ownership back of these critical asset, which happens to be API connectivity.

So what's your best advice to folks then about how to approach this whole thing? Because, um, there's a lot of complexity and there's a lot of organizational issues. How do I get started?

Well, the number one, uh, step is understanding, you know, what is that we're trying to do? And if what we are trying to do is to fully own this connectivity layer, which will allow the organization to move faster, then we need to provide a solution that happens to cover all bases when it comes to connectivity. And of course events, it is a very important part of it, but it's not just events, it's events, it's AI traffic, API traffic, and being able to then provision that to the teams in such a way that the teams can then slowly migrate to a fully, uh, managed, let's say solution that the platform team has offered to them, uh, without having to, uh, essentially, you know, manage that connectivity ad hoc every time they're building a new API or they're pushing data to a new event topic.

And so certainly there is going to be a transfer of responsibilities, but ultimately what these achieves is a reduction of complexity because now we have one place to manage our connectivity and we have also an increase of developer efficiency because now developers are doing one less thing that it's very critical, but it shouldn't be doing to begin with. It's a mistake that they're doing infrastructure work to begin with. They should be building products and applications, uh, and innovate on in that area, whereas the infrastructure is being given to them, almost like electricity always on, always running the platform team makes sure that that electricity keeps, uh, being funneled to them, but they don't need to worry about it.

So I think that what this requires is the right technology and this is what Kong, uh, uh, is building has built and it's providing to our customers, but also a shift of mindset where we really want to be committed into making sure the teams are really focused on innovating and not focused on building crosscutting requirements over and over again. And for that, it is a cultural shift, guys, you heard it here. There's more applications and types of things in that distributing environment than ever, but the key to it all is finding a way to centralize the governance of it all.

Hey Marco, thanks for being on the show. Thank you. All right.

And back to you guys in the studio.