Здравствуйте, Ночной Смотрящий, Вы писали:

scf>>Исключительно из-за роста сложности или есть другие соображения?

НС>Services form information barriers
Вообще-то это считается преимуществом
НС>Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
Да, но эти затраты невелики и чувствительны исключительно для синхронного кода, когда запросы идут по очереди, а не параллельно.
НС>Testing and deployment are more complicated
НС>Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure
НС>Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.
да, сложно. да, при неправильном разбиении на микросервисы будет много поли

НС>Ну и ссылочку еще добавлю. Оно всегда вылазит, когда мы от хипста-демок переходим к реальным энтерпрайз системам.
я бы сказал, что в реальных системах consistency нужно для небольшого подмножества данных, которое и следует хранить в одной базе с транзакциями. На остальном можно сэкономить, значительно ускорив систему.

Здравствуйте, Ночной Смотрящий, Вы писали:

scf>>Исключительно из-за роста сложности или есть другие соображения?

НС>Services form information barriers
Вообще-то это считается преимуществом
НС>Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
Да, но эти затраты невелики и чувствительны исключительно для синхронного кода, когда запросы идут по очереди, а не параллельно.
НС>Testing and deployment are more complicated
НС>Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure
НС>Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.
да, сложно. да, при неправильном разбиении на микросервисы будет много боли

НС>Ну и ссылочку еще добавлю. Оно всегда вылазит, когда мы от хипста-демок переходим к реальным энтерпрайз системам.
я бы сказал, что в реальных системах consistency нужно для небольшого подмножества данных, которое и следует хранить в одной базе с транзакциями. На остальном можно сэкономить, значительно ускорив систему.