Piotr Malinowski: Write Once, Run Anywhere? Building Perfect Docker Images for Java Apps

This talk focuses on the intricacies of building Docker images for Java applications, emphasizing best practices for ensuring they run efficiently across different environments. The speaker, P. Malinowski, shares insights from his work at Revolut, highlighting the importance of leveraging Docker to package applications effectively. He explains the evolution of Java's deployment methods, including the concept of 'write once, run anywhere' from the mid-1990s and contrasts it with modern approaches such as Docker's multi-platform capabilities and image optimization. Key topics include the use of build packs, the configuration of Dockerfiles for optimal performance, and the significance of understanding image layers in reducing startup times in high-traffic environments like Kubernetes. The speaker also addresses practical challenges related to the size of Docker images and advocates for using tools like Dive and Jib for efficient image building and management.

hi folks so welcome to the first talk that is not a panel in the language track and uh we will enjoy now porra and talking about the nitty-gritty details that you need to keep in mind when you want to build a Docker image that really runs everywhere uh because as we know uh containers run everywhere but they don't as we will probably now EXP experience so enjoy

and have a good time hello everybody so before like we dive into the presentation question number one to you guys do you use Docker containers can you raise your hand okay um who is not using Docker containers that's interesting but like 99% is using it right so I think the topic is important and and who is using Java again okay you are in the right place thank

you okay my name is p malinowski and I will be go I'll be talking about Docker images um so shortly about me uh I work at revolute uh I'm a Java engineer and I I did some research about my past recently I just checked out I just started with Java number five a long time ago uh and I was traveling through a lot of framework Stacks uh

also I was uh I was doing some devops tasks related to Brer and kubernetes and open ship all the stuff in the past uh right now I'm in revolute we what is special about revolute uh is that we don't use spring in revolute but we use uh Java a lot uh and what I do I do actually at revolute is that uh I work in a team

called money health and and this team is uh is generally about helping you spend your money Better In A Better Way basically to just waste your money less uh so what we have here uh is there a few screenshots from the applications but um um I'm the person that's behind those features in backend but what we do is actually we help you by providing you some statistics

about how you spend your money and statist statistics on the various categories we also have a nice budgeting functionality that I really like to use myself also I'm a I'm a customer of of Revol at the same time uh for a long time so uh and besides you know the the category management we have uh in revolute there's much more that is going to happen and we

have very ambitious plan so uh I'm inviting you guys to apply to revolute it's also that we are a sponsor here and we would like you to have you board uh but from the engineer point of view what is really like the most interesting part for me uh is the challenges we have at revolute uh related to the scale of revolute right now we have about 40

million customers uh and it affects us a bit you know and the traffic it's kind of a normal day traffic you know uh it's taken from the one of the of the monitoring tools we use I'm not sure if you see the number there but it's 80,000 uh uh requests per minute it's quite a lot and we do it in like in the Java back end uh

okay going back to this uh the topic so the first thing that that you will get when you put the topic of finding best docker images for Java application and you put it in the Google that's what you would get and well I could end this presentation here and well but we I hope that I can explain later on uh what is possibly wrong here and just

to um remind what is that that's a Docker file and and because it's a Docker file uh it's a very short Docker file by the way with their inheritance with copying the the jar file and with the command that runs uh Java application will it work basically it will work uh so we could end up with this but that would not be a perfect Docker image uh

also another alternative that would like is fast and could work is this command this is a Gradle task called boot buil image the task that uh spring boot have uh and again you could but in during this presentation I would like to explain what's happening here and how you could configure this stuff that's really heavily influencing the whole Docker image being created and last but not least

uh probably that's too small for you but the whole idea about this presentation uh is is is taken from when I joined revolute I got the the Mac M1 uh laptop and I was trying to use some uh Docker images uh with Java applications that we have uh in backend and when I started running those doer images I realized that the startup time Java application in Docker

is about like 30 seconds and I was like I was surprised because I always thought that Java uh well that Java and Mac M1 this is a good match and it should be fast but it wasn't and I will try to also explain a bit what's happening here why this it is so slow here okay and then but before we go into those details of the docker

and Java I would like to take you uh invite you for the time TR TR and we will go to the year 191 1995 uh because that's the title of the presentation right once run anywhere and uh this is pretty fun because I didn't know about it earlier that's the marketing term used by by sun when they released Java 1.0 in like end of 1995 1996 and

already at that time then when Java was created that was the big thing that was something that was special for uh and if you read that uh that news from from Sun uh you can already figure out there's there's uh there is a catch so generally of course the idea of right once run everywhere sounds good but they already say in that news information that while you

can run it everywhere but on Mac OS it is delayed okay so all right and uh I have some diagrams from the past and they look like that they are from the past and it's that's it's that's on purpose uh this is these are probably original Sun diagrams from the 990s uh and if you look at it uh but it looks very nice basically I mean Java

is is a programming language that we use a lot and we don't think about the basics and here the but I have to say it again the idea of WR once run anywhere it's takes originates with the idea that we have a Java program let's say a file with class that it's transformed compiled into some bite code or Intermediate Language and then this code is run by

the Java virtual machine so in order for you to run the application well you need to uh just switch the jvm you know that's as easy as writing a new jvm for the given platform uh so you could do it um that's pretty nice especially if you compare it to the competitors at that time to C++ for example or C or any other language that had to

be compiled on every platform every time you would like to run it um but this is not everything and it's not enough for uh write once and run everywhere to be working so uh on the previous slide I was showing you the the Java program that consists of just one class but in reality we have of course a lot of classes right so the engineers from Sun

had a great idea that uh in order to run the Java application well we need to pack it into some kind of package right so they they created jar format it's from 1997 Java 1.1 um and this format is very simple it's very nice it's just a zip file with Java classes and some metadata as simple as that but will this work that H well it should

work right but it does not work the problem is the problem is with dependencies if you have a application that does not use dependencies and I can I'm pretty sure that nobody have that application everybody's in some dependencies right then that we have a problem because you cannot have uh there's no way of having dependenc dependent libraries in a jar at least in 1997 but again this

was not working well you could do some magic but you could not have dependencies inside the jar so of course people were smart and they decided okay in order to to be able to do my Java minus jar we go into something called jar hell we take all the jars and we can approach this problem from two different angles one is called fat jar and is a

very standard approach everywhere another one is called Spring executable jar format it's more sophisticated and spring boot is using it it for you um and the so the the fat jar is very simple because it just takes all the dependencies unpacks all the jars and put them in a one one big fat jar uh with spring exi executable jar format it's not like that we put jandes

directly in jar but this requires a custom class loader so whenever you spring and spring boot you will have a custom class loader that handles this external dependencies uh loading for you uh that but again we now have a big jar that we can run but how we would like distribute it because I mean originally there was no idea of how we could distribute the Java application

there's no like installer or something uh so that's the maven Central 2004 and you could put in the maven repository of course a lot of libraries but you could potentially also put applications there uh plus don't do it it's it's not suitable for that but you could do it and I was doing it long time ago uh by dist distribution was working this way that we've been

uploading it those Java applications to the maven private repositories and then they were like downloaded by uh by the apps running somewhere without Docker but we can do better and the whole idea of Docker it's 10 years later than than 2004 uh they have a very similar marketing term to what Sun used is just called build once Run Anywhere uh but Docker goes a bit further because

Docker is not just uh the ability to build and run doare is also about distribution of the software that's why I was trying to like show you the full path for Java we have taken you know we started with a compiler and jvm ended up with W here Docker is is something is a set of tools for the whole life cycle and of course Docker is not

just for Java it is for every uh possibly every programming language and every code you could run uh so but there is also one important information here because in in 2014 this devops movement was getting more and more attractive so the idea of shipping faster uh was very important and still is so and they recognized that the idea of taking the app with everything not just with

dependencies but with like operating system and and let's say jvm and pack it together so the idea here is it goes beyond far beyond what was there for Java and that's why I think also Docker is so successful because it handles it very well and eliminates this friction between environments um again architecture diagram very simple one from 2014 these days I have to just say this is

not exactly like that but for this presentation that's not so important that that that the docker has progressed so much so we have the docker host we have client that runs those commands against Docker host and we also have a Docker registry where all the images are stored and the central part is image but in fact when you run the image it is turned into a um

how you would then deploy those things on the left you see the traditional deployment model uh on the right you see you see the kuet you know let's say current model however in reality these days kubernetes is not using Docker internally okay it's a different runtime it's totally not totally but it's a different stuff uh but Docker has like started the whole idea uh so this is

still valid uh so we have moved actually the deployment of apps from the standard tradition app like leaps operating system separated into a container deployment uh which uh allows us to just do it more repeatable way and faster and more effective um but then uh if we are going to to dive a bit deeper into the docker I think the most important part here is how we

build and how we create Docker images uh and this is U the explanation of how the how the docker image format is created and it's pretty smart uh those things on the left are the latest edition I mean like two three years already um so-called manifest list this is a new thing but whenever you would like to download a Docker image there is a lot of uh

HTTP calls that need to be issued to get that Docker image for you so the first thing you do when you would like to reference or download the docker image what is the reference like it's like ready call on latest for example that's the reference to Docker image it could be longer but generally that's that's a short reference uh when you would like to get that image

you need to find the the Manifest list for that image first then you choose the Manifest for the given platform you are interested in uh and if you have this Manifest this manifest consists of multiple layers uh and the the layer itself is just an archive pretty similar to what jar is but here you have a list of layers it's also important it's not a set it's

a list the ordering of layers is important uh there's also a config that's associated Json file uh that like describes the how to convert the the image into a running container uh the the important part here also is that both layer and config have a field called digest because what Docker is using it's something called it's called Uh content addressable storage so whenever you you have a

layer it has a digest and you get that digest that layer but by the by by digest not by ID or whatever anything else but the digest is the it's the same time the ID of the layer and this is a good thing because it allows us to reuse layers uh and it helps us to reduce the the image size and of course uh it's just uh

the networking that's uh less being used um but there's one more thing that actually or even two things that are not here on this on this diagram that's the standard but if you try to like understand what's exactly here and what's what what's how it works you will notice one thing in the first place there is no Docker file here so if you just study that these

are like I didn't hide it anywhere it's just that's the reality Docker file is not a part of the docker image Docker file is a recipe for the docker image it's not the content of the docker image uh another thing is that in Docker files you have the inheritance basically when you write a Docker file you inherit from Docker image some other Docker image you write from

and you provide the base Docker image in in reality there is no inheritance in Docker images but whenever you provide the the docker file with the recipe to like inherit from something it means that the docker image itself will contain references to the two layers from the base image but there is no information about the base image uh in the docker itself just an example here uh

I took some Docker images just to just to show you how exactly looks it looks like um so this is the Manifest list for Eclipse tamarine jdk uh you can see there's a little list of manifest for different architectures so we can choose the Manifest uh then uh you have the specific manifest for this time is for amd64 with the size and digest so we you are

able to download those layers uh by digest um and the config this is something probably that you see in some tools um that can show you the content of the image okay uh the first uh first demo is the there will be a lot of tools in this presentation uh it's got a tool called Dive uh it's a very nice tool well UI text but UI uh

that allows you to go into a given Docker image and check the content of it so if you are unsure what takes why the doer given doer image is so big you can go there and check you can figure out what files have been what are the what is the content of every of every layer how many layers are there also Ive can show you some in

like analysis of the image so we can like go through that and and check what's happening uh um since we have already let's say agreed that we don't need Docker file uh and we know the docker image format then we can start building those images finally right and uh in this presentation I focused on three ways of building Java applications with Docker the first one on the

left you all know that prob I believe you all know that it's called classical and generic uh Docker build or Docker buildix so we provide the classic Docker file and you have a Docker image as simple as that the other way the other one uh it's called build pack I call it magical I call it magical because it indeed does a lot of work for you and

you just issue a command and it kind of works uh but in in in in details that's a pretty also interesting way to build a Docker image and this is something that you probably do when you use spring boot because uh spring boot is using build packs to build uh Docker images and the third one on the right uh is a very Java specific way uh it's

a Google library that allows you to build Docker images as if it was an archive not the we don't need Docker to build that image it will just create those archives add metadata and will allow you to like just create a Docker image without any uh containers involved to build it so this is a different approach uh I also find it quite uh going into the docker

file so um I have updated the original example a bit by adding some stuff that might improve the image but in fact the docker file as as a language is pretty Advan well it's easy but it has a lot of things that you could do and because of that freedom you really need to be a very proficient and understand all the all the best practices to do

it properly so one of the things you should probably do is add labels to the image another one is you should provide the for multiplatform support some information about AET platform generally it is welln it's easy it's simple it's fast you can do it like that but there is a catch if you see here we are running the image contains itself a layer with the application and

this app jar is a so-called fat jar so it's like a very big file one big file and that could be a problem uh especially for bigger apps uh how do you how do you run it you know you just use common Lane right not nothing really serious Happening Here uh but um I use this spring pet clinic as an example so I would like to show

you that these things actually run in reality and they work and it's not uh nothing that we should be worried about but if you look at how much time it takes um yeah it's not it also takes time and here I'm uh building this Docker images first for arm 64 and Le next one for IMD 64 uh platform so I build it twice and as you see

I when I build it twice I build it twice there's no caching I just need to rebuild it spend twice as much time uh then again this magical uh a very interesting project called build packs and so it's it's a big topic is a lot of documentation about it so I really recommend you to just go into the into the documentation and find out what can be

configured but just some of the like summary about this tool is that first of all it's a standard part right now of uh spring boot boot build image stuff H it has a lot of nice features uh it uh is configurable it is extendable it is quite slow how show it later on but it has cach that should work and also it is multi-purpose which means that

it works for Java but it can work also for any other technology and I think myself that this is really cool because uh if you are not an expert in a technology some technology buildpack can just build quite a good image for you you just yeah you can just point that the buildpack at the source code of that application it almost automatically will build your Docker image

so you can run that application without even knowing technology um and how pack works yeah well it works with the pack command uh and it of course starts with a jar file ex again it takes a jar but it does some magic to the jar and uh creates the docker image by looking into the jar detecting what's inside finding some metadata and creating like downloading the jvm

for you and everything is like kind of automated can you get you can configure a lot of environment variables that will allow you to just uh find unit even further uh then we have this Jeep thing um which is um it could be Comm on line but I'm using it as a gradal plugin uh it's very configuration and it will also uh I would say the biggest

difference is that it is uh not using jars at all the idea here is different you compile the code and as as like a final step of compilation you just let's say assemble the code into the into the G file into the docker file instead of assembling it into a jar file because after all a Docker file is a set of archives right uh doer image set

of archives so um that's a a bit different approach which end up it's which is fast and ends up with uh the target uh Docker image uh and jip um as again some short demo how you can configure it I use the starine base image because it supports base images as well uh you can provide on which platforms it will be built and it will just build

the image very quickly and then it will upload the image either to local Docker regist or the docker regist that's not that that's not uh local okay but then um so we have those three tools three ways of building images and how we can compare those deer images how to choose which one's better right so the first tip uh you can figure out and differences by using

dive the to I've shown you in in the beginning it has a very nice Json output that you can like create diff from so here on this uh on the right side you will notice that there are two layers that has been affected uh and like the layer on the top the digest has changed so the layer changed the the layer below number eight digest didn't change

but the ID changed doesn't matter ID we don't care about it also there's like a Google to Tool call called container div it can compare and list you differences between Docker images so that's how you can actually spend some time and figure out what's inside and going further into the image best practice there's a lot of best practices and maybe even too much uh to remember so

what I would recommend is rather focus on few of them and in this presentation again I cannot tell you about everything I wrote here but I will focus on those blue ones okay uh even though of course the others are important so for example you should be running you shouldn't be running Docker images as root this happens really believe me uh you should name the images properly

uh the image itself should be traceable which means that should have reference to the pipeline that built in the owner and so on uh and of course it should be small and in the end everything should be fast and simple right so there's a lot of those best practices but I have to just focus on a few of them uh so I go with multi-layered approach because

I introduced those tools to to be able to compare those tools right so uh and choose the one that fits the whole building process in the best way uh so um and here I have this three tools and this there this is the image layout uh for those tools starting from the top one uh with build X you we have six layers created uh with the biggest

layer is the jvm itself uh similar with jib but uh you will notice one significant difference uh with BX there's like the top layer uh is just the fat jar it's one big layer it's a fat jar uh in jib we don't have a jar we have it we have the Java code separated into two layers there's like libraries layer and very small one application layer so

the actual classes of the application then we have pack which introduces build pack approach which in introduces 21 layers some of them are really small uh of course like the the biggest part of it is the jvm the the JRE uh but uh again we still have separated libraries from the Cod application and there's also like a special layer for resources like resources uh plus some other

stuff that uh uh is a part of the features of the pack okay but what would happen if I do a small code change how this layers would how the images would change if I make a small code change let's say I don't know I add a new class to the or it's a small that's not a small code change change a string somewhere right then uh

when I use build dig I will have to rebuild the whole fat jar so I will invalidate the whole jar and I will invalidate the whole uh layer I will have to create a new layer and it's possibly hundreds of megabytes uh with JB pack the small code change will just result in a very small layer that is changed and invalidated what what what it means it

means that if I have invalidated just one small layer the the docker push command will be much faster because I just upload the changed layer also the docker pull command will be much faster as well because I just changed a very small layer and every other layer is already there on your machine so that's is something to just remember that we can uh improve the download Time

by using multi layers but there is of course a catch so generally what you have already might be just good enough and that's it that's it and maybe we should not be take care about it because it's working fast enough another thing is there's a principle called separation of concerns and from that standpoint I think we should consider creating multiple layers and every layer is like responsible

for a different concern uh but if you would really would like like to dive deeper and have the best possible image then you would probably need to do a frequency analysis so for example if you have just some libraries that change more frequently maybe they need a separate layer and you could do such a magic with Jeep and pack you can specify uh exactly which layers should

contain what okay maybe that also there's a common discussion about whether we should build minimal images if that's that's the best way to like deal with uh with with with tocker images and I must say that in my opinion we shouldn't uh because I I I checked the the the content of the docker image standard Docker images I I also compare this across a lot of components

in revolute so in almost everywhere like 80% of the docker image is both the jvm and Os base and the the operating system dependencies that's it that's 80% and and then libraries of course and application code and you can see that application code is like about one less than 1% of the whole Docker image and and application code is something that probably changes the most frequently um

especially if you deliver uh frequently so from that standpoint it seems that the jvm and Os does not change frequently so you just download it once and you just reuse it and reuse it and reuse it over and over again okay uh so my opinion we should rather focus on consistency and reusability and have a good standard in your company when to use the docker image uh

same Docker image in multiple places for multiple components and that's a very good starting point so have this let's say we have Revol Java it's 500 megabytes it's bigger than those um public uh images however we everywhere okay going into the multiplatform thing uh so one of the topics from the beginning of the presentation uh so first of all do we multiplatform and I thought that not

really we've been all using Intel processors for many years uh even though Java started with like spark and so on but we forgot about it we've been using Intel everywhere but now we have those Mac with m1s uh and there is even more things happening interesting things happening in the market of servers and Cloud providers that they are starting they started to provide uh machines in the

cloud that are based on arm processors and this is pretty cool and pretty fast and cheaper than than Intel so what's blocking us from using this opportunity and run Java on arm well what's blocking us well not not multiplatform images are blocking us so we should my opinion invest some time and build multiplatform images not just for local development but try to doing it also for the

cloud uh how you can do it the simplest possible way is to use theer build dig you can specify multiple platforms and this will run uh it will take some time unfortunately but it will run if you look deeper into the M multiplatform feature uh this is something that was added you know quite recently to uh Docker is that you can actually build on every CPU you

can build almost every on for every platform it's called cross compiling but um in Java World it that's not make sense but the idea here is that we are using the feature of Linux kernel that allows us to register so some Handler for some binary format so whenever you run let's say a Docker image Docker container on your laptop and it's aimed for a different processor than

you have the qm will be used and this is the explanation why the Java startup time I it was so huge because I was not using my processor I was using emulation and it's like 10 times slower at least 10 times slower uh to run such application so be careful about it you can run any Docker image almost on every platform but this will be emulated and

this will not work as you would like it to work uh by the way how you could find the image platforms these are the commands you could use uh all of them they will show you the information but in a different way uh so yeah so you can check it uh and then uh I also did some Benchmark I said okay maybe we should you know everybody

would like to have the F the fastest possible build P pipeline right so okay let's try those tools and check uh which one's fastest and what I realized is that even though pack is slow but it's like I don't know 15 seconds difference so for a bigger application probably it's just doesn't make that's not so important in some cases it could be especially if you would like

to build multiplatform images then you have to M invoke this process multiple times so then then you can think of using Jeep or even Docker buildig uh because it's much faster than than using build packs okay the next thing about best practice especially for Java is you know how you run Java in uh in doer so what parameters you should provide well that's the real real example

from the apps we use that we configure in revolute like 80% probably of of backend components have that that setup or very similar so the one thing of course this is like huge topic again the thing that we should always be thinking of when we run things on Docker either it's locally or kubernetes or anything else that uses Docker is to set those constraints on Java uh

the ram percentage that's being used all by Ja it's Bram percentage of the amount you give to The Container uh active processor count same thing uh it's more questionable whether you should set it set it or not but generally if you know how how much resour how many resources you are giving how many CPUs you are giving you should probably set it because it will improve the

it will performance uh what also we use in revolute we have very nice monitoring uh tool that we use it's called New Relic and uh you have to configure it right next thing to remember certificates we forget about certificates unless they expire if they expire then everything stops working right so we need to have a way to externalize uh certificates let's say out of the docker image

so we can like quickly change them uh and same with configuration in in revolute we are not using environment variables for that purpose we are using a yam file where the whole configuration of of the app is is stored however passwords are not in that file passwords are in the inv vault uh that it's we are like connecting uh while while running so we don't use like

secrets from kubernetes we just connect integrate with fault but what else you could do here um you could get some inspiration from buildpack because buildpack has a a very nice memory calculator for Java and Java in memory in Java is very important as we all know uh and it's it's worth spending some time on to properly configure that what else I would suggest like checking the the

the flags that you can set on the on the jvm level for example I find myself interesting the flag that will stop the image exit the image when there's out of memory error so you will like have an information that there were some restarts of application due to that but of course this is of course again can be discussed important thing is that we should have the

we have the ability to print all the jvm flags and figure out it will tell you exactly what is configured for Java and then you can let just choose the things that you would like to optimize last but not least I mentioned earlier when you run the Java apps locally please specify the limits for this container especially memory because if you don't do it you will probably

give too much also with CPU that's again you could you you could but if you don't do it it will work but it's a good generally generally a good idea to set the limit and of course in kubernetes that's the same thing next thing I mean um probably guys do you use desktop it's like a commercial software so mhm so using uh well we at rol we

are not using Docker anymore because of the licensing and costs so we had to figure out what tool to use to like figure to to to uh to dive you know to check what's happening inside uh the docker demon and we use I Ed like lazy Docker uh it's you know it of course gives you the information about the docker image but it gives you information about

running containers as well like with also some statistics configuration environment variables and and so on and so forth uh it's highly recommended by me and uh of course you can do some actions of course I I I run it in the background and when I run like automated test I just sometimes check what's happening um okay getting into the conclusions uh I mean we have a lot

of principles in uh in it generally I mean maybe you can recognize them uh so the first one on the top is uh kit simple stupid right uh other one with the on the left is uh you are't going to need it and the third one it depends right and all those rules they make sense they make perfect sense so but balancing this require you to you

know by to measure things so I think I we should if you would like to optimize stuff you can always optimize it but you need to know what you want to achieve and then choose the tools that allow you to do it so measure then act uh I will give you some examples on what you can measure uh you can like measure comit on deployment fre frequency

if this is a high frequency then maybe it's a good idea to have separated layers for applications because then you will save a lot of space in registry but also you your app your apps might start faster might download faster and use less Network networking uh maybe you would like to optimize the build time maybe it's just too too long so maybe it's a good idea actually

to use tools that build the docker image faster build cost is of course like a bit more related to cloud and how much you paid for for building process so for example if you are using emulator to build uh a Docker image it costs you much more because it's much slower it takes much more CPU so maybe it's worth using the native CPUs uh push time and

pull time yeah I mentioned earlier that's the idea you know that you might uh want to optimize the time it takes for the docker to uh to download damage or upload damage also the uploading is interesting because normally it's a part of the cicd flow you have have to push the image somewhere right so it takes time so um if you reuse a lot of layers then

the push will be fast uh and and based on that I was showing you those multi-layered images there is one thing I didn't mention earlier so we can have a lot of layers but layer is also a cost because if you download a layer it's a separate HTTP call so if you have too many layers you just have to issue a lot of calls and this of

course generates traffic so let's be careful about not adding too many layers especially if they are small then that it might be not worth the price uh and also you had a network bandwidth sometimes you might have problems if your Docker image is like I don't know 8 gabt that could be a problem so measure then act and when it comes to it depends I have some

recipes that how you can talk to your manager okay so if your manager is telling you that you should stick to our company standards there's no reason to change anything that's probably you should use Docker file there's no other way uh but also this Docker file makes some sense if for example this the storage for images you don't pay much for this and you have very custom

buil logic that then okay let's just use Docker file you can configure Docker file in a way that it will allow you to have multiple layers but it's a bit of work but you can do it uh you can also generate Docker files and then uh use them so there's a lot of freedom you could do it uh if your manager say is telling you we don't

have time to do it and of course our our like your colleagues are saying that spring has it okay you can use pack but be informed uh and you can always say yes we can use it but it does not support arm for example okay and uh but other things are pretty cool in in build pack it's also slow as I mentioned uh but there are some

nice extra features especially regarding security that could be really good uh and lastly and this is the real situation I had in my in my uh devops life before that I was not allowed to use Docker demon in building process so I could not run Docker uh so what did I did I used jib because I don't need Docker so I could build doer image without having

Docker and this is pretty cool and also if someone tells you that we do things like Google and we should stick to what does it happens yeah and it works and the Gip is a pretty nice Library uh but also um it it's it's configurable uh it's um when you have limited storage then also it might be worth investigating it last but not least okay what is

uh High call it local CI Duality I think that for as developers the most important thing thing should be to have this fastest feedback loop possible but the problem here is that you know our code and our test are running into different places I mean they are running in as a part of devops Pipeline and they are running on the bare metal laptop and these days these

laptops are much faster than uh probably uh the much faster than the machine you are using to build uh your uh application in the CI so it's a different also architecture and different platform so from that standpoint I think we it's worth investing some time to have your uh setup as fast as possible so you don't spend uh a minute for a build but you spend let's

say 15 seconds and when you are using multiplatform Docker images especially for example if you use uh containers check please check if the test containers you are running the Java apps let's say Kafka do they run natively or do they run in the emulator because if they run in the emulator they will be super slow but they will work um okay I think we have some time

for questions thank you Pro um the problem is we actually don't uh you can you can rush to at least one so uh 44 minutes can you can you comment on how dock image size affects storage and startup time in Final environment for example kubernetes every image needs to unpack info yeah yeah every image needs to pack info that's not necessarily true it changes you know because

it there some features for like streaming the docker image when you run it but generally that's the case whenever you would like to run the image it has to be downloaded on the kubernetes Node first uh and then turned into a container and run that's the the standard thing you do it and that's that's why reusable makes sense because if you have all your components use the

same layers then you could just download it once and then all components will like benefit from it but generally that's the case you need to download those layers to be able to run the image all right I think the other questions then we need to take to the outside meeting Booth uh thank you very much for this great talk uh I invite you guys to visit the

revolute uh stand uh and of course you can ask me questions there as well uh we are hiring of course so we are all welcome to join us in revolute thank you very much much