Определение структуры приложения - важная часть работы инженера программного обеспечения. От правильного определения структуры будет зависеть стабильность работы приложения, его надежность и удобство добавления новой функциональности.
Часто бывает достаточно сложно однозначно сказать, правильно ли определена структура приложения или нет. Инженер в области программного обеспечения – это специалист, который решает задачу техническими средствами. Важно понимать какие задачи ставились перед инженерами, какие сроки были определены, менялось ли техническое задание в процессе работы, обладали ли инженеры достаточной квалификацией для решения этой задачи, участвовали ли инженеры в принятии решений по относительно структуры приложения.
Технические решения, которые предлагает инженер должны соответствовать тем задачам, которые определил заказчик. То, что правильно для одной задачи будет неправильным для другой. Наверное, не стоит разворачивать одностраничный сайт в Кубернейтесе, настраивать балансировку нагрузки создавать автоскейлинг. Для этой задачи вполне подойдет виртуальный сервер VPS (или хостинг) с предустановленной системой управления контентом (CMS) или фреймворком. Если и это покажется слишком сложным способом решения этой задачи, то можно воспользоваться конструктором сайта (например, Tilda). Вместе с тем для высоконагруженного приложения выбор Кубернейтесе будет оптимальным.
Когда мы говорим о выборе между микросервисной структурой приложения и монолитной мы подразумеваем, что мы проектируем сложную систему с высокой нагрузкой. Пришло время определиться в терминах. Под монолитной структурой приложения мы будет понимать приложение, в котором весь код приложения находится в одном месте и для доступа для метода приложения не требуется сетевого взаимодействия. Под микросервисной структурой мы будем понимать приложение, которое состоит из частей, которые взаимодействуют друг с другом посредством сетевого взаимодействия.
Среди недостатков монолитных структур часто отмечается, что можно поправить в одном месте, а отвалится в другом. Но это проблема не монолитной структуры как таковой, а ошибках в проектировании монолита. Достаточно распространенной практикой сейчас является создание монолитного приложения, которое состоит из модулей/компонентов/пакетов, которые имеют отдельный репозиторий в Гите и интегрируются в проект по мере необходимости. Это позволяет спроектировать монолитное приложение таким образом, чтобы оно состояло из относительно независимых частей.
Проблемы микросервисов заключаются в том, что как только мы выделили один микросервис в приложении мы должны думать о том, как мы до него достучимся, как сервисы будут общаться между собой. У нас будут транзакционные издержки на передачу данных по сети. Трудности с деплоем в том случае, если исправления микросервиса могут повлечь за собой изменение работы завязанных на него других сервисов.
И вывод достаточно простой, если есть возможность оставаться в рамках монолита, то нужно оставаться в рамках монолита. Выделение микросервисов это не улучшение кода – это способ решения возникающих проблем. Например, у нас несколько приложений и мы хотим сделать единую систему авторизации в этих приложениях. Зарегистрировался в одном и получаешь доступ ко всем остальным. Мы можем сделать на каждом приложении свою систему авторизации, но в этом случае будет сложно избежать дублирования кода и каждое приложение будет иметь доступ к базе данных пользователя. В этом случае логичным представляется выделить функциональность, связанную с авторизацией в отдельный микросервис и все остальные приложения будут обращаться только к нему.