Удалёнка слишком хороша и поэтому она должна умереть
Общеизвестен™ такой подход к проектированию решений и, в частности, решений микросервисных, как Domain-Driven Design. Его суть, для тех кто не слышал этот общеизвестный™ термин, состоит в том, что архитектура технического решения должна моделировать сам реальный, можно сказать физический, бизнес-процесс. Из часто разбираемого типового примера: микросервисы оформления заказа, резерва товаров и проведения платежа аналогичны соответствующим структурным подразделениям реального бизнеса: заказ оформляется в точке продаж, собирается на складе, оплата проводится через бухгалтерию и всё это разные отделы, работающие между собой по определённым контрактам.
Хорошо проработанная в рамках такого подхода архитектура обеспечивает хорошее время отклика, отказоустойчивость, масштабируемость и прозрачность работы системы. При этом собираемые метрики работы системы не являются некими KPI, целевыми показателями, критерями оптимизации, а лишь служат для заблаговременного выявления потенциальных проблем и применения изменений до того, как эти проблемы наступят.
Если хорошо сформированная бизнес модель - это готовый шаблон для будущего микросервиса, который нужно лишь переложить в технические решения, то верно и обратное: сама такая организация с хорошо налаженными процессами и есть готовый микросервис. Она подчиняется тем же законам, имеет те же проблемы и пути их решения, её архитектура поддаётся анализу и доработке по абсолютно тем же подходам, и в конечном счёте тоже обеспечивает <crtl-c-ctrl-v>хорошее время отклика, отказоустойчивость, масштабируемость и прозрачность работы системы</crtl-c-ctrl-v>.
