How to separate the monolith to microservices?

How to separate the monolith to microservices?

How to separate the monolith to microservices?

This is not a trivial problem... But it is worth its price.

Thanks God we have DZONE.com :-)

As we can read at
https://dzone.com/storage/assets/3259596-dzonerefcardz-gettingstartedmicroservices.pdf
before we can start breaking up a monolith, it’s important to make sure the monolith is designed following good software architecture principles.

Some common rules are:
1. Separate your concerns. 
Consider using Model-ViewController (MVC) for front-end abstraction.
Use welldefined APIs for high cohesion and low coupling.
Separate interfaces/APIs and implementations.

2. Use Convention over Configuration (CoC). 
Keep configuration to a minimum by using or establishing conventions.

3. Follow the Law of Demeter. (similar to "Single Responsibility Principle" = SRP) Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Each unit should only talk to its friends. Do not talk to strangers! Only talk to your immediate friends.

4. Use Domain-Driven Design. 
Keep objects related to a domain/component together.

5. Focus on Automation. 
Automate testing and fully automated deployment pipeline.

6. Design to Interfaces / APIs.
Classes shouldn’t call other classes directly just because they happen to be in the same archive. Such group could be later a microservice...

7. Group code by functionality, not by layer. 
Monoliths usually have a layered architecture, and it’s common to group classes by layer. Instead you should break up your code into packages separated by functionalities to allow easier splitting into future microservices. It also makes easier to see the dependencies between your future microservices.

8. Make your code stateless and externalize your application’s state. 
One cannot rely on static variables or global variables as the source of your application’s state. Use external data sources such as key-values stores or databases to maintain state.

Known problems:

1. Sharing
2. Asynchronicity
3. Security
4. Simplicity
5. Evolution
6. Health