Основное отличие микросервисов от монолита в том, что они более автономны и изолированны друг от друга. Общаться между собой они, кстати, могут не только по http, чаще это происходит через очереди RMQ или кафку какую-нибудь.
Если несколько микросервисов у вас будут хранить данные в одной БД или вообще в одной таблице, то это несколько ухудгает изоляцию и ваша микросервисаня архитектура снова начинает пахнуть монолитом, только затейливым таким монолитом, поскольку, возможно, вы на следующих этапах захотите вынести общий код из микросервисов в какие-то библиотеки, начнете импортировать одни и те же модели разными "микросервисами". И получите в итоге тот же монолит со всеми его недостатками, а достоинства микросервисной архитектуры потеряете, приобретя при этом её недостатки.
Кроме того, простые по своему устройству микросервисы положено при необходимости масштабировать горизонтально, с чем будут проблемы у докера с его компоузом.
амое правильное развёртывать микросервсиную архитектуру в кубернете.
При этом очень часто, если конечно вы не живёте в монорепозитории, конфигурация развёртывания настраивается вообще в отдельном проекте.
Для разработки и отладки вы обычно изолированы в своём микросервисе, вам может быть достаточно для девелоперских нужд докер-компоуза, который поднимет вам БД, nginx, очереди и что вам там еще надо для нужд локальной отладки и тестирования.
Простой
