Метрики "до" и "после" не собирали. В большинстве случаев в этом, на самом деле, нет смысла, поскольку мы решали задачи, которые можно решить только с использованием микросервисов (например, обновление техстека в монолите).
Не совсем понимаю, какие именно конкретные кейсы хочется услышать) Что касается статей - то это наш практический опыт использования микросервисов. Мы столкнулись с рядом проблем и задач, когда стали использовать микросервисы в наших проектах. Цикл статей систематизирует наш опыт и показывает, в каких случаях стоит использовать микросервисы, какие у них есть подводные камни и как перейти на микросервисы, если было принято такое решение
Поспорю с тезисом о том, что нам не надо было задумывать об ACID при использовании одной БД) В нашем проекте каждый микросервис ходит к БД в рамках своей транзакции. Одна БД, конечно, позволяет использовать распределенные транзакции, но у таких транзакций есть ряд минусов (в частности, проблемы, связанные с ними, тяжело расследовать). В общем, мы не использовали распределенные транзакции, а обеспечивали целостность другими способами
Мы считаем, что у нас в ряде проектов используются именно микросервисы) А почему вы решили, что у нас мидл или макро?
Использование одной БД с разными схемами, насколько мне известно, не противоречит архитектуре микросервисов. Кстати, проект с одной БД - это только один из примеров, в нашей практике есть и другие примеры, когда каждый микросервис работает со своей БД
Что имеете ввиду под "оставить старую версию при миграции"?
Монолит не плох и не хорош, также как и микросервисы. Мы используем оба подхода. В нашей практике есть случаи, когда использование микросервисов было полностью оправданным (например, перевод legacy-решения на новые технологии или быстрое написание нового функционала в MVP-стиле рядом с основным решением), однако есть и такие, где использование микросервисов не так однозначно. В продолжение темы в мае выйдет 3-я статья из цикла - в ней рассмотрю причины для перехода от монолита к микросервисам.
Статья на хабре - это 5-минутный трейлер вместо полнометражного фильма о микросервисах) Но зато теперь вы знаете все, что нужно знать о создании микросервисов, чтобы об этом говорить с экспертами — по крайней мере, в течение следующих 10 минут!
Цифр, к сожалению, привести не могу - уже писал, что у нас не было ситуаций, когда 2 одинаковых проекта разрабатывались бы 2-мя абсолютно одинаковыми командами в разных стилях (монолит и микросервисы). В предыдущем сообщении написал те случаи, в которых, по нашему мнению, переход на микросервисы был оправданным
Проблемы? Да, были! Особенно когда приходилось объяснять всем, что это не просто для строчки в резюме. А бизнес? Он был настроен скептически, пока команда программистов не показала, что это решение помогает экономить на кофе)
А если серьезно, то повторю главный тезис предыдущей статьи: микросервисы не бесплатны, у них есть и плюсы, и минусы, и нужно понимать, зачем вы их используете. В нашей практике есть случаи, когда использование микросервисов было полностью оправданным (например, перевод legacy-решения на новые технологии или быстрое написание нового функционала в MVP-стиле рядом с основным решением), однако есть и такие, где использование микросервисов не так однозначно
Не соглашусь: микросервисная архитектура не говорит о том, что сервисы обязаны общаться друг с другом только через брокер. Есть множество способов общения между сервисами. В нашей практике мы, как правило, используем очередь сообщений и web-api.
Что касается распределенных транзакций, то, на мой взгляд, это антипаттерн: трудозатраты, связанные с отладкой и расследованием проблем таких транзакций, крайне велики. В микросервисной архитектуре есть другие способы поддержания целостности данных (например, паттерн Outbox и Saga, о которых буду рассказывать в следующей статье из цикла).
СУБД не является микросервисом, поскольку микросервисы должны строиться вокруг бизнес-потребностей (а не технических компонент).
Ахахх) "Микросервисы как лекарство от склероза и разгильдяйства" отличное название) подумаю о выпуске цикла статей о разных лекарствах, которые должны быть в арсенале любого уважающего себя разработчика)
Насчет работы нескольких команд над монолитом - да, такая практика возможна. Но надо понимать, что и там могут быть минусы, например, частые конфликты при одновременных изменениях в ядре. Я не утверждаю, что монолит - это плохо, но у каждого подхода есть свои плюсы и минусы
Если правильно понял, то Вы имеете ввиду, что есть вещи, которые легко масштабировать (например, вычисления легко масштабируются путем добавления CPU), а есть те, которые сложно масштабировать (если мы уперлись по производительности в БД, то реинжениринг базы это, действительно, дорогая задача). Хочу отметить, что монолит сложнее масштабировать за счет добавления ресурсов: мы не может дать CPU только высоконагруженной части приложения, а микросервисы позволяют масштабировать только те куски приложения, которые действительно в этом нуждаются
Конечно, декомпозиция нужна и в монолите, однако в монолите проще забыть про декомпозицию и сложнее поддерживать четкие границы по сравнению с микросервисами
Что касается рамок микросервисов, в целом согласен - с точки зрения компании унификация стека является большим преимуществом: компания накапливает опыт работы с конкретными технологиями, быстрее решает инциденты и реализует фичи. Однако в нашей практике есть проссплатформенные приложения (часть модулей написана на C#, часть - на Java). Также в нашей практике есть опыт миграции части монолита на новые технологии: миграция всего монолита была слишком дорогой, но небольшой кусок функционала был переведен на новые технологии. Еще отмечу, что мигрировать на новые технологии микросервисы проще: можно начать миграцию с наиболее простых микросервисов, постепенно переходя к более сложным модулям. При внедрении новой технологии надо учитывать много разных факторов, один из них - техническая возможность дешевой встройки новой технологии. Микросервсисы дают такую техническую возможность, но, конечно, не закрывают организационные и другие вопросы.
Что касается масштабирования, то оно не всегда упирается в БД. Есть куски приложения, которые сильно нагружены по CPU. Такие куски масштабируются не за счет БД, а за счет распараллеливания вычислений.
Что касается пункта про команду - согласен, требуется понимание целиком, как устроен продукт, однако это понимание не обязательно должно быть у всех членов команды
Спасибо за ссылку, вывод автора о том, что "делать проекты до человеко/года на микросервисах как минимум в два раза дороже, чем на монолите" в целом соотносится с нашей практикой. Не уверен, что в 2 раза, но точно дороже. У нас не было опыта разработки 2-х в целом одинаковых приложений в разных архитектурных подходах: каждое приложение имеет ряд особенностей, поэтому сравнивать монолит и микросервисы "при прочих равных условиях" не представляется возможным. Хочу отметить, что и у монолита, и у микросервисов есть свои плюсы и минусы. Статья нацелена на то, чтобы подсветить их и чтобы выбор того или иного подхода был осознанным
Метрики "до" и "после" не собирали. В большинстве случаев в этом, на самом деле, нет смысла, поскольку мы решали задачи, которые можно решить только с использованием микросервисов (например, обновление техстека в монолите).
Стек: C#, Java
Не совсем понимаю, какие именно конкретные кейсы хочется услышать) Что касается статей - то это наш практический опыт использования микросервисов. Мы столкнулись с рядом проблем и задач, когда стали использовать микросервисы в наших проектах. Цикл статей систематизирует наш опыт и показывает, в каких случаях стоит использовать микросервисы, какие у них есть подводные камни и как перейти на микросервисы, если было принято такое решение
Поспорю с тезисом о том, что нам не надо было задумывать об ACID при использовании одной БД) В нашем проекте каждый микросервис ходит к БД в рамках своей транзакции. Одна БД, конечно, позволяет использовать распределенные транзакции, но у таких транзакций есть ряд минусов (в частности, проблемы, связанные с ними, тяжело расследовать). В общем, мы не использовали распределенные транзакции, а обеспечивали целостность другими способами
Спасибо за теплые слова о статье)
Мы считаем, что у нас в ряде проектов используются именно микросервисы) А почему вы решили, что у нас мидл или макро?
Использование одной БД с разными схемами, насколько мне известно, не противоречит архитектуре микросервисов. Кстати, проект с одной БД - это только один из примеров, в нашей практике есть и другие примеры, когда каждый микросервис работает со своей БД
Что имеете ввиду под "оставить старую версию при миграции"?
Монолит не плох и не хорош, также как и микросервисы. Мы используем оба подхода. В нашей практике есть случаи, когда использование микросервисов было полностью оправданным (например, перевод legacy-решения на новые технологии или быстрое написание нового функционала в MVP-стиле рядом с основным решением), однако есть и такие, где использование микросервисов не так однозначно. В продолжение темы в мае выйдет 3-я статья из цикла - в ней рассмотрю причины для перехода от монолита к микросервисам.
Статья на хабре - это 5-минутный трейлер вместо полнометражного фильма о микросервисах) Но зато теперь вы знаете все, что нужно знать о создании микросервисов, чтобы об этом говорить с экспертами — по крайней мере, в течение следующих 10 минут!
Цифр, к сожалению, привести не могу - уже писал, что у нас не было ситуаций, когда 2 одинаковых проекта разрабатывались бы 2-мя абсолютно одинаковыми командами в разных стилях (монолит и микросервисы). В предыдущем сообщении написал те случаи, в которых, по нашему мнению, переход на микросервисы был оправданным
Проблемы? Да, были! Особенно когда приходилось объяснять всем, что это не просто для строчки в резюме. А бизнес? Он был настроен скептически, пока команда программистов не показала, что это решение помогает экономить на кофе)
А если серьезно, то повторю главный тезис предыдущей статьи: микросервисы не бесплатны, у них есть и плюсы, и минусы, и нужно понимать, зачем вы их используете. В нашей практике есть случаи, когда использование микросервисов было полностью оправданным (например, перевод legacy-решения на новые технологии или быстрое написание нового функционала в MVP-стиле рядом с основным решением), однако есть и такие, где использование микросервисов не так однозначно
Ага, опять) каждый микросервис - это как возвращение старого друга. Или старого недруга, в зависимости от точки зрения
Не соглашусь: микросервисная архитектура не говорит о том, что сервисы обязаны общаться друг с другом только через брокер. Есть множество способов общения между сервисами. В нашей практике мы, как правило, используем очередь сообщений и web-api.
Что касается распределенных транзакций, то, на мой взгляд, это антипаттерн: трудозатраты, связанные с отладкой и расследованием проблем таких транзакций, крайне велики. В микросервисной архитектуре есть другие способы поддержания целостности данных (например, паттерн Outbox и Saga, о которых буду рассказывать в следующей статье из цикла).
СУБД не является микросервисом, поскольку микросервисы должны строиться вокруг бизнес-потребностей (а не технических компонент).
Что имеете ввиду? Что микросервисы дороже в эксплуатации?
Ахахх) "Микросервисы как лекарство от склероза и разгильдяйства" отличное название) подумаю о выпуске цикла статей о разных лекарствах, которые должны быть в арсенале любого уважающего себя разработчика)
Насчет работы нескольких команд над монолитом - да, такая практика возможна. Но надо понимать, что и там могут быть минусы, например, частые конфликты при одновременных изменениях в ядре. Я не утверждаю, что монолит - это плохо, но у каждого подхода есть свои плюсы и минусы
Если правильно понял, то Вы имеете ввиду, что есть вещи, которые легко масштабировать (например, вычисления легко масштабируются путем добавления CPU), а есть те, которые сложно масштабировать (если мы уперлись по производительности в БД, то реинжениринг базы это, действительно, дорогая задача). Хочу отметить, что монолит сложнее масштабировать за счет добавления ресурсов: мы не может дать CPU только высоконагруженной части приложения, а микросервисы позволяют масштабировать только те куски приложения, которые действительно в этом нуждаются
Согласен, мы также пришли к выводу, что у обеих архитектур есть свои сильные стороны, поэтому применяем обе архитектуры в своей работе
Поддержу, доводы обоснованные👍
Конечно, декомпозиция нужна и в монолите, однако в монолите проще забыть про декомпозицию и сложнее поддерживать четкие границы по сравнению с микросервисами
Что касается рамок микросервисов, в целом согласен - с точки зрения компании унификация стека является большим преимуществом: компания накапливает опыт работы с конкретными технологиями, быстрее решает инциденты и реализует фичи. Однако в нашей практике есть проссплатформенные приложения (часть модулей написана на C#, часть - на Java). Также в нашей практике есть опыт миграции части монолита на новые технологии: миграция всего монолита была слишком дорогой, но небольшой кусок функционала был переведен на новые технологии. Еще отмечу, что мигрировать на новые технологии микросервисы проще: можно начать миграцию с наиболее простых микросервисов, постепенно переходя к более сложным модулям. При внедрении новой технологии надо учитывать много разных факторов, один из них - техническая возможность дешевой встройки новой технологии. Микросервсисы дают такую техническую возможность, но, конечно, не закрывают организационные и другие вопросы.
Что касается масштабирования, то оно не всегда упирается в БД. Есть куски приложения, которые сильно нагружены по CPU. Такие куски масштабируются не за счет БД, а за счет распараллеливания вычислений.
Что касается пункта про команду - согласен, требуется понимание целиком, как устроен продукт, однако это понимание не обязательно должно быть у всех членов команды
Спасибо за ссылку, вывод автора о том, что "делать проекты до человеко/года на микросервисах как минимум в два раза дороже, чем на монолите" в целом соотносится с нашей практикой. Не уверен, что в 2 раза, но точно дороже. У нас не было опыта разработки 2-х в целом одинаковых приложений в разных архитектурных подходах: каждое приложение имеет ряд особенностей, поэтому сравнивать монолит и микросервисы "при прочих равных условиях" не представляется возможным. Хочу отметить, что и у монолита, и у микросервисов есть свои плюсы и минусы. Статья нацелена на то, чтобы подсветить их и чтобы выбор того или иного подхода был осознанным
Спасибо!
Я про Diamond DA40NG. На нем усилия значительны при правильной установке триммера
Спасибо! А насчет перспективности - поживем-увидим. В авиации всегда волны. Я верю, что к окончанию училища все наладится)))