Все чаще слышу высказывания типа “монолиты не так уж плохи”. На этом основании можно предположить, что микросервисы благополучно миновали пик чрезмерных ожиданий и перешли в стадию избавления от иллюзий в хайп-цикле Gartner. Пока этот архитектурный подход находился на пике, многие команды успели прострелить себе ногу (а то и обе) применяя микросервисы. Видел даже примеры, когда из монолита делали прям какие-то наносервисы и разделяли их на слои API, бизнес-логика и слой доступа к данным (мне страшно представить как они справля(ются/лись?) со сложностью эксплуатации этого хозяйства).
Один из наиболее часто задаваемых про микросервисы вопросов обозначен в заголовке этого поста. Лучшие умы (я даже пытаться не буду) не смогли дать ответ лучше “микросервис должен помещаться в голову одного человека” и “в команде микросервиса должно быть столько людей, чтобы их можно было накормить двумя пиццами”. Не сильно проясняют ситуацию, не правда ли?
А что если этот вопрос неправильный? Очень часто мы задаем неправильные вопросы, когда нам не хватает компетенции. Может стоит заменить вопрос на “какими навыками необходимо обладать, чтобы использовать микросервисы и предохранить ноги от огнестрела”?
На мой взгляд главное условие - умение разрабатывать слабосвязанные системы. Если ваша команда не способна построить монолит с внутренней слабосвязанной архитектурой, то в микросервисы лучше не соваться, прострел ноги гарантирован. Частично принципы проектирования приложений SOLID, DRY, KISS, YAGNI подходят для проектирования микросервисов. А ответ на вопрос “а как это все применять применять в мире микросервисов?” подскажет только практика.
В итоге, каждой команде самостоятельно придется определяться с моментом, когда начинать смотреть в сторону микросервисов (и смотреть ли вообще), как именно определять их границы и размеры при выделении из монолита. Через опыт и практику…