 Go ahead and get started once I can start my clock. There we go. Cool. The name of this presentation is Cloud Native My Camel from low code to pro code, inject serverless, and cloud native goodness into your app dev with Apache Camel 3. So if you didn't get from that, we're going to be talking about app dev. We're going to be talking about some cloud native app dev. If that's not really your bag, the next 30, 40 minutes is going to be a little boring. So that's your chance. All right. Cool. Well, I'm glad you guys decided to stick around. My name is Mike Costello. I'm a programmer. I've been doing this 20 some odd years, mostly in the enterprise Java space. I'm a distributed software lover. Enterprise integration patterns are kind of my thing. That's one of the things we're going to talk about in this presentation. I play a little bit of soccer. As you guys can tell, I haven't been playing a lot lately, but I should be getting back to it now that we've kind of come out of the pandemic a little bit. I'm an Austinite. I've been here for about 25 years. Little bit of change in the city since. Also worth noting, I work at Red Hat. I've been there for most of the last decade, about nine years so far. And I have a blog. If you guys care to check out my opinions on other things, you can check it out at entropic.me. The slide deck should be up on the session, too. So yeah, no need to frantically type. Cool. So let's talk about what our agenda is going to be. One of the first things we want to talk about is whether or not this buzzword we keep hearing, Cloud Native, is that just architecture? Is that marketing speak? Or is that a new architectural construct? Is that something we need to pay attention to? One of the things we'll talk about is what is low code? We'll give ourselves a definition so we can actually go on and figure out why Apache Camel is really good for this. What's Procode? What is Apache Camel, for instance? We probably want to level set ourselves a little bit. We'll talk about how Apache Camel is an idiomatic DSL for enterprise integration patterns. And then we're going to talk about a bunch of new stuff in Apache Camel 3. It's a new major version. There are about 17 minor versions in thus far. So it's a little longer in the tooth than you might expect if you haven't heard of all the change there. But there's some super cool stuff. So we're going to discuss some low code constructs. We're also going to discuss an iPass, which is an accompaniment to these new changes in Camel 3. And there's many, many, many, many more components, adapters, so on and so forth, that are new in Camel 3 that weren't sitting there in Camel 2. So we want to take a long look at that, but we will take a little peek. We're going to demo along the way. We're going to live demo. So I've made that big mistake. We'll see how it goes. And I think we'll have time for a Q&A. So real quick, what is cloud native? Some guy took a very, very verbose attempt at defining what cloud native means and what it means in our app dev space. Too long didn't read, the basic premise is this. If we're just native to a single cloud, we are not cloud native. For instance, if I take some proprietary cloud service in Cloud A and I try to go run it in Cloud B, I have problems. I can't tell you the number of times that I've been working with teams. And they've spent a laborious amount of effort, time, and money in erecting a cloud. Their executive management is a police-as-pond trade. And they're like, OK, cool, so let's go to the next cloud. Well, naturally, the conversation that follows that isn't very pretty once they learn that that's going to take at minimum 9, 12 months, likely much longer. It's not just microservices. One of the things we'll see in cloud native architecture discussions is thou shalt microservice. And I'm not saying thou shalt should not microservice. By any stretch of the imagination, in fact, you probably should. But that in and of itself is not enough to be cloud native. Ultimately, this fellow who decides to define cloud native there boils the sound and the silhouettes to a set of characteristics. We have to be elastic. We have to have on-demand scaling. We have to be resilient. And let's not just think about resiliency in terms of, oh, I have a replication controller, and bang, my guy pops back up. We need some more caring and feeding to that. We need to be manageable and observable. We need to be location-agnostic. We need to be event-driven, and we need to be API-centric. Cool. What is low-code? Pardon me. So a bunch of definitions out there. I just took two of the biggies. Foresters, like a Gartner-type research company. I'm sure you guys are all aware. And they have a definition that says, hey, there needs to be minimal hand-coding. I think we all kind of parse that out of the term low-code. But a quick setup in deployment is actually part of this definition. What that really means is we need to have some sort of paths of some sort. We can't expect somebody to go through all the machinations that it might normally take them to go write deployment descriptors or deployment YAML or yada, yada, yada to integrate not just with the platform, but the surrounding things that they may want to integrate with in the platform. IBM goes a little bit farther. They say it's got to be a visual approach. OK, that makes sense, right? Your kind of no-code, low-code stuff normally comes with some sort of something to view. But they said something that I also thought was quite interesting. And that is low-code development platforms also aid more seasoned programmers. And we're going to take a peek at what that might actually mean when we start getting into the Camel 3 stuff. Cool. So what is pro-code? This is actually a picture I took yesterday. It's of Linus Torvalds. You can kind of see him in the background there. But one of the things he described is their makefile was a makefile in name only. It's got incredible complexity to it and whatnot. So pro-code isn't really a thing. In fact, it's probably pretty insulting to a lot of people in our industry. We're basically saying, I'm pro and you're not, right? That's not really that cool. However, what we're really trying to say here is kind of like Linus was saying yesterday, is that what we refer to as pro-code is much more complexity, some sophistication to not just the logical factoring, but likely ancillary assets that go along with it. For instance, I may have some complexity in a CI CD pipeline. I may have artifacts like a Knative service, ICO artifact, a bunch of different YAML type things. This is when we start to get out of our low-code and kind of into the, you have to be a pretty gosh darn good software engineer to be able to wrangle with the code base in front of you. All right, cool. So I kind of sped through that. You guys will see why I'm going so fast in a second. But so I think we have to ask ourselves, just so we level set, what is Apache Camel, right? Kind of why we're here. It's initially released in 2007. So this is something that's been around with us for 15 years. It's actually quite mature. You'll see it at organizations all over the world. Some very, very important ones. It's a versatile open source integration framework based on known enterprise integration patterns. And some enterprise integration patterns that you might think about is, let's say I get a piece of XML and I want to split the nodes of XML. Or if I get a little piece of a payload, some JSON comes to me and I say, hey, there's a piece of that JSON that lets me know I need to go over here and in other cases I want to go over there. We'll actually look at something like that in a second. Apache Camel is idiomatic. And what I mean by that is we have these phrases from to enrich, transform, as I mentioned, split route, so on and so forth. And there's a bunch of stuff happening underneath the covers in Apache Camel. But programmatically, what I factor is these idiomatic expressions. I don't necessarily need to know the entirety of how one might communicate with, say, a message broker. I just need to say, hey, from this message broker and use a camel component, which will take some of the complexity out of the way for me. There's hundreds of these components that I just mentioned. These work as kind of adapters to commonly use enterprise software components. SAP Salesforce, so on and so forth, right? You've got adapters or components for that, but you also have your traditional kind of, I need to get to a database, I need to get to Mongo, Postgres, and let's say I want to do some cool stuff with XML, transformation, stuff like that. That's all there. The library actually gets leveraged in a bunch of different JVM runtimes. We may have seen each ourselves off in OSG Island with Karath 10 years ago. More modern, in a more modern sense, you might have even seen yourself on enterprise Java platforms, Open Liberty, JBoss, right? But nowadays you probably see yourself more likely to be in a spring boot or something like a Quarkus. And so here, this is from the Apache Camel website, and this gives us a little bit more of a feel for what Apache Camel is. Here we'll notice there in the middle, this is actual Java that might constitute what we call the Camel DSL. Notice we consume from our file component. There's gonna be a bunch of files in something called C adder. We're gonna filter based on an XPath expression, and then at the end of the day, we want those things that we filtered and met our XPath expression, those are gonna go off to some sort of queue. You'll notice on the right hand side, we have things like processors, we wanna handle EIPs, like I said, things like split, content-based routing, these sorts of things, and at the bottom there, again, we see this reference to a ton of different components, right? At the end of the day, we have hundreds of components to choose from. Cool, so what's new in Apache Camel 3? So I'm Klaus Ibsen, who's a super cool guy, check him out online if you get a chance. He's one of the leaders of the Apache Camel 3 project, or the Apache Camel project, and he's put together a quick and concise list that's too long for us to really discuss. There's a lot going on that's new in Apache Camel 3. We're gonna focus on a few things that kind of lend itself to our kind of low-code constructs that we're after. So some of these new things are, there's a YAML DSL. In the past, we had an XML DSL, we had a Java DSL, many of us kind of always stayed in the Java DSL. Now we have a bunch of DSLs, but more specifically, we're gonna focus on the YAML DSL, and something called Camelets. So that last little snippet of an integration I showed you, the idea behind a Camelet is it's a building block. So instead of having, I could go write that, and let's say one of my colleagues wanted to share the particular integration, instead of them having some control C, control V fun, right? They can actually go reuse that building block by just passing in something very simple. We're actually gonna take a long look at that in a second. There's a declarative bypass that we talked about. The idea behind Camel K, you may have guessed the K part, is to exploit Kubernetes and to exploit the platform. So there's out of the box integration with a platform. This could be serverless. This could be SEO, i.e. your service mesh. This could be other things like the open API spec, that we may want to kind of seamlessly integrate, Yeager, open tracing, Prometheus, so on and so forth. We may have needs to just kind of plug in there without necessarily wanting to instrument everything that goes along with that. And that's kind of where Camel K comes in. It also has something that we call a Camelet catalog. And these are again, an extensible set of building blocks that we can use so that if I'm a low code guy and I don't necessarily know how to factor some really, really complex code, I can just say, hey, pro-code part of the house. Do you mind making me some cool Camel? And I'll just use it without necessarily having to know what's really going on and having to write a bunch of code. And then again, the pro-code enhancements. Some of these things are pretty cool. There's faster start and run times. We'll see that due to modular decomposition. We've got quarkus extensions with an eye towards native compilation. That means we can get deployment times and performance that is order of magnitude faster than we may have been in the past. A type safe DSL, that's a biggie of mine. That was always a problem in Camel 2, especially as we collaborated with our colleagues and a ton more. Camel K is again, an eye pass. And let's level set on what I mean by exploiting Kubernetes. If everybody knows what an operator is, an operator is something that kind of cares and feeds for deployment. And generally speaking, what operators do in Kubernetes is they'll expose an API. And if I use that API, I can tell the operator, hey, I want you to care and feed for my deployment in this way. I want you to configure it as such. An example of an operator might be the StreamZ project where I say, hey, I want you to go launch a Kafka cluster and I want you to give it the following characteristics. It'll go care and that operator will then say, hey, you know, there's things you need to do along your lifetime. You need to rebalance stuff like that. So these are the types of things that an operator does. We describe our integrations just like the code that we saw previously. We describe those integrations as YAML based on this API. And what Camel K will do is actually looks at the YAML, Java or anything else we're throwing at it in an integration and determines via heuristics what you actually need in your integration. What I mean by that is it'll say, oh, hey, you're using the following components. That means I need to go grab the following dependencies. We need to make a build and I need to package up the build accordingly. And it'll actually ship that out. It has a build system and it ships that out into the image registry of your Kubernetes distro, it'll then deploy it for you. So again, meeting those kinds of local, that original local definition where we had to have quick setup and deployment, right? I don't, as we'll see later, I don't actually need to know anything about Kubernetes to get one of these, to get integrations running and building, building running and deployed into Kubernetes because of Camel K. It uses a Camel catalog and a Camelette catalog. So a Camel catalog for the components and a Camelette catalog that gives us these building blocks and this allows us to ensure some governance, right? So now instead of having one team who's building Camel.221 and the other team, they wanna use Camel 217 and somebody else wants to use Camel 34 and somebody else wants to be on Quarkus, somebody else wants to be on Spring Boot, so on and so forth. We now have a consistent dependency chain that's instrumented by Camel K and we can maintain governance across that. Again, I'm not asking developers to go put together all of this, I'm saying, hey, just give me the business features that you wish to express in your Java or YAML, what have you, et voila, bang, I'm gonna go do the rest for you. And it deploys an integration with a set of characteristics, right? Should it join a service mesh, for instance? So let's take a peek real quick. This is an example of an integration customer resource and let's go over to a place where we can look at this a little bit better. Cool, hopefully everybody can see this. We're in VS Code. If you don't see VS Code, for some reason, out there on the intervabs, something's gone wrong. So what we're looking at here is one of these APIs and what you'll see here is, again, we have that integration type, or a kind. You see the API version name, we gave it a name and then as we talked about previously, the camel DSL is idiomatic and this is it in YAML, right? We have a rest configuration, we probably wanna put something like that together. We're gonna answer on local host at 8081. We're going to, we've got a rest operation rate place order, it's a post. We have something called a route. You'll notice this says, hey, go over to this direct order coffee guy and naturally, if you're a low code person, you probably need a little bit of training for this to be meaningful, but I need to know what direct means, right? But as you can see, we consume from that order coffee endpoint. And then we have a set of things that we do, again, that are idiomatic. I won't bore you guys with this because I'm running a little short on time. However, we have a set of conditionality that we go through, we take, we do some, we have our log component there. We go out to a camlet. And this camlet doesn't necessarily, this particular camlet only takes in an URL, right? It's going to obfuscate everything about the HTTP interaction to you. Our HTTP component, however, needs more stuff, right? However, the camlet will go ahead and do that. So it's going to go out to an URL and get a random coffee. We've got some more conditional expressions. We've got the JSON path component. We're going to select some items, so on and so forth. And inevitably, we may not have met our conditions. We also have another route here. And what I didn't point out is that one of those steps earlier sends something to this particular route. This route, again, uses a camlet, right? There's a lot of configuration that I might want to do with going out to something like a JMS broker. This attempts to obfuscate some of that. And there's only a few different things I can choose here, so on and so forth. I'm going to go to local host, what have you. And that's it. So that's what, but this is that YAML there, that camel DSL is all wrapped up in this integration object, which my camel K operator can now, if I was to go throw this at my camel K operator, it's going to go try to build that. It's going to go try to make an image out of it. And then it's going to try to deploy it. Cool, so you're probably thinking to yourself, all right, so the IBM definition included a big, big, big thing. It's got to be visual, right? And as you guys saw, I kind of needed to know what I was doing there in that last one. I had to have a pretty good feel for the camel DSL. Even though it was in YAML and maybe a little bit easier to use, I don't have to worry about what Java version I'm on and yada, yada, yada, is Maven going, do I have the right Maven plugins? Even though I didn't have to worry about all of that, there's still some complexity and I still had to do some coding. So one of the great things about the introduction of the ML DSL is we have a new generation of gurus that are actually taking on this premise. One of the things we're going to take a peek at is Caravan. So we're going to go back into VS Code in a second and we're going to look at Caravan. It's an official Apache project. So it's not just some Frankenstein thing that's bolted onto the side of Apache Camel. This is part of the actual community distribution. There's also something cool called Camel JB. What one of the things that's always been problematic about running these snippets of camel is, well, I need to go get myself a runtime. That runtime has specifics, right? I need to know how to use Spring Boot or I need to know how to use OSGI in the past or I need to know how to use JBoss. How do I actually distribute camel into an ear or how do I distribute it into an OSGI bundle, right? I can't, back in the old craft days, going back seven or eight years ago when that was quite hot, can't tell you the number of times I spent in an OSGI manifest and that was the bulk of our discussion when trying to deliver code, right? Camel JBang is something that will go, look at your piece of camel. Doesn't matter whether it's in YAML, Java, so on and so forth. We'll instrument a runtime for it, get everything it needs and then camel now and camel three has a camel main and bang, will camel main you? Et voila, you're up and running. So let's take a peek. Cool, and so this is the route that we were just looking at the YAML for as expressed here in Caravan. As you can notice, we have our conditional behavior that we saw before, that's drawn in a certain way. Everything that we just had, everything that we just kind of quickly stepped through is there. We have also, as we saw previously, we have a rest configuration. To give ourselves a better look at this, let's go ahead and create one of these. So I'm gonna say get coffee. I'm gonna say direct. And I don't have anything to send this to. So I'm gonna go actually create this here. Cool. And you'll notice we now have an additional route over here. We'll go over to that in a second. We don't consume anything because we're a get, of course. And then I think that should be good. Yeah, cool. So let's go over here to this route, our new route that we just created, get OSSNA coffee, right? And I've got this direct thing that we just said. Hey, go create that. Now, we don't have, we have less time than I would like us to have. So we're just gonna do a quick set body. We're gonna say, hey, test me. Cool. That's good. Let's real quick look at some other things that are available. We of course have all our camel components, right? You can see things like activeMQ, AMQP. And we also have these things called camelates. Again, this attempts to simplify these things. So you guys will notice many, many more things here than we had in the past. Tons of AWS stuff. For instance, the AWS, Kinesis, Firehose sync, so on and so forth and AWS Lambda sync. None of these things existed back in camel two days. But we won't worry about that for the time being because we're interested in something called camel JB. So I'm going to press that little start then. There's a small issue with my guy that I am running right now. So sorry about that. But we'll go ahead and you'll notice what camel JBang is actually doing here is you should see some dependencies downloaded. It started up Apache camel. We started our routes. You'll notice that I have HTTP endpoints that are answering, so on and so forth. You'll notice I didn't just use a palm. There's no Java jar that I just issued. None of that happened. This is all camel JBang instrumenting this for quick prototyping. So we'll go over here. Sorry, we'll go over here. And just so we know that there's nothing up our sleeve. Go down here to get coffee. Cool, and we just put in test me, right? So obviously it gets phenomenally more complex than that and we would like to add some more complexity, but it's just that easy for a developer to be able to go write some code in a GUI, test the code without necessarily really knowing what is happening in the surrounding universe around them with camel JBang. And is able to do this exclusively with a GUI. They could of course also come down into the YAML DSL themselves. Sweet. So what is a camel? I keep referencing these things and I keep calling them pre-built integrations. And we just saw this picture, right? There's a ton of them. We've got a few hundred that are available right now via the community. These are all built on the YAML DSL and currently, as I mentioned, we have hundreds of these. We have a, but we can also add our own custom camelettes. What that means is I likely have a couple of different personas on my engineering team. So I likely have some people who are great. They sling code all day long. They're very, very interested in some of the kind of pro-code stuff we'll talk about in a second. And I also have some people who are likely less seasoned. And they can take on some of these low-code concepts and say, hey, pro-code site of the house, if you guys can extend a set of camelettes, these pre-built integrations, when things get really, really hard for me, I can still actually contribute and deliver code, right? Because I can reuse your camelettes. Yeah, so let's go take a peek at what that means. Cool. So here is, you guys will notice I changed editors for extra credit. I'll let you guys guess which one I prefer. But here we are in Eclipse and we have, again, a camelette. We'll notice there's nothing crazy going on here. I have a little bit of metadata, right? That I'm saying, hey, title description. I have some properties. I let people, or I let everybody else know what's gonna come out of my camelette. In this case, I have a camelette source. We have a source and sync dichotomy with camelettes. Some are sources, some are syncs, right? I can, with a camelette binding, I can put these two things together quite quickly. So in this case, again, you'll notice here's the camel DSL and we're, again, in YAML. So just real quick, I have a timer. I tick every so often and I'm gonna go off to our random coffee API and then I'm gonna lay that off to whatever the sync is. That sync could be that GMS broker sync. It could be your sales, it could be a Salesforce sync. It could be any number of different things. Let's go take a look at, in our case, what our sync is gonna be. Cool. So I've got the medium code camel sync here and this is very much going to take in whatever it got, whatever you're trying to lay off to the sync, right? It's got a few of its own properties. It lets people know what it's going to, what will actually come out of the sync. And oh, by the by, it's consuming from a camelette source. The camel DSL again, we're in YAML. Now, there's a bunch of different ways I could use this. I could do something like a camelette binding where I can say a source sync, right? So I could say, hey, give me the old school GMS broker source and then give me the Kafka sync because I need to move some data around or give me the database source. Give me the Kafka sync because I wanted to do something that approaches CDC. In our case, we're actually, I'm going to do something a little bit different. And this is one of the things that I think is very cool here. I can use this in Java as well. Just because this YAML DSL exists, just because this DSL exists in YAML form there, I can reuse this as long as the camelette exists in my camel catalog. What this means is if I'm a developer and I want to sling some integrations around via my camel K iPads and there's some complexity that somebody else has already solved, I can just reuse that. I don't need to go reinvent the wheel again at all. And what we'll notice here is this is Java base and we're going to go throw this into camel K. We're going to consume from that camelette source, right? We pass it in a property. So if you'll remember, one of its properties is this a timer, it's going to tick so often. We're going to tick every, I think a few seconds. We may want to do some things in a processor, so on and so forth. Inevitably, we end up at our camelette sync, right? Again, we pass in a property and that is what composes the integration and I'm able to use, as we mentioned, these building blocks in a more, if you will, pro-code or traditional app dev setting. So let's go off to my cheat sheet. Let's grab something from here. And let's go run this. All right, so, oops. So I'm using, I'm using OpenShift. You don't have to use OpenShift, you can use any Kubernetes distro. That's relatively recent. Again, I'm using OpenShift, but don't worry about that. Let's go ahead and execute the camel with a K CLI. What you guys will notice here is I'm using something called camel with a K. This is a camel CLI and what this is going to do is it's going to ship that integration, if you will, up to our camel K operator. Now, you might say to yourself, hey, Mike, you only shipped Java there. That was just a piece of Java. There wasn't that integration custom resource that we just looked at. What this is actually going to do, we just did an OYAML on the command that we just created. What this is actually going to do is it's going to create, sorry, we'll go all the way up to the top, that, yeah, this is going to create that integration resource. And so here we notice the code that we just shipped, the container, we gave it a few traits, if you will. Here's the dependencies that, based on the heuristics that are ran over by code that it indicates that I actually need. It's going to go in the build, it's going to go package all of those dependencies, go grab them from a Maven repo, literally do a Maven build, et voila, we're going to ship that off. Now, let's see if that worked. Cool, it looks like it did. Real quick, let's take a look at the Camels that are available. These are the lists of Camels that are available in camel K, and we'll notice there's our medium code, camel source and camel sync. If we go to, we'll see we're working away, we're ticking away, we're sending messages, we're going out and hitting this random API, the salt's going a little fast, but inevitably we got some astringent, creamy, peanut, green grape, licorice type coffee, and it apparently is from Mexico. Cool, so that is two Camels working together in a Java-based integration that we just shipped to camel K, et voila, bang, it made a build, it deployed. Now, let's go a little further, and running out of time, sorry about that. So one of the cool things about camel K that we mentioned is it's exploiting the Kubernetes platform, and I have the availability via something called camel K Trace to tell the camel K operator which of these capabilities to plug into. So I can say, hey, go plug into a serverless, go plug into Prometheus, go plug into a service match, and shameless self-promotion. If one was interested in how one might do some of this stuff with a service match and how these things plug in, play together, and maybe even some opinions on how to do that, it's a little linkage for somebody's presentation at KubeCon called Governing in the Cloud Native Event Mesh. Cool, so let's go do that. We're gonna go back to Eclipse. I've got two things that I'm gonna throw up there. I've got this first guy. This guy is called Event Bus Transformation Integration, and what this guy does is consume from, you'll see a K-native component. K-native in is the serverless path that we've chosen here. He'd also get some serverless goodness with Kata, but up to you, I quite like K-native. And instead of this just being K-native serving, it's actually going to be listening to K-native channels. So we're gonna do the K-native eventing stuff. And it's going to pick up a message from a channel called TestingDB Events, much like it would a message broker. And then it's going to do some stuff and it's gonna lay off to that guy as well. We're also going to ship this guy Event Sync Integration. And what this is is just a timer. It's gonna repeat 50 times. And it's not gonna do a whole lot. It's just going to say, hey, open source summit, welcome to Cloud Native Integration. And then it's gonna lay off to one of these K-native channels as well. Cool. So let's go back over here. Woop, I need to do that. And we'll go back to our cheat sheet. And you guys won't be too surprised to find out that I have already built some of this stuff here. So we're gonna be a little bit faster than we might otherwise be. Cool. So actually, let's do this. We're over time. But the main thing here is you'll see previously we hadn't, we didn't have an event bus transformation integration running. Bang. The second we start pumping messages into the serverless event bus, it picks up and scales from zero to one. What's most noticeable about that, if we go back to, whoop, this guy, is we gave this a set of traits. We gave it, oops, let's go one more. We'll go to this guy here. And this is what we just told, what I told Camel K earlier to do. One of the things we'll notice is we have a trade K-native service enabled. We actually made a K-native service without having to actually go throw any ML in there with it. We also just said K-native enabled in general. So if we go to do, so inevitably what we'll see is event bus transformation integration is gonna scale back down to zero. This should take about 30 seconds to a minute. In the meantime, I'm going to show you guys, there we go. And as you can see now, it's starting to scale back down to zero. This will sit at zero until again, it's woken up. So we're kind of in our Q&A time. We did have a little bit more that I wanted to talk about. I'm gonna show you real quick a native compilation because I can show that off real quick what that implies. However, I think the most important part that I wanna leave you guys with is this. And then I'll shut up if anybody has any questions, they can ask some. Many of our low code, no code appliances over the years have been bolt on appendages to our enterprise stack. They're over off here in left field. Nobody wants to touch them in the organization. It's really, really, really unpleasant, right? This presents a path where your more seasoned engineers, as well as your less seasoned engineers are able to use the same bits. Everything that we just saw in camel K that it produced is gonna be doing the exact, is gonna be using the same dependencies. It's gonna be using the same runtimes, most likely. So on and so forth that we might see in a more pro code scenario. And so because I promised I would do so, let's do this. These take a little bit to build, but that is how quickly we just started up. Actually, let's do this real quick. That didn't start up. Cool, we started in 0.19 seconds. Anybody who's been in the enterprise Java space for a while, working with a team right now that has a deployment that takes about eight hours for their application to deploy, you'll notice that this just deployed in 19 milliseconds. That is incredibly short. Anytime we're doing serverless work, where we need to answer pretty quickly, we need to go from zero to one well within our 30 second time out, right? So on and so forth. This kind of pro code technique becomes quite handy. So all right, I'm gonna stop there. I had more stuff I wanna discuss, but I've left everybody with one minute for Q and A. So my apologies. But if you guys wanna grab me in the hall, so on and so forth, I'd love to chat about this stuff. I can probably spend the rest of the year chatting with you guys about this stuff. Yeah, categorically. So one of the things we just saw there was Camel J-Bang. Camel J-Bang when it hadn't instrumented without using Spring Boot. There is a Camel main right now in Apache Camel 3. So you could just job a jar into your Camel main a well up bank, right? You're good to go. Scala, I haven't spent a ton of time with over the last 10 years or so. So I don't know how well the hooks are gonna work. I would assume though you should be able to load, you should be able to invoke a Camel main from Scala that's sitting in your JVM. But again, I would definitely check my mouth on that. All right, King, well, I'm at my time. Like I said, you guys are free to grab me in the hall. I don't wanna keep you guys from your lunch. Of course, that'd be horrible of me. But yeah, we're over time. I think nobody's rushing to get in here. So if you guys wanna keep chatting, I'm free to. If you don't, I'm sure you have better things to do. But anyways, guys, thanks very much. And yeah, I hope you guys enjoy the rest of the conference.