Which technology stack should I choose?

So far, a lot has been written about microservices, and one is not really sure what exactly a definition of microservices should be. Depending on who you ask, you get different answers. However, the hype has been behind for some time and there are some empirical values ​​that you can now use as a basis for your own decisions about which technology stack you should use.

I will not try to define the term microservices here. Rather, we will briefly discuss different points of view. Some of them will certainly sound familiar to one or the other reader from their own experience. The focus will be on the area that deals with existing systems and requires moderate migration instead of a completely new development.

Let's start with the all-in-one solution. This is the packaging of all the necessary ingredients in a Fat JAR. This method became well known through Spring Boot and was later taken up by some projects from the Java enterprise environment. In this context you can access all known technologies from the selected technology stack, and at the end all the necessary components are packed into a single JAR. This file can then be used as a binary that can be started in a JVM without any further components. There are therefore no further requirements for the runtime environment than that a JVM is available.

As far as I know, Spring Boot is the pioneer of this type of project initialization. Here you have the option of selecting the required components and technologies in a web interface [1] and generating a complete project framework from them. After the generated archive is on your own computer, it can be unpacked and a project structure appears that can be opened with any IDE. Hello World programs are included, which enable the application to be run immediately.

There is a similar project on the Java EE side. The basis for this is the WildFly Swarm project. You can also - as with SpringBoot - select the desired technology standards on a website [2]. However, in contrast to Spring Boot, only the pom.xml generated with the selected dependencies. In my last attempt, no Hello World program parts were generated that would allow you to try it out immediately. Here the service at Spring Boot is clearly higher and thus the time for the initialization of a project is shorter.

With KumuluzEE we also have a version adapted to the Java EE area [3]. As with the candidates already mentioned, there is also a generator here, in which the individual components can be selected. Based on this, there will be another one pom.xml generated.

At this point I would definitely like to stay away from the discussion of whether to prefer Spring or Java EE. From a purely technical point of view, I would like to express that both stacks are very, very extensive and only show their full potential when you get involved in the full stack. The update cycles of the two stacks are also important.

Other full-stack solutions as an alternative

Just as a complete solution is offered with Java EE or Spring, there are also other full-stack solutions, mostly with a focus on a specific area of ​​application. Here, too, the developer is provided with a template that consists of a compilation of various technologies that have been more or less coordinated with one another in the respective version. Since this is an integrating project, replacing one of the core components used in it usually involves more work. However, this does not mean that these approaches are not efficient for a specific problem; rather, it can be a very good and efficient tool.

Some projects offer solutions that do not contain a UI and target microservices architectures that are purely data-driven. At the moment, the combination of REST and JSON is usually used for communication.

With Spark [4] we have a representative who has set itself the goal of offering a Java 8-based solution environment for the implementation of REST microservices. After the dependency has been added to the project, for example in the pom.xml in the case of Maven, one starts with the definition of the request paths that should be available. There you have the opportunity to manipulate the request / response objects.

In the following example we will make a GET request on the path /Hello with a result Hello World answer.

Functional interfaces were used almost everywhere so that the developer can work with lambdas when defining the logic. What seems simple and simple at first glance must of course be checked to see whether it is still manageable for the planned project size. For some of the projects, I personally have the impression that they are well suited for fairly straightforward requirements.

If you want to delve a little further into the deeper levels of technology, Netty [5] is a good entry point. Here you can fine-tune the communication. However, one is also forced to deal with the peculiarities of TCP / IP communication. We will not go into this solution here, as it is usually a very specific area of ​​application.

Of course, I don't want to hide the fact that there are also cluster solutions in the area of ​​microservices. By this I mean technologies like Hazelcast, Vert.x., Akka, Lagom and many more.

Mixed solutions are also a viable option

If you look at all of these solutions, it can happen very quickly that no version actually fits. There are actually only three ways here. First: The project is not even started or changed, so everything stays as it is. Second: The decision is based on the assumption that one is going for the tolerable ...