 Okay. Hello. Let's start for the next session here. So now we are talking about again, so actually following the previous talk, which is also about your developer experience for deploying your apps on Kubernetes. So today we try to convince you that it's able to deploy your apps on Kubernetes without the boilerplate. My name is Roland Huss. I'm from Red Hat, a software developer, software engineer, and with me is... So I'm Marc. I also work for Red Hat as a software engineer, and I'm currently maintaining the Eclipse AQ project and the Fabricate Kubernetes client. Yeah, so as application developers, I'm pretty sure you're familiar with these diagrams. You start by coding your application, then you build it, you package it, and eventually you pass it on to an operations team that will be in charge of deploying this application and making it available for users, probably in a dedicated server, which has a compatible loss for operating system for your application, and a suitable runtime environment. However, with the appearance of Kubernetes and the popularization of the DevOps culture, many of these responsibilities have shifted to the left, so now you're not only responsible to provide this package application, but you actually need to containerize the application and provide the Kubernetes configuration files, those Jammel files, to be able to deploy your application into Kubernetes. So to containerize your application, the most common way is to use a Docker file. So here we have a really simple Docker file to be able to containerize a Java application. It has a very specific syntax that you will need to learn and you will also need to understand and probably maintain in the future. And in addition, you have to have in your system a given set of tools, so in this case maybe a Docker Demon and the Docker CLI, to be able to interact with these files and containerize the application and finally push it to a container registry. Similarly, for Kubernetes, you will also need to create and maintain these Jammel files, so I think that the most simple deployment that you can do requires at least these four files, so a deployment, service, config map, secret, but obviously eventually you will need more resources, maybe an ingress, a volume, auto-scaling capabilities and so on. So each of these resources have a very specific syntax that you again need to understand, need to master and will need to maintain in the future. And also just like for the Docker files, you will also need specific tools in your environment to be able to interact with these files and eventually deploy them to your cluster. So here in this example, you have this kubectl apply and finally that will finally let you deploy the Jammel files into the cluster. So in theory, everything looks nice and so on, but as your application grows in complexity and also gets older, so do these files, right? They become longer and they become larger in quantity. You get to deal with more and more files which get more and more complex. So as an application developer, and I think we've been hearing about this all the morning, I've been here a while and everyone has been talking about this complexity. I think that what we want is to have certain tools that will actually help us deal with all of this complexity. So now Roland will give us a good overview of the available tools. Yeah, sure. So actually, we have seen also not only, of course, you know these kind of Jammels we have seen all in the first session by Marcos and Mauricio, so what kind of hell this is really. And we are really wondering whether this couldn't be done better. So we all knew the old times as developers, so we are all developers here. So and actually Kubernetes is not made for us, right? It's just this is an abstraction which is for operations and not and we have seen can really very, very robust. And what is needed, what people are really trying to do is to add additional abstraction to the job of Kubernetes. And hopefully these abstractions will help you to understand the complexity and to master the complexity of Kubernetes itself. And yeah, let's have a quick look what's out there in the wild. And our approach now is I give a very brief overview of the things that we think that are helpful. There would be a list which is obviously not comprehensive. It's a subjective selection that we have picked. And they all deal about two concepts. So when you are a developer, you have actually two tasks, right? You develop for Kubernetes, to be honest. You need to build container images somehow. So you need to create those. We have seen the Dockerfiles. They can be also very complex. And then you need to get all the stuff onto Kubernetes. And for that, you are probably pop up your editor, create YAML files and deploy this. So this is the usual way and we will look whether this goes better. Daniel just talked a lot about the inner and outer loop. And this is a very important concept for all the developers in there. Because actually I'm as a developer, I really want to live in the inner loop, right? So I want to have quick feedback on this stuff. I do not want to make a change, push it to Git and then just to check out what my code has done. I want to stay local. Maybe this is the day to day. So there might be a brighter future with road development. But as it is now, we are all living in the inner loop. And let's look what those tools have in the box for the inner loop. And the outer loop is actually, I don't have to talk much more on that. So outer loop is exactly how you get all the stuff into production. And to all the big test cycles for end-to-end testing and whatnot. Yeah. So what we thought about actually, we have invented a fun matrix, which is called the YAML Stealth Level, which means how much of YAML you can really hide in the developer platform. And with YAML, we don't mean the syntax of the format itself. We just mean all the complexity that Kubernetes YAML brings with me. So it's a kind of a code word, so to say. And in the next slide, we see that there's kind of a correlation between the YAML Stealth Level, so how much you'll hide YAML. So on the left-hand side, you see you have direct exposure of all the Kubernetes complexity. And then on the right-hand side, you see have some shielding by the developer tools that you are using. And of course, there's a trade-off, right? So all these tools are very opinionated. They make decisions for you. And then you lose of course some kind of flexibility, but it's easier to understand. Your learning curve is lower. And yeah. So then, of course, now we have here a list of various tools that all are dealing with HapeUl. Actually, this is a kind, as I said, a very subjectively, we widely picked some. We probably also missed very important ones. So please bear with us. Actually, yeah. So let's go quickly over all of those. So the first one on the list is Hape. So probably, who of you do not know Hape? Let's ask me the question that's around. So, okay. Everybody kind of knows Hape. So maturity here means also popularity. So it's not really mean that it's super stable, but Hape is everywhere. And it's not really developer tool-wide. But actually, we as developers usually have to deal with Hape if we set up our dependencies, for example. And yeah. So it made it to the list. Of course, the YAML stealth level, the YSL, is very low because you are directly exposed to the YAML set if you create a chart. But of course, if you consume it, you are probably shield from that. So it's a little bit biased here. And the next one are already longer out there already. I just mentioned them. So they all have kind of a similar scope, like garden, octet, and tilt. But this slightly different focus. So for example, garden more is focusing on modeling the dependencies among microservices and give you also a local developer experience. Whereas octet or more has a focus on developing within the cloud with developing containers. And tilt also has a very high focus on local developer experience in there. And then today in the morning, we heard about Dagger that you can also kind of consider Dagger as a development tool. But you might not really directly think about that. But we have seen that you can really improve your local development experience as well with Dagger. And not only creating your CI pipelines programmatically. And then finally, then we have other Dinosaur here like Scaffold. It's also already also out there since quite a long time. And gives you also the ability to directly build your container images without having Docker files. So they leverage and build pics for that and then push it out to the cloud. And finally, something which might be a little bit surprising on the list are Knative functions. So Knative functions is also very opinionated way how you get your local code on top of Knative. So Knative is a serverless add-on on top of Kubernetes. And you can learn more about Knative functions in the Knative maintainer session on Friday too. But it's also kind of a new thing which you might be interested in. So this is an overview. We have the links there and the slides. So if you download the slides, you have a handy point in there. And I have to say that this list is really about cross language tooling. So this is really about tools that you can, that usually come with an own CLI. So they kind of impose their development workflow onto your workflow. And in the next list, we see a little bit more tooling which is a little bit deeper and which really integrates into your current development workflow, which you already have, which often is much easier. And so, but surprisingly, the list is not very large. Actually, it's only around, so this is what we found. So please come to me and tell me more if you know for Node in Python, though I don't, we couldn't really find any deep integration in the Python build system for creating this kind of deployment stuff and container images. But KO is really a brilliant tool. So if you haven't used it and if you're a goal-length developer, you probably, for sure have heard about it. So KO is a tool which creates container images out of your Go build files without any Docker files. So it's also very opinionated how it creates the images, but you can choose them. Then we have Chip, which is coming into Java world and it comes as a maven and cradle plugin to create your, also your container images without any Docker demon, which is quite nice because it just takes this together. And then finally, we have jcube. So one question, who have heard about jcube already? Nobody? One? Okay, that's great because the rest of the talk will be about jcube and this is our, as I said, our approach is a quick overview of the thing and now we type deep into a single one. And I think and we think that jcube is a very nice thing how you can integrate into your current existing maven and cradle builds without learning any new tooling. So this is a very nice thing. Okay, so jcube is a set of tools and plugins that will actually help you generate container images and generate and deploy the cluster configuration manifests for your Java application. So it's a Java specific tool, we saw before that they were cross language and then this one specific for Java. jcube consists of several components. So there is this jcube kit, which contains all the logic for jcube and that can be actually consumed as a standalone library. However, there are a set of tools, a set of plugins, in this case the Kubernetes maven and cradle plugin that actually expose all of the jcube functionality and that can be consumed through maven. Similarly, there is the OpenShift maven and cradle plugin that is built on top of the Kubernetes maven and cradle plugins and offer specific functionality for OpenShift. So yeah, I really like to think about jcube as the Java way into Kubernetes because it's actually really easy to integrate into any kind of Java project. So here we have two examples. If you have a maven project, you simply add jcube or the Kubernetes maven plugin into your plugin section and you're actually ready to go. And you can actually execute most of or leverage most of jcube's features by running them as separate maven goals. So in this case, you can package your application as usual, but then you can actually build the container image, generate the cluster resources, and finally deploy them into your Kubernetes cluster. Similarly for Gradle, there is the Kubernetes Gradle plugin that you can simply add to the build.gradle file and then you can actually leverage the jcube features as if they were Gradle tasks. So same as for maven, we have the equivalent for Gradle. So one of the main advantages of jcube is that you actually don't need to install any other tool in your machine. If you have a Java development kit and maven or Gradle, you add it to your project and that's it. You don't need to have QCTL, you don't need a Docker Dman, you don't need a Docker CLI, you don't need anything. In addition, something really really cool is that jcube actually encapsulates different build strategies. So just by changing a configuration flag, you can go from building your container image using Docker to use GIP, build packs, or even S2I build strategy. As Roland mentioned before, there was this Jamel stealth levels of complexity. So one of the good things of jcube is that you can go from zero configuration. So basically jcube provides support for multiple frameworks, Spring Boot, Micronaut, Quarkus, and even standalone Java applications. And it will generate suitable defaults for those frameworks. Obviously if maybe they aren't suitable for your applications or for your needs. So you can actually overwrite these opinionated defaults by providing XML configuration if you're using maven or build DSL configuration if you are using Gradle. You can even provide what we call Jamel fragments. So these are small pieces of Jamel. So if you have a deployment, maybe you can provide the annotations or the labels. And what will jcube do is read these fragments and merge them with those that it generates for you. And finally, the good thing about jcube is that it's designed both for the inner and the outer loop. So for the inner loop, it provides many, many features such as debugging your application in the cluster or even life code your application with the remote dev feature. So we saw before this remote approach with this container. jcube has this embedded inside. So you can actually life code your application while it's still interacting with other services in your cluster. And it's also designed for the outer loop. So it provides some tools that can be really useful for your CI environment. So you can actually push your container images to a registry. You can generate hand charts. You can push those charts to a hand registry and so on. Yeah. So this diagram basically, and before we go into the demo, shows how jcube works. So basically what jcube does once you invoke one of the goals or the tasks is it inspects your project, it analyzes it, and then it generates some opinionated defaults. If you run the k8s build goal, it will actually use these defaults to generate a container image that should be suitable for your application. Then you can run the k8s push, which will push the container image to a docker registry or a container image registry. And similarly, you can run the k8s resource goal to generate cluster manifests and k8s deploy to deploy them into your cluster. So yeah, talk is cheap. I think it's better if we see this in action. So here I have a very simple spring boot project. This is the simplest project I could generate. It has just the definition of the spring boot parent, and then a dependency to the spring boot starter web. And it has just a single class. So it has this rest controller that exposes an endpoint in the root path. So when you perform a get request, you will get this simple greeting. And if we want to leverage jcube, the only thing that we need to do, as we saw in the previous slides, is add the plugin to our plugin section. And we should be actually ready to go. However, since I want to deploy to push my image to a docker registry, I'm going to provide some override to the default. So we saw that jcube provides these features. So in order to push this to docker hub, I need to provide my username. So it's important to note here that you usually don't need any configuration if you don't want to have. So you get also the name created automatically. But if you want also the ability to override this and to adjust this. So as you like, and of course, this configuration or customization goes very far so that you could even direct the amplifier. So now, also, in addition to the standard resources, I'm going to create this bigger, an ingress. So I'm going to deploy this into my minicube cluster. And I need my IP. With this, I will create an ingress, leveraging the nipnip.io service. So I will set the base domain here. Thank you. I think that should be it. Yeah, with just these simple configurations, thank you. We will actually be able to automatically deploy the application into my minicube cluster. So if I check my cluster right now, there's nothing there. So I can build my application just like any other application. So this is built. And then I can actually build a container image using the ktest build goal we saw before, push it into my Docker Hub registry, generate the cluster resources, and finally apply them. So if we now check the cluster, we already have the application running and I should be able to perform a request yeah. And as you can see, it just went there. It's super easy to set up. We check what really happened under the covers is that jqp actually created a Docker file for us. So you can, this is transparent for the user, but you can see that it did create a Docker file with multiple layers and some complexity. And it also created the Kubernetes YAML files. So all of this stuff gets really hidden from us and it's done automatically for us. Yeah, so actually the point of this very short demo, I hope you've seen that you can start very quickly without any knowledge of Kubernetes at all. But the point is that you really can integrate it into your current existing workflow. You only have to mention or reference an existing plugin and you don't need to learn any new tooling. I think this is one of the key benefits of using such tooling in there. And of course you can still continue to use test containers as other stuff for an inner loop part. But yeah, so this was the point. This was one example. As I said, I hope that there will be more tooling which is coming, which are looking like this and improving the development experience because it's still hard. It's still hard to get your application, especially if you have a lot of external dependencies on the Kubernetes itself. Yeah, with that, I think if there are any questions, actually, we have still some minutes for questions. There's one over here. So maybe you, I tried to repeat that. So maybe. Yeah, so this one is only for Java at the moment, right? So this is unfortunately, there's none, as I said, we haven't found anything similar in other languages. But for now it's only in Java, but maybe people, yeah, find this useful and try this out. And actually, I have to say, there's also history of the plugin. So if you have heard about the fabricate main plugin previously, so this was one done several years ago by Reddit as well. This is the evolution of it. So it's really separated. So it's pure Kubernetes. So the original plugin was also a little bit open shift focused. But this one is really now pure under neutral foundation there. So this is the next step in the fabricate main plugin, if you know that. Yeah, so sorry. But actually, if you like, you can start one. I think the concepts are quite interesting because the generation, there are pluggable generators that create all these YAML files for you. And of course, you can create your own generators for your developers so that they can that you have also can bring in your own opinions how you create the YAML files. Okay, I think now we are over with the time. Or is there any last question? If not, then thank you very much for joining. I hope you enjoy the rest of the clip.