Microservices, split the monolith!

Some good reasons to split; the pace of change established on your goals, if you aim to lower the release cycle you want to isolate consequences, Team Structure should reflect your business and geographic logic, Security will drive why you want to split the monolith and it’s a great way to increase security and reduce costs by tightening were you need to, and, technology because teams which are proficient with specific stacks will happen as you grow into Microservices.

Assume the Cost of Change, mistakes will happen throughout your journey although there are ways to reduce it by making it granular - start with 1 service and add another once that one is figured out opposed going from 5 to 20 (pain) and make as much mistakes as possible in the witheboard understanding the boundaries and dependencies.

Identify parts of your code which can be worked in isolation, glue together things that change together and break apart what changes independently.

Make sure you use Business Logic which reflects your organisation logic and create packages which represent your organisation, ex. Catalog; Finance; Logistics; Customer Service, Warehouse, etc and identify dependencies (databases too).

The rule to size the microservice also in function to be able to re-code it in 2 weeks will give you a great head start into achieving a smoother transition 

About Databases, code doesn’t cross DB, use API calls instead of direct calls allowing you to change and decouple the service by you keeping the request structure or call intact.

One good practice is to release different versions of your API allowing for legacy requests to remain active while you alter the code elsewhere to use the newer versions opposed to just shift and break communication.

Splitting code is traditionally simpler than Data and this is one of the stumbling blocks of change.

You might have to consider technology options or even split/partition your data which will require a very strategic and careful testing and planning (right doctor!) don’t invent the wheel or write your PhD about it, there are in the market a lot of good options.

There isn't a point mention to methods all possible methods and pitfalls here since they are very tailored to your organisation model and needs.

Reporting usually requires a different approach since you will want to consolidate relate and generate insights from multiple services, an Event Bus could be in play.

With static data which doesn’t change regularly (ex. list of countries) consider making it code to make it easier to push it to your service or even use as configuration files to avoid data duplication or having to design a service of it’s own with a DB API LB etc.

Start small and build it up in your failures which will lead to success.