Microservices architecture for spring boot application

Question

I have a Spring Boot application which is containerized. The application has become huge with lots of complications and its difficult to maintain it. So I am thinking of breaking it into microservices. I have gone through the theory for microservices and have a basic understanding about it.

First things first... I have these modules directly connected to the spring boot app:

1. Mongodb - Non-relational DB
2. Influxdb - TimeSeries DB
3. MQTT - To publish notifications to UI and to spring boot app
4. UI application - To get necessary data via APIs

Here are some major features which I have to convert to microservice:

1. Trending
2. Alarm
3. User Authorization

Main Question: As per above data I have decided to go with the following type of design, enter image description here

Please suggest me if this is ok... or do I need to consider any other approach. Also these individual microservices will be run as individual docker containers.

• T. Sar: Those aren't microservices, they're just plain-old vanilla "services". Unless they're super-small and self-contained (which they don't appear to be), they're just services. And that's fine - there is no problem in creating services instead of microservices.
• Prasad Patil: @T.Sar, can you please tell me more on why do you think its not microservice. I am actually new in this architecture designing.
• Bart van Ingen Schenau: @PrasadPatil, the term Microservice is typically used for a service that has a narrow scope and is independenty deployed and versioned from other services. Communication between microservices happens over a network connection.
• DavidT: It is generally seen as an anti-pattern to share the database between independent services/micro-services. As soon as you allocate seperate database to each service it forces you to think more carefully about the boundaries between the services, hence you probably need to explain your reasoning for breaking out micro-services, i.e. are you "Premature Micro-servicing".
• Prasad Patil: @Bart van Ingen Schenau, I will deploy these services as independent docker containers. Each service has very specific task as their name suggests. Like alarm service will just compare alarm configuration and present value of sensors I value and configuration matches then alarm will be raised. Is this the correct approach or can you please suggest some corrections ?

Answer 1

From a top level view your design looks fine. Using a API gateway and a message broker are fairly standard designs. I would be somewhat concerned about the databases, since micro services should typically have separate databases to ensure the services are actually independent. It is likely that not all services need both non-relational data and time series data, some might not need a database at all.

But the more concerning thing in my opinion is the motivation for using a microservice architecture in the first place. If you struggle with enforcing modularity and separation of concerns in your existing application there is nothing magical with microservices that make this happen automatically.

You need to spend quite a bit of thought and planning about how functionality should be divided and how services should communicate to have any chance of success. If you have done this you could just as well apply it to a single application, sometimes called "Modular Monolith". Microservices tend to make the boundaries between modules more rigid and more difficult to change, and this can be a good or a bad thing depending on circumstances.

The main advantage of micro services is for large organizations, since it lets teams work more independently. The more rigid boundaries help allowing teams to work undisturbed. But if you only have one team responsible for all services you will likely have additional overhead for fairly little benefit.

In the end the important thing is the division of responsibilities, regardless if you are using Microservices or not, and we cannot help you with this since we do not know the application domain.

• Prasad Patil: thanks for your opinion. Was looking for something like this which would point me in some direction. So, if you see.. the different services are not interlinked but there is some data which will be commonly used between these services. For example: Details about devices (sensors).. So the alarm service will look at the alarm configuration and raise an alarm if the sensor value equals or exceeds the alarm value.
• Prasad Patil: I have just started with exploring microservices, can you point me to what changes I can make related to databases or the overall architecture. OR even some source where I can expand my understanding. As far as a modular monolith is considered its feasible for my current scenario... but going forward there are more services to come which will make the monolith more bulky and error prone. Hence, I need to migrate to microservice so that our team need not spend more time segregating the monolith after its too huge.
• JonasH: If services share data they are interlinked and interdependent, such dependencies should be part of the services APIs, not hidden in a database. There are plenty of lectures and articles on both microservices and modular monoliths if you look around, I cannot recommend anything specific. But this sound kind of like the "Big Rewrite", and that is a dangerous thing to do. There is a risk you do not fully understand all the dependencies and complications. In most cases I would advocate for gradual refactoring since it will be much lower risk.