я просто резюмирую последние сообщения, ничего не добавив от себя ;)

Хотя при архитектурной трансформации его приходится так воспринимать.

... и локальным MS SQL сверху придавить

В качестве шины интеграции с монолитом

(а ведь буквально несколько сообщений назад всё выглядело так замечательно...)

уже давно нет

Просто есть порог сложности, до которого микросервисы нафиг не нужны.

комплексности, не сложности

Данное утверждение предполагает что после этого порога микросервисы нужны?

и это не луч, а отрезок на n-мерной линии. Тут не нужны, тут нужны, тут снова не нужны

Просто есть обратная шизофрения, когда мы настолько боимся получить hard-coupled-что-то, что там, где нужны доски, мы пилим в щепки, а потом из них склеиваем доски.

а потом еще один порог, после которого они становятся опять не нужны )

Скорее с @Priani4ek согласен, что это многомерная хрень.

Да ещё и подвижная.

Я обычно думаю про микросервисы как про решение организационных, а не технических проблем. И тогда все становится чуть проще для принятия решения.

Инетерсный взгляд. С чего вы это взяли?

SOA и Микросерсная архитектура - это архитектурные стили, то есть наборы принципов и паттернов. Какие сокеты и сетевые соединения, о чём вы.

Как этот набор паттернов ограничивает в выборе средств коммуникации сервисов?

- Решения могут быть распределённые и нет.
- Даже монолиты могут распределённые и нет. Миллион раз это обсуждали
- В распределённых решениях баланс ресурсов смещается в сторону сети.
- SOA и Микросервисная архитектура - это service based архитектуры, строительным блоком которых являются сервисы
- SOA и Микросервисная архитектура предполагают построение распределённых решений
- SOA отличается от Микросервисной архитектуры в основном таксономией сервисов и подходами к декомпозиции, соотвественно
- в  SOA и Микросервисной архитектуре баланс ресурсов смещается в сторону сети, при этом ничего не мещает при выполнении дизайна "играить" баланосом ресурсов, в каких-то местах (сервисах) нагружая память и проц, диски и пр