Comment by SatvikBeri

Comment by SatvikBeri 2 days ago

1 reply

I didn't mean the application is less performant (indeed, it might be even more performant since there are more things we can tweak), but that the overall build + upload process is noticeably slower. I remember it taking <1 minute to rebuild + deploy an uberjar in 2016, and on an application of similar complexity today it takes somewhere between 3-15 minutes. Admittedly, this is a different company, language, and setup, so there are a lot of other potential differences.

cogman10 2 days ago

Yeah, it'll be unrelated to docker.

Uberjars are (typically) extracting all the classes from jar dependencies and combining them into a single jar. That's all gzip compression work.

Container layers are simply saved off filesystem modifications. If you use something like Jib to build your image, then the actual deployable should actually be a lot smaller than what you could do with an uber jar. That's because Jib will put your dependencies in one layer and your application jar in another. Assuming you work like most everyone, then that means the only thing that usually gets transferred is your application code. Dependencies only get sent if you change them or the base image.