ЧТО БУДЕТ ПОСЛЕ МИКРОСЕРВИСОВ?

В последние годы микросервисная архитектура стала дефакто стандартом для многих крупных компаний, стремящихся к гибкости и масштабируемости своих приложений. Однако, компании уже начали давно сталкиваться с проблемами при использовании микросервисной архитектуры:

1️⃣Сложность управления. Увеличение количества микросервисов приводит к усложнению их координации, мониторингу и отладки. Каждый сервис требует отдельного управления, что увеличивает операционные затраты. Мониторинг становится по-настоящему сложной задачей, когда количество сервисов, инстансов БД и кешей переваливает за 10000.

2️⃣Повышенные требования к инфраструктуре. Микросервисы требуют сложной инфраструктуры для обеспечения надежности и масштабируемости, что может быть дорогостоящим и трудоемким в поддержке. К тому же каждая компания решает проблемы с инфрастурктурой по-своему, как может и умеет, и это накладывает некоторые ограничение на дальнейшее развитие инфраструктуры.

3️⃣Сложность тестирования и отладки. Распределенная природа микросервисов затрудняет проведение интеграционного тестирования и отладки. Протестировать взаимодейтсие 2, 3, 4 сервисов еще вполне можно, но, когда фича затрагивает 10+ доменов, и в каждом домене еще по нескольку сервисов, учавствующих в цепочке взаимодействия, тестирование и координация интеграции превращается в тот еще квест)

4️⃣Снижение производительности из-за необходимости сериализации и передачи данных по сети между сервисами.

5️⃣Проблемы с управлением API, дороговизна изменения и актуализация API сервисов, передача лишних данных или наоборот недостаточных данных. У меня в сервисе был метод, на который было завязано более 80 других микросервисов, и потребовалось больше года, чтобы все клиенты смогли перейти на новый API.

Крупные компании, такие как Google и Amazon, всегда задавали тренд развитию облачных технологий и, естественно, с проблемами огромной микросервисной архитектуры они уже знакомы. В 2023 году, как гром среди ясного неба, начали выходить статьи о проблемах микросервисной архитектуры и новых подходах разработки облачных приложений.

Так, например, инженеры Google предложили разрабатывать приложения как логические монолиты, передавая их в автоматизированные среды выполнения, которые самостоятельно решают, где запускать рабочие нагрузки. По их словам, это позволило снизить задержки в 15 раз и сократить затраты до 9 раз. Для этого они разработали свой собственный фреймворк — Service Weaver

Команда Amazon Prime Video поделились своим опытом перехода от микросервисной к монолитной структуре для мониторинга видеопотоков, который привел к снижению операционных затрат на 90% и улучшению производительности.

Что это все значит? Да то, что ближайшие 2-3 года большие IT коммпании начнут пересматривать регламенты и подходы к разработке. Очевидно, мы будем наблюдать частичный возврат к монолитам и модульным монолитам. Разработчикам придется учиться работать с большой кодовой базой и уметь писать код так, чтобы в любой момент его можно было вынести на другой физический инстанс. В общем, господа разработчики, начинайте готовиться заранее 😉

От себя скажу, что эта тенденция реальная и она уже назревает и в Российских IT компаниях. Так что жду в следующем году на конференциях доклады касательно данного вопроса.