Comments 42
Написание слова "гудбай" в следующий раз лучше тоже поручить нейросетке
ключевая ошибка, вам изначально не нужны были микросервисы, но вы рассчитывали, что будет рост и под это заложили микросервисы. В целом количество кода росло, но команда не выросла.
Отсюда и проблемы, ведь небольшой команде микросервисы не нужны.
ну формально, да.
Ведь микросервисы закладывают под рост нагрузки и команд, а тут ничего не растет, вот и вывод в конце статьи.
а в целом, если монолит решает задачи, то значит на нем можно остановиться. Если потом упретесь в какой-то потолок производительности, то начнете опять пилить на сервисы.
ключевая ошибка, вам изначально не нужны были микросервисы
Да, но эта же ключевая ошибка, она касается, я вряд ли ошибусь, если скажу, что этак 80% проектов, в которых используются микросервисы.
Статистикой не владею, наверно вы правы.
Я поклонник гибридного подхода: делаем монолит, но по мере необходимости обвешиваем сервисами и интеграциями.
Не совсем понял - какая связь между архитектурой приложения и организацией работы с исходным кодом?
Монолитное приложение может состоять из кучи библиотек, каждая из которых ведется в отдельной репе, так и единый код можно запускать как кучу отдельных сервисов.
Все же основанием для выбора архитектуры должно быть что то другое ;)
Вы построили не совсем правильную микросервисную архитектуру.
Грубо говоря Вы построили распределенный монолит. Оттуда и все проблемы.
Теперь Вы решили его проблемы, просто решив эти проблемы. Это хороший опыт, но немного некорректный, чтобы оценивать и критиковать микросервисную архитектуру как концепцию
diderevyaginтолько, интересный поинт. Что бы Вы посоветовали команде в момент боли, когда они раскатались на такое большое количество микросервисов?
Что бы Вы посоветовали команде в момент боли
Мой подход был бы такой:
Команда построила распределенный монолит. Это создало проблемы.
Дальше - анализ. Принятие решение. Если проект позволяет - свести к нормальному монолиту. Нет - распил такого распределенного монолита на реальные микросервисы.
Вы пошли путем 1 и это вполне хороший выбор. У меня были замечания скорее к терминологии
Вместо того чтобы работать быстрее, небольшая команда увязла в стремительно растущей сложности. Важнейшие преимущества этой архитектуры превратились в бремя.
Какую проблему решают микросеврисы - deploy fast в проектах с большим количеством команд: каждая команда деплоит свой микросервис независимо(сохраняя контракты ессна) и в крупных проектах может быть чуть ли не ежечасовый релиз нового функционала. В аналогичных условиях типичный релизный цикл монолита - один год. Естественно такой лайфхак ускорения релизного цикла за счет релиза "по частям" имеет и свою темную сторону - there is no one silver bullet.
Все остальные бенефиты микросервисов - buzzwords разной степени "buzzword-ности".
А у вас - небольшая команда и не планируется ее резкий рост. Значит основного бенефита от микросервисов вы в принципе получить не можете - одна команда релизит "как умеет" и ее "в 50 раз" не ускорить. А вот косков "темной стороны" собрали полной - очень недалеки от джек пота.
Хорошо что приняли волевое решение и выбрали архитектуру, больше подходящую вашим задачам.
Откуда такие цифры по монолитам? Хоть ежеминутно могу релизить при сохранении внутренних контрактов, да и вместе с изменением контрактов 😂
Делишь монолит на модули, определяешься с инфраструктурой и инструментарием, никаких проблем в разработке большой командой нет.
>каждая команда деплоит свой микросервис независимо(сохраняя контракты ессна)
А если развертываемый функционал требует изменения контракта? А если еще и не у одного микросервиса, а сразу у нескольких?
deploy fast в проектах с большим количеством команд: каждая команда деплоит свой микросервис независимо
Что мешает деплоить модуль монолита? DLL, so, плагин.
Перезапуск с необходимостью прогрева монолита? Извините, не встречал необходимости деплоить каждый час.
с большим количеством команд
Ещё работает не только на количестве команд на проект, но и заказчиков на проект: у нас вот вроде всего человек 20, но как релиз монолита - квест подписаний у начальника. А так общую шину запилили - и разным заказчикам уже свои апихи с микрофронтами отдельно под согласования
Заглянул в оригинал - а пост-то 2018 года!
1) Очень интересно, когда и как они перешли на микросервисы
2) прошлогодний пост https://www.linkedin.com/pulse/twilios-success-api-architecture-building-scalable-robust-oprne/ говорит о микросервисной архитектуре. Возможно это другой продукт.
Disclaimer: я против микросервисов и K8S как архитектуры по умолчанию
Микросервисы это архитектурный долг. Проблемы разработки (организационный и технологические) перетекают на девопс и архитекторов, но не сразу. Первая порция бесплатно©
Работает в Гугл из-за масштабирования команд: при десятках тысяч людей можно выстроить девопс дешёвый на единицу продукта.
У Google амортизация инфраструктуры (k8s, service mesh, внутренние тулы) размазывается на тысячи сервисов и команд. У компании с 5 командами те же накладные расходы делятся на 5.
Ещё момент: у них микросервисы решают организационную проблему (закон Конвея в плюс), а не техническую. Когда сотня человек не могут коммитить в один репо без хаоса - появляется реальная причина дробить. Да и фиг с ним, monorepo + модульная сборка даёт независимый деплой без распределённой системы.
Но вы не Гугл©
Ознакомился со статьей, интересная для меня тема. Микросервисная архитектура - это не про моду, а про определенные знания на этапе даже не сбора требований, а на самом раннем, еще до планирования и первых экспериментов с архитектурой.
Вы должны понимать изначально - зачем вы создаете свое IT решение, а не действовать по ситуации.
Закон Конвея гласит - архитектура копирует структуру команды. Если у вас менеджмент работает в режиме тушения пожаров, решает проблемы по мере поступления и не смотрит наперед, то распиаренные микросервисы вас не спасут никогда.
Происходит повально накопление ситуационных решений и костылей. Естественно, в монолите проще фиксить, чем ходить по 50 репозиториям и искать нужную розетку для вилки.
Старая история - 1 баг пофиксили, появилось новых 2 - это 2 новых бага в монолите.
НО ЭТО ЖЕ 2*50 = 100 потенциальных багов в микросервисах.
И приходится лазить по репозиториям и править кучу хотя бы DTO или дата-классов, чтобы добавить/изменить одно поле.
Также знакома ситуация, когда проблема не в архитектуре, а в управлении командой. Менеджер хочет-хочет Agile с CI/CD и всё такое, а видит ценность не в людях, а в процессах.
Соответственно получаем "коди ради кодинга" и у Самурая только путь.
Теперь к содержимому статьи: вы пишите, что стали выделять общий код в общие библиотеки.
Тем самым вы подтверждаете ситуацию, описанную в книге Микросервисы. Паттерны разработки и рефакторинга Криса Ричардсона - общие библиотеки убивают гибкость.
Идеальный микросервис не должен быть зависим от общей концепции, весь смысл в слабой связанности компонентов.
Это также определяет мою гипотезу, что вы в вашей команде "плывете" по Конвэю обратно к распределенному монолиту, хотя и в разных репозиториях.
Жалобы на кеширование, трудности работы с очередями - это уже последствия, конкретно эти инструменты становятся неэффективными, если используются вместе с кучей макаронного хрупкого медленного кода.
Если вы в гигантском цикле будете "воду в ступе толочь" часами, то магия Системного Дизайна исчезает, хоть на Go хоть на С++.
Еще есть мысль, куда посмотреть - многие программисты раздувают методы (имеется ввиду методы классов) работы if-else "бизнес-логикой" не по принципам SOLID, а ситуативно и интуитивно по якобы классным принципам DRY.
Типа "чуть-чуть, пару строчек, 1-2 if-else и все в единый метод". И потом это раздувается в спагетти-монстра. Такие принципы плохого программирования недопустимы в микросервисной архитектуре.
В конце-концов - проведите еще раз детальную работу с функциональными и нефункциональными требованиями. Если у вас сайт на 3.5 пользователя в месяц, то подойдет и Wordpress у фрилансера, а не 50 микросервисов.
Задачи архитектуры должны соответствовать цели проекта, а не взятой с потолка моде.
Хороший посыл, который вроде простой, но многие этого не осознают. Я сам относительно недавно (несколько лет назад) осознал простую истину, что нет вообще никакого смысла гнаться за "крутыми", "модными" архитектурами и стеками в любом проекте.
Действительно, стек, архитектуру, паттерны определяет не мода, а реальная потребность при разработке. Золотые слова, про пример с сайтом на 3.5 пользователя а день. Зачем тратить впустую время и свои же человеко часы, если можно взять для этой задачи Вордпресс и просто сделать сайт без всяких выклбеливаний. Большинству заказчиков в целом всё-равно, как технически реализован их сервис им важно качество, время (ведь от него зависит бюджет проекта) и стабильность работы. Следовательно, нужно всегда планировать, что лучше всего подойдёт для того или иного проекта.
Касаемо кода, то сейчас наблюдаю довольно ироничную ситуацию. С приходом в разработку llm, по сути оказалось, что KISS DRY и часть SOLID, очень любимы нейронками. При этом "красивые", но мудреные подходы они не сильно любят. Почему так, описывать долго, но если коротко, то связано с принципами работы llm и mcp. Так что да, сложные решения нужно использовать тогда, когда в них есть реальная необходимость.
Есть еще удобный вариант развертывания монолита, когда кодовая база одна, но разные инстансы монолита отвечают за разные блоки функционала, т.е. грубо говоря каждый инстанс монолита отвечает за свой destination(или набор), что позволяет гибко масштабировать монолит при необходимости.
Монолит с OSGI модулями бизнес-логики - неплохая комбинация, очень нравилась в свое время. Самый быстрый и простой деплой почему-то получался на практике по сравнению с обычными монолитами и микросервисами. А команды делить по DDD надо.
Да неужели. Такой длинный текст.
Микросервисы нужны для удобства разделения команд и масштабирования (скейлинга) частей приложения.
Все. Остальное мода.
А почему вы не вынесли общую логику с общими библиотеками в отдельный микросервис? Тогда основная боль обновлений ушла бы в историю.
Я как человек, который последние 20 лет работал в основном с БД и все что с ними связано. Возникает вопрос, почему не сделать большую часть кода на БД? БД Отлично справляется с нагрузками, может выдержать хоть миллион операций в секунду.
Не знаю ваш объем данных, но как правило БД работает с данными в десятки раз быстрее любых самописных API или микросервисных систем. Плюс удобство работы, когда у вас и работа с данными и с логами с методанными все в одном месте и почти одним языком
Вывод из статьи: Если микросервисы очень переплетены между собой, то лучше монолит. На автоматическое масштабирование рассчитывать не стоит
почему не сделать большую часть кода на БД?
Тестировать трудно, git merge не работает, читаемость низкая, сложности горизонтального масштабирования, потеря типизации, вендор лок (разница T-SQL/PL/pgSQL)... Итого скорость написания до прода раз в 10 ниже.
Это только то, что помню. Десятки крупных недостатков. Но иногда очень быстро, да
Как микросервисы стали тормозом. И почему мы вернулись к монолиту