13 Java frameworks for rock-solid microservices

It’s been a long trip for Java, a language that began as the lingua franca for the box on top of the television set in the days when TVs didn’t come with Roku or Chromecast built-in. Then Java was going to own the World Wide Web by animating the browser before JavaScript came along and elbowed it out of the way.

Java ended up finding a niche in the server farms where there were once enough different chip architectures and operating systems to make the “write once run anywhere promise” compelling. And in those server farms Java has lived on, a favorite of enterprise IT shops addicted to reliability and developers with a love of strong typing.

In the meantime, JavaScript in general and Node.js in particular have challenged Java on the server, using their high throughput and thread-free speed to take over a huge chunk of the traffic on the web. Node has captured the imagination of the newest server-side programmers by offering not only speed and resource efficiency but also the simplicity of code that runs on both the client and the server.

Yet despite the rise of competition, Java continues not only to survive but to excel. Many of the teams tasked with developing microservice architectures are continuing to use Java. A major reason must be because the technology is battle-tested from years on the front lines parsing HTTP requests. Sun created a rock-solid virtual machine, and Oracle continues to nurture and support it.

Another reason must be the continued evolution of the language. Java 8 offers solid support for the functional languages like Scala and Kotlin. The JVM is now a foundation for many of the best experiments in computer language development. Dozens of new languages can compile down to Java byte code and link up with each other to make complex projects work together. Many of the stacks running smoothly on a JVM may be built by a mixture of Java and a number of other languages.

The biggest reason, though, must be sheer inertia. As I write, 371 jobs for COBOL programmers are listed on Dice. There are many, many more jobs with the word Java in them. Is it any surprise that smart teams are looking at their huge stacks of aging Java code and thinking that the simplest solution is just to add a side door that spits out the data as JSON data structures? Voilà. The old code keeps running, but it acts like a modern microservice at these side doors.

All of these options and more ensure that Java continues to play a strong and vital role in the microservice revolution. And it’s no surprise that the Java open source community has followed along, creating many new options for Java programmers who need to teach their Java code to speak like a microservice.

Here is a list of 13 open source options that Java developers are using to turn out solutions that form the foundation of microservice architectures everywhere.

Spring Boot

The Java world has been building Spring applications for a long time. Spring Boot is a particular version of Spring that makes the process much easier by handling many of the configuration details for you. Spring Boot was created to automate the start of Spring projects of any kind, not just microservices. To make things even simpler, once you’re done with the application, Spring Boot mixes in a web server and spits out a single JAR file that is pretty much all you need except the JVM. Think of it as the original Docker container. All of this cleverness is appreciated by many of the people tasked with building microservices because all of the configuration gets to be annoying when you have to do it again and again for each of the dozen or so microservices. If Spring Boot can automate it, churning out several dozen microservices is that much easier.

The microservices developed with Spring follow the same MVC philosophy as the macro web applications we’ve been building for years. The framework enjoys all of the deep connections built up over years of Java development including integration with all major and minor data stores, LDAP servers, and messaging tools like Apache Kafka. There are also dozens of little and not-so-little features for maintaining a running collection of servers, features like Spring Vault, a tool for maintaining the secrets, passwords, and credentials needed by the servers in production. All of these advantages show why Java programmers have been joining the bandwagon for many years.

Eclipse MicroProfile

In 2016, some of the fans of the Java Enterprise community looked around and decided to clean out all of the cruft from the Java Enterprise Edition so people could build simple microservices with the classic parts. They tossed out a surprising number of libraries, but kept code for processing REST requests, parsing JSON, and managing dependency injection. What they ended up with, dubbed Eclipse MicroProfile, was fast and simple.

Since then the MicroProfile community made a pact to release new versions as often as quarterly while adding new code for keeping the microservices running smoothly and securely. The development process and code structure will be very familiar to anyone who has lived in the Java EE world, but the endless configuration hassles have been polished away. It’s proof that you can teach old dogs new tricks.

Dropwizard

When Dropwizard appeared in 2011, it opened the eyes of Java Enterprise developers to how little code was really needed. The Dropwizard framework delivered a very simple model for development with many of the important decisions made for you, and it has continued to follow this path. You add some business logic and then pretty much everything else is configured for you according to the convention. The result are slim JAR files that users praise for starting up quickly.

The biggest limitation may be the lack of dependency injection. If you want to use dependency injection to keep your code clean and loosely coupled, you’ll need to add the libraries yourself. There is no Dropwizard way to do this, unlike in the Spring world. Most of the other luxury items, though, are now supported including logging, health checks, and resilience-providing code. You won’t need to make too many sacrifices.

WildFly Thorntail

The folks at Red Hat built their own version of MicroProfile complete with a slick configuration tool. The framework was originally called WildFly Swarm, but then it was renamed to be Thorntail. The Thorntail website helps you create your own Maven build file just by specifying the features you need. Maven then takes care of assembling everything. Thorntail will also detect the major components you’ll need by scanning your code, but you can override this with a BOM (bill of materials) file. When it’s all running, Thorntail will strip out the parts of the Java Enterprise Edition that won’t be used and create a JAR file that’s small and ready to deploy with one command—a slick feature that allows the Thorntail project to call it an Uber-JAR. It’s another approach to following in the tradition of the Java Enterprise Edition without keeping all of the heavy baggage.

Helidon

Helidon has only been out for a few months since the press releases and the first commit to the GitHub repository, but the framework is already attracting the kind of attention that support from Oracle guarantees. While the Java universe is huge, plenty of it still revolves around Oracle. 

Helidon’s architects followed many of the same themes that are repeated in the other projects here. Rip out the Java Enterprise Edition cruft and keep the lightweight, servlet-based core that has earned the world’s trust. In Helidon’s case, the developers started with Netty and added just enough code to do some routing and error handling. To make things interesting, they embraced two basic models for the code, the so-called SE and MP versions.

Helidon SE will look very familiar to Node.js programmers with the long chains of function calls joined by periods. Helidon MP will look more familiar to the Java programmers who use JAX-RS. There are also some useful and well-appreciated tools for checking the health of servers or tracing the flow of data through a forest of microservices. These are compelling reasons to explore the potential, even without Oracle’s support.  

Cricket

Yet another framework for fast API development is Cricket. Cricket is small despite including several extras like a key-value data store to save you from connecting a database and a scheduler to control repetitive background processing. There are no other dependencies that add complications or lock-in, so it’s pretty easy to add your code to Cricket and start up an independent microservice.

Jersey

One of the standard approaches to developing a web service is the Java API for RESTful Web Services (aka JAX-RS), a general spec that has been implemented in the Jersey framework. The approach depends heavily on using the annotations to specify the path mapping and the return details. Everything else from the parsing of the parameters and packing of the JSON is handled by Jersey.

The main advantage of Jersey is that it implements the JAX-RS standard, a feature that is desirable enough that some developers combine Jersey with Spring Boot to enjoy both together. 

Play

One of the best ways to experience the cross-language power of the JVM is with the Play framework, a pile of Scala code that links up with Java or any of the other JVM languages. The foundation is very modern, with an asynchronous, stateless model that doesn’t overload the server with endless threads trying to keep track of the users and their session data. There are also a number of extra features that can be used to flesh out a website like OpenID, validation, and file upload support.

The Play codebase has been evolving for more than a decade, so you’ll also find echoes of long-forgotten times like support for XML. Play is both mature and lithe, a combination that can be rare in the wild.

Swagger

Building an API may seem as simple as writing some code that listens on a port and delivers answers, but the developers of Swagger beg to differ. They’ve created an entire API specification language called OpenAPI that you can use to spell out what you’re API will do. This may seem like an extra step, but the Swagger team has also provided code that turns this specification into automated tests, documentation, and more. The simple, almost spartan description of an API in the Swagger configuration file is spun into Java code for implementing the interface, documenting how it behaves, and providing a set of tools for testing the code built underneath it. There is even a mechanism for API governance so you can work with the unwashed masses who will soon be banging on your API’s door and expecting answers.

Swagger is an ecosystem for APIs and it’s not limited to Java. If your team moves to Node.js or any of several dozen other languages, there is a Swagger Codegen module waiting to convert your OpenAPI spec into an implementation in that language.

Restlet

One of the bigger differences between the various frameworks is the number of connections to other services and libraries. The Restlet project offers one of the larger collections of features and connections. It’s already integrated with libraries like JavaMail, in case your microservice will need to speak POP, IMAP, or SMTP to some mail server, and Lucene/Solr, in case you want to build searchable indices of large chunks of text and the metadata wrapped around it.

The possibilities in Restlet just keep going because this stack generally supports several different options for every part. You don’t need to use JSON, for instance, because the code will handle XML, CSV, YAML, and a few more file formats. You get several different options for the templates for structuring your response as well. One of the neater extra features is the Restlet client, which lets you test your APIs from the Chrome browser.

Squash

Debugging microservices is often a real challenge because the parts are so loosely coupled and it’s difficult to track the flow of data through all of the layers of the system. Squash lets you set up breakpoints in your code running on a Kubernetes cluster and then receive all of the data back in your IDE as if it were code running locally. Squash also integrates with Node.js and Python runtimes in case your collection of microservices is not Java-only.

Telepresence

Another option for debugging is to use Telepresence to create a local proxy for a microservice on a distant Kubernetes cluster. Your calls for this service will be diverted to the local version where you can set up breakpoints or do anything else you can imagine on your local machine.

Zipkin

Zipkin is a mechanism for logging events on various microservices and then correlating the events so that problems can be isolated and studied as they ripple through the collection of machines. There’s a Zipkin implementation for Java as well as at least six other languages so multi-lingual systems can be tackled. Some of the most sophisticated frameworks like Spring already have Zipkin integrated in some form.