Стек технологий при переделке монолита на микросервисы?
Подходите к решению проще и спокойно.

Допустим у нас была система на Django (Python) - огромная система с кучей всего. Мы прикинули и поняли, что разбивка монолита на микросервисы не обязательно должна быть "глобальной и сложной". Можно поделить монолит на более мелкие монолиты:

1) Вынесли сервис авторизации из монолита на Django в отдельную систему на Django.
2) Вынесли партнерский модуль из монолита на Django в отдельную систему на Django.
3) Вынесли модуль постройки отчетов из монолита на Django в отдельную систему на Django и поставил диспетчер очередей, чтобы не блокировался запрос.
4) Вынесли платежный модуль из монолита на Django в отдельную систему на Django.

И так далее.

В итоге, мы продолжили работать на той же Django, только получили несколько независимых систем в разных репозиториях (которые можно катить, стопать, обновлять независимо), получили более гибкую систему передачи запросов (прямые, менеджеры очередей очередей итд), плюс изолировали данные где-то прямо физически разные базы, а где-то разные юзеры с разными правами.

Ну т.е. не надо прямо так глобально думать, можно просто побить системы на более мелкие куски на том же стеке, что вы работаете и уже будет лучше и проще. А потом уже более мелкие куски дробить при необходимости.
Есть взрослые системы microsoft \oracle и прочие ibm
Делайте на них.

Кстати сбор и обработка традиционно делаются на разных комплексах. Единая только база данных. 
Это не микросервисы это обычная архитектура.

Использование http/s в качестве транспорта добавит вам лишние накладные расходы, как в пинге, так и в обьеме. 

Насчет бесплатного (опенсорсного). Вы платите за функционал, представьте вы захотели нарисовать своими силами что то типа power bi?

Впечатлились ?

Так что разделите систему на 2 части:

1. АРМ для пользователя - все что относится к оперативному вводу и обработке
2. АРМ для аналитиков - все что относится к анализу и отчетам

Платформа: 
Net core, MS SQL server, SSRS возможны конечно варианты