Так как сервисы все-таки взаимодействуют, они уже не являются совсем независимыми. И выбор разных стеков или БД - становится или очень дорогим или вообще невозможным.
Ни в одном определении микросервисов нет ничего про "шину сообщений". Да и какая разница, шина сообщений или сервис-меш? Связность от этого не меняется (ну, если только не pub-sub, при этом связность вырастает).
Например у тебя разные НФТ для разных частей поддомена (за который отвечает команда). Разные требования по безопасности, производительности, жизненному циклу и так далее...
Только архитектурный стиль или независимость БД никак не связаны с низкой связностью компонент. Связность зависит от анализа, а не от монолита или SOA.
Вот да, там очень хорошо показана бесполезность термина "микросервис" ) Я предпочитаю использовать формулировки Фаулера (как одного из основных популяризаторов), так как у Ньюмана в разных книжках используются разные формулировки )
Интересно, почему автор считает, что он разбирается в микросервисах? Пока лишь видно, что плохо разбирается в RPC, REST, SOAP, HTTP, виртуализации и в паттернах распределенных систем.
Хм, писать фронт в 2025ом на ReactNative и Swift? Проще уж взять один общий Flutter и уменьшить стоимость разработки фронта процентов на 30, еще и сразу получив рынок андроида.
Нет, конечно, я про размер оперативки для контейнера, содержащего работающий сервис. Но интеграция с etcd (а зачем оно нужно, кстати, лидер в кафке не в etcd живет), https, s3 не требует кучи памяти. Как и несколько небольших кэшей, хотя все зависит от размера записей в кэше, если там по 10тысяч элементов по килобайту, то они уже 20 мегабайт съедят.
Другое дело, что обычно на Java/Kotlin сделают все на спринге, что позволит потратить на подобные задачи в два раза времени, хотя, конечно, при этом уже нужно будет 128 оперативки, а не 90, но это обычно всем пофиг.
Ни для одной из этих целей не нужны микросервисы.
Так как сервисы все-таки взаимодействуют, они уже не являются совсем независимыми. И выбор разных стеков или БД - становится или очень дорогим или вообще невозможным.
Это всего лишь одна из множества книг. Как и все прочие - как с верными, так и с неверными утверждениями.
И чье это определение? И кто его придерживается?
И связность никак не зависит от "одна БД" или "несколько БД".
Так и в монолите нет рисков. Добавил archunit для проверки доступов - и все автоматически проверяется.
Сообщения можно передавать кучей разных способов. Обращение к view в БД - тоже отправка сообщения на чтение, никакой разницы. И соответствует ООП )
Ни в одном определении микросервисов нет ничего про "шину сообщений".
Да и какая разница, шина сообщений или сервис-меш? Связность от этого не меняется (ну, если только не pub-sub, при этом связность вырастает).
А ты не путаешь аутентификацию и авторизацию?
Например у тебя разные НФТ для разных частей поддомена (за который отвечает команда). Разные требования по безопасности, производительности, жизненному циклу и так далее...
Хм, а как выглядело "свалить"? Один процесс, одно ядро, ограничение памяти - как остальные запросы-то страдали?
Есть куча возможностей ограничить ресурсы на одного клиента.
Это исключительно особенности настройки БД, не какой-то рокет-сайнс.
Ну и, заметим, шансов плохим запросом убить все сервисы, которые в нем участвуют (при каком-нибудь джойне, реализованном ручками на API GW) не меньше.
Хм, мультимастеров не существует )
Ну невозможны они теоретически.
Хм, почему БД ложиться? Одно соединение тормозит - и все.
А почему shared database - антипаттерн? Почему интеграция через БД - плохо, а интеграция через kafka - нет (хотя это та же самая интеграция через БД)?
Вообще, любые паттерны или антипаттерны не имеют смысла без описания граничных условий и ограничений.
Только архитектурный стиль или независимость БД никак не связаны с низкой связностью компонент.
Связность зависит от анализа, а не от монолита или SOA.
Вот да, там очень хорошо показана бесполезность термина "микросервис" )
Я предпочитаю использовать формулировки Фаулера (как одного из основных популяризаторов), так как у Ньюмана в разных книжках используются разные формулировки )
Интересно, почему автор считает, что он разбирается в микросервисах?
Пока лишь видно, что плохо разбирается в RPC, REST, SOAP, HTTP, виртуализации и в паттернах распределенных систем.
Хм, на рынке таких уже давно весьма много, в чем проблема?
Да и переучить с Swift или Kotlin не проблема.
Хм, писать фронт в 2025ом на ReactNative и Swift? Проще уж взять один общий Flutter и уменьшить стоимость разработки фронта процентов на 30, еще и сразу получив рынок андроида.
Нет, конечно, я про размер оперативки для контейнера, содержащего работающий сервис.
Но интеграция с etcd (а зачем оно нужно, кстати, лидер в кафке не в etcd живет), https, s3 не требует кучи памяти. Как и несколько небольших кэшей, хотя все зависит от размера записей в кэше, если там по 10тысяч элементов по килобайту, то они уже 20 мегабайт съедят.
Другое дело, что обычно на Java/Kotlin сделают все на спринге, что позволит потратить на подобные задачи в два раза времени, хотя, конечно, при этом уже нужно будет 128 оперативки, а не 90, но это обычно всем пофиг.