 Good morning, everyone. Welcome back to the OpenShift Coffee Break show. We came back after our Norton Hemisphere summer break, but today we come back with a great guest, a great topic. I'm very happy to welcome our guest of today, which is our colleague Anna Maria, and also we have, of course, our tarot. So good morning, everyone. How are you folks? Well, fine. Having my coffee near me. Hope that I can sit from it while talking to the audience. That's the way, that's the way. Where's your coffee? I forgot my coffee. I just speak it. Yeah, and I hope you have all your coffee shot because it's important to start today with good energy. Just a recap of what is this show. This is the OpenShift Coffee Break bi-weekly show on OpenShift TV, where we talk about OpenShift, cloud-native, enterprise architecture, and all that kind of stuff. My name is Natalie. DevOps. Don't forget DevOps. DevOps, GitOps. Yeah, yeah. And DevSecOps. Yeah, excellent. Thanks. We talk about everything, but today we focus on the developer experience for Java developer and on how to modernize Java application. My name is Natalie Vinter, product manager for OpenShift here in Redat, and I let Anna Maria and Dero represent herself. Well, I'm Anna. Nice to see you and to meet you today. I'm working as a developer advocate for Red Hat at the moment and became recently this year a Java champion. So I'm welcoming you all with this talk, where we're going to see more from developer side, but a bit of DevOps as well. So hopefully you'll like it. Nice. Thank you. Yeah, I'm still Tero. Still senior staff engineer at Wangal working with DevOps. Actually, it's Wangal Liftoff. There was a merger a week ago. And I will be the bad cup, not that I will be the good cup in the episode. Tero is the one that make the... We were telling to Anna that Tero is the one that make difficult question, but it's a joke. Well, I would like to say that if you have any question during the show, please send into the chat on Twitch and YouTube. We are streaming both in Twitch and YouTube. And we will come back to the show and ask questions to Anna and everyone. So, well, Anna, today the topic was modernizing Java apps. So also, Tero was asking before in our brief session, what is this modernization about? What does it mean to modernizing apps and Java apps? Well, as I was telling to you, it's about improving applications for your end users, you as a developer, architect, tester, DevOps engineer, I mean all the team involved there to improve applications for end users, feeling good while modernizing. I think that we are in a very good spot as IT professionals. And we have the opportunity when changing something or we're building something to actually not have improved the end user experience, but also improve our experience as well. And I think that in the past years we have been all focused on achieving that in our teams and having fun while building new stuff or reworking some old stuff. And probably the engineering world has been around this since it started. And things are improving, getting better and better. Thanks to a lot of frameworks, a lot of tools and open source, of course. Of course, of course. We talk all open source over here. Good morning to all the folks attending. There is someone from Komaraju from India. Oh, good afternoon to you. And good afternoon to all the people attending. I guess there's someone, probably there is also someone from Australia. Last time we have someone from Uruguay, which was a totally hero because it was 3 a.m. in its time, so it was fantastic. So yeah, I'm very happy. And you know what? Today, of course, we have our discussion, but then also Anna is going to show us also some live demo. That is the spirit. Also, Thero is one big fan of live demo. I remember when we were doing POC, it was all live, of course. It's not a demo if it's not live. Yeah. So we're all live. It's going to be live. Live coding. Live coding. Do you have any presentation or anything you want to show us before we go? Yeah, I would like to introduce you into the topic of today swiftly, like in the meantime, grab the coffee and discuss a little on the chat. And afterwards, see the demos. So let's start the show. That's on a perfect plan. OK, so welcome to modernizing Java apps. We already met earlier, but in addition to what I already shared, I love both Java and Kubernetes and a lot of other technologies because I'm passionate about solving challenging technical scenarios. So the more complicated things are I really love to solve them. That's pretty much the way I'm going. And in the discussion that we're going to have today, we'll start it with modernization. So why should you modernize? And you can write your answers in the chat because I'm going to look at that. So why go into modernization part? Some reasons found out through time through my own experience. Well, adding features to what was already in an application was becoming harder and harder. It took longer time. And when things take longer time, you can do it once, you can do it twice, you can do it three times. But afterwards, you're thinking maybe there is a better way. And you are thinking what you can improve regarding what you're already doing. And secondly, especially when I was a junior developer and working at, let's just say, a big code basis. I guess, important more products need large code basis, it seems. I was a bit afraid of touching certain areas of the application code. So when you are kind of afraid of touching certain application code, because you don't know how that is going to react on the change, because probably there's not enough testing or there might be not enough resources to do an integration test for that particular area. That's when you have to think like you should change something in the way that you're doing things. And of course, I think these days were anniversary, like 10 years since the microservices hype has started. And like 10 years ago, a lot of people thought that this is it, the old architectures, there are an endangered species in terms of architecture. We're going to do distributed systems. And we're going to split what is complex into multiple applications, because this is the way we should go and people discovered that you can do and deploy them independently. And in the beginning, this was a little bit VM oriented. But in the meantime, with Kubernetes and containers, things got even better. And not only deployment independently, but when it comes to making applications that work independently, they're also isolated when it comes to fault. So if your application is concerned of doing only a certain business function, well, this is great because if something is not going that nice with that application, your entire platform is not going down. Of course, there's going to be some users that are not going to be that happy because they're probably not getting on the happy path scenario for their actions. But at least you can contain the problems. So you don't affect everything. And I'm probably, even nowadays, you have experienced times when you are using your favorite websites and they're not available and they're displaying to you an error message like, please come back later. That's annoying. I mean, I find that's annoying. And especially when you want to pay for something, that's annoying. But it happens even nowadays. And talking about Kubernetes and containers, thanks to that, zero downtime is not anymore like a fantasy story. It's a reality. There are ways to deploy things and achieve zero downtime. So making things smaller, having zero downtime and doing them independently sounds like the best thing ever. And since you're making them like independent, you can scale them independently. So what this means is that if your end users are going for a certain promotion on your platform, and there's a lot of, I don't know, a lot of charge on that, on those endpoints, you're not going down with everything. You can scale independently. You don't have to think like to scale independently. And then it will take a lot of time for things to get started. Because if you're using all the goodness that is micro services plus containers and proper orchestration, you should be in a happy spot. So can I ask a question at this? Sure. You might touch this topic later on. Let's have a scenario that you have, you started from microservices, you had nice, let's say you have five services. It has their own like topic. They do one thing only. But during the years, you plot those. So you add features, features, suddenly you have 10,000 endpoints in one microservice. When do you actually start splitting those micro services? Well, the thing is that you start to split those when you see that the startup time maybe is becoming heavier because you're adding way more to the plate. And if you're looking from, I mean, if you're comparing your original scenario to where you got, I mean, you always have to compare where you started and where you got. Is it that the same scenario or is it got that complex? And you can sometimes spot that actually it's like one and a half scenario. So when it's when like one and a half scenarios, that's when you're thinking like maybe it would be a good thing to decouple these things. Otherwise, I will grow into actually a containerized monolith. And that's what you want to avoid. Like you don't want to go back to that place. Another good thing about microservices, you can monitor them and you can monitor what's going on with them. And most of the time, the startup time is being affected. And you're also looking into your application code and you're like feeling that not everything is belonging here. And that's something that you can do together with your colleagues. Especially if you're Java developers, you're used to work together to do same features. And if you're coming from a monolithic work, you're used to, you know, discussing those and how things are interacting. And it's, you have to be brave and cut things when they need to be cut. That's the story. So be brave. Do not wait until it gets too big. And you go back to the 500 megabytes containerized app. We want to... Yeah, it's just the var file. It's 500. Okay. Thank you for interrupting me. I wanted to share with you how the story started for microservices. Well, probably you've seen this before. If you worked in a typical ER application. You probably made some tires. There was a presentation. There was a business integration resources and so on. And these are pretty nice ways to organize your app. Especially if you're starting from scratch, it's very nice. You can use all the great patterns, Java patterns that you learn in school, that you read in books. You can apply them. And it's really, really cool. But in time, things are growing. Because most of the time, this kind of application interacts with one or more databases because you need to persist the data. Typically relational databases. And then you have to interact with some other apps because you're not alone in the world as an application. And if you are, you are a very lucky case. But sometimes you need to import some stuff from somewhere because you don't have to hold the information in the world in your app. Or you're not allowed to do business reasons. Or sometimes you have to send the information to another app. The business users are saying, I want you to do that real time. Like when this is happening, you send it real time. Or you need to do some reports for your business users to see some information about how things are working for your different areas for your app. And all these things can be multiplied. And they become really, really big. And when you're looking to this picture and you are, you as a team are saying, so let's go and split this and make this microservices. And imagine a bigger thing here. You're going to find out that there are some challenges when it comes to going to distributed system. Well, the coupling capabilities of Alana is not an easy task. And this is something that a lot of people can talk and tell you their experience. It's easy to make a simple app, a simple microservice. But when you are looking back to your monolith, and it's the big thing, and you spend a lot of time making those features and coupling those features, it's very difficult to decouple. Then looking at containers. You are looking as a developer and see that, well, if I want to see and replicate how this app is going to work, I need to make a Docker file. I need to work with Docker images. I need to make containers out of those. So you need to acquire a few skills, even for your local development. Because, well, in the other parts, you're going to be helped by your colleagues from the operational side. And then it's about cohesion of team members. Because you need to talk way more often with your colleagues when it comes to moving to a distributed system. That's going to sound a little weird, because probably we were talking with your colleagues before. But many years ago, I worked in such an environment that we used to make the deployments. And the deployment meant that somebody was building the ER, or there was a Django job building the ER. And somebody was taking the ER and was making the deployment for a specific application, a server profile. And it was procedural communication. Let's just put it like that. But nowadays, in order to go fast, you need not just to use the talk to the colleague, but you also have to talk to and make that procedure actually an automated procedure, not like do that and talk all the time. Because you don't have one big app anymore. You have many small apps, and it will become a burden for everybody. They would have to talk to their colleagues from operational side all the time and deploy that microservice, deploy that microservice and so on. That's not how twins work. So how to move forward when it comes to doing this? Well, I would say to start small with a simple decoupled capability of your big app. Look at your big app and just extract something and start with a small feature. Even if you think that all your features are complex and complicated, try to take one and just chop a little bit of its functionalities or maybe a little bit of its dependencies and start with that one. Then you can add some dependencies from your model to your monolith, but carefully, carefully do that. Like really think if you want to add that one. Sometimes when you are rebuilding a big application that can now becomes like a platform and distributed system, you can also look in the market. Maybe there are managed services that are very cheap or open sourced. That can do that thing for you. And instead of that team to spend time of rebuilding things from scratch, maybe you can take that already and put that into your app. Secondly, maybe there are better dependencies than what you used to use in the past. So always look what is available in the market, especially open source market. Secondly, you need to separate the highly coupled functionalities early. So what I'm trying to say here is that think about the way that you are working with transactions. A lot of time, a lot of time, we spent like studying how to make those transactions like go really, really well and have a good observability what's going on with them and not to lose information when persisting data. And now we're going with distributed transactions. So think of those early time to not think of them at the end of the project or near the end of the project and say, oh, but now we have to persist data and to communicate this data across the microservices. How are we going to do that? So try to think of that aspect from the early stages. And speaking about transactions and everything, you have to divide vertically what's going on with your app. So remember the monolith, it was very horizontal. Well, when you're going with distributed systems, you're thinking vertically. So all the time, think of your system like there's some vertical, your app is vertical, it's not anymore horizontal. And you always have to think that is my app deployed, can be deployed independently? And some of you are going to say like, hey, but if I'm persisting data in databases, is that independence? Well, yes. Because when you were deploying your monolith on your previous app, you were actually assuming that there's going to be a database available there. So why can't your new microservices think the same thing? But of course, always think about how the event consistency is going to go through the multiple persistence stores and so on. So don't forget about that one as well. Now if you can deploy the app independently, you can release early. This means you can go to the business users and say, hey, we would like to check that this is aligning to what you want. Now, this is a calibration of expectations as well. Because remember, you started from a small, more simple decoupled capability. So probably when you release early, it's not going to give that highly complex thing that they were used to when the big app was being developed. But you always have to remind them that you see things earlier so you can change your mind. And that's a big plus. And your business users can tell you what is important for them. So you can always understand what is important for them and look back to your app. And last but not least, you start again based on that feedback. Yes, it's not a one-time thing. It's a continuous improvement thing. And it continues improvement thing for many small apps. But the thing is that once you are up to speed and you get the rhythm, you are actually going to feel more energized into building these things. And to get even more energized, you have to have some more development practices. And that's what I'm going to share with you now. Because I think there's been a lot of talking and need to share some demos with you as promised. So before we go into the demo, Anna, I would like to discuss a little bit about, we discussed here about the methodology, right? It's not a technology or a framework. Here is just the methodology. And this is a good, let's say, Halihab, to a nice open source project, which is Converior, which is a community that helps with some tool, modernizing and migrating, let's say legacy app. I would like to share in the chat the link to the community, because it's very important what you say. And moreover, it's a process before it is a framework or just a technology stuff. It's a process. There's also some methodology, some culture that need to be changed. And I'm sure Tero is going to say DevOps somewhere. Actually, I had a question linking to DevOps. Actually, we had an last episode with Jaffa, we talked about all things DevOps. And everything from development point of view, it ends up how to measure things. So I think that it's also important here that how do you measure that you are actually doing correct things when you're modernizing that you have better quality, you release faster customers and users are more happy. So you need to measure that. You just don't modernize in sake of modernizing, but you're actually doing something that profits the whole company. Yeah, true. One thing regarding measures, if you're working at child, I think the fastest way to measure is like if you reach the goals of your sprint. So if your sprint has completed and you reached the goals and you managed to have the demo with what your end users expected. So that's one way to measure. Of course, that kind of success doesn't come immediately. It comes in time. And it comes also with acceptance. And also another way to measure, of course, monitoring is very important using metrics in your app. And I'm going to show that to you as well. So all the time, keep an eye on what you're doing with the tools that you have at hand. And this is where the DevOps part is very important because most of those tools in alerts are coming from the DevOps side so you can get alerts. And there's a lot of processes that can be improved, especially when it comes to build, not just seeing a build that has failed, but you can also see how much time it took a build to be done. And that's very important as well because if it takes 30 minutes to build something, it's not very performing. You have to ask yourself a question and then you have to come back to the board and think how you're going to improve things as a development team. How much time for things to get deployed up and running and all the time measures on these paths can be done throughout the entire process. So keep an eye on that one as well. And if you can post that chatting tool with the team, I can't slack or anything that you're using all the time you can integrate stuff. DevOps. Okay. So can I go to the demo? Sure. The stage is yours. So we don't have an additional question, but if we have... I would like to remind, if you have any questions, please send in the chat so we will bring the question in the show. So we can answer your question during the show, but now it's time for a live demo. Sure. So first things first, start small. So we're going to start small. And if you want to start small and build your own first microservice, probably you've seen this before, but I need to have my scene and starting point as well. I'm going to go to code.quarkas.io and make my own small app. And I'm going to make my greeting app built with Maven. Start small. So we were talking about start small. And when you want to see like an effective result of your work, most of the time you're building some kind of web service. So I'm going to use two extensions for building REST web services and anti-sports utilization for that. Going next. What I want to do with my web services is that I want to see and interact with them while developing. So I need, I think I need swagger. I'm going to select this extension as well so that can interact with my services and work with them. Secondly, I said that sometimes you need some persistent store. And to go faster, I'll use the memory database and we'll sell the database. And I don't, I like queries. I've written a lot of queries, but I like when things are being kind of generated and I can prove based on the generated stuff. So I'm going to just type in hibernate and select hibernate or I'm with Ponachi because it's not just going to make some work be taken away from me, but it's actually going to be some more work taken away from me because it has Ponachi. And we were talking about containerization. Now let's move to the heavy stuff. So I'm writing here container. I see that there are a few options for me to build my container image. So no more talker. And I'm just clicking container image, Jib to generate, to build my container image using Jib. And I need to deploy things. But I want for some things to be generated for me and since we're at OpenShift TV, I'm going to select OpenShift to generate OpenShift resources from annotations. So remember this is the developer point of view of doing things. And of course we talked about metrics. So let's add micrometer. So to recap for people that maybe are not aware about this tool or Quarkus, this is one of the framework that you can use for, let's say, modernizing your Java applications. And this is kind of wizard where you can build the skeleton of your app, right? This is the, yeah. And you can also build it from an archetype. So if you like me even a lot, I like me even a lot. You can use the archetype and you can configure even more stuff, not just generated from here, but it's easier from the browser. Yeah. So now let's generate my app and download it. Okay, saving to my local and go and have fun in the IDE. So I got some sources, some stuff generated and I've added something extra for me because I need to complicate a little bit the scenario today, but... Just one thing. Can we increase a little bit the font because then in the zoom window... Yeah. Let me just make a little cleaning stuff here. I will increase the font when I'm sharing my code. Yeah. So I got some boilerplated stuff, like a service. So this is the first part that is being generated thanks to that page. And I can go ahead and make some changes over it because, well, things are not as always as generated. We need to adapt this to the real life. And before doing that, I want just to start the things to see that this application that I got is actually working as expected and is not, you know, just generated code. So let's go here and say in the end, Quarkus Dev. So I'm going to start Quarkus in my Dev mode to see how fast it starts, how things are going for it. Okay. By the way, I'm going to use Quarkus in JVM mode, not the native one for this demo, but if you want to go even faster, you can use it in the native mode as well. Wow. This is the one based on Grail VM. Yeah, I also have also Grail, but we're going to go traditionally Java way with the JVM based one. Okay. So things are pretty much getting started here. And I just want to see a few things being shown in my Dev mode before jumping back to the IDE. Yeah. Well, here's the thing what I want to show you. See this thing, Dev services for G2 started, but I didn't configure any database yet. Well, the thing is that in Dev mode with Quarkus 2, you have Dev services for most of the persistent databases available. This means that you can work and do development work in Dev mode with a database without configuring anything. Remember, this is just Dev mode. So it works only with this mode for deploying part. Well, you need to go back here and you have to give some information about your database. So what I'm going to do, I'm going to generate my information for my H2 database. Nothing fancy. Drop and create. And of course get some information from import.sql when you start the app that I'm not having an empty database. Okay. Now, going back to my code part, I want to make an entity. I want to talk to the database. So going back here and I'm going to create my message entity. Edit. And I'm going to go traditionally hibernate and jpa. So we're going to say at entity. And what I'm going to do different, I'm going to use Panacea entity. Why did I do this? Because if I'm going to the Panacea entity and just making this a little bit bigger, I already see that the primary key part is solved for me. So I want to build this example really fast. I don't want to just spend a lot of time building it. Remember, start with a simple functionality. So the primary key is taken care of by Quarkus, private string content. That's cool. It's cool, right? No more work. I like to have less work. And just add some fields to the entity. And let's go a little bit traditional here. No Lombok or anything for the moment and generate getters and setters. I'm going to use this entity. I'm going to use this entity. I'm going to use this entity. Like we used to do it in the good old days. And since I'm going to talk directly with this entity, I want to use also an annotation to get more data from it. So I'm going to use JSON include. This one. Include. None nulls only. So this is it with my entity. I'm going back to change my greeting resource. I'm going to define null directly on my entity and then list. And this is going to retrieve a list of messages. So this is kind of odd what I've done here, right? Probably some of you are like, what? What are you doing? How can you do this? This is called active record pattern. So you don't need to define repository as any intermediary if you want to work directly with the entity. So I'm going to do this. I'm going to do this. Thanks to the ponache entity part. That's where the goodness stays. And this is how you are able to do this, but it's not going to produce to explain. It's going to produce application. So these are my messages. This is how things have changed. Let me look how the deaf mode is looking like. If you're looking to deaf mode, you can see here that says test pause. Let me press air. Come on. Running tests for the first time is going to go well. And this what has done with our pressing R, what happens is that you are actually going into continuous testing mode. What this means is that if you're changing something in the code, that part is the tests are going to be rerun again. And as you can see here, I changed something in the code, but I didn't change the unit test. It's a developer. You have a reminder that you have to change the tests as well. And you have like a good part where you can see that which part, which test is failing. And you can go back to the IDE, go to resource, and just put here not null. And change this one to not null value. And that's it. Well, let's, let's also give some information for my database to be not that empty. So I'm going to generate some messages. And going back to my deaf mode. I can see that now my tests are complete. All my tests are passing. Well, this is cool. I like when this is going is happening. And let me go to the browser a little bit and check how things are going to local host 8080. And if my app is still running and starting, because when I started my app in deaf mode, my app has started here as well. Let's see how Hello is looking like. Okay. Hello gets pre-populated with some messages in different, coming from different languages in different countries. Pretty good. Where is, where is Italian? Where is Italy? I have a surprise in actually I was preparing a little bit more for the demo to add the Italian with a post, but that's in the repo. Okay. I was sure that you're going to ask me about that. Of course. Okay. So this is cool, right? I mean, you already have some, some good experience. Now let's go back to the application of properties and speak about containers and images. I want to also see this available. I'm going to see it somewhere in a, in a container and a wrap-in running. So what I'm going to do, I'm going to say container image. Push. True. What this does is that when I'm using ambient clean package is going to push a container image to my designated registry. So I'm using quay.io. And I'm going to have these definitions for my image. So it's going to be my registry, my NSN box, greeting app with a certain tag. And also see here that I have some Kubernetes. So I can do some Kubernetes generation as well. But I also want to deploy to Kubernetes. So I'm going to say Kubernetes.deploy. Deploy. True. So now I'm going to do going to go here. Always check Java 11 or Quarkus and the same ambient clean package. And to speed up things, I'm going to skip the tests because I know they're already good and they're running. So I'm just going to package all of this. My favorite argument, skip tests. It's just for, it's just for the demo part. Did not worry. I mean, you can validate this in my GitHub repository. I'm going to share that with you. That code is working. All the tests are working. So it's just for this one time because things are taking a little bit longer for me when I'm live streaming from my, from my computer. So that's just an thing that I'm doing. And probably some developers are doing that as well. Myself included. But it's very cool that developer doesn't need to write any as far as I understand. And it doesn't need to write any Docker file, any Kubernetes manifest. It's just Java driven. Yes. Everything is Java driven. And you don't need to be aware of, of any of the differences there. So where is this going to be deployed just to share with you while this is being built? This is going to be deployed in my sandbox. So in my open ship sandbox, every, every niche and every one of you can get a sandbox for 30 days, I think. You have a free sandbox, just register with the red hat account, meaning put your email and there's details and you get this for free. And you don't need anything else to work with it, except well for maybe OC CLI or Kubernetes CLI, if you like Qubectl better. And just to do, to develop in here. And I think I already have things deployed. So let me check my deployment config is here. Hmm. They're all out and started. I'm going to start it myself. Um, oh yeah. I forgot to add a route. Now this is a way to add a route, but this is not the way that I would have added a route as a developer. So I'm just going to do this. I've created the route here, create route, no path, because I'm, I don't know much at this moment. So I'm just going to click create. And yeah, but as a developer, I don't like to use many click clicks. Sometimes. Oh, and my app is running. That's cool. It's not ready yet on everything, but it's actually running on my, on my endpoints and really, really available. Cool. But if I wanted to avoid using that create button to create routes, what I should have done is actually go here. My sec. Quark is that open shift dot route dot expose. True. This would have actually created the route automatically for me. Now what I want to share with you is that what happened in that deployment is not just like magic. Well, it's look like magic, but it's not that magically happening is more something that is generated from annotations. So you can find what was deployed here in target Kubernetes. So you can find what was deployed and it's securely deployed with a service account already done for you. This is using the right image pull policy, not present. So it's very cautious with the resources. And the DevOps persons know what I'm talking about here. So it's pretty, pretty secure and already done for me. This is cool. And also there's a Kubernetes version of it. So if you want to work with Kubernetes directly in Kubernetes objects, you can go ahead with that one. This is pretty cool. But some of you will say that, yeah, but I still have to do this. I have to go and copy and paste it somewhere in a file in a folder. So I can work with things later. And because, you know, something your DevOps colleague is going to say, yeah, you've done this, but is not having the resources defined. So your app is not very efficient in terms of and container and Kubernetes resources. And you're going to be like, what? So what you're going to do, and I've done this before, you're going to go to this place. And actually you're going to go to Google and say, Cube set deployment resources. And you're going to search this on Google. You're going to go to Kubernetes.io. Go to requests and resources. And you're going to copy this part here. You're going to look like it's correctly done. Identity under image. And you're going to go here and you're going to paste it. And you're going to say a prayer that maybe there's enough resources for you to deploy something. And if it's not, there's going to be a colleague that's going to modify it. But there's a better way to do this. Remember the sandbox. You can go to the sandbox and you can see how much memory and how much CPU your application is consuming. So if you can tailor the resources yourself. So you don't have to like wait and make assumptions and prayers for that to happen. So remember the memory part. So I saw that there were like 125 megabytes. So I'm just going to go to 150. And always the limits have to be bigger. So I'm just going to double it and the CPU. I'm just going to get it like this. But this is very Kubernetes oriented. So I want to make it a little bit more developer oriented. What I can do, I can go here. And say Quarkus that open shift. Eating voice here. And I'm going to say resources.request. So pretty much copying the hierarchy here. That memory. And I'm going to say 150. Then I'm going to copy again. And say a resources.CPU. And going to say like. This is for the request. When I'm looking to them side by side. I'm always careful what I copy. I'm going to make 300 for the memory to make it double. Because I'm lazy DevOps person. I would set up vertical point auto-scaler. And have those applied automatically. Yes. But we can debate about the virtual auto-scaler as well. And CPU. And then. One question I don't have. Because now I put my security hat on. And then the security guy comes. Hey, what is this image spilled on? So how can you define the base image. That this application is spilled on. So that we know what is running underneath the application. So you also have. I forgot to say that you get some Docker files. That are already. I mean, you get your Docker file. Your basis and everything where you're from. Is secure because well, they're coming from a trusted resource. They're not just getting randomly from Docker. So you already get that when you're getting that generated. From the website itself. So don't worry about that. And the rest of it you saw that there's a service account. There's all the world winding and everything. So you're not messing things around. Now these are for generating the request. So what this is going to do. This is going to generate the information here. My open shift. Next time I'm running my app. But going forward with this. If I'm going here. Some colleague is going to say like, yeah, but. I like to go into DevOps a little bit. And. I just want to, you know, make my own changes. And be able to, to work with this myself. And maybe refactoring your name this to. DC dot YAML. And have this protected because in target, all the time is going to be overwritten. So what you can do if you still like this way of working, like modifying yourself, the YAML, because. I've been used to doing that for some time. There's a way for you to test the animals. So you go to palm dot XML. And you're going to add a magic extension. Here. And I mean, just. Test. Open ship. I have. I have to remember how it was. Open ship. Test. Okay. Got it. I've almost forgot about it. So you add the quarkest test, open ship client. And what this does for you. It's a very cool extension. That you can go here. It can make your own Java class called. Open shift. DC test. I'm just going to go with. This naming. Yes, yes. I want to add it. And of course, this is going to be a quarkest test. But I need to add a little bit more flavor to it because I need to work with open shift. And I'm going to add with open shift. Test server. Whoa. What did I just do here? What this is going to do for me is going to be able to mock. And open shift environments so that I can test my resources there. So what I'm going to go next with, I'm just going to use the open shift test server annotation. Over my open shift. Open shift. Open shift. Open shift. Server. Not that server. This one. Come on. Open shift. Server. Yeah. Yeah. Okay. And then mock open shift. Tests. I'll call it a shift server, let's just add it here. And then just make a test method at test and public void, test DC from file. So what I'm going to do here, I'm going to use this string path and say the path to my file here is source, main Kubernetes, and I'm going to say dc.yaml. And then mock, I'll push a test server, I've got the wrong thing. Why are you getting this one close? Yeah, now I got the right thing. It happens. I knew that it was not the right thing. Get the open shift client, because I want to interact with the server via client and then get the deployment configs and load those from my path. And what I would do is, as a DevOps engineer, I would try to drive around things to see if they really work. So this is a test to check if my deployment config is actually going to work as expected. So let me go see how the run part is going. Oh, did this already run? It was very fast. No, this is a different one. It takes a while till it's getting run. And now we're waiting for the test to be run. What this kind of technique is very useful is to like to do the animals. So if you're that kind of person, please go ahead and do this kind of thing. And also, by the way, the open shift test client can be combined with open shift client, which is another parkus extension where it can be used for you to build Kubernetes objects from Java. But be careful when it comes to building Kubernetes objects from Java, because you should talk with your DevOps colleague might not be very happy to have things generated from your parkus app, although he or she can limit you when it comes to doing that. So what happened here is that I'm getting there. What happens is that I'm pretty sure it happened to you before. You're forgetting like a tab or something or you're forgetting like a space or a coma or anything. This can happen to anybody, but you can now use tests like Java tests to check that before we're actually going into deploying things. And now that we've done these stuff here, some of you are going to be like, hey, Anna, but some things are missing in what you generated here. I said, yeah, I don't have any health checks applied. So going back to the browser and going back to parkus, parkus, please. Why are you moving back? Now this is, okay. And just type in health here. And I'm going to get the health part. I don't generate again and just re-import the project. Come on. I don't want to overwrite my data. I'm just adding it via MVM. So going back here and adding this here. Adding the parkus more health extension, I'm just putting all what I need for me to make my own life in readiness checks. And you're going to find a customized life in this check in the repositories. So going back here, going to make a part. This is annoying. I'm going to refresh this one. And I want to show you some magic. I'm going to do this. And I'm going to keep tests. And I'm going to close all these and just open this one. Maybe see it change in real time and getting back to this one. So it takes a little while while it's being generated. Also this is going to not just make the generation, it's going to also push my image and it's going to deploy. So all the good stuff. Remember? OK, now it's cleaning and generating things again. All from here. And I think I ate. Yeah, I ate something. It's going to be fun, but it's fine. OK. So let me see if it's done. It's a good part missing. OK, build is successful. OK, Kubernetes. I'll push it again. And now your DevOps colleague is going to be very happy because you already have your live nest probe configured. And that's really cool. And also the readiness part already done. So really cool, only generated by adding an extension, nothing else. Of course, you can customize and you find that in the repo, your health end point. So be free to do that. And of course, your generated YAML is going to follow what you're coding in Java. So that's very, very important. And last but not least, let's have some fun with the mattering part of the application. And for that, I'm going to use my script. So let's copy this one and go this way here. I've created a small shell script. That's called ignite.cp. And what this does is that it's scanning for the properties directory. And sometimes it happens. When you want to deploy the same application code, you maybe have different resources. So you don't have to copy paste that application code and just change some resources. You can externalize that to config maps. So keep some definitions in your config maps. And you can make config maps from environment files on these properties files. And I would suggest if you're using OpenShift, that you use my minus minus from M for file, because that is going to put these two as keys in your config map. And I'm going to show you how cool is that. Then I will copy the information that's here in OpenShift.yaml and just change a few bits here so that I can make more deployment configs and more other Kubernetes and OpenShift objects so that I don't have to rework the YAML all the time. And then I'm just creating those objects in OpenShift. And I'm attaching each config map to each deployment I have. So let's start the joy. Just go here, say ignite.ch. Come on. Sorry. I made a small mistake. The OpenShift persons would have judged me for that. So now things are going fine and are being created as expected. So I'm not just using, I'm not doing anything manually anymore. Now I want to show it to you another cool thing, but I'm going to use the sandbox for that. So I'm going to go to my project. See, I have a lot of deployment configs here. And I have the config maps also created. So if I'm going to greeting app for Belgium, if I'm going to YAML, I want to show something to you. It's a very long YAML, I know. And managed fields. I don't know if they are removed in the Kubernetes version yet. When you wait long enough, it will unfold those. So they will be folded. So it just has to load the document first. Ah, OK. Thank you. But what you see here is that the name of my configurations are actually region and country. But the keys are different. It's Belgium and region and country from the config map country, country minus B and country from country minus B. So what this means is that I'm using different config maps. But my deployment configs will always see the same variables. And this is very helpful for me because as a Java developer, I go back to my code and I'm going here and I'm going back to my app. And I can save this global because I'm getting this from the environment, say global region and getting region from Kubernetes. And if I want to make sure that there is something there, if I don't know something doesn't get generated, there's no config map of something like this, I put C as a default value or for my local tests because I also have to test in local. And then country and get country and get here, I'm going to save Romania because I'm from Romania. And this is it how I can get environment variables that are available actually in Overshift. I don't have config maps on my local and work with it. I work with these in my Java code. So I don't even have to care how many of those will be there. And this can happen if you are deploying in multiple zones your microservice. So this can happen pretty often. And now let's use this config, make it an interface, global config, very suggestive here. And I'm going to use an annotation that I was really happy to see when it was released. It's called config map things. So this is replacing config properties from Quarkas 1. And this has the prefix global. And I'm just going to make two methods here, region, and string country. So this is how I can automatically map things from my resource properties, from application properties to another part of my app. And now we're going to configure the most important part, the common, actually no, custom configuration. Make it this as a class. And remember, micrometer? Yeah, we're going to do this and work with this here. So I'm going to just inject my global config and make my own common tags that are going to be shared across the entire application. Now, the common tags are very useful for the common tags for monitoring and seeing your app, especially if there are different regions where you're publishing your app. You need to annotate this with a singleton and, of course, with that produces. And this one returns metrfilter.commonTags. And we're going to give a list of arrays as list and just give the tags that I have. So I'm going to say here, country, config.country. And then tag.off country config. No, not another country. Yeah, region. Got the region. Big.region. And I need to pour the coins. OK, now let's close this one. And I think I have configured also the micrometer part from using external configuration. So I am keeping happy my DevOps colleagues who are working pretty happy with the config maps. And I am staying in my Java code equally happy. I don't know what the config maps are. So let's go back to the terminal and just make one last deployment. OK, I'm going to do this in the endpoint package thing with the test so that you trust me that they're working. So this is going to push and deploy things again. And if I were to just redeploy all the things with my magic script, I would have to go here. And since I already have some of the objects in my ignite, I will need to create the config maps anymore. But I will do this and probably I will do this to replace. But this is pretty much the way that you can combine the best of each world, meaning Java and Kubernetes OpenShift, all from clean Java code. And just a little bit of Kubernetes knowledge. I mean, just using the small things that are depicted in Kubernetes.io. Now going back to my sandbox, this is pretty cool place because you can see the topology of what you deployed there. So you can see all the applications. You have deployed. You can check how they're doing. If they're up and running, typically this bright blue here means that they're up and running and they're OK. You can also look about how much they're consuming. So you have a pretty good monitoring place. And Natali showed me this one. We just need to go back and remember where it was. Oh yeah, code ready workspaces. So thanks to Natali who helped me with the demo a bit. I can work with my code also in the code ready workspaces. So you can go here and you have your own in-browser workspace where you can just go and make changes to your apps. So if you want to do that, feel free to do that. Like if you want to go browser-based. And the only thing that you can do is just get a Git repo URL, for example, including my Git repo URL. And just go and modify that in your own workspace. And now let's go back to the presentation because I spoke about my Git repo, but I need to show where that is. OK. This is where you find the code. And please check it out because it has a little bit more things like a life-ness endpoint already configured. And try to check that one out and see how things are getting generated once you have that one in place. It's pretty, pretty cool. So everything that was done today is available there. And of course, if you spot anything that is not working or you would like to have it improved, or please do challenge me. I'm welcoming that. So pretty much over the time, I think. Yeah, we are pretty good on time. We don't have other shows in EMEA in our morning. So we can go beyond one hour, let's say. But we were pretty in time because we see lots of things there. I mean, there was everything. Yeah, that was oriented. Now I see that the next developer used a cool tooling. So what the developer is shipping is has to pass on the ammo files to the DevOps so that they can put those to the kit and follow GitOps. So there is still more gap between doing something deploying some development and then deploying to other pre-production environments and using proper ways to manage also the Kubernetes manifest as code so that you have an audit rail who has changed request limits in production and stuff like that. So is there an extension for that, maybe? Maybe an extension? Well, besides, I think there is something, the OpenShift client. But as you said, for production, I mean, I would say that this kind of approach works for just a starting and having a starting ammo. But if you are to go further, I would say to still talk to your DevOps colleagues because, as you said, production is different from development. So probably in production, things are going to look different. And there's going to be a colleague who is going to make another subfolder in that Kubernetes part who's going to say, Prott, I do not touch this. Please ask me about this because I know from my own experience that when you go to production, the resource split and the scaling part and the configuration part is not anymore something that can be touched by a developer. And typically when making changes to yamls that are going to even through production, you should check with your DevOps colleague like request a review on that one. So there is no shame in requesting a review on a full request when you're making changes on yaml that actually might affect the app. Things are a little bit different. I mean, there's still a separation in the specializations and what the DevOps colleagues will know to do better than us. But at least from the developer point of view, you're speeding up the way that you are working with Kubernetes. You're not needing to install a lot of things on your computer just to see that your app is up and running. And you can also have an idea how your DevOps colleague has guessed the allocation of resources. Because for a lot of time, a lot of people thought there's like a guessing game about the resources. There's guessing game regarding health checks and all these things. And it's not guessing game. There are ways for you to determine and measure how these things are working. So and I pretty much like to keep things very neat and separated also Kubernetes objects like you saw with the config maps. I really love just separating things into their proper objects and just using Java further. That was very, I'm shocked about how it's looking easy to start. You know, it looks very easy, but I think there is a complexity under the hood of many things. So you use the Quarkus generator, let's say, for generating the Pomex ML. And then you had an extension. And then you are the metering and deployment and config maps. It looked so easy to modernize apps. Thanks, Anna. Today it was. It's called Magic. It's called Magic, yeah. Well, every developer and every IT professional has his or her magic. And I want to say that for going further and making more complex and making live your own applications, you have to put your own magic, meaning what you learned throughout the years when using patterns. They still apply. You just have to adjust a little bit your practices and you'll see that you are going to be even faster and more productive when creating microservices and modernizing Java apps. Cool, cool. Thank you. And I don't see an additional question in the chat. There was only someone say that there is a new category on Twitch software and game development. Thanks, Peter. We will take note about it to reach out more people in the community. And I shared in the chat your repo. So the people can, doing the same thing, try to do the same thing from your repo. And with developer sandbox, they can use developer sandbox. They can use your repo and deploy and do all the cool stuff you did. And if they have any question, maybe they can ping you on Twitter on our Twitter. I don't know if you want to share also your Twitter handle. But it's in the slide before if you would like to share it so the people can ping you. And for this talk, I'm really, really glad to have this show today. Thank you, Hannah. It was a very cool live demo. I'm sure that also loved it because it's a super fun live demos. We've seen lots of things. And what we have today, if you stay on OpenShift TV today, we have the level up show. Has can admin. So please stay on OpenShift TV today. We have our common schedule. And we will come back. The OpenShift TV will coffee break. We'll come back on September 22. We will talk about Quarkus for IoT with the Quarkus for IoT community. So I would like to thank everyone that joined today. Thanks, Anna, for awesome demo. We would like to have you back when you want for another awesome demo. And with this, I just say hello and talk to you by September 22 on OpenShift TV Coffee Break. Thank you, everyone. Bye. Thank you. Have a great day. Bye. Thank you.