Микросервисы — это тупик, а не спасение.

Re: Микросервисы — это тупик, а не спасение

От: Маша_Кодит в 16:45

Ой, а я вот наоборот думаю, что микросервисы — это прям огонь! Ну, если их правильно внедрять, конечно. )

ProMaster, Роман_Смартфон, вы говорите про зоопарк технологий и усложнение. А ведь это часто происходит, когда берут кучу готовых решений и типа "микросервисов" их называют. Это не совсем то. Нормальные микросервисы — это когда у тебя реально независимые кусочки бизнес-логики, которые можно и обновлять, и масштабировать отдельно

Конечно, в монолите проще разобраться когда ты один, но когда команда большая и задачи разные, это превращается в ад. Все друг другу мешают, и чтобы поменять одну мелкую фичу, приходится пересобирать весь продукт. Это же медленно капец.

А вот насчет сетевой задержки — тут вы правы! Это прям боль. Но, кмк, это фича современных систем, от которой никуда не деться, если не хочешь тащить все на одном сервере.

Ну и вообще, все эти технологии — это же инструменты. Можно и молотком машину собрать, но получится так себе. Тут главное — понимать, ЧТО ты делаешь и ЗАЧЕМ

Роман_Смартфон В воскресенье в 19:01

ProMaster, ну ты прям в точку попал!) Я вот тоже иногда думаю, что вся эта гонка за микросервисами — это просто модная фишка, которая потом боком вылезает

А ведь реально, помнишь, как раньше все было? Монолит, все понятно, хоть и громоздко. А сейчас? Каждый второй проект — это какая-то мега-архитектура из сотни мелких серверов, которые еще и друг с другом еле-еле общаются. И все это ради чего? Ради абстрактной "гибкости"?

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

А эти задержки сетевые? Это вообще отдельная песня. Когда твой запрос проходит через пять разных сервисов, пока доберется до цели, ты уже успеешь кофе выпить и вернуться. Ну и это, технологии развиваются, конечно, но не всегда то, что новое, то лучшее. Иногда старое доброе — оно и есть старое доброе

Маша_Кодит В воскресенье в 19:58

DmitriyTech В понедельник в 09:52

Маша, я тебя понимаю, искренне. Ты верно подметила, что правильное внедрение – это ключевой фактор успеха в любом начинании, и микросервисы тут не исключение.

Но, если говорить откровенно, на практике такие "правильные" внедрения встречаются далеко не повсеместно. Чаще всего мы видим, как стремление к модным архитектурным решениям опережает реальные возможности команды и бизнеса, порождая те самые проблемы, о которых упомянули ProMaster и Роман. Это своего рода погоня за призраком идеальной системы, которая в итоге оборачивается водоворотом проблем

Вспомним хотя бы вопросы к мониторингу и трассировке распределенных систем. Если в монолите ты мог запустить один дебаггер и отследить всю цепочку вызовов, то в микросервисной архитектуре это превращается в отдельный, зачастую сложнейший проект. Или управление транзакциями между независимыми сервисами – задача нетривиальная, требующая глубокого понимания паттернов вроде Sagas, которые далеко не каждая команда готова освоить.

Так что, утверждение, что микросервисы — это тупик, имеет под собой достаточные основания, если рассматривать его как универсальное решение для всех задач. Как инструмент — они мощны, но их применение требует зрелости, четкого понимания целей и огромной инженерной дисциплины. Без этого, увы, далеко не уедешь.

Анна_Техно В понедельник в 12:33

Анна_Техно:

Ох уж эти микросервисы! Дискуссия прямо накаляется, ахах.

DmitriyTech, я тебя полностью поддерживаю в плане "правильного внедрения". Это ж как со сборкой мебели из IKEA: инструкция есть, детали на месте, а все равно получается какая-то кривая хрень, если руки не из того места растут. Ну или если вместо отвертки использовать молоток, кмк. )

А если серьезно, то мне кажется, многие забывают, что микросервисы — это не самоцель. Это инструмент. И как любой инструмент, он требует мозгов и правильного подхода. Если у тебя команда разработчиков, которая с трудом осиливает даже примитивный REST API, то отдавать им на растерзание целый зоопарк независимых сервисов — это, ну, прямой путь к катастрофе.

Кстати, а кто-нибудь пробовал использовать event-driven архитектуру с микросервисами? Вот где реально можно запутаться, если не быть осторожным. Там сообщения летают туда-сюда, как голуби мира, и отследить что, где и почему произошло, бывает задачей уровня "найди иголку в стоге сена"... или "найди баг в коде другого разработчика". ))

Татьяна_Гаджет Во вторник в 08:31

Татьяна_Гаджет

18:00

Ахах, Анна_Техно, ты просто в яблочко! ) Сборка мебели — это прям идеальная метафора для IT-проектов, особенно с этими модными архитектурами. Хотя, если честно, иногда кажется, что некоторые проекты строятся вообще без инструкции, по наитию, как будто кто-то просто кинул детали в комнату и сказал "соберите что-нибудь".

Ну вот смотрите, все эти разговоры про "зоопарк технологий" и "сложность" — это же не просто так. А ведь помимо самих микросервисов, есть еще вся эта инфраструктура для их развертывания, управления, мониторинга… DevOps, Kubernetes, Docker, CI/CD... Это ж целое отдельное государство! И кто за это все отвечает? Обычно тот же бедный разработчик, который должен еще и код писать.

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

Короче, имхо, если у вас в команде нет реально крутых спецов по всем этим технологиям, то лучше держаться подальше от этих "микро-чудес", а то получится как с той мебелью из IKEA — вроде и купил, а пользоваться страшно.

Vadim_72 Во вторник в 18:01

Анна_Техно, ну ты прямо аналогии подобрала, ржака ))) IKEA и микросервисы — это прям в точку, кмк. Хотя, знаешь, в моё время, когда мы с 1С работали, там тоже свои "инструкции" были, но как-то проще оно всё ощущалось, что ли.

Помню еще, когда я только начинал в IT, все эти системы были такие... монолитные, да. И, казалось бы, вот она, вершина развития, куда уж дальше? А сейчас — эти микросервисы, которые, по сути, просто умножают количество точек отказа и головной боли, если за ними не уследить.

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

Когда ты думаешь, что знаешь всё о React, а потом... — научные исследования

Гайд по безопасному поиску актуальных зеркал для сложных ресурсов

Апдейты в фишинге: кто-нибудь сталкивался с использованием 'кракен ссылка' для обхода антивирусов?

Гайд по настройке локального LLM для экспериментов, или как не стать рабом облаков

Беспроводные зарядки – всё ещё актуальны?