[Перевод] Компромиссы микросервисов @habrahabr

От переводчика: с момента выхода популярной статьи Мартина Фаулера «Микросервисы» (перевод на Хабре) прошло уже достаточно времени, чтобы автор смог дополнить свои наблюдения свежим опытом проектирования и разработки микросервисов в различных компаниях, и рассказать о нем в новом посте, чей перевод представляется вашему вниманию.

Многие команды разработчиков нашли архитектурный стиль микросервисов подходом, превосходящим монолитную архитектуру; другие команды выяснили, что для них микросервисы — лишняя обуза, подрывающая производительность разработки. Как и у любого стиля архитектуры, у микросервисов есть свои плюсы и минусы. Для того, чтобы делать осознанный выбор, вы должны понимать эти свойства и уметь рассматривать их на фоне собственных конкретных условий.

Микросервисы дают преимущества…	…ценою издержек
Жесткие границы модулей Strong Module Boundaries Микросервисы усиливают модульную структуру, что особенно важно для больших команд разработчиков.	Распределённость Distribution Распределенные системы тяжелее программировать, поскольку удаленные вызовы медленные и всегда рискуют неудачей-отказом.
Независимый деплоймент Independent Deployment Простые сервисы проще деплоить, и, поскольку они автономны, меньше вероятность отказа системы в случае, если что-то идет не так.	Cогласованность в конечном счете Eventual Consistency Поддержка сильной согласованности чрезвычайно сложна для распределённых систем, и это означает, что придется иметь дело с согласованностью в конечном счете.
Технологическое разнообразие Technology Diversity С микросервисами вы можете смешивать несколько языков, фреймворков и технологий хранения данных.	Эксплуатационная сложность Operational Complexity Вам потребуется опытная команда эксплуатации для управления множеством сервисов, которые будут регулярно редеплоиться.

Читать дальше →

via Хабрахабр / Интересные / Тематические публикации http://ift.tt/1H4yiXY