I'd like to decompose a number of Java REST services (WAR files) into individual container-ised "MicroServices" - so that I can scale services ondemand, insulate the applications, have loose couplings, facilitate cloud deployments, etc, etc (roughly ~100 services currently being used in an ESB/running in the same JVM)

I've had a look at a few Docker tutorials, and I'm concerned that each container is going to be around 150MB (due to the JRE) - not large by itself, but if I need to scale out to hundreds/thousands(/or more) of service instances, there's going to be a lot of redundant disk space being used...

Is there a better way to break Java services down into containers?

  • Am I using the right tool for the job? (Docker vs AWS ElasticBeanstalk vs AWS Lambda vs Java Application Server(/s) vs ???)
  • What's the best practice in terms of shared resources? (isolate everything or share everything (trading independence for lower resources)? e.g. Can/Should I have a shared drive mounted from a host system, containing a single shared copy of the JRE?)

Currently investigating JavaSE8 (compact1) - which is a much more palatable 40MB (incl OS)

  • 1
    Your problem won't be disk space but memory: JVMs require fixed-size heaps, whether or not they use all the space. You might want to consider that a web-app container (WAR) already provides isolation between services. – kdgregory Nov 7 '16 at 18:51
  • @KarlBeilefeldt has an answer for your specific concern but I want to point out that simply deploying services to different containers does not give you loose coupling. It's a precondition to getting value out of microservices, not a result. Microservices can add significant costs and inefficiencies. You'd be wise to make sure you really are getting advantages out of the approach. It's possible that a good approach for your set of 100 services is 30 independent containers, not 100. Split out thing that are not tightly-coupled, refactor to reduce coupling, rinse and repeat as desired. – JimmyJames Nov 7 '16 at 19:30
  • Docker vs. Elastic Beanstalk is not an either/or choice. You can run docker containers on elastic beanstalk. Also, I agree with @kdgregory My experience is that the main memory requirements of JVM's are what add up fastest, and can push you to pay more for infrastructure. – joshp Nov 13 '16 at 19:02

Docker shares the redundant disk space between instances of the same container, and redundant layers of images between instances of different containers. For example, if you have two different microservices, but they both start with FROM openjdk:8-jre-alpine at the top of their Dockerfile, then Docker will share the JRE disk space between all the instances on the same host.

Even if Docker didn't behave that way, this is the fundamental trade off you frequently make with microservices. A lot of microservices architecture technologies work this way. NoSQL databases like Cassandra, for example, often create dozens of copies of data. You shouldn't be afraid to trade cheap disk space to get scalabilty.

As far as your "right tool for the job" question, many people have successfully used Docker in similar situations to yours, but many people have used the other technologies you listed as well. Ultimately, you have to make that determination for yourself.


You're at that point in decomposing where managing 100 running somethings (i.e. Docker, Elastic Beanstalk, etc) may be more of a pain than it is worth.

I would look at two different things here. First, I would consider grouping services into smaller "sub-services". Don't think that a single service has to be a single machine/docker image. I might be inclined to, as an example, group all of the security services in a single service and determine the best way to deploy that.

Second, I have used AWS Lambda and Elastic Beanstalk for service distribution. Elastic Beanstalk is great for longer running / high CPU services. It has many ways to scale up and down (CPU usage, network I/O, SQS queue length, etc). Lambda has much the same thing but now you're running in a bit more restricted environment. Lambda can work very well but in my opinion it handles either modest traffic or cron type of activities the best.

As a warning - a frequently run Lambda taking some time each run can quickly become more expensive than an Elastic Beanstalk machine.

Overall, IMHO, the benefit of microservices is the ability to both update small sections of your code easily and to be able to scale sections of your code easily. But the downside is where you're at - what division of services makes sense? The build/test/deploy/monitoring of 100 containers might be more than some organizations can manage. But split them into, say, 10 to 20 containers and now you've got a much more manageable problem.


Java 9 modules are designed to address some of these concerns: http://www.theserverside.com/news/2240242583/Java-9-promises-modularity-and-new-value-types

But maybe you should migrate to JavaScript which has a smaller memory footprint.

  • 2
    "But maybe you should migrate to JavaScript which has a smaller memory footprint." Is that a joke? – JimmyJames Nov 8 '16 at 14:55

You can use a ear file if you leverage EJB's of any form. I would look closer at OCI implementations in Java I have used this in the past and things worked out very well.

protected by gnat Nov 13 '16 at 19:57

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.