 Thanks, Carlos. Hello again, everybody. So my name is Sebastien Gozian. I'm the co-founder of TriggerMesh, been involved with KNATIV for quite a while. And I got five minutes to talk to you about this. Modernizing IBM MQ application with KNATIV and KONG. Don't add Kubernetes because it makes for a very bad acronym. So we'll stick with KNATIV and KONG. It's a very interesting use case. At the same time, it's a bit of a Frankenstein. So actually, once I'm done talking, I would love to hear from you what you think. So what I mean by modernizing applications, what we're seeing when talking to customers, prospects, and so on, they want to move to open source. It seems rather simple, but it's actually a big desire. It's about removing proprietary software as much as possible, and the reason is pretty simple, is to cut costs. So adopting open source as much as they can, and while they do this, they need to integrate with existing systems that they cannot get rid of. So big proprietary systems like Oracle DB, IBM MQ, you name it. So it's this desire that they have to become less dependent on very expensive systems, adopt open source, but at the same time, they still need to keep on using the infrastructure that they have. So move to open source, still integrate with existing system, make them relevant as they move to the cloud, as they adapt cloud-native technologies, cloud-native techniques, and so on. And then the third big thing about modernizing application is really to rejuvenate the overall application and operational landscape. And it's more of a culture thing. And we've been talking about it in DevOps for a long time. It's changing the culture of the enterprise. How do you deploy apps? How do you maintain them? How do you monitor them? And so on. So it seems simple maybe here where we have very much cutting edge, but there are lots of enterprises out there for whom adopting GitOps is quite challenging, and it is a big change because that's not how they deploy application. Monitoring with new things like Prometheus, it's a big change, right? But nonetheless, they all wish that they would go to prod much faster, right? So that's the thing, right? It's changing the culture, changing a little bit of the landscape so that they go much faster and they reduce cost. It's as simple as this. That's the benefit of modernizing. I don't know why it's flickering, but okay. So big boring use case, right? So lots of apps that we're seeing in enterprise that we're talking to. It's lots of Java applications. And a lot of them look like this. So it's HTTP server returning Java, exposing a REST API. And behind it, you're actually fronting mainframe applications with whom you're communicating with using IBM MQ, right? It cannot be more legacy or enterprise than this, right? And you can have thousands of those apps, right? So if you use something like MuleSoft, for example, you've written REST API with MuleSoft and then you're doing some data transformation in Java. And then to communicate with your mainframe, you're going in and out of MQ, IBM MQ, right? And in and out of MQ, it's, as I said, to talk to a very old system of records running on mainframe. So that's where we start from, right? And how do you modernize this? Which path do you take and so on? So what we're seeing is that it's a little bit why I mentioned the API gateway earlier in the panel. So we're seeing adoption to newer API gateways like Kong, right? So we're seeing lots of enterprise moving to Kong. And then if you start putting Kong in the picture and you imagine that they're trying to rejuvenate or modernize the platform on which workloads are running, which means Kubernetes. Suddenly you end up with Kong as a gateway wanting to deploy in Kubernetes, but still you have to deal with your old system of record and your MQ, right? So how do you get out of this? How do you strangle this and get moving, right? So that's where I'm actually very happy about this, but it's also a little bit of a Frankenstein from a technical standpoint. So I would love to see what you're thinking about. So we cannot get rid of the system of record is still in place. You're still going to talk to it through MQ, right? And then suddenly you have Kong that's exposing your REST API, right? So in the middle, we're now putting TriggerMesh here. And with our APIs, what we provide is data transformation. So all the transformation that you could do in plain Java, you can do it declaratively with KnativeObjects, for example. You can do filtering, you know, processing with functions, you know, whether you use our functions or KN, doesn't matter. And then to talk to MQ, you use, well, an MQ source to read from a queue. And then we have an MQ target so that you can put into a queue, right? So a source and a sink into MQ, right? So if you start, you know, you start from this and suddenly you move to something like this that moves, that deploys in Kubernetes is defined by API objects. So it's fully declarative, right? And you can drive it with CICD, right? So it's great. It's very modern. That's where you want to go. But, you know, what we're finding is that the path to go from the old to the new that would look like, you know, something like this, it can be a bit challenging because it's a big step. So the step is that, you know, suddenly your Kong as an API gateway, that's your entry point. And what's behind, you know, I showed you an example, but it could be much more asynchronous. And it could be an event-based flow. So your Kong REST API suddenly now needs to bridge to an event-driven flow, right? So you're bridging two worlds here. And Kong needs to emit cloud events, right? If you want to, you know, deal with Knative and eventing constructs and so on. The flows can be asynchronous, but if you want to reply to the client with a reply, at some point you need to synchronize, right? So we've built a synchronizer using, you know, a correlation ID in the events so that we can wait for a particular event back, right? And then the final step is that we need source and target to MQ. That's actually the easy part. But we've done it, you know, as Knative objects. So everything here is available on GitHub, TriggerMesh, Kong CE demo, CE for cloud events, right? And you'll get the full flow. So the first thing is a Kong plugin that transform a REST request into a cloud event, right? So you curl to Kong, you give it some payload, and suddenly you have a cloud event, you know? Thanks, Sokai. Thanks, Scott. So you got your cloud events here, you know, emitted by Kong. Which means that suddenly you go REST and now your event into a Kubernetes cluster, right? So you've made that path. This has the advantage that depending on the route that you hit on your API gateway, you could have different cloud event types, and you could now do routing based on event types, right? So we fall back on, you know, an eventing type world. Yeah, YAML. So MQ connectors, you know, as I said, that's the easy part, right? So we have brand new API kinds, MQ source, MQ target. You specify your credentials. You specify your Q manager, your Q name. Here on the target, you know, that's something that's interesting with MQ is that if you put a message into a specific queue, you can say, hey, the reply is going to be in another queue, right? So here, you know, it's their request reply mechanism. So here you have a reply to parameter that says, hey, the mainframe system of record is going to put its reply into this other queue. So read from that other queue to get the reply, right? So that's your connectors to MQ. Now open source, fully declarative, you're good. And certainly the flow looks like this. You end up with talking to Kong, open source, or getting, you know, the enterprise product from them, right? But you could go fully open source with the Kong API gateway. You use our cloud event plugin. You get an event into a Knative router. You can do routing based on the event types. Different transformation, function-based, you name it, how you want to do the transformation. You put into MQ, your mainframe could do its job. Put the result back into the output queue, which we read with our source. And then the magic, which is a little bit Frankenstein-ish, is the synchronizer, right? So we're going to wait for an event with a particular ID to make a synchronous reply, right? So we have an asynchronous flow, you know, that we are exposing with a, you know, a synchronous mechanism. So that's one way of modernizing, you know, such a flow here. And just to, you know, just to go a little bit, you know, yeah, I'm the guy who's not using dark mode. So I'm just going to, so I don't know if you can see this, but so a trigger match with, you know, to make things a little bit easier, we've written this integration language, which is based on HCL. So here you see that entire flow that I described with our language, with our router. So based on the event type, so route attributes, you see the different type go to, you know, a specific transformation. Transformation could be function. Here that's our, you know, function example. And then at the end, I mean, you see that a function can say, hey, once you've executed this function, go to MQ. So it says, you know, to target MQ, and you have the definition of the MQ target, right? Of course, this is not, you know, Kubernetes object, but we can generate, you know, from this, we can generate the YAML. That's where the developer experience, I think, you know, to me gets complicated because if you ask a new user to start writing a flow like this with pure YAML, you know, it becomes very complicated. But here you see the full YAML that gets generated with, you know, the source to MQ, the synchronizer, you know, the different triggers, the different functions, right, the broker. So you get all these objects, and the compilation of all those declarative objects makes your entire, you know, flow. All right? So, thank you so much, modernizing your MQ applications with Kong and KNative. Thank you.