если у вас увеличив сложность одного микро сервиса, автоматически увеличивается сложность других микросервисов, то у вас чтото не так с микросервисами и их границами
Не совсем. Есть такой функционал которых разъезжается по всем микросервисам: локализация, безопасность, обновления протоколов, логирование и т.д. и тут изменение в одном сервисе - требует менять их все...
@@yaqco2172 то что можно вынести оно и так выносится... но явно не всё и иногда возникают ситуации когда весь парк микросервисов приходится менять... иногда даже накатить новую версию пакета на все микросервисы - это проблема...
Хмм.. Интересно если например это DLP или SIEM система, то пусть попробуют её запихнуть в монолит. Одно дело десктоп приложения которые завязаны на железо(SCADA или приложение-комбайн для Side channel Analysis (типа Riscure Inspector), но даже в этих случаях примененяется система плагинов для расширения функции ПО.
Докладчик абсолютно не в материале микросервисов. 1. Определение микросервисов в корень не верно - "Микросервисы - способ проектировать приложение так, чтобы единица обслуживания и отгрузки была минимального возможного размера". Если руководствоваться его определением, то идеальная микросервисная архитектура это архитектура из entity сервисов (сервис на каждый агрегат). Но такой подход просто невероятно сильно увеличит связанность системы, превратив ее в распределенные ком грязи, оставив все минусы, как монолита так и микросервисов. 2. Тезис "Микросервисы позволят собирать разные бизнес-решения из элементарных технологических кубиков". Тут вообще нарушены все принципы микросервисов. - Микросервисы это не про "технологические", а про предметно ориентированные кубики. При разработке микросервисов основное внимание уделяется потребностям бизнеса, а не технической стороне. А если конкретнее - выявление поддомена бизнеса и определение ограниченного контекста для него. - Микроесервисы ни в коем случае не должны помогать собирать бизнес решения из кубиков. Вы путаете с SOA. Микросервисы образуют неразделяемую архитектуру (shared nothing) для максимального уменьшения связанности. Ошибочно полагать, что микросервис (ограниченный контекст) представляет собой отдельную сущность, например Customer. Он представляет собой бизнес-контекст и / или рабочий процесс, например CatalogCheckout. Цель микросервисов не в том, чтобы максимально уменьшить размер сервисов, а в том, чтобы создать полезный ограниченный контекст (решение) для конкретного поддомена (проблемы). И и достижении этого, предпочтение отдается возможному дублированию, нежели связанности.
В отличие от большинства комментаторов, не являюсь ни хейтером ни фанатом микросервисов. И очень понравилась идея, когда узнал о них + пишу под разные задачи на разных языках, поэтому вообще был в восторге, что такая костылина теперь модный стандарт, который можно использовать. Но как же ты охреневаешь, когда понял в процессе, что архитектуру нужно немного поменять. Работа просто останавливается, после того, как разрулил все связи под новое, концентрация говорит пока, давай заново включайся. Я понимаю, что комментаторы они сразу еще на схеме делают идеальную архитектуру, а потом просто одной рукой кодят, второй пьют чай и параллельно свободным глазом смотрят аниме, но не всем повезло делать каталоги или не все хотят кормить команду, в которой 1 сотрудник пишет 100 строк в сутки, разные бывают ситуации. Микросервисы это будущее и тут сомнений нет, но нужны новые максимально высокоуровневые фреймворки, которые снимут большую часть головной боли и рутины
Не согласен с теорией появления микросервисов, микросервисы появились еще в начале 2000, когда образовался такой термин как SaaS и SOA. SaaS надо было как-то разворачивать и обновлять, тогда и появились микросервисы, в 2001 уже были зачатки CI tooling-а, а после 2006, когда AWS запустила EC2 эта архитектура стала более популярной. Сама же методология DevOps появилась в 2008, а в 2010 появилась методология CI/CD
Абсолютно согласен,работал в команде, где начали пилить микросервисы, проект денег не заработал, команду сократили в итоге поддержка микросервисов обходится очень дорого, добавить функционал приходилось прям заморочиться. Потом так вышло, что начал пилить монолиты для стартапов - на этом монолите можно жить стартапу несколько лет, каждая команда пилит свой модуль - чужие не трогает. В итоге за пару месяцев выходишь на MVP. Первый же проект (на микросервисах) пилили более полугода.
Из моей практики всё же практичней(если это возможно) SOA. то есть пилим сервисы не на функции, а на процессы. К примеру из моего недавнего опыта: Система интенсивно работающая с внешними API(н-ное количество разнородных), БД и оборудованием(Производственные линии), а так же с ERP(правила интеграции наши). Пилим на отдельные сервисы: 1. Транспортный сервис для конкретного API. 2. Сервис оркестрации транспортных сервисов. 3. Сервис рутины БД(сервисные операции в ДБ). 4. Сервис пользовательского интерфейса. 5. Сервис API для клиента производственной линии. 6. Сервис интеграции с ERP. И получается что мы имея 6 видов сервисов и имея возможность их клонировать получаем гибкую систему, которую: 1. Легко изменять. 2. Легко масштабировать. 3. Легко обслуживать. 4. Отказ одного сервиса не влечет за собой шатдауна.
Интересный доклад, но представлен взгляд с инженерной точки зрения через понятия "сложности" без цифр,, хотя правильно бы взглянуть с бизнес стороны, где дешевле использовать микросераисы, а потом пивотить и создавать монолит на свой вкус. Да, будет техдолг, но на то он долг чтоб быть списан при пивотах)
Отличный пример неудачного доклада: подача с отрицаниями ("это я доказывать не буду"), тонны текста в презентации, отсутствие оригинальной идеи и т.д. Как говорится, смотри и учись (на чужих ошибках) 🙂
Ядро наверное пожалеет что взяло Даниила к себе. Когда человек больше языком чешет, чем делает это печально! Хотя Даниил воплотил мечту всех джунов - не писать производительный код, а просто языком трепать! Даниил надеюсь, я никогда не увижу код написанный вами, тем более в ядре. Желаю, чтобы вас раскусили и уволили быстрее, чем вы там что-то наделаете
Он конечно товарищь повышенной таксичности, но откуда такая злоба =). Знаний которые он переносит в дело достаточно, и то что люди с ростом меньше делают, а больше языком чешут это данность не случайность
На практике это будет выглядеть иначе. Если стартап начинается с монолита, то он и останется в нем жить до банкротства с прогрессирующей сложностью поддержки. Бюджеты на распил монолита на практике согласовать практически нереально. Его будут пытаться масштабировать, выделят людей для разработки и по итогу расходы превысят все мыслимые границы, но бизнесу покласть на всякие архитектуры, ему нужны фичи здесь и сейчас. Лучше сразу продавливать микросервисы с очевидными минусами на старте, решить все проблемы до появления нагрузок, а значит и больших штрафов\потерь средств. Нежели пытаться в начале с экономить на условную сотню часов пары разрабов.
У Вас ложная дихотомия в утверждении: "микросервисы - хорошая архитектура и поддерживаемость by design, монолит - пргрессирующая сложность и банкротство". Далее Вы, на основании этого ложного утверждения делаете выводы: "что надо продавливать микросервисы, пусть за это заплатит бизнес (правда, чужие деньги не свои же) - потому что когда-то потом это окупится". В реальности все может и скорее всего окажется наоборот. Микросервисы стартапа превратятся в микросервесный монолит о чем и говорит докладчик, а стоимость разработки будет возврастать с каждой строчкой.
Монолит можно написать хорошо и он будет маштабироваться совершенно спокойно. Модульный монолит с асинхронными ивентами и вертикальным срезами спокойно маштабируюется, а в случае необходимости модуль вносится в отдельный сервис, главное не пытаться выносить то, что должно быть рядом в бд
Миллион таблиц миллион диаграмм в стартапе? Что за чушь несет этот "знаток". Уважаемые люди из Ядра - гоните его немытой метлой, прям этот индивид портит вам авторитет!
если у вас увеличив сложность одного микро сервиса, автоматически увеличивается сложность других микросервисов, то у вас чтото не так с микросервисами и их границами
Не совсем. Есть такой функционал которых разъезжается по всем микросервисам: локализация, безопасность, обновления протоколов, логирование и т.д. и тут изменение в одном сервисе - требует менять их все...
@@michaelkokorin1145 В чем проблема вынести это все в общие либы/фрагменты/т.п. и менять один раз?
@@yaqco2172 то что можно вынести оно и так выносится... но явно не всё и иногда возникают ситуации когда весь парк микросервисов приходится менять... иногда даже накатить новую версию пакета на все микросервисы - это проблема...
Из чего он сделал вывод? Предложил идей сказал что они самоочевидны, и сказал что вывод???
Хмм..
Интересно если например это DLP или SIEM система, то пусть попробуют её запихнуть в монолит.
Одно дело десктоп приложения которые завязаны на железо(SCADA или приложение-комбайн для Side channel Analysis (типа Riscure Inspector), но даже в этих случаях примененяется система плагинов для расширения функции ПО.
звук после 40:00 просто никакой, а вопросы больше всего хотел услышать
После 44:30 стало чуть лучше...
Ядро как всегда. Извините.
Докладчик абсолютно не в материале микросервисов.
1. Определение микросервисов в корень не верно - "Микросервисы - способ проектировать приложение так, чтобы единица обслуживания и отгрузки была минимального возможного размера". Если руководствоваться его определением, то идеальная микросервисная архитектура это архитектура из entity сервисов (сервис на каждый агрегат). Но такой подход просто невероятно сильно увеличит связанность системы, превратив ее в распределенные ком грязи, оставив все минусы, как монолита так и микросервисов.
2. Тезис "Микросервисы позволят собирать разные бизнес-решения из элементарных технологических кубиков". Тут вообще нарушены все принципы микросервисов.
- Микросервисы это не про "технологические", а про предметно ориентированные кубики. При разработке микросервисов основное внимание уделяется потребностям бизнеса, а не технической стороне. А если конкретнее - выявление поддомена бизнеса и определение ограниченного контекста для него.
- Микроесервисы ни в коем случае не должны помогать собирать бизнес решения из кубиков. Вы путаете с SOA. Микросервисы образуют неразделяемую архитектуру (shared nothing) для максимального уменьшения связанности. Ошибочно полагать, что микросервис (ограниченный контекст) представляет собой отдельную сущность, например Customer. Он представляет собой бизнес-контекст и / или рабочий процесс, например CatalogCheckout. Цель микросервисов не в том, чтобы максимально уменьшить размер сервисов, а в том, чтобы создать полезный ограниченный контекст (решение) для конкретного поддомена (проблемы). И и достижении этого, предпочтение отдается возможному дублированию, нежели связанности.
В отличие от большинства комментаторов, не являюсь ни хейтером ни фанатом микросервисов. И очень понравилась идея, когда узнал о них + пишу под разные задачи на разных языках, поэтому вообще был в восторге, что такая костылина теперь модный стандарт, который можно использовать. Но как же ты охреневаешь, когда понял в процессе, что архитектуру нужно немного поменять. Работа просто останавливается, после того, как разрулил все связи под новое, концентрация говорит пока, давай заново включайся. Я понимаю, что комментаторы они сразу еще на схеме делают идеальную архитектуру, а потом просто одной рукой кодят, второй пьют чай и параллельно свободным глазом смотрят аниме, но не всем повезло делать каталоги или не все хотят кормить команду, в которой 1 сотрудник пишет 100 строк в сутки, разные бывают ситуации. Микросервисы это будущее и тут сомнений нет, но нужны новые максимально высокоуровневые фреймворки, которые снимут большую часть головной боли и рутины
Не согласен с теорией появления микросервисов, микросервисы появились еще в начале 2000, когда образовался такой термин как SaaS и SOA. SaaS надо было как-то разворачивать и обновлять, тогда и появились микросервисы, в 2001 уже были зачатки CI tooling-а, а после 2006, когда AWS запустила EC2 эта архитектура стала более популярной. Сама же методология DevOps появилась в 2008, а в 2010 появилась методология CI/CD
Абсолютно согласен,работал в команде, где начали пилить микросервисы, проект денег не заработал, команду сократили в итоге поддержка микросервисов обходится очень дорого, добавить функционал приходилось прям заморочиться.
Потом так вышло, что начал пилить монолиты для стартапов - на этом монолите можно жить стартапу несколько лет, каждая команда пилит свой модуль - чужие не трогает. В итоге за пару месяцев выходишь на MVP. Первый же проект (на микросервисах) пилили более полугода.
Из моей практики всё же практичней(если это возможно) SOA. то есть пилим сервисы не на функции, а на процессы. К примеру из моего недавнего опыта:
Система интенсивно работающая с внешними API(н-ное количество разнородных), БД и оборудованием(Производственные линии), а так же с ERP(правила интеграции наши).
Пилим на отдельные сервисы:
1. Транспортный сервис для конкретного API.
2. Сервис оркестрации транспортных сервисов.
3. Сервис рутины БД(сервисные операции в ДБ).
4. Сервис пользовательского интерфейса.
5. Сервис API для клиента производственной линии.
6. Сервис интеграции с ERP.
И получается что мы имея 6 видов сервисов и имея возможность их клонировать получаем гибкую систему, которую:
1. Легко изменять.
2. Легко масштабировать.
3. Легко обслуживать.
4. Отказ одного сервиса не влечет за собой шатдауна.
Интересный доклад, но представлен взгляд с инженерной точки зрения через понятия "сложности" без цифр,, хотя правильно бы взглянуть с бизнес стороны, где дешевле использовать микросераисы, а потом пивотить и создавать монолит на свой вкус. Да, будет техдолг, но на то он долг чтоб быть списан при пивотах)
Отличный пример неудачного доклада: подача с отрицаниями ("это я доказывать не буду"), тонны текста в презентации, отсутствие оригинальной идеи и т.д. Как говорится, смотри и учись (на чужих ошибках) 🙂
человек после 30 лет работы признаётся, что все эти 30 лет он как архитектор(или не все 30) плохо работает
Что такое терраформ кластер?
Тоже интересно :DD
Кластер, который описали и подняли с помощью террафррм?
@@jewgenijmoldawski3306 Я правильно понял, что если с помощью терраформа поднять кластер постгрес, то он называется терраформ кластер?
@@jewgenijmoldawski3306 Не похоже, спикер проговаривает "кубернетес кластер или терраформ кластер" на 6:31
не согласен
добры даклад! "Варвара Лискова" - пасьмяяўся :)
Ядро наверное пожалеет что взяло Даниила к себе. Когда человек больше языком чешет, чем делает это печально! Хотя Даниил воплотил мечту всех джунов - не писать производительный код, а просто языком трепать! Даниил надеюсь, я никогда не увижу код написанный вами, тем более в ядре. Желаю, чтобы вас раскусили и уволили быстрее, чем вы там что-то наделаете
Я тоже надеюсь, что есть разумные люди в Ядре посмотрят и выставят эту "сову на глобусе" за дверь и надеюсь карьера это "пузыря" покатится под откос
Он конечно товарищь повышенной таксичности, но откуда такая злоба =). Знаний которые он переносит в дело достаточно, и то что люди с ростом меньше делают, а больше языком чешут это данность не случайность
На практике это будет выглядеть иначе. Если стартап начинается с монолита, то он и останется в нем жить до банкротства с прогрессирующей сложностью поддержки. Бюджеты на распил монолита на практике согласовать практически нереально. Его будут пытаться масштабировать, выделят людей для разработки и по итогу расходы превысят все мыслимые границы, но бизнесу покласть на всякие архитектуры, ему нужны фичи здесь и сейчас. Лучше сразу продавливать микросервисы с очевидными минусами на старте, решить все проблемы до появления нагрузок, а значит и больших штрафов\потерь средств. Нежели пытаться в начале с экономить на условную сотню часов пары разрабов.
Монолиты тоже можно писать нормально
На практике, не доживешь ты пока получишь плюсы от микросервисов
Обидно за монолиты стало даже)
У Вас ложная дихотомия в утверждении: "микросервисы - хорошая архитектура и поддерживаемость by design, монолит - пргрессирующая сложность и банкротство". Далее Вы, на основании этого ложного утверждения делаете выводы: "что надо продавливать микросервисы, пусть за это заплатит бизнес (правда, чужие деньги не свои же) - потому что когда-то потом это окупится". В реальности все может и скорее всего окажется наоборот. Микросервисы стартапа превратятся в микросервесный монолит о чем и говорит докладчик, а стоимость разработки будет возврастать с каждой строчкой.
Монолит можно написать хорошо и он будет маштабироваться совершенно спокойно. Модульный монолит с асинхронными ивентами и вертикальным срезами спокойно маштабируюется, а в случае необходимости модуль вносится в отдельный сервис, главное не пытаться выносить то, что должно быть рядом в бд
Миллион таблиц миллион диаграмм в стартапе? Что за чушь несет этот "знаток". Уважаемые люди из Ядра - гоните его немытой метлой, прям этот индивид портит вам авторитет!
Верните этому человеку 90е. Пусть себе «строит»…