There are many myths and misconceptions when it comes to developing Java microservices. Here, we take a look at three commonly held beliefs about microservices development that are untrue.
Myth #1: Microservices have no front end
For some reason, there's this belief that Java microservices have to be server-side components that connect to back-end resources, such as databases and message queues. There's also a misconception that a microservice can only expose itself through a JSON string requested through a RESTful API call. None of this is remotely true.
It's common to deploy a microservice that does nothing more than deliver HTML to the client. It's also becoming more popular to deploy Java microservices that cut through various layers of the deployment stack. These kinds of Java microservices provide a UI, model components and connectivity to back-end resources, all within the confines of a single, isolated, independently deployed application.
Go ahead and include a UI you developed with Spring MVC or send HTML directly to the client from your Docker container. When you provide a UI with your microservices, it makes them better, not worse.
Myth #2: You must use Spring Boot or Eclipse MicroProfile
So long as you comply with fundamental microservices design principles, there's no Java development framework that you should consider off limits.
The two most popular frameworks for developing Java microservices are Spring Boot and Eclipse MicroProfile. And while these two projects are great starting points, they are by no means the only game in town. So long as you adhere to the various principles that are germane to cloud-native development, you can use any framework you like to develop Java microservices.
It's not at all wrong to develop a Java Platform, Enterprise Edition application that uses Enterprise JavaBeans (EJBs), package it in an embedded WebSphere Liberty server and deploy it as a microservice. Similarly, you could create a servlet and JavaServer Pages-based application, package it in an embedded Tomcat instance and deploy it in a Docker container; that too would be a completely valid microservice. So long as you comply with fundamental microservices design principles, there's no Java development framework that you should consider off limits.
Myth #3: The API set is limited
It's easy to get the impression that Java microservices need to be developed using a limited set of APIs. But that impression is wrong.
Sure, Eclipse MicroProfile only defines 13 APIs over and above the Java Development Kit as part of the specification's required feature set. That doesn't mean other libraries can't be added. Need Java API for XML Web Services as part of your microservice? Just add a reference to the API in your Maven POM file. Do you want to use Java MVC? Just add a reference to your Gradle build, and ensure your deployment target supports it. There are certainly many opinions on which APIs are best for developing and deploying Java-based microservices, but the opinions of others shouldn't impede anyone from doing what's right for a given project.
Dispelled Java microservices myths
While myths circulate about Java microservices development, the important thing is that you embrace cloud-native design principles, code according to the principles outlined by the 12-Factor App and remain aware of the constraints and restrictions of container-based deployments. If you do these things, you need not be concerned with the tales others have spread about Java microservices.
