February 26, 2020

Docker Microservices in Java

Microservices

Java Tools

According to our recent Java Microservices Report, Docker microservices in Java applications are the most adopted virutualization method — and it’s not even close. With over 73% of developers using Docker for virtualization, Docker is ubiquitous.

But why has Docker become such a big name in microservices? In this article, we’ll explore why Docker Microservices are so widely used in Java microservices-based applications, how they’re used, and what shortcomings they have (if any) for Java development.

What Is Docker?

Docker is an OS-level virtualization tool used to segment applications into “containers.” These containers, or microservices, can be loosely-coupled with other containers — which serves as the foundation of the microservices application architecture.

Docker creates an environment that becomes completely systems agnostic — whether you are running with Linux or Windows providing consistent operation of applications throughout your lifecycle

Docker Containers in Java Applications

Typically, Java applications using Docker are using it in multiple containers. In fact, our recent Java microservices survey showed 39% of Java developers using between 11-25 containers in their primary application.

What does that tell us about what developers are using Docker containers for? They are using them in a lightweight capacity. In fact, most development teams use up to 8 services per host. That means most are focused on running smaller containers together on a single host to test their integration and interactions.

Docker Microservices Configuration

One of the beautiful aspects of configuring Docker Containers is that developers have complete flexibility in configuration — including operating system or developer language. Better yet, developers don't need to start from scratch. Docker’s Hub lists over 10,000 base images to choose from.

Those base or parent images allows a team to start with a certain server/container or database that you can completely redesign to meet the developer’s design specifications. The Docker Hub allows a developer to not worry about sharing specific versions of software to install on a machine. Now a team can choose some base image or starting point to now build off of so teams can simply manage the configurations by modifying an image and sharing those modifications.

For instance, in the configuration we walk through in our Preparing a Docker Compose Environment blog, you can clearly see the basics needed to run a Docker Container with three services. They are using a base or parent image Tomcat and Mongo from the public Docker Hub. Next you can see that they are specifying the ports of the stock Tomcat server as well as linking the services together. Lastly, they are adding an archive to our Tomcat server to host and adding environment variables. That’s how easy it can be to get three services running locally.

petclinic:
  image: tomcat
  ports:
    - "8000:8080"
  links:
    - supplements
  volumes:
    - ./petclinic.war:/usr/local/tomcat/webapps/petclinic.war
  environment:
    - "JAVA_OPTS=-Dsupplements.host=supplements"

supplements:
  image: tomcat
  ports:
    - "8888:8080"
  links:
    - db
  volumes:
    - ./supplements.war:/usr/local/tomcat/webapps/supplements.war
  environment:
    - "JAVA_OPTS=-Dmongo.host=db"

db:
  image: mongo
  command: -smallfiles -nojournal

Docker Container Orchestration

Docker containers are typically orchestrated with the open-source container orchestration service, Kubernetes. Docker Swarm, the in-house container orchestration solution, is out of favor with most developers — partially because of a lack of functionality and adoption, and partially because support is reported to end in 2021.

Docker says as much, stating on their website that:

“Kubernetes has become the standard orchestration platform for containers. All the major cloud providers support it, making it the logical choice for organizations looking to move more applications to the cloud.”

Issues With Docker

Because Docker serves primarily to execute an application architecture, its perceived shortcomings are more of an indictment on the developer than the application itself. In fact, the most common complaint for Docker, security, can just as well be applied to developers’ collective failures in addressing security for individual microservices. (Ignoring Spectre and Meltdown here for the sake of argument.)

Another issue for developers using Docker is adding a level of complexity to a developer's machine.That level of complexity can make Docker startup times significantly longer than a bare-bones server running a smaller archive. That increased time can severely impact a development team ability to develop quickly and efficiently. That's not to mention the added complexity in container interaction, which can make tracing code end to end a longer, harder task.

There are always pros and cons to switching application architectures. Before making a switch be aware that Docker (or the microservices architecture) is not always the best or desired solution.

Using JRebel and XRebel With Docker Microservices in Java

Architecture of the Distributed Version of Spring Pet Clinic

One of our favorite ways to demonstrate how JRebel and XRebel work for microservices is by using one of the most common pairings in Java development – Docker and Spring. Using the distributed version of the Spring Petclinic demo (architecture visualized above), you can see how XRebel works to profile code across containers, with JRebel “hot-swapping” code into those containers without redeploying the combined microservice application.

Want to get a personalized demo for your Docker-based application? Schedule a demo for your team by clicking the button below.

Schedule a Demo