Jakarta EE JakartaOne Livestream 2021, 14 Dec 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Running Jakarta EE Applications inside Kubernetes with Nested Container Architecture | J1 Live 2021

Description

Implementing nested architecture of application containers running inside system containers while running Jakarta EE projects opens extra flexibility of resource allocation & management, accelerates Kubernetes clusters provisioning, and cuts the overall costs.

---
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.

Learn more: https://jakarta.ee/

Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/

A

Hello, everyone welcome to jakarta. One live stream, my name is ruslan siniski. I am cto of your chosen and co-founder of gelastic, which is a division of virtuoso today. So today we will talk about running, jakarta, ie applications inside kubernetes and inside nested containers.

A

Let me share my screen and we can start the exciting presentation great. So let me know if you see my screen yeah good, so.

A

Then, let's start the fun part now.

A

Great so jakarta inside kubernetes with nested containerization, we will discuss and actually do a demo deployment demo of a demo application which was created by reza rahman, and this project demonstrates how you can develop applications with jakarta using domain driven design.

A

So this project is available in git repo, so you can go download, it's open sourced and there is a nice documentation actually created by reza and other contributors. So it explains what it does like and near how how to setup it, and today we will deploy this project inside kubernetes. So I will show step by step instructions and yeah like we will see how cool it is great. So then we need, of course we need the kubernetes right to deploy uh jakarta, ae application.

A

So for this specific demo I will use kubernetes, which was um created by julastic. I mean kubernetes, build which was created by just in general. It's a similar builds. You can find on other platforms.

A

It has some prepackaged components inside right, but in general you can apply the same deployment approach to any kubernetes on any cloud because kubernetes actually promises to provide interoperability as well. So then, before I go to some theoretical part, I will initiate creation of our kubernetes cluster and we will use this cluster for future deployments. Yeah. Let me move it on, so I go to um just panel here. You can see right. I have some pre-configured kubernetes. I already deployed something there, but I want to create from scratch right.

A

So I can go to marketplace here and you can see like kubernetes cluster here or you can print like kubernetes and just choose this wizard and uh you can choose different versions of kubernetes. I will go with from this one um different, uh reconfigure dashboards again, a cable is just standard things like because specifically is not the focus for this stone, but more like how to deploy the kubernetes, and I will attach storage, some uh materials from grafana, remote api and jagged resin tool just in case.

A

If I use them later and I will choose region, I have a premium region which is a good performance, provide good performance and then we'll call it kubernetes depth environment. So we have like two different topologies like dev: environment production, their environment. It's like control panel and one working production starts from three control panel and to like a boxers and two scalable workers. You can change the topology later, but for speeding up the time like, let's start from the development environment yeah, so I initiated deployment.

A

We will need to wait few minutes till it's done and while it's deploying, we will go through some theoretical path part and to analyze. Why? Specifically, we use nested contingency, because this is something unique and interesting to understand that there is. There is a possibility to use nested container virtualization so before or we go to super specific details.

A

We know that actually many people know application containers, right and virtual machines so because application containers are popular, virtual machines are coming from the old world, um many customers are using them, and but there is something in between as well, which is called like system containers and, uh to my surprise, not many people heard about this, and many people knew about this, and it's really something in between application, containers and virtual machines here, because application containers they run like one microservice, while system containers, they can run like multiple service, multiple applications, so they behave in a similar way like virtual machines, but their density is better than virtual machines.

A

It's not as good as application containers, let's say like, but still they are significantly better than visual machines and who are the representatives of these technologies right like so, everyone knows docker, so docker is very good for application containers right, but for system containers we have like two players: it's chosen and lxc, and these companies are working more than 17 years of technology. So it's not something new.

A

It's already widely used, but it's not very, very well known for developers, because application containers was designed for developers, but system containers were designed it mostly from system administrators.

A

So the main difference between application, container and system containers is the following. So application containers they are focusing on one service.

A

The best practice phase that it's good to deploy one service, one application per container, so while system containers they can run multiple services, multiple applications pretty similar way. As you know, as we did in the past, with virtual machines, uh it doesn't mean you have to do it. It means you have a choice, so you can run the same way like application container one service inside or you can run multiple depending on your case, also system containers. They provide strong installation.

A

It means they are more often used in hosting industry for hosting heterogeneous environments, so I mean like applications that belong to different customers, because security is good enough to put the workloads from different customers of the same infrastructure. So it's hard to break is a patient um yeah. Also.

A

There is no layered file system by default, so you can apply, but by default there is no very fast system.

A

Great and let's compare our virtual machines and system containers like why we love system containers, because we can easily replace virtual machines by system containers so, for example, this deployment of kubernetes uh inside virtual machines what we have like we have inside every uh kubernetes node, where we play like kubernetes. Now we have like gastrois right and this guest yes consume resources, while if we deploy kubernetes node inside system containers, then it's possible.

A

Now there is no guest res because they share like the same host operating system in the same kernel. So container agent is managing this continuous, so density, I mean utilization of resources.

A

In this case it will be better it's more efficient at the end, and now, if you deploy like, let's say, multiple visual machines for one uh host, you can see the difference here, like usually virtual machine if it doesn't consume all the resources right like we have like different examples here like, for example, this one it consumes. This.

A

From some visual machines world these resources in the most cases, they will not be shared with other virtual machines, so it means uh they will be staying in this virtual machine and you cannot deploy anything else so because they will be reserved for this specific virtual machine while with containers uh same example right like so. First of all, we have smaller overhead because we don't have guest os inside this virtual machine and second these resources. They can be shared with other containers on the same host because containers they by default share resources with other containers.

A

And now, if we think, like you, can sum up, everything like you know overhead resources in use and reserve, but not used resources. You can see pretty clear difference here right so on. The visual based host virtual machine based host first of all, like overhead, is big right on on the whole infrastructure. Let's say like you have a hundred host machines and then it will be some part which is reserved but not in use, and you cannot reuse this part.

A

While if you deploy your kubernetes inside system containers, then first of all overhead will be much smaller and you still can reuse unused resources. They will be available for additional workloads or for vertical scaling of the existing workloads.

A

So as a summary again like running grenades inside system containers, you know, first of all, it behaves in the same way like you're running inside virtual machines, but secondly, which is even the most important. It provides you better efficiency, but it improves your total cost of ownership.

A

So you can save money and then additional benefit of containers. Comparing to visual machines. That vertical scaling is much easier and faster, comparing to virtual machines because, for example, if you create a virtual machine like say four gigabytes of ram right on one of the public cloud providers- and you want to add a little bit more, it's impossible. You have to provision twice bigger machine, so you cannot add just one more gigabyte of ram some cloud vendors.

A

They offer this, but I'm talking about the majority majority, not because it's not an easy operation and they just provide specific flavors of virtual machines and uh yeah. But while with containers, if kubernetes is running inside containers, you can always adjust up and down the size of this physical of this system container. So it means.

A

If you need little bit more resources, you can always add, and you can always adjust on the fly without the need to reprovision this virtual machine or like system container. So as a summary containers, again like it's easier, cheaper and faster, like scaling vertical scaling.

A

Great now coming to the limits uh you understand, like some complexity here, I wanted to emphasize complexity here right, so we need always to think about the limits we configure inside kubernetes and inside containers and inside our application.

A

Specifically, so we have pretty simple situation when we have kubernetes nodes, this kubernetes node by itself has not limits right, so you allocate like 16, gigabyte of example, and then we have like application container inside kubernetes now, which you define again like some constraints as well like container statements right and then you have java application inside which has its own limits. You usually specify like cmx, and you need to fine tune all these limits, so it works properly, because if you don't do it properly, it might happen um following like.

A

So this is a good case like when you fine tune like it more or less consumes the same developer resources itself, but it might happen the following that you have let's say container right, this gray, one but and red one is our java virtual machine and for example, if you set wrong limits, so you set lower limit than limits of container. Then your application will never be able to utilize all available resources for inside this container.

A

So we call it like um over allocation form of resources per container right, and another issue might happen when you put other way around when you put limits of your java virtual machine higher than limits of your container, and it's pretty is pretty dangerous situation. So in this case you will may lose some resources. You know under utilization, but in this case you can get out of memory kill event, so your application will be killed and you'll be downtime.

A

So no, but setting scaling limits for gpm. It's not just 13 xmix limit right. In the most cases it is, but still you need to understand that java can consume more. That is define it by xmx and it's defined by heap size.

A

So you need to take into account number of threads that can be possible run inside this gvm right, so that the number of threads multiplied on some amount of memory per this thread will consume memory, and also you need to think about metaspace, where java gm keeps let's say, working data like metadata about objects. Inside the heap and other data, that's necessary for operation of gvr and another one which is max direct memory size where sometimes people store data, not inside xmix.

A

They store data directly in native memory of operating system so for for better performance, let's say like so or they don't want to involve garbage collection collectors into the process. So at best guys you know who know how to tune all these limits. They understand all these points just wanted to emphasize this. You know. Sometimes it can be tricky great and let's come back to our demo.

A

Oh yeah, we have our kubernetes dev environment right, uh we have like one control plane, uh we have storage and we have like one worker. uh We got usually in insulastic, but mostly in all other platforms, you will get some additional credentials. For example, in july we create like this board with the players by default, so we provide you talking and you can go inside and see like different things here, like you know, demonstrate and jobs. You know just just basic stuff: ingress controllers, for example right, and there is also ability to go to prometheus.

A

A

Yeah so promoters, and let me actually open also.

A

It's loading, so prometheus is available now right and now grafana.

A

We provide some reconfigured dashboard as well, where you can track consumption by.

A

By different just cluster, for example, right by cpu, an input usage memory and so on great so before deploying let's do quickly vertical scaling of our worker because for now, actually you can adjust apology.

A

Let me adjust the apology.

A

There's something wrong with my internet. Sorry guys it's just! I am in the hotel doing demo from.

A

The south cluster and yeah we can have. Oh, we can check scaling limit vertical scaling limit. So this is our kubernetes worker node and we can scale this up to let's say like a gigabyte of frame right and apply, and while we are scaling our worker, I can go to control plane and then yeah by the way our limits were adjusted. So, as I've mentioned before, like we can adjust the limits on the fly without the need to recreate the working, it's pretty quickly easy and fast right.

A

So, but now, let's do the actual deployment of our jakarta application, which is called karma tracker. So what we do. First of all, we check like inverse controllers yeah because we deploy some hello world. I don't want this hoverboard to be open and check it right. You can see like hello, but I don't want this hello world.

A

I want on my cargo record, so I will delete this english controller and now we have cluster resolving this controller, and now I need to clone my git to my repo, but before I do it, I install git client yeah. So what I did just to show you here so I just did install uninstall, so we are working inside the center s or a specific operating system. The common can be different, but I believe we understand the general approach.

A

Now we want to clone our project, uh which is located here right, julastic architecture, we just forked and did some minor adjustments yeah, and then we just clone this.

A

Almost done so good, so we go to america inside.

A

Great, so we have all these nice files- okay, great.

A

So let's click on the screen and now I will apply postgres secrets to my application right so to you like for storing uh database credentials, let's say right and then I will apply another yaml for creating the database.

A

So this cmos, if you can find them here by the way, they're available secrets here right just again as it's a demo, so you will have your own, obviously like you have to change it, but for demo it's it's it's okay and postgres.

A

So we create some database that we will use in our demo and then, as the next step, we will deploy payara application with payara docker image to port with two replicas.

A

So like this done, and you can go and check what is inside here, let me show you yeah. So all the apple is available.

A

Here, great and now we want to check the status of our deployment so just for testing. We can see first of all secrets what kind of secrets we have here right and we can also check status of our deployments right. So you can see we have like two replicas of cable tracker and just in case we can check services right available, so that was so the all steps required for deployment of our ducati mdm application.

A

And now I can close my console here and I can open uh my kubernetes. So you need to wait some time because the application is starting right. So, let's refresh yeah, it might happen. Actually it happened before like. So we need to give some time like for this application to to get up and running.

A

Yeah but before it starts, so I wanted to show you on something else: about um resources.

A

For example, we change resources for our working right uh by the way you can see it's deploying here like so it's in progress now, uh because the cpu consumption goes up and memory consumption is go up right, so the kubernetes is deploying the application um still so, but in in a couple minutes we will get it up and running.

A

Okay, cpu goes down now, so probably it should be already.

A

A

Yeah, I I believe it will come up so you're. Coming back to this limits you can see in this cluster. We have is this working out. We have like eight gigabytes and um consumption is still growing up right but, for example, let's think about production cluster, where we have like three working nodes right and we have, for example, 16 gigabytes per each node right, 16, gigabyte and altogether uh we have like 48 gigabyte per three nodes and real consumption is only two gigabytes.

A

So this is what I mean uh meant while saying: okay like there are some resources that are not utilized and the good thing like we have system containers. Why? It's? uh Why we like them, because all these underutilized resources they can be shared with other containers so but they still again like they still be available for you. You can get them immediately, but because we have like pool of resources always available, but you can really improve density and efficiency at the end.

A

A

It's very strange: I was working before see one once one more time.

A

Yeah we have like two cargo tickets.

A

And uh yeah services kind of attractive was.

A

Very strange, okay, let me deploy probably to production like so something happens with this one. We will come back to this one later so yeah. Let's do it in this cluster control plane.

A

So I will just repeat the same steps one more time. So, first of all, I want to check my english controllers right and then I delete hello world and then I install git.

A

And then I will clone the git.

A

Almost done 90 percent, maybe all right.

A

Now we come inside karma trekker and then a demo effect. What you do we apply secrets and then we apply postgres create database and then we deploy.

A

Great and then we can do uh status check deployment right, so you can see um they're not ready, yet uh we will. Of course we will need to wait till till it's already, and you know let me oh no. No, I really don't know likewise like this.

A

So our production is ready, but I believe again like we need to wait a little bit more uh and before we check the status. uh Let me show you again one one of the interesting differences of this community's deployment. So, as you see here, we have a consumption statistic right and the real consumption is very low. Comparing to the limits and the good point of system containers, they enabled us to offer real pay-per-use consumption.

A

I mean billing model so what it means, uh as I mentioned, with virtual machines when it doesn't matter how much you use inside, like you always pay for the limits with system containers, it's possible to introduce a better impressive model which is based on real consumption, uh because all these resources, as I mentioned they shared by default like it, doesn't make sense to charge people to charge in customers for these resources right um you, you need to measure and real consumption and uh introduce a real pricing.

A

So we call it pay per use yeah, and it looks like this. Sometimes you need this resources, and but sometimes you don't need them at the end. Billing will count only real consumption. So but please be aware that paper used, it is not equal to pay as you go. It is not equal to pay as you allocate. It is not able to pay us your reserve all these names.

A

They are able to pay for the limits not for the use, and it's easy to understand like this usage model like if you go to linux and you print like three minus m, you will see a real used memory right. So there is a specific word which is called like used so and when people, when somebody says like paper used, it should mean like pay for exactly this number like for this parameter, not for the total available resources, and there is some or let's say, confusion right at some cloud players.

A

So, for example, amazon says, like you, only pay for what you use as we use it, but in reality, when you go to to a portal inside, so they clearly stay different to think like they say, like your ability for the task, memory and task cpu allocated not for the use, so you can choose how much to allocate and you will be build it for allocation.

A

So again like uh coming back to this slide like this is the allocation, and this is a use so and same actually with google like. I don't know why these guys are confusing others, but they say, like cloud run charge you only for the resource you use, but when you go inside the cloud run panel, they clearly state like memory to allocate to each container instance. That's not used like it's allocation so and the differences can be huge like so we tracked the difference between real consumption and the limits across.

A

Let's say: 100 data centers around the world and you can see like the difference, can be like four or five times so people usually put higher limits than they consume. It's a lot of money at them like, so that's why system companions are very useful for kubernetes.

A

So let's go to the demo and check our deployment again. I have a hope. No, this one doesn't work for some reason and hopefully this one will work.

A

Guys, I'm sorry well, I will have to follow up and figure out like why it's not working just before the demo. I did the deployment and it was everything fine strange like, but we have all this deployments here.

A

Today available 11 minutes, I'm not sure. What's going on.

A

I apologize like it's. It's very pity, yeah, but again like these steps, as I mentioned, so uh they should result to a successful deployment like so at least it is inside here. um I'm not sure like why why it's not available now good.

A

Pt uh so guys, so that's I believe, for in short, what I wanted to present like again, like I'm so apologized that it did not work like I will figure out and follow up with twitter. It's the first time like I. I have such kind of inconvenience during the demo, but you know sometimes demo may not work. I don't know why, like so, I will double check it.

A

A

So guys any questions, so if you have please let me know.

A

No question so far: okay,.

A

A

Yeah there is a description on how to.

A

How to build this application and yeah.

A

Good guys, so I will wait for a few minutes for questions. If no questions, then I will follow up regarding this demo.

A

Yeah, what we have actually something.

A

Oh maybe check in cognitive yeah. That's a good point. Let me see.

A

No, it's super lucky, but I don't like it. It was really working before the demo like, so I will have to debug it and figure out what the problem is. It was working in the demo.

A

Oh cargo tracker- oh my god, like your ceiling, so this one by the way it's a it's a cache in production, but um our dev cluster should be uh as well like this. It should be available. Let me see.

A

This one is hardly clear, but so our production cluster.

A

Our production cluster.

A

Yeah, so that's um get deployed cargo tracker and yeah administration interface. You can see here it's just again like simple demo example: books.

A

Dashboard live, so you can print something and check. So, if you can, if you wish to help this project, you can participate uh it's in the contribution to this demo application. We can expand, it, extend it and make it even better yeah, but in general it's a good start starting point and again I thank you reza from contribution for creating this one, so people can can start easily great guys. So again, I apologize for the some issues and yeah have a good day and enjoy the rest of the event.

A

Thank you. Bye.