Technology stack when converting a monolith to microservices?

Question

Software design

The bottom line is this, there is a monolithic self-written accounting system, ancient as a mammoth's droppings (an infernal mixture of CRM, ERP + reporting and analytics block). All this works slowly and sadly.
All of a sudden there were resources to turn it all into something more modern. Similar solutions offered on the market (first of all, we looked at 1C, of ​​course) are either very difficult to finish, or they have a completely horse price tag.

The following is stated - switch to thin clients (access to the system through a browser), each of the blocks (as long as there are 4 of them, they may want more) should be autonomous and independent from others (in terms of support and updates), support data exchange through a common API ( ideal http, TCP/IP allowed), maximum use of free software, up to 1000 users.

The refactoring of the old business logic is more or less already underway, now you need to choose the right platform for this project. In general, an architecture of microservices suggests itself, but there are concerns about data consistency.

In general, I ask you to express your thoughts about the stack of necessary technologies for deploying such an application.

Answer 1

Approach the decision easier and calmer.
Let's say we had a Django (Python) system - a huge system with a bunch of stuff. We figured it out and realized that the breakdown of a monolith into microservices does not have to be "global and complex". You can divide the monolith into smaller monoliths:
1) Moved the authorization service from the Django monolith to a separate Django system.
2) Moved the affiliate module from the Django monolith to a separate Django system.
3) Moved the report building module from the Django monolith to a separate Django system and installed a queue manager so that the request is not blocked.
4) Moved the payment module from the monolith on Django to a separate system on Django.
Etc.
As a result, we continued to work on the same Django, we only got several independent systems in different repositories (which can be rolled, stopped, updated independently), we got a more flexible request transmission system (direct, queue managers, etc.), plus isolated data somewhere then directly physically different bases, and somewhere different users with different rights.
Well, i.e. you don’t have to think so globally right away, you can just beat the systems into smaller pieces on the same stack that you are working on and it will already be better and easier. And then crush smaller pieces if necessary.

Answer 2

And there will be no considerations. The story is spherical in a vacuum and the “microservices” themselves are generally the simplest part. But with the migration process and its detailed planning, you can suffer. In principle, we can immediately say that systems that exist as a monolith for more than 5 years rarely take less time to change the architecture

Answer 3

https://ampp.org/ and "direct hands" of the architect.

Answer 4

There are adult systems microsoft \ oracle and others ibm
Do on them.
By the way, collection and processing are traditionally done at different complexes. Single database only.
These are not microservices, this is a common architecture.
Using http/s as a transport will add extra overhead, both in ping and volume.
About free (open source). You pay for functionality, imagine you wanted to draw something like power bi on your own?
Impressed?
So divide the system into 2 parts:
1. Workstation for the user - everything related to operational input and processing
2. Workstation for analysts - everything related to analysis and reports
Platform:
Net core, MS SQL server, SSRS options are possible of course

Answer 5

1. You really need to think well about the API
2. For the front, React is fast and convenient
3. For the back, use what is already there and what your programmers know.
4. APItoClient layer - Appolo for example,
there are many options, but this one looks the least problematic.