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

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.