The benefits of Java microservices in a Docker and DevOps world
To seasoned developers, microservices may sound like SOA by another name. But Java microservices apps delivered via Docker through DevOps techniques actually provide much more agility and scalability than SOA applications
A microservices application is one that is composed of a series of discrete services, which communicate with one another via an API. Microservices apps are the opposite of monolithic applications. The latter run all operations as a single process, or a set of large processes, whereas microservices break an app into a large number of small processes.
As an example of a simple microservices app, developers might design a Web application so that its public-facing front-end runs as one service, and its storage is delivered via a different service. In practice, however, most microservices applications involve more components than just two.
Java microservices versus SOA
To Java developers who were around about ten ago, the microservices approach to application design probably sounds familiar. In many ways, the Java microservices paradigm is similar to Service-Oriented Architecture, or SOA. SOA, which was popular in the 2000s, also emphasized the division of complex applications into discrete services. That communicate via APIs.
SOA enjoyed some popularity, but it never revolutionized the way applications were designed. The SOA fad faded after a few years, and monolithic applications remained common.
Why use Java microservices?
So, what’s making microservices popular all of a sudden now, and how are microservices different than SOA? To answer those questions, let’s first examine the advantages of microservices, then take a look at how two other current trends, DevOps and Docker, make microservices more advantageous than SOA.
Java microservices advantages
The main advantage of microservices architecture is simpler application design and administration. Because microservices break a complex set of operations down into discrete parts, they make it easy for developers and admins to make changes to one part of the application without affecting other parts or requiring the entire application to be restarted.
Java microservices can also provide some security benefits. When the different parts of an application are isolated from one another, an attacker who is able to gain control of one service does not gain control of the entire application.
This security isolation can be especially useful in use cases like the Web application described above. In that case, the data storage system would remain safe in the event that an attacker compromises the public-facing application front-end.
Java microservices, DevOps and Docker
Microservices complements some other trends that are changing the way developers write and deploy software. In particular, the DevOps trend that began in the late 2000s is driving renewed interest in microservices, which help to make software delivery more modular and efficient.
In addition, the introduction several years ago of Docker containers gave developers a new, easier way of building microservices. With Docker, you can run each service inside a container, and combine those containers to compose a complex application.
Docker makes it easier to create and manage a microservices application than the old SOA paradigm allowed. With Docker, once your services have been Dockerized so that they can run in containers, you can deploy those containers to any server with Docker installed. You can also move them around between hosts for portability. And you can use container orchestration tools for automatic provisioning.
Putting the ‘micro’ in Java microservices
It’s worth mentioning, too, that Docker containers help developers to create very small services. Under the SOA model, even if you broke your app into multiple services, the services that composed an app tended to be very large, in the sense that each service could span many servers and handle very large numbers of users. An application that relied on a storage cluster for its data service and a single Web server instance for its front-end would count as an SOA application, but it would not be particularly nimble.
In contrast, using Docker, it’s possible to create multiple instances of the same service by spinning up multiple containers. This is beneficial if demand for a service increases and it needs to scale. Application capacity is not limited by the size of the services that compose the application, and there is no need to devote more resources to a service at any given moment than it is actually using.
Under the SOA model, things would not be so flexible. Your data cluster and your front-end server would consume the same amount of resources no matter how many users were connected to your app. If demand for the app surpassed what the services were designed to handle, they would crash, because you would not be able to spin up new instances of the services quickly and add them to your app.
By making services truly “micro,” then, microservices provides more agility than SOA.
Conclusion
In short, then microservices delivered via Docker containers enable much more automation and agility than SOA. While it may be tempting to dismiss microservices as simply a new incarnation of an idea that was tried and largely dismissed a decade ago, the microservices revolution is actually different in many respects. If you haven’t yet tried using containers to break your monolithic app into more digestible parts, you might find that it’s well worth the migration effort.
