 So, hi, this is the presentation. I'm very sorry for the technical difficulties. I hope you will be able to see everything you're supposed to see. My name is Peter Palaga. As was said, I work for Red Hat at Red Hat Middleware. I am currently paid for developing and maintaining Red Hat Fuse on EAP, which is distribution of Camel. We will be speaking quite a lot of Camel today. The upstream project of the product is called Wi-Fi Camel. I'm there in the team for about a year and a half before that I work directly on JBL's EAP and Wi-Fi. In my free time, I work on several main and build related tools, such as source dependencies. It's a way how you can declare dependencies in Maven and Gradle in terms of source commits instead of released artifacts that you pull from remote repositories. Except for that, I work on Editor Config integration for Maven and Gradle. Who of you knows Editor Config? It's a format for defining styling rules for the source code. And it's supposed to be IDE independent, so IDEs that support it, such as IntelliJ. When they see the Editor Config file, they read the settings and adjust their internal settings based on that, such as indentation and end of lines and so on. The talk is called generally about Java because at the time when I was submitting the talk, we were kind of forbidden to speak about Apache K OK in public. Now the embargo is gone, and I can speak about Apache K OK. So this will be more Apache K related than Java in general. But still, there are some important points for Java in general in this talk. So it's not that imprecise to speak of one second redeployments for Java, because this is basically about one way how this can be reached. So before we speak too much about Apache Camel, who of you has quite a good idea what Apache Camel is. One, two, three. OK, who of you has ever written a working Apache Camel route, which was not so many, so I'll give you a very quick introduction into Apache Camel. So first, it's quite an old project. Since 2007, it's also very big in terms of lines of code. I think it's the second by lines of code on GitHub in Java. It's really, really very big. It has many Maven sub-modules, and it crashes IDEs because of the size very often. It is an integration library. It is a toolbox which allows you to create these so-called routes. And what is a route? It's a way how you can transfer data from one system to another system that were not directly designed to communicate with each other. And Camel gives you tools to do exactly this. It has connectors for many different systems, and it gives you ways how to handle the data, the mapping, transformations, and so on. It's based on a book called Enterprise Integration Patterns. The book has a web page that you can see at the bottom. So there's quite a sound theory behind this, and Camel is actually an implementation of this concept. Here are a few examples of those integration patterns. In total, there's like 60 of them described in the book. I'm not sure if Camel implements all of them, but I'm quite sure the ones you will need in your life are there. There will be a short demo where I will show you some of them. Here, the number of components or systems you can connect out of the box with the open source Camel. This is the complete list. In the demo, we will use Twitter and Telegram. These are protocols, file types, public APIs, and so on. This is just the part that is available out of the box, except for that there exist tens, maybe probably not hundreds of components that are not there mostly because of licensing issues that connect proprietary systems. To define routes, you will use domain-specific languages. There are several of them offered by the project. These are perhaps the most common, Java and XML, except for that there's also Groovy Scala and some other ones. Here in Java, you would extend root builder and override the configure method. And here, you will say that we are pulling messages from, from, from, from. Does it work? It doesn't look like. We will pull messages from Twitter. We will log every message we'll see and we will forward them to Telegram, to a bot that is defined somewhere in a configuration file. This is the same in XML, and you can do the same thing in other languages in a similar way. So now, as you look most of the time, we have like 30 minutes, so this has to be very quick. So can you read the font now? I hope so. Great. So this is a, this demo should show how you would create a root, an application containing a root, and how you would deploy it to OpenShift or Kubernetes. I will use OpenShift. The project contains a few dependencies, such as Spring Boot. These are bombs that you will import so that the versions are compatible with each other. There's a few boot starters provided by the KML project that you import here. We will use Undertow on Spring Boot because we are from Red Hat. And we will, we need Twitter and Telegram and a few other things. Here, let's have a look what the content of the application looks like. This is the entry point for the font jar of Spring Boot. It's very simple. And the roots are defined, as we have shown in an extension of root builder. Here, we start, we pull the data every this many seconds from Twitter using this. We are looking for these keywords. And we lock every message we see. And we do some processing of the messages. And then we send it to Telegram using the recipient list integration pattern. There are two roots. Here, the one is the forwarding root. And this is just an echo root on Telegram that remembers every client that connects to my Telegram bot so that I can dispatch to all clients that are connected on Telegram. So if you would like to participate on this demo, you could tweet now a message containing camel and devconf. And then if you connect to this Telegram bot, you will see the message, the tweet, being forwarded there. So let me now deploy the demo to OpenShift. It starts to, so I'm pushing to MiniShift. MiniShift is a remote, in this case, that points at a Git repo inside my cluster. It's Gox. Who of you knows Gox? Gox, it's much like GitHub. It has a nice UI, and you can deploy it very easily on OpenShift. I have deployed it, and I have pushed the code of my application there. I'm lazy to find the repo and show it to you, whatever. Except for that, Jenkins was started because my project contains a Jenkins file. And the Jenkins file will be automatically executed on OpenShift Edge. The build should be visible here, login. So if everything goes nice, and it fails because I haven't started my mirror that takes my local Maven repository, it's a very easy hack that uses MRM Maven plugin for forwarding. And when I restart the build now, it should succeed. It will take more than a minute. I think we are not going to wait for it. We can open the bot through Telegram web, and we should see the messages forwarded there. These are from yesterday, I think, when I tested. And there should appear some new, or we will see the same messages that we see here, because I have posted some test messages on Twitter there. And they should appear once again when the container starts. So this is basically how a traditional integration with Apache Camel works, still on there. It uses Fabricate Maven plugin to build the image. You can see the plugin configuration in the profile. It's in the OpenShift profile. Basically, it's a very common way to use Fabricate plugin to produce local images. And as I said, we use Jenkins that adds tens of seconds to the build. And in the end, even if we didn't use Jenkins, it would take more than a minute. And that's exactly where the Came OK project is aiming. We want faster deployment. So the deployment is there, and we should see some messages here. They just arrived. And if you post something on Twitter now, it should appear here in a couple of seconds. I'll leave it open if somebody of you wants to send more. So Martin's message was sent probably even before I started the demo, but whatever. So this is the traditional way, right? And there's a whole big new area of interest for Apache Camel as a project nowadays. One of them is low-code or no-code integrations, which are primarily targeted at so-called citizen developers. Citizen developers are engineers or, I don't know, authority officers who are not programmers, but they are technically skilled enough to be able, using dedicated UI, to create simple integrations, to take data from one system, to transform it somehow and push it to some other system. Read files, read APIs, and so on. There's a project implementing this. It's Apache Synthesis. I have deployed it on my OpenShift instance. Maybe I could show you very quickly how it works. It's in separate space. I probably will have to log in. So here, I would have to start with connection. I can choose from things that actually come from Apache Camel, from the traditional one, and they are presented here somehow. I will be reading from Twitter, and these are exactly the things I was defining in the Java DSL to start the pipeline. I have already defined a connector like this. It's this one. It has the secrets filled out, and I have defined a connection for Telegram as well, and the secret is there. To create an integration, I just take these two. I will start from Twitter. I will end with this search. I would fill in the keywords. Camel and dev.com.cz. And I will forward it to the bot. I need a chat ID. I will not fill it out. When I finished and click, this would create a container, create an image, deploy it, and we would see the same thing happening here in the Camelbot as we have seen with the Java Spring Boot application. When I click finished, currently it would again take a minute or a bit more depending on how complicated your integration is. And that's exactly when the Apache Kmo K project comes in with the ambition to make this much, much faster, right? Let's go back to the presentation. Let's have a look if somebody has posted something here. No, nobody. I will just kill the pots so that we can do the same once again with Kmo K. So back to the presentation. And the second area that is a motivation for this new Apache Kmo K project is serverless. In serverless, you not only have functions, as you know them from Amazon Lambda, but you also need some sort of glue that connects various functions and external systems. And that's exactly where there's a huge match for the traditional Apache cable, but there's a requirement to be able to prototype the glue, the connections, the routes very fast. And actually, there's also a requirement. That's not a requirement, that's a characteristics of these two areas that the integrations, the pipelines there are not going to be very complicated. That's just going to be very simple or no logic at all. With Spring Boot, you can bring in many Java classes, you can use dependency injection, and you can use lots of business logic there. And there's no such requirement here because you will not be able to create a complex business logic through a synthesis UI. And the citizen integrator is not skilled enough to do this as well. And with serverless, you also want just to forward data, maybe transform it somehow, but not too much complex logic. So taking these two things into account, and the third one, that the low memory and CPU usage startup of the integration matters a lot, especially if you are the one who provides this as a service because you are paying the bills for the electricity. It's not just that the integrator needs fast feedback, but when the container starts fast, the CPU cycles are simply not there, and the RAM usage needs to be kept very low. So you need to look at ways how to eliminate the time, one minute, and how to eliminate the RAM and CPU used for container builds, image builds, and startup of the container. And that's exactly where KMOK aims at. It's very new, couple of months. So what you will see here is very, very fresh and new. So when I say it simple, what does it mean? How would I have to simplify this Spring Boot application so that it's acceptable for FHG KMOK? I will not be editing here because I think I'm a bit late. I'll just switch to another revision in my history, this one, and I will comment what is simplified there. So I have taken Groovy, but this could also be a Java file. And if it was a Java file, I would, in the first place, have to remove the package declaration because FHG KMOK understands only plain Java files without package declaration. So package declaration isn't there. Second, everything has to be inside this single file, which is sometimes, or which is really stupid for some use cases, but it perhaps suits 99% of the users of those systems that we have so, like citizen integrators and serverless functions, glue. So we have moved every single thing into a single file. We have inlined the processors. This is the one. This is the second one. The first processor is uppercasing the keywords. It was there in the Spring Boot demo, too, but I haven't commented on that. So if it sees KML, it makes uppercase KML out of it and the same for DEVCOMC. And the second, this is the Telegram bot implementation that just stores the chat IDs of the client. So if any one of you now connects to the bot, this class or the chat ID of your session would be stored in a global here, hashtag, so that I can dispatch to all of you, OK? And the rest is much like it was before we have two routes. Actually, I haven't commented where this placeholder, how these placeholders are replaced. In traditional KML, I had a properties file inside the Spring Boot application. With KMLK, I have to create a secret. To create a secret, I have a couple of lines of code and I actually create a secret out of these application properties files. And what I do is, I'll delete the old secret project CK1. So I have deleted the old secret. If it was there, I have copied the application's properties to a temporary directory. I have removed comments. And I have added my Telegram authentication secret at the end of application properties. And then I have created an OpenShift Kubernetes secret called forwarder properties. And now, when I run the route like this, we should see something like a diploid, which didn't work. Why? Because the secret is wrong, perhaps. Forwarder props to secret is correct. My god. Let's have a look what the secret looks like. Ah, the rest of the properties is not there. That's the problem. And why? Still here, so some of the steps didn't work. Let's try to do it one by one. We are in the right project. We delete the secret. We copy this one temporary. We remove this one. OK. Now the secret is complete. And we should be able to deploy this using K and K. Because it's the very same route, we should see the tweets forwarded here in the Telegram bot, which just happened. And if somebody of you posts a tweet, again, it should appear here. How does this work? We have some time, so I can explain. There's a camel binary, which is just a client that speaks with the cluster. You can download it from camel K, releases, unzip, add to your path, and it starts working. And there's a camel K operator inside the cluster. Who of you has a fairly good idea what Kubernetes operators are? One. Good. Let's explain. And this is just a very, very broad introduction from a Java guy. You are on a conference where there are many better talks to go to to learn about this. But what do you need to know? That it's an application management concept. What it means? Management. Creating applications, removing applications, editing, changing, modifying applications. That's management. It does what a human operator would do to manage applications. How does it work? It works based on declarative input. You tell the cluster what you want, and the operator looks at the declarative definition of the state and tries to reconcile the desired state with the actual state. The operator hangs on the official Kubernetes API. And there are two important things to see there. It gets notifications about changes in the model of the cluster. When a new resource is created, the operator gets a notification. And when it gets a notification, it implements a custom logic to do something useful. For example, create some resources, delete some resources, modify some resources, scale up, scale down, look into existing applications, call their APIs, and so on. It's up to the author of an operator what the operator should do. The second part is custom resource definitions. So on one hand, we have building resources in Kubernetes, such as ports, services, and so on. On the other hand, you can extend the model, the building model, with your custom kinds of resources. And your custom kinds of resources carry data that your operator needs to know to do the management of your applications. And the custom resources are exactly the way how to define the input for the operator declaratively. And this is what the KMOK operator is doing. The input is a groovy file, a Java file, and XML file. The KMOL command line client takes the file, and what it does, it creates a custom resource of a type integration inside the cluster, nothing else. And the operator, the KMOK operator is running, and it gets a notification that there's a new resource of kind integration. It looks into the data of that integration instance. What does it contain? It contains a piece of groovy code. Ah, this means we need a groovy runtime to run this. So it looks into the list of available runtimes that are built in into the operator, which are, by the way, also custom resources, and looks for a match. Oh, OK, groovy is supported. Let's take the groovy runtime, and the groovy runtimes brings, actually there's a slide to it, groovy runtime brings a set of dependencies, actually main dependencies with it. Let's take this set of dependencies as a base for an image, for an image. Good. And then second, the operator looks into the definition file, which endpoints In our file, there was Twitter and Telegram. So it means the operator takes more main dependencies and adds it to the list of dependencies that are needed to run this integration. OK, so now we have a list of dependencies. The operator looks into the set of known images. Have you ever seen this list of dependencies before? If yes, there's an image, and let's take it. We don't need to build the image. We have saved a lot of time. OK, this is one of the tricks. And the second one is that the images used by the KMOK, they contain just the general code, and they don't contain the root definition itself. They don't contain the groovy file, or the Java file, or the XML file. Those ones are mounted to the running container as a config map. And that's the second important trick, to get the speed up. OK, so now when I change this, when I change the root definition from, well, let's say from upper case to lower case, I hit Save. The KMO client recognizes the change in the file and instantly creates an update of the resource inside the cluster. And the operator looks, the dependencies haven't changed. I don't need to rebuild the image or build a new one. I'll take the old one, and I'll just connect the config map with the root definition there. So limitations. Actually, very easy. The wrap up, these are three things I wanted to remember from this talk. KMO-K is an operator-based Kubernetes runtime for KMO. It's for fast prototyping and rather simple routes. It's not 100% replacement for traditional KMO. That's it. Here is the project info. If you have questions, I'm there in the corridor. Thank you very much.