Migrating multi-module project to microservices?

Question

I have multi module application. To be more explicit these are maven modules where high level modules depends on low level modules. Below are the some of the modules :-

    user-management
    common-services
    utils
    emails

For example :- If user management module wants to use any services from utils module, it can call its services as dependency of utils is already injected under user-management. To convert/call my project truly following microserives architecture, I believe i need to convert each module as independently deployable services where each module is a war module and provides its services over http(mainly as resful web services) . Is that correct or anything else need to be taken care of as well ?

Probably each modules now has to be secured and authentication layer as well ?

If that's the crux of microservices I really do not understand when someone ask whether you have worked on microservices as to me Its not tool/platform/framework but a simple concept to divide you monolithic application in to smaller set of deployable modules whose services is available through HTTP. Is n't it ? May be its another buzz word.

Update:- Obviously there are adavantages going micro services way like independent unit testablemodule, scalable as it can be deployed on separate machine, loose coupling etc but I see I need to handle two complex concerns also

1. Authentication:- For each module I need to ensure it authenticates the request which is not the case right now
2. Transaction:- I can not maintain the transaction atomicity across different services which I could do very easily at present

Answer 1

In one way you are correct, in Microservices from outside it looks like this. When you go inside as you rightly mention about two complex concern :

Authentication:- For each module I need to ensure it authenticates the request which is not the case right now

Transaction:- I can not maintain the transaction atomicity across different services which I could do very easily at present

Apart from this there are various things which one need to understand otherwise doing and deploying microservices would be very tough:

I am mentioning some of them here, complete list you can see from my post:

• What exactly is a microservice? Some said it should not exceed 1,000 lines of code.Some say it should fit one bounded context (if you don't know what a bounded context is, don't bother with it right now; keep reading).
• Even before deciding on what the "micro"service will be, what exactly is a service?
• Microservices do not allow updating multiple entities at once; how will I maintain consistency between entities?
• Should I have a single database cluster for all my microservices?
• What is this eventual consistency thing everyone is talking about?
• How will I collate data which is composed of multiple entities residing in different services?
• What would happen if one service goes down? How would the dependent services behave?
• Should I make a sync invocation between microservices to always get consistent data?
• How will I manage version upgrades to a few or all microservices? Is it always possible to do it without downtime?
• And the last unavoidable question - how do I test the entire application as an integrated application?
  • How to do circuit breaking? (if one service down should not impact other)
  • CI/CD pipelines and .......

What we understood while starting our journey in microservices are:

1. Design pattern for breaking business problem in microservices is Domain Driven Design
2. Platform which support microservices development. (we used Lagom for this) which address some of the above concern out of the box

So in all while moving towards multiple process arch. communicating using Rest or some other methods, new considerations needs to be taken care which are not directly visible in Monolithic, and people want to whether you know about those considerations or not.

Answer 2

What you have understood is perfectly good and you have found the right area where microservices are getting complex over monoliths (Distributed Transaction) but let me clear up some points about microservices.

1. Microservice doesn't mean independent services exposed over HTTP: A microservice can communicate with other services either in a synchronous or asynchronous way, so REST is one of the solutions and it is applicable for synchronous communication but you can perform asynchronous communication too like message-driven using Kafka or hornetq etc. In synchronous communication an underlying service can call over Thrift protocol also.

2. Microservice following SRP: The beauty of microservices is that each service concentrates over only one business domain use case, so it handles only one domain object's functionality. But utils module is for common methods so every microservice depends on it. So even a small change in the utils module needs to build all other microservices so it is a violation of the microservices 12 principles so dissolve the utils service and make it local with each service.

3. Handling Authentication: To be specific a microservice can be one of three types:
   a. Core service: Just perform a domain operation (like account creation/updation/deletion)
   b. Aggregate service: Call one or more core service, gather results and perform some operation on it.
   c. Edge service: Exposed to a client (like Mobile/browser etc). We sometimes call it a gateway service; the crux of this service is take a user request and based on the URL forward it to an actual microservice. So it is the ideal place to put authentication if it is common for all microservices.

4. Handling Distributed Transaction: Yes this is the hardest part of microservices but you can achieve it through an event-driven/message-driven way. Every action pops an event; a subscriber of this event receives the same and does some operation and generates another event. In case of failure it generates a reverse event which compensates the first event created.

   For example, say from micoservice A we debited 100 rupees so create an AccountDebited event. Now in microservice B we try to credit the account. If it is successful we create AccountCredited which is received by A and creates another event AmountTransfered. In case of failure we generate an AccountCreditedFailed event which is received by A and generates a reverse event - AccountSpecialCredit - which maintains the atomicity.

Answer 3

How you split your application depends on the type of modules you have. If the module contains business logic than it makes sense to create a new service and communicate via Http or Messaging. On the other hand if your module has no business logic, but just a set of helper functions in might be better to extract it to a separate public/private maven package and just use it as a dependency.

Yes, microservice is a buzz-word that just recently became popular, but a concept has been around for a while. But it also comes with more than that. While it gives a benefits of scaling and independent service deployments, it comes with a price of complexity of managing and orchestrating big amount services.

For example in monolith application when you just call a function from another module you know for sure that it is always available for calling. With microservices some of the services might go down because of disruption or deployment, in which case you have to think about handling these situations gracefully (for example apply circuit breaker pattern).

There are many other things to consider when doing microservices and there are many literature available on this topic. I read Microservices: From Design to Deployment from Nginx. It's short and sweet.

So when people ask you Have you worked with microservices before? I guess they want to know if you familiar and had some experience with all the pitfalls of this concept.

Answer 4

In my opinion microservice architecture marries well with DDD

I think you should consider your multi-module project as a "monolith" and do your microservice separation based on domain concepts and not on maven projects.

Ex: Do not create a microservice called "utils" but rather a microservice called "accounts" or "user-management" or whatever your domain is. I think without domain driven development it kinda loses its usefulness.

It is really easy afterwards to work on different aspects of the domain knowing that it is separated by the rest. You should check out hexagonal architecture by Alistair Cockburn

Answer 5

What you have is mostly correct, but you appear to be considering some things as requirements when they are not, and you are forgetting one very important characteristic that microservices are supposed to have.

The main characteristics of microservices are statelessness and independence. Whether they are "WAR" modules and whether they provide their services over "HTTP" (and certainly whether they are RESTful) are secondary concerns and you may hear arguments to the contrary.

Statelessness means that no individual microservice may contain state. (Except for caches.) Microservices are supposed to always delegate the task of persisting data to some database module so they don't keep any state in memory. The idea is that this way, if one microservice fails, (or if an entire machine containing many microservices fails,) you can just route incoming requests to another instance (or another machine) and everything will continue working.

(Of course, if you want my opinion, it is just a cowardly acknowledgement of the fact that we don't know how to write reliable highly concurrent software, but the database guys are smart and they seem to have figured it all out, so we will just delegate the problem of maintaining our state to the software that they have written.)