Microservices

Some microservices can have their own user interfaces. For example, if a particular department within a larger organization has its own microservice, it makes sense that the user interface is also specific to that department. Since the microservice is designed for internal use, it’s not likely to require as much scaling as, for example, a public-facing webshop. Therefore, it makes more sense to build the microservice as a Vaadin application, with its own Vaadin user interface. The service can still expose an API for other microservices to use.

Look at the following example:

In this fictional organization, orders, invoicing and shipping are handled by separate departments. Each department has its own microservice with a Vaadin UI specialized for their needs. The microservices are also communicating with each other through an event bus.

Sometimes, you may have to build a user interface for a specific group of users that need to interact with multiple microservices through some API. In this case, the user interface alone becomes a microservice itself, but without an API. The user interface aggregates multiple microservices into a holistic user experience, preventing the user from having to jump between multiple user interfaces in their day-to-day work.

Look at the following example:

In this fictional organization, the warehouse workers need access to both the product catalog, the inventory service and the shipping service. These microservices are all maintained by different teams, who use different frameworks (such as Spring Boot, Node.js and .NET) to build them. The microservices expose REST APIs for the user interface to use while communicating with each other through an event bus.

The warehouse UI is a Vaadin application that provides not only the user interface itself but also acts as its own API gateway. In other words, there’s no need to set up a separate API gateway since the Vaadin application can communicate directly with the other microservices. This is effectively the Backend For Frontend (BFF) pattern.

You can scale specific microservices according to demand. This is beneficial if different parts of the system have varying loads. By only scaling the parts that need it, you can use the hardware resources more efficiently, thereby saving money.

Since the microservices are decoupled and communicate over standardized network protocols, the teams can choose the best technology stack for their requirements. This also reduces the risk of vendor-lock-in.

Well-designed microservices can handle failures gracefully, either by degrading functionality or by employing fallback mechanisms. Given the fact that they are also loosely coupled and independently deployable, the system as a whole becomes more resilient to disturbances. The failure of a single service won’t take down the entire system.

Teams can work on their own microservices at their own pace and deploy them as often as they like, without affecting the rest of the system. Microservices can be developed in parallel and features can be deployed faster.

As the number of microservices increases, so does the number of moving parts. Getting these parts to interact efficiently and consistently isn’t easy. Data integrity is harder to achieve when multiple services are involved in implementing the same business process, especially when any of these services can go down at any time.

If you’re not careful, your efforts may result in a distributed monolith that has none of the advantages of microservices, but all the disadvantages. In the worst case, you may end up with a Distributed Ball of Mud, which is even worse than a "Big Ball of Mud".

Letting teams choose their own technology stacks was listed earlier as an advantage, but that can also be a disadvantage. Having too many technology stacks can make it more difficult to move developers between teams, which is a risk for the organization. Furthermore, the development and deployment environment — with its continuous delivery chains and all — becomes more complicated the more technology stacks it needs to support.

Microservices communicate over network calls, which are inherently slower than function calls. Furthermore, network calls are inherently less secure than function calls: They require more overhead for encryption, decryption, authentication, etc. If not managed, this leads to poor performance of the system.

A distributed system consisting of multiple processes is more difficult to test and debug than a single process running on a single machine. The root cause of an issue observed in one microservice may be in a different microservice.