Остановка: "Переосмысливая Микросервисы и Монолиты в Современной Разработке или поиск золотой середины"

В мире разработки программного обеспечения вечная битва между сторонниками монолитной и микросервисной архитектур продолжается. Но что, если мы говорим о вымышленном противостоянии, и разработчики просто упускают из виду целый спектр архитектурных возможностей между ними?

Сделаем выводы: Микросервисы - решение для сложности, а не ее причина. Все приложения становятся сложными, и микросервисы помогают управлять этой сложностью.

Затраты и выгоды микросервисов. Если выгоды не перевешивают затраты, микросервисы не принесут радости.

Спектр возможностей. Существует нечто большее, чем монолит против микросервисов - целый спектр архитектурных вариантов посередине.

Гибридная модель - лучшее что есть из обоих миров. Смешивание крупных сервисов монолита с маленькими микросервисами дает удобство монолита и гибкость микросервисов.

Текущая война: монолит против микросервисов.

Согласно недавнему посту в блоге AWS, компания отказалась от микросервисов и вернулась к монолиту, возродив древнюю битву монолитов против микросервисов. Но действительно ли эта дискуссия имеет смысл? Или это всего лишь часть более крупной истории?

Статья AWS, хотя и названа так, чтобы привлечь внимание, касается, скорее всего, перехода от функций как услуги к архитектуре, которую можно считать микросервисной. Но важен не сам выбор архитектуры, а то, что это обычный опыт: первая попытка не сработала, затем был выбран другой путь, который оказался эффективнее. И это нормально. И почему мы боимся микросервисов?

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

"Вы должны быть на этой высоте, чтобы использовать микросервисы." - Мартин Фаулер. Построение распределенных приложений требует высокой технической грамотности. Управление множеством сервисов требует автоматизации. Есть много деталей, которые нужно отслеживать, особенно при коммуникации между сервисами.

Для маленькой команды или проекта, применение микросервисов там, где это нецелесообразно, или если нет готовности вложиться в навыки и технологии для построения и управления распределенной системой, приведет к трудным временам.

Важен ли размер ? Микросервисы не обязательно "микро" в смысле "маленьких". Размер не имеет значения. Слишком маленькие сервисы могут быть менее полезными и потребуют больше усилий. Фокус должен быть на подходящем размере для вашей ситуации - монолитного или находящегося на меньшем конце спектра.

Гибридная модель

Если не нужно стремиться к идеалу микросервисов, то где остановиться? Гибридная модель - идеальное решение. Монолит (или несколько) смешивается с микросервисами. Это предоставляет удобство монолита и гибкость микросервисов. Вы можете использовать лучшее из обоих миров, выбирая удобство монолита для большей части кодовой базы и гибкость микросервисов при необходимости.

Ну и в заключении могу сказать, что :

Война монолитов против микросервисов - это всего лишь часть большой истории. Вместо выбора одной из сторон, стоит рассматривать широкий спектр архитектурных вариантов посередине. Не стоит бояться микросервисов, стоит решать, подходят ли они для конкретной задачи. По мне главное - не придерживаться крайностей, а искать оптимальные решения в каждой ситуации.

На моем канале Самоучки IT https://t.me/samvsepoimesh вы найдете еще много информации от разных авторов.