– можно ответить, что архитекторами до Solution Architect эволюционно по технической ветке, а корпоративным, либо по технической ветке, либо по менеджерской, включая бизнес—аналитика. При этом стать архитектором можно в любое количество лет.
Внедрение микросервисов начинается с бизнеса, когда маркетинг начинает делать эксперименты – запрашивать фичи в виде MVP, потом тестировать на рынке, после либо браковать (что редко), либо дорабатывать. Доработка требуется как после подтверждения предположения, так и ошибочного в виде корректировки. Для службы эксплуатации это означает выкатку огромного количества фич, которые были разработаны впопыхах и могут обрушить основное приложение – монолит. Эта служба пытается запускать эти изменения в изолированной среде в виде отдельного функционала, для чего просит отдел разработки, разрабатывать их отдельно – в виде микросервисов.
Нужно разделять два уровня разделения: технологическое и доменное. Технологические особенности в работе едины, так как что сервисы, что его компоненты, если он разбит на составные части технологически запускаются и поддерживается одинаково. Но, в отличии от сервисов, которые должны быть минимально взаимосвязаны с другими сервисами и должны обеспечивать определённое API и SLA, то компоненты сильно связанны. Причиной разделения на компоненты имеют технологическую природу. Например, интернет-магазин содержит сервисы, такие как сама интернет-витрина, сервисы оплаты, складские сервисы, а интернет-витрина представляет из себя сервис на CMS Joomla! и систему управления базой данных (СУБД) MySQL. Здесь разделение сервиса на составные части произошло из-за разных программных продуктов, написанных на разных языках программирования. При этом, для заказчика это единый сервис на CMS Joomla!, выполняющий единую функцию предоставления интерфейса для заказа пользователям в онлайн, предоставляемый хостингом как единый сервис (по отдельности не будет работать), может работать как каталог товаров без других сервисов (оплаты, заказа). С технологической точки зрения компоненты сервисы:
* По одиночки не функциональны;
* Сильно связанны, так как на каждый запрос к CMS формируется множество запросов;
* Интерфейсы взаимодействия сложны и разнообразны – тут применяется даже не API, а язык взаимодействия SQL;
* Сильно связанны функционально через сложное техническое API – для пользователя известно лишь
поддерживаемая совместимость одних версий CMS с другими версиями СУБД.
Разделение системы на микросервисы начинается с анализа их границ, анализ выгод от разделения и привнесённых сложностей распределённой системой. Отделять микросервисы лучше при комбинации необходимости:
* Технологической необходимости, например, большая нагрузка, которую сложно выдержать без отделения, например, масштабированием, другой вид поддержки (SLA);
*
