Translating and Adapting Java Microservices: A Practical Guide . Link to the first part of the guide . Any Java server program, and therefore any microservice, is just a .jar or .war file. There's one great thing about the Java ecosystem, or rather the JVM: you only need to write Java code once and it can run on almost any operating system, as long as you don't compile your code with a newer version of Java than your target JVM version. . This is important to understand, especially when it comes to topics like Docker, Kubernetes, or (drumroll!) The Cloud. Why? Let's look at different deployment scenarios.
Minimalistic Java Microservice Deployment Example
We continue with the bank example. So we've got the monobank.jar file (monolith) and our newly extracted riskengine.jar (the first microservice for risk checking). Let's also assume that both applications, like every other application in the world, need a .properties file. In our case, it will only contain the database URL and credentials. A minimal deployment might consist of two directories that look something like this: First:
This leaves the question open: how will the .properties and .jar files get on the server? Alas, there are many answers.
How to use build tools, SSH and Ansible to deploy Java microservices
Boring, but no less excellent advice on how to deploy Java microservices ... Actually, exactly the way system administrators deployed any Java server program in companies over the past 20 years. This is the mix:
your favorite build tool (Maven, Gradle)
good old SSH/SCP to copy .jars to servers
Bash scripts to manage deployment scripts and servers
or even better: some Ansible scripts.
Of course, this is not suitable for innovators who need a “breathing” cloud, servers with automatic load balancing, and so on. This is a real boring old school. However, it works!
How to use Docker to deploy Java microservices
Let's get back to the sweet pangs of choice. A couple of years ago, Docker entered the scene, and with it, containerization. If you've never worked with it, here's a brief description for end users and developers:
The container (simplified) is similar to the good old virtual machine, but “easier”. If you don't understand what "easier" means in this context, you are welcome to study this answer on Stackoverflow .
The container guarantees its own portability. That is, it works anywhere. Sounds familiar, doesn't it?
It's funny that given the portability and backwards compatibility of the JVM, this feature doesn't seem like much of an advantage. You can simply download the JVM.zip on any Raspberry Pi (or mobile phone), extract it and run any .jar file. The situation changes when it comes to languages such as PHP or Python, where version incompatibilities or deployment settings are more complex. Or if your Java application depends on many other installed services (with the correct version numbers): for example, a Postgres database, or a Redis key-value store. So, the main advantage of Docker for Java microservices, and more specifically for Java applications, is this: the ability to set up homogenized testing or integration environments using tools such as Testcontainers. Complex sweeps are easier to install. Take Discourse forum software . You can install it with a single Docker image, and that one contains everything from the Discourse software written in Ruby to a Postgres database to Redis and a kitchen sink. If your deploys are similar, or if you want to run a pretty little Oracle database, try Docker. So, to summarize, instead of just looking at the .jar file, you now:
merge your jar into a docker image
commit this image to a private docker registry
pull and run this image on your target platform
or copy the Docker image directly to your prod system and run it.
How to use Docker Swarm or Kubernetes to deploy Java microservices
Let's say you decide to try out Docker. Every time you deploy a Java microservice, you create a Docker image that bundles your .jar file. Let's say you have a couple of these Java microservices, and you want to deploy these services on multiple machines (in a cluster). The question arises: how to manage this cluster? Run Docker containers, health check, deploy updates, scale the system (brrr)? Two possible answers to this question are Docker Swarm and Kubernetes. A detailed description of both options would make this already long guide too long, but we thought it was important to mention that both options ultimately rely on you writing YAML files (see the stories about Yaml indentation) .) to manage your cluster. If you want to know how it feels in practice, just search Twitter for a similar query. So the deployment process for your Java microservices now looks something like this:
Configuring and managing Docker Swarm/Kubernetes
All Docker steps (see above)
Write and execute YAML until your eyes bleed until everything works.
How to Test Java Microservices
Suppose you decide to implement microservices in production. How now to test the integration of n-microservices during development? How can I see if the complete workflow is running, not just individual parts of it? In practice, one of three methods can be applied:
With a bit of work (if you're using frameworks like Spring Boot), you can bundle all your microservices into a single startup class and load all the microservices with a single Wrapper.java class - depending on whether you have enough memory on your machine to start them all. your microservices.
You can copy Docker Swarm or Kubernetes settings locally.
Just don't run integration tests locally anymore. Instead, deploy a dedicated DEV/TEST environment. This is what quite a few commands actually do, succumbing to the pain of local microservice setups.
Also, in addition to your Java microservices, you will probably also need a running message broker (like ActiveMQ or RabbitMQ) or perhaps an email server or whatever messaging component your Java microservices need to communicate with each other. This leads to a significant underestimation of the complexity on the DevOps side. Take a look at Microservice Testing Libraries, they can ease that pain. In any case, this complexity brings us to the common problems of microservices, which we will talk about right now. In the final part , we will discuss common questions about Java microservices.
Any Java server program, and therefore any microservice, is just a .jar or .war file. There's one great thing about the Java ecosystem, or rather the JVM: you only need to write Java code once and it can run on almost any operating system, as long as you don't compile your code with a newer version of Java than your target JVM version. . This is important to understand, especially when it comes to topics like Docker, Kubernetes, or (drumroll!) The Cloud. Why? Let's look at different deployment scenarios.
It's funny that given the portability and backwards compatibility of the JVM, this feature doesn't seem like much of an advantage. You can simply download the JVM.zip on any Raspberry Pi (or mobile phone), extract it and run any .jar file. The situation changes when it comes to languages such as PHP or Python, where version incompatibilities or deployment settings are more complex. Or if your Java application depends on many other installed services (with the correct version numbers): for example, a Postgres database, or a Redis key-value store. So, the main advantage of Docker for Java microservices, and more specifically for Java applications, is this: the ability to set up homogenized testing or integration environments using tools such as Testcontainers. Complex sweeps are easier to install. Take Discourse forum software . You can install it with a single Docker image, and that one contains everything from the Discourse software written in Ruby to a Postgres database to Redis and a kitchen sink. If your deploys are similar, or if you want to run a pretty little Oracle database, try Docker. So, to summarize, instead of just looking at the .jar file, you now:
GO TO FULL VERSION