When I mention Java to young developers, including my own son, I typically get a look similar to the one I gave my father when he talked about Cobol. I might as well be discussing hieroglyphics. At technology conferences, there is a constant stream of Go, Python, Rust and other newer languages, but little mention of Java.
That worked fine when only new, digital-forward companies were adopting the next generation container-based microservices architectures. These companies were starting from scratch and could adopt whatever language was fashionable or that developers were excited about.
That’s all changing as microservices, Kubernetes-based architecture begin to penetrate the mainstream. Now more traditional companies in industries such as manufacturing, banking and healthcare that have decades of IT systems in place are retooling using microservices to meet the needs of modern business. Many of these companies are Java houses with years invested in Java systems, release toolchains, and knowledge. Ditching all of that investment is needless disruption that makes the cost of migrating to microservices more expensive than they can justify. The solution is simple: build microservices with Java. Unfortunately, implementing that solution is not simple.
Java for Microservices Challenges
Using Java for microservices poses problems, especially in containerized environments. Java stacks tend to be big with a large amount of memory utilization. Using these macro-stacks for microservices, especially in container systems, is highly inefficient. One of the advantages of containerized environments for microservices is they make scale out much easier and more automatic. Java applications, however, can take too long to instantiate, making spinning up new containers impractically time-consuming.
The good news is a number of new technologies are helping alleviate the technical issues that inhibit the use of Java in microservices environments. GraalVM, Quarkus and MicroProfiles aim to reduce the size of the Java stack, lower memory utilization and speed up instantiation so Java fits better in container environments. These dovetail nicely with other technology, such as SpringBoot 5.2, which produces the type of language extensions needed to build microservices. This basket of technologies is setting the stage for migrating existing Java applications to microservices while building out new containerized applications in the language.
The bigger problem with Java and microservices emerges from system design. Java systems, like many traditional systems, are not designed as a series of small services. Instead, they tend to be monolithic. This isn’t much of a problem for greenfield applications but that describes very few environments. In most cases, coarse grained n-Tier applications need to be deconstructed into small components. These components then have to be rebuilt, Lego like, into the original application.
While databases and messaging queues, typical components in Java environments, are already available in containerized forms, the bulk of in-house business logic is not. Until technology becomes available that can analyze and break apart monolithic Java applications automatically into microservices, the process will be laborious. Pulling out one common piece of code into a microservice, and then another and another, is a common methodology for making this type of transition. It works, but it’s time consuming.
Related Article: What You Need to Know About Containerization
Don't Write Off Java Just Yet
There is nothing inherently wrong with Java as a language for microservices. The bigger problems arise out of the structure of traditional Java applications and the evolution of the Java stack. The latter is being addressed now with new technology that enables developers to build microservices out of the Java language. The problem of past design choices can be managed through new design pattern and methods. In the future, technology will take on more of role in the migration to microservices.
Java is not dead, it’s not even sick. Solid and well-understood makes for better development environments than fashionable. Java is not fashionable, but it’s still right for business.
Related Article: Container Security Woes Push Evolution in 2 Directions