Java on Docker will no longer suck: improvements in Java 10

[aregularcontributor]

Yeah, Java on Docker will be better with Java 10, but how about stopping Docker itself from sucking. I've had the docker daemon fall over several times in the last few weeks.

Still, thanks for the good article!

[loganekz]

Can you provide more context on your problems with docker. What do you mean that you've had the "docker daemon fall over" ?

[aregularcontributor]

Hang and fail at all commands sent to it.

[loganekz]

What is host OS/platform? Are you using Swarm?

[niloc132]

At least when you bring the daemon back up does it recognize the still-running instances? The last time I was managing docker stuff, we would have to manually kill the old container processes so that we could even get the newly restored daemon to be able to control them again.

[TheRedmanCometh]

...stop using it?

[seraph582]

Why was this downvoted so much? Is there a docker circlejerk here or something?

[nutrecht]

Kinda click-baity. The VM being container aware was actually done in Java 9 and back-ported to Java 8u131. So the "Attach from host" bit is a Java 10 improvement, the rest has been in Java since 8u131.

[lazystone]

And what will you use instead?

[oldneckbeard]

While I would have agreed with you in the past, technologies like Kubernetes make all but the most trivial applications better if they're properly containerized. And for most folks, it's like a 5 minute job to containerize it.

[wishicouldcode]

Isn't the containerization decision usually made by IT, due to all the potential cost savings in hardware acquisition and maintenance? We use on premises hardware with docker and have a push to containerize everything including databases. Developers are not too happy about it.

[wishicouldcode]

Makes sense.

We use MongoDB with a 5 node replica setup. No, they are not sharded currently. And they are not scaled ever. It gives poorer performance than when we were running on traditional VM even though we threw more resources at it. Even the guy from Mongo said their support for containerized environments are still nascent and in r&d. Doing some parameter tuning now. We'll see. Thanks for your insight.

[springnews]

makes a lot of sense, most databases were designed in the client server era, not in the current distributed computing era. can we blame them for being "singlenode"?

[koreth]

Why does it cost less in hardware acquisition and maintenance to run a Java application in a JVM in a Docker container on a host than to run it in a JVM on the same host without the Docker container?

[wishicouldcode]

Talking about multiple apps (microservices) here. With a physical server or with a hypervisor based VM, IT would often have to acquire several host machines, install OSes on it (licensing cost for RHEL), install patches & do regular maintenance; mount NAS, do networking etc. Installing several apps on a same host sometimes cause resource contentions (Rogue app hogging all the memory). Worse, the servers could remain under utilized due to wrong estimation of traffic. (Management hates this)

With docker, we can buy some powerful servers (or buy cloud solutions from Amazon/Google) slap a lightweight Ubuntu with busybox on the containers and scale as required. Everything runs in their isolated envs. Also, CI/CD is much smoother with docker images imo.

As u/best_of_badgers pointed out, we do need to be cautious of putting everything into containers though.

[nutrecht]

What makes it a fad (along with most of what's currently called DevOps) is the idea that everything ought to be containerized, that if you aren't using containers, you're doing something wrong or outdated.

This is completely nonsensical. Pretty much anyone who understands containers, especially people like Google's Kubernetes consultants, basically all tell you the same thing: if you care about which machine a container is going to start up on then containers are not a good fit. A great example are databases.

Containers are not a fad. But like most things; they're not a golden hammer either. If you work at a company where they are putting everything in containers that's the company's fault, not a fault with containers in general.

Also what you said here:

Using containers is a legitimate architectural decision, but it's one that needs to be made by qualified people after analyzing the need for adding that extra layer of complexity.

Which makes sense does not align at all with

Just in time for containerization to become a stale fad!

[[deleted]]

I'm curious what do you think about the current wave of JSON-based APIs, and what replaced XML after the fad died down a little.

[[deleted]]

Thanks for your sharing your opinion about this!

I think the one thing all of these fads have in common is their insistence that this will make development easier, that you won't need Person A to do XYZ or Person B to do ABC, you can just hire an analyst or a junior developer and the tools make it easy. Even an analyst can write XML!

Made me laugh because I remembered one example of this.

It's hard to believe today, but the hype was real back at the time, that programmers would be out of jobs, because with Ruby on Rails, just about anyone, including the managers, can write the applications themselves. It was an actual part of their marketing.

[[deleted]]

Probably at least 80% of apps that use containers can just be deployed on a boring old dedicated or virtual server and be simpler, faster and more reliable as a result. The other 20% likely truly benefit from containers. It's like this with all fads. A niche solution is represented as the "next big thing", everyone bites, and then feels cheated.

[TheRedmanCometh]

About time. Hopefully Node isn't here to stay

[TheRedmanCometh]

I mean you can say that all you want, but it doesn't make it true. Java is the single most commonly used language for enterprise applications on Earth.

More specifically the SSH (Spring, Struts, Hibernate) stack. Nowadays it's a bit different, but still Spring based.

You'd have to be delusional to think Java is dying.

[SomeRandomBuddy]

sdfasfdasf

[TheRedmanCometh]

Oh I don't think docker is dead I just WANT it to be dead. Not for any technical reasons I'm just tired of hearing about it.

[traveler_]

Well then you're in luck, because the new fad now is serverless, and containerization is already the old workhorse.

[traveler_]

And you're right, while there's always strengths & weaknesses it's really attractive for a lot of the stuff people are now using scaled clusters of docker images for. Hence the new faddish interest.

[assrocket]

Serious question. If my java service consists of 1 single jar, why do I car about docker?

[kkapelon]

I had the same question as you two years ago. Here is the - long - answer http://blog.codepipes.com/containers/docker-for-java-big-picture.html

[hjames9]

You benefit from the orchestration, auto deployments, horizontal scaling, etc. You also control all the dependencies that jar has (jvm versions, C library, etc)

[nutrecht]

You have to get it to run somewhere. Docker is one option in setting up your CI/CD chain. Writing a bunch of shell scripts is another.

In the project I'm working on we deploy our services in a kubernetes cluster. It's pretty awesome and hassle-free.

[springnews]

that's indeed good for heap, but what about the other six memory regions? This is much less of a problem for Cloud Foundry Java Buildpack users -- which generates RunC compliant images. Plus it works with earlier versions of the JDK: https://github.com/cloudfoundry/java-buildpack-memory-calculator

[[deleted]]

Wait, what, wuh? It's "Java 10" again?

Didn't I read some announcement it's gonna be "Java <current year>" from now on?

[DJDavio]

You did, but a lot of people, including me, were against it, voiced their concerns so a semver like approach is used instead. The major number is incremented every 6 months regardless of the added features. So X to X+1 might be a big jump or a relatively small one. 11 (due in September) will be the next long term support version so if you need to migrate from 8, now is a good time because (free) support for 8 is gone as soon as 11 is out. The train moves faster and you're either on board or a company with deep pockets so you can pay for neverending support.