Как микросервисы стали тормозом. И почему мы вернулись к монолиту

[ganqqwerty]

Написание слова "гудбай" в следующий раз лучше тоже поручить нейросетке

[avovana7]

ganqqwerty, fixed, thank you :)

[Cordekk]

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

[avovana7]

Cordekk3, имеете ввиду, что нужно было растить свою команду инфраструктуры?

[Cordekk]

ну формально, да.
Ведь микросервисы закладывают под рост нагрузки и команд, а тут ничего не растет, вот и вывод в конце статьи.

[Cordekk]

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

[haitdb]

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

Все же основанием для выбора архитектуры должно быть что то другое ;)

[avovana7]

haitdb, интересно) Например? :)

[diderevyagin]

Вы построили не совсем правильную микросервисную архитектуру.

Грубо говоря Вы построили распределенный монолит. Оттуда и все проблемы.

Теперь Вы решили его проблемы, просто решив эти проблемы. Это хороший опыт, но немного некорректный, чтобы оценивать и критиковать микросервисную архитектуру как концепцию

[avovana7]

diderevyaginтолько, интересный поинт. Что бы Вы посоветовали команде в момент боли, когда они раскатались на такое большое количество микросервисов?

[diderevyagin]

Что бы Вы посоветовали команде в момент боли

Мой подход был бы такой:

Команда построила распределенный монолит. Это создало проблемы.

Дальше - анализ. Принятие решение. Если проект позволяет - свести к нормальному монолиту. Нет - распил такого распределенного монолита на реальные микросервисы.

Вы пошли путем 1 и это вполне хороший выбор. У меня были замечания скорее к терминологии

[sergey_prokofiev]

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

Какую проблему решают микросеврисы - deploy fast в проектах с большим количеством команд: каждая команда деплоит свой микросервис независимо(сохраняя контракты ессна) и в крупных проектах может быть чуть ли не ежечасовый релиз нового функционала. В аналогичных условиях типичный релизный цикл монолита - один год. Естественно такой лайфхак ускорения релизного цикла за счет релиза "по частям" имеет и свою темную сторону - there is no one silver bullet.

Все остальные бенефиты микросервисов - buzzwords разной степени "buzzword-ности".

А у вас - небольшая команда и не планируется ее резкий рост. Значит основного бенефита от микросервисов вы в принципе получить не можете - одна команда релизит "как умеет" и ее "в 50 раз" не ускорить. А вот косков "темной стороны" собрали полной - очень недалеки от джек пота.

Хорошо что приняли волевое решение и выбрали архитектуру, больше подходящую вашим задачам.

[tkovacs]

Откуда такие цифры по монолитам? Хоть ежеминутно могу релизить при сохранении внутренних контрактов, да и вместе с изменением контрактов 😂

Делишь монолит на модули, определяешься с инфраструктурой и инструментарием, никаких проблем в разработке большой командой нет.

[sergey_prokofiev]

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

никаких проблем в разработке большой командой нет.

Тут наверное стоит определиться, что такое "большая команда". Для меня это 150-300 девов и кодовая база с историей лет в 10-20.

[Vedomir]

>каждая команда деплоит свой микросервис независимо(сохраняя контракты ессна)

А если развертываемый функционал требует изменения контракта? А если еще и не у одного микросервиса, а сразу у нескольких?

[sergey_prokofiev]

А если развертываемый функционал требует изменения контракта? А если еще и не у одного микросервиса, а сразу у нескольких?

да, в микросервисной архитектуре версионирование контрактов и поддержка легси версий столько сколько "нужно" - это must have. No pain - no gain :)

[vitaly_il1]

Заглянул в оригинал - а пост-то 2018 года!
1) Очень интересно, когда и как они перешли на микросервисы
2) прошлогодний пост https://www.linkedin.com/pulse/twilios-success-api-architecture-building-scalable-robust-oprne/ говорит о микросервисной архитектуре. Возможно это другой продукт.

Disclaimer: я против микросервисов и K8S как архитектуры по умолчанию

[vitaly_il1]

Дошло - кто-то начал разгонять этот старый пост месяц назад - на reddit и ycombinator