A full-profile application server, such as Glassfish are Wildfly , was conceived to integrate a lot of frameworks that could be used separately with a lightweight server such as Jetty otherwise. However, the benefit was that all parts were assembled for you and you didn’t need to iron out the wrinkles you might encounter gluing various frameworks together. Also, an application server saves a developer from writing code that not pertain to the business domain: the application server copes with multithreading, provides a persistence solution, simplifies receiving messages from JMS queues and so on. It should be noted, that one can use a web-profile application server, such as Tomcat along with Spring to solve the same problems. The difference is that Spring mostly does not abide by standards of enterprise Java.

Using an application server solves a lot of developer’s problems, although when an application grows in complexity to the scale of Amazon store, another approach can be more preferential. Namely, one can split the application into a number of parts, each of which solves a single problem, for example, if one builds an e-commerce application, one such part could produce the catalog for customers, the other should provide a cart functionality, and also there should be an API to work with merchandise comments and ratings. Such parts into which a huge application can be split are called microservices. Microservices often expose RESTful APIs to communicate with each other, so the idea is not new, but received a lot of attention of late.

The advantages of microservices are, first, as was mentioned, such approach can solve complexity issues. Second, you can scale (or increase number of instances of) only those services that require scaling, but not the whole application and as a consequence one can separate parts that are CPU hungry from memory hogs and deploy them to appropriate hardware. Third, different parts of an application can be written in various languages. Finally, it is easier to refactor and rewrite separate parts than the part of a bigger applications. The disadvantage is in additional complexity of managing a distributed application, that is microservices come not without cost..

As was previously mentioned, one can use a language of her liking to create microservices, and there are scores of frameworks in different languages to accomplish the task. We’ll limit our discussion to Java which has its own pack of frameworks to create microservices also known as microframeworks. To simplify things one can introduce some classification of frameworks, and one possible is Java EE-based microframeworks and non-Java EE based.

One of the first microframeworks that appeared on the market which relied on standard frameworks which are part of Java EE specification was Dropwizard that was the framework of choice for those who would like to start building microservices with Java and had Java EE background. One could easily guess that the representative of the rivaling camp should be based on Spring and, in fact, there is a powerful Spring Boot framework which allows one to build complex microservices fast by relying on Spring ecosystem.

Another way to divide microframeworks is to place them in reactive or nonreactive buckets. The most prominent of the first class is Vert.x which is a JVM cousin of node.js, and Java EE microframeworks should be placed to non-reactive bucket.

It should be noticed that Java EE microframeworks are not limited to Dropwizard. Recently some new appeared, such as WildFly Swarm from Red Hat. One can find an uncomplete list of Java microframeworks as well as some tutorials and articles in /r/JavaMicroServices/ subreddit.

The topic of Java microframeworks is extremely interesting and deserves exploration as microservices approach is not all or nothing proposition, that is ane can start building an application using either a full-profile application server or Spring, when there is no complexity microservices help solve, but later add new functionality or features using microservices and later refactor the whole application into a number of smaller parts.

As the first step of exploring a new field, I created a DropWizard course for beginners on Udemy and a simple project on BitBucket . Dropwizard was chosen due to my Java EE background and also because it was recommended by ThoughtWorks technology radar . The difference of a Dropwizard application from regular Java EE application is that the former is not deployed to an application server, but is launched as a jar file from command-line interface, actually a so-called fat jar file which contains all the necessary dependencies in it, so that one has the same set of dependencies both in development and production.

Here is the list of my Dropwizard tutorials:

If you have some interesting articles and tutorials concerning Java microframeworks, you are welcome to add them to the aforementioned subreddit. Dropwizard and Vert.x have separate subreddits devoted to them.