Привет!

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

С другой стороны, я понял, что у меня самого нет внятного понимания, когда модулярный монолит пора начинать резать на отдельные сервисы.

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

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

#talks@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

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

И сегодня будет ещё пара линок о том, что микросервисы не должны быть выбором по умолчанию.

Микро правило распределённого проектирования Фаулера: My First Law of Distributed Object Design: Don't distribute your objects.

Пост DHH на ту же тему.

Для того чтобы идти в зону боли и страданий распределённое программирование нужны веские причины.

#posts@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Прекрасное подтверждение для тезиса "Сначала объектно-ориентированная декомпозиция, потом модульный монолит на этой базе, потом, если потребуется, микросервисы".

О том как использовать диаграмму эффектов для рациональной объектно-ориентированной декомпозиции я напишу третьим постом в текущей серии о диаграмме эффектов.

#posts@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Наконец-то мир начал отходить от массового помешательства

https://habr.com/ru/company/jugru/blog/670816/

#talks@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

А вот и Фаулер советует стартовать с монолита

Из статьи достаточно прочитать две фразы:
1) Almost all the successful microservice stories have started with a monolith that got too big and was broken up
2) Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

1) Практически все микросервисные истории начинались с монолита, который вырос слишком большим и был разбит (на микросервисы)
2) Практически все случаи, о которых я слышал, где начинали с микросервисов, закончились серьёзными проблемами

#posts@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Посмотрел Don’t Build a Distributed Monolith - там мужик в бонусной проблеме как и я говорит, что микросервисы разрабатываемые одним человеком - мощная заявка на распределённый монолит.

В целом в докладе не то чтобы есть какие откровения, но посмотреть можно.

А потом посмотрел Top 5 techniques for building the worst microservice system ever. Вот тут в конце уже было некоторое откровение. Для реализации агрегации данных из разных сервисов, чувак предлагает сбор этих данных делать в репозе сервисов-владельцев, но деплоить этот код в сервисе-агрегаторе.
Я не то чтобы побежал это делать, но идея кажется любопытной.

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

#talks@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

"Золотые слова, Юрий Венедиктович!"

Доклад: https://www.youtube.com/watch?v=9Q7GANXn02k

#talks@ergonomic_code #why_no_microservices@ergonomic_code