Название: "Код Зла"
Сценарий:
Начало
Туманный городской пейзаж. Мы видим старое здание с табличкой "Software Corp". Главный герой - Алекс, молодой архитектор ПО, приезжает на новое место работы, где ему поручают создание новой банковской системы.
Сюжет 1: Таинственное наследие
Алекс знакомится с командой и узнает, что последний архитектор, работавший над этим проектом, исчез без следа. Оставив лишь заметку: "Разберитесь с доменами... или они разберутся с вами".
Сюжет 2: Пробуждение домена
Алекс начинает анализировать предметную область. Каждый раз, когда он ошибается в понимании домена, странные вещи начинают происходить: свет мерцает, программное обеспечение ведет себя непредсказуемо, а коллеги слышат шепот неведомой сущности в коридорах.
Сюжет 3: Встреча с предыдущим архитектором
Алекс случайно обнаруживает потайную дверь в офисе. За ней - старый серверный кластер и дневник прошлого архитектора. Дневник рассказывает о том, как домены, неправильно оформленные и понятые, стали живыми сущностями, стремящимися воплотить свои правила и инварианты в реальном мире.
Сюжет 4: Борьба и понимание
Алекс решает воспользоваться DDD, чтобы "укротить" домены. Его команда, преодолевая страх, ведет глубокие интервью с экспертами домена, определяя ограниченные контексты и настоящие потребности пользователей. С каждым новым открытием, мистическая активность в офисе уменьшается.
Сюжет 5: Конечная битва
Алекс создает идеальную модель, где каждый агрегат и сущность на своем месте. Однако, последний домен, самый сложный и неясный, начинает активно сопротивляться. Свет гаснет, здание начинает трястись. Алекс, вдохновленный духом прошлого архитектора, проводит мастер-класс по DDD, и в результате выявляется последний недостающий элемент. Сущность, терроризировавшая их, успокаивается и становится частью их системы.
Конец
Солнце вновь светит над "Software Corp". Алекс и его команда понимают, что настоящая магия DDD - в понимании и сотрудничестве. Вдали, туманный силуэт предыдущего архитектора благодарно кивает им и исчезает.
Титры.
(с) ChatGPT
Сценарий:
Начало
Туманный городской пейзаж. Мы видим старое здание с табличкой "Software Corp". Главный герой - Алекс, молодой архитектор ПО, приезжает на новое место работы, где ему поручают создание новой банковской системы.
Сюжет 1: Таинственное наследие
Алекс знакомится с командой и узнает, что последний архитектор, работавший над этим проектом, исчез без следа. Оставив лишь заметку: "Разберитесь с доменами... или они разберутся с вами".
Сюжет 2: Пробуждение домена
Алекс начинает анализировать предметную область. Каждый раз, когда он ошибается в понимании домена, странные вещи начинают происходить: свет мерцает, программное обеспечение ведет себя непредсказуемо, а коллеги слышат шепот неведомой сущности в коридорах.
Сюжет 3: Встреча с предыдущим архитектором
Алекс случайно обнаруживает потайную дверь в офисе. За ней - старый серверный кластер и дневник прошлого архитектора. Дневник рассказывает о том, как домены, неправильно оформленные и понятые, стали живыми сущностями, стремящимися воплотить свои правила и инварианты в реальном мире.
Сюжет 4: Борьба и понимание
Алекс решает воспользоваться DDD, чтобы "укротить" домены. Его команда, преодолевая страх, ведет глубокие интервью с экспертами домена, определяя ограниченные контексты и настоящие потребности пользователей. С каждым новым открытием, мистическая активность в офисе уменьшается.
Сюжет 5: Конечная битва
Алекс создает идеальную модель, где каждый агрегат и сущность на своем месте. Однако, последний домен, самый сложный и неясный, начинает активно сопротивляться. Свет гаснет, здание начинает трястись. Алекс, вдохновленный духом прошлого архитектора, проводит мастер-класс по DDD, и в результате выявляется последний недостающий элемент. Сущность, терроризировавшая их, успокаивается и становится частью их системы.
Конец
Солнце вновь светит над "Software Corp". Алекс и его команда понимают, что настоящая магия DDD - в понимании и сотрудничестве. Вдали, туманный силуэт предыдущего архитектора благодарно кивает им и исчезает.
Титры.
(с) ChatGPT
Опрос, касается только статей, не книг и только архитектуры/дизайна.
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Anonymous Poll
24%
Быстро находите ответ
36%
Долго и упорно ищите и в итоге находите ответ
22%
Чаще не находите ответ
2%
Ни разу не смогли найти ответ
16%
Посмотреть результаты
Микросервисы / распределенные системы
Опрос, касается только статей, не книг и только архитектуры/дизайна.
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Интересно посмотреть на результат вот с какой точки зрения: в сумме второй и третий ответы дают больше половины. То есть, вообще-то, несмотря на бесчисленное множество и бесконечное обилие материалов, найти что-то конкретное достаточно сложно, а если возможно, то затратно по времени.
В таких условиях выглядит так, что лучше тактикой будет стараться сократить необходимость использования поисковых систем, тут подходов много и все они затратные, но все же:
1. Максимально вкладываться в образование (в широком смысле). Часто из-за высокой загрзуки на это остается мало времени, а именно это дает возможность сократить множество нерешаемых задач
2. Формировать внутренние и внешние сообщества, где вбросил вопрос и кто-то может знать конкретный вектор поиска ответа или ответ
3. Развивать практические навыки на различных хакатонах и за счет прототипирования, – теория без практики быстро выветривается из головы
4. Расширять кругозор на митапах и конференциях, – здесь как раз идеи того, что можно попробовать сделать на практике; важно то, что вы знаете с кем можно обсудить проблему детальнее, этот человек буквально перед вами
5. Отдавать предпочтение книгам, – все-таки долгое погружение в один контекст дает лучший эффект, чем сотня разрозненных статей. Статьи пишут те, кто читает книги 🙂 Это я, конечно, упростил, но, скорее всего, именно книги помогут чаще находить ответы самостоятельно, потому что они развивают мысль, а статьи все ж чаще дают конкретный ответ, без более широго контекста, подводки, рассуждений, выводов с примерами и так далее
Поделитесь своими идеями в комментариях, какие еще видите подходы?
Может быть у нас вместе получится собрать несложный фреймворк/экосистему с конкретными материалами, но сначала нужно определить базис, а это как раз и есть различные подходы.
В таких условиях выглядит так, что лучше тактикой будет стараться сократить необходимость использования поисковых систем, тут подходов много и все они затратные, но все же:
1. Максимально вкладываться в образование (в широком смысле). Часто из-за высокой загрзуки на это остается мало времени, а именно это дает возможность сократить множество нерешаемых задач
2. Формировать внутренние и внешние сообщества, где вбросил вопрос и кто-то может знать конкретный вектор поиска ответа или ответ
3. Развивать практические навыки на различных хакатонах и за счет прототипирования, – теория без практики быстро выветривается из головы
4. Расширять кругозор на митапах и конференциях, – здесь как раз идеи того, что можно попробовать сделать на практике; важно то, что вы знаете с кем можно обсудить проблему детальнее, этот человек буквально перед вами
5. Отдавать предпочтение книгам, – все-таки долгое погружение в один контекст дает лучший эффект, чем сотня разрозненных статей. Статьи пишут те, кто читает книги 🙂 Это я, конечно, упростил, но, скорее всего, именно книги помогут чаще находить ответы самостоятельно, потому что они развивают мысль, а статьи все ж чаще дают конкретный ответ, без более широго контекста, подводки, рассуждений, выводов с примерами и так далее
Поделитесь своими идеями в комментариях, какие еще видите подходы?
Может быть у нас вместе получится собрать несложный фреймворк/экосистему с конкретными материалами, но сначала нужно определить базис, а это как раз и есть различные подходы.
Традиционно для подписчиков канала скидка на archdays.ru 20% и на онлайн и на оффлайн по промокоду microservices_arch
В этом году большой конкурс и чтобы никого не расстраивать, с теми, кто согласился, мы провели и проведем еще митапы (два уже запланировано, скоро анонсы), а спикеров митапов ArchDays Meetup мы приглашаем бесплатно на конференцию, так что их можно будет найти пообщаться 🙂
В этом году большой конкурс и чтобы никого не расстраивать, с теми, кто согласился, мы провели и проведем еще митапы (два уже запланировано, скоро анонсы), а спикеров митапов ArchDays Meetup мы приглашаем бесплатно на конференцию, так что их можно будет найти пообщаться 🙂
On the Definition of Microservice Bad Smells.pdf
312.1 KB
Список Microservices Bad Smells. Смотрим в статью, смотрим на свое решение, думаем.
Microservices_Migration_of_a_Mission_Critical_Syst.pdf
1.1 MB
Миграция на микросервисы Mission Critical системы.
Анонс ArchDays MeetUp
12 сентября в 19:00 Илья Смирнов, руководитель практики ML/AI в ГК Юзтех расскажет об архитектуре системы моделирования на базе цифровых двойников производства.
На многих отечественных производствах полным ходом идет цифровизация, практически все технологические параметры уже измеряют с помощью тех или иных датчиков. При этом важно не только быть наблюдателем процесса, но и иметь возможность его моделировать, и тут на помощь приходят цифровые двойники – математические модели, корректно описывающие поведение конкретного объекта, оборудования.
Подробнее и регистрация тут:
https://meetup.archdays.ru/meetup-12092023
Ждем всех, будет интересно!
12 сентября в 19:00 Илья Смирнов, руководитель практики ML/AI в ГК Юзтех расскажет об архитектуре системы моделирования на базе цифровых двойников производства.
На многих отечественных производствах полным ходом идет цифровизация, практически все технологические параметры уже измеряют с помощью тех или иных датчиков. При этом важно не только быть наблюдателем процесса, но и иметь возможность его моделировать, и тут на помощь приходят цифровые двойники – математические модели, корректно описывающие поведение конкретного объекта, оборудования.
Подробнее и регистрация тут:
https://meetup.archdays.ru/meetup-12092023
Ждем всех, будет интересно!
Forwarded from Event Storming (Sergey Baranov)
Нужно ли разработчикам/тестировщикам/админам знать бизнес-модель компании/продукта в которой они работают? (напишите в комментариях чем это, на ваш взгляд, помогает или почему в этом нет смысла).
Позже напишу причем тут бизнес-модель :)
Позже напишу причем тут бизнес-модель :)
Anonymous Poll
93%
Да
7%
Нет
Микросервисы / распределенные системы
У меня окончательно оформилось предложение по точечному аудиту/исследованию микросервисного архитектурного решения :) Аудит затрагивает: - степень соответствия выбранного стиля бизнес-модели и потребностям рынка - степень соответствия орг. структуры микросервисному…
Первый публичный заход.
Сегодня на it-picnic.ru расскажу о быстром восстановлении архитектурных знаний.
Выступление построил практико-ориентированным, то есть буквально, что делать по дням, чтобы быстро получить широкий спектр архитектурных знаний, когда скорость важнее точности и полноты.
После пикника подготовлю небольшую методичку, по плану к ArchDays будет готова.
И с первыми артефактами уже можно будет с желающими поучаствовать объединяться в группу :)
Сегодня на it-picnic.ru расскажу о быстром восстановлении архитектурных знаний.
Выступление построил практико-ориентированным, то есть буквально, что делать по дням, чтобы быстро получить широкий спектр архитектурных знаний, когда скорость важнее точности и полноты.
После пикника подготовлю небольшую методичку, по плану к ArchDays будет готова.
И с первыми артефактами уже можно будет с желающими поучаствовать объединяться в группу :)
IT_Пикник.pdf
9.1 MB
Презентация с выступления.
В компании три команды, все три проводят дискавери.
Все проверяют гипотезы, у кого-то срабатывает.
Означает ли это, что другие ошиблись? Нет. Это же гипотезы. Они на выходе имеют два легитимных состояния – подтверждена или опровергнута.
А вот те, чьи гипотезы не подтвердились, внесли точно такой же вклад, ведь если бы их не было, то эти гипотезы, скорее всего, все равно кто-то в итоге проверял. Если в описанном выше кейсе одна команда проверяла бы все гипотезы, то существует вероятность, что такая команда вообще дошла бы до подтвержденной гипотезы, остановившись где-то в середине пути.
Если какая-то гипотеза не подтвердилась, то нужно сделать формальные выводы, а результатом будет увеличение объема знаний об объекте исследования и сужение мощности множества доступных вариантов для последующей проверки.
Это касается как продуктовых гипотез, так и технических экспериментов.
Спроектированные по всем канонам микросервисы позволяют проверять в единицу времени множество гипотез, как касающихся продукта, так и технических характеристик решения, что так же косвенно сильно приближает точку достижения успешности решения в целом.
Все проверяют гипотезы, у кого-то срабатывает.
Означает ли это, что другие ошиблись? Нет. Это же гипотезы. Они на выходе имеют два легитимных состояния – подтверждена или опровергнута.
А вот те, чьи гипотезы не подтвердились, внесли точно такой же вклад, ведь если бы их не было, то эти гипотезы, скорее всего, все равно кто-то в итоге проверял. Если в описанном выше кейсе одна команда проверяла бы все гипотезы, то существует вероятность, что такая команда вообще дошла бы до подтвержденной гипотезы, остановившись где-то в середине пути.
Если какая-то гипотеза не подтвердилась, то нужно сделать формальные выводы, а результатом будет увеличение объема знаний об объекте исследования и сужение мощности множества доступных вариантов для последующей проверки.
Это касается как продуктовых гипотез, так и технических экспериментов.
Спроектированные по всем канонам микросервисы позволяют проверять в единицу времени множество гипотез, как касающихся продукта, так и технических характеристик решения, что так же косвенно сильно приближает точку достижения успешности решения в целом.
Domain-driven-design patterns for domain-driven microservice design, in UML notation
На тот случай, если кому-то в UML надо будет отобразить элементы DDD
source:https://ieeexplore.ieee.org/document/8354426
На тот случай, если кому-то в UML надо будет отобразить элементы DDD
source:https://ieeexplore.ieee.org/document/8354426
Микросервисы / распределенные системы
Декомпозиция наглядно.
По этой картинке необходимо пояснение.
Что здесь изображено?
По пунктам:
1. Существует бекенд, в котором сервисы Calculator и PartnerService зависят друг от друга неявным образом через сервис ContractService. То есть в изображенной структуре все зависят ото всех и изменения в любом из компонентов прямо или косвенно оказывает влияение на все 5 компонентов.
2. Посредством моделирования (этот процесс за скобками, можно использовать классический DDD, можно Event Storming, можно Domain Storytelling, да даже исходя из Business Capabilities) были определены границы и эти границы наложены на существующее решение. Мы видим на изображении, что Contract, Partner и ContractService по текущей внутренней реализации одновременно востребован и в контексте Sales и в контексте Risk Assessment.
3. Здесь изображеная целевая картинка, как может выглядеть декомпозиция. В Sales остается ContractService, в Risk Assessment остается PartnerService. Но остается вопрос: «а что делать с общей сущностью?». И ответ далеко не очевиден, потому что если посмотреть только на данные, то вроде как они нужны и там и там. Проблема в том, что зачастую в самих данных, в самих атрибутах нет метаданных об использовании этих атрибутов в тех или иных бизнес-операциях, контекстах, бизнес-процессах. Эту информацию приходится воссоздавать, чтобы определить какие данные в каком контексте какой смысл несут. Это важнейший аспект и как раз его нарушение ведет к появлению тех самых распределенных монолитов.
Как с этим быть?
4. В рамках моделирования и определения Ubiquitous Language (по сути языка, в котором каждый термин имеет однозначеное значение в заданной границе) мы выясняем, что в контексте Risk Assessment нет понятия signContract(), соответственно в этом контексте нет и термина для атрибута signatureDate. При этом исследуя Sales мы видим, что в этом контексте, контексте Продаж, нет понятия voteContract и в нем не определены термины ceditRating и votingResult. То есть здесь явным образом в одном сервисе и в одной сущности смешаны понятия из двух разных моделей. Негативное следствие этого – увеличение общей сложности, зависимости, размытие ответственности, ну и как следствие – подобная реализация сдерживает развитие каждой модели в отдельности. Что с этим делать?
Есть два варианта, безопасный и менее безопасный.
Безопасный показан на изображении:
5. Мы явно в рамках существующего сервиса делаем дубликат сущности Contract и сервиса ContractService и проводим рефакторинг внутри существующего сервиса. Например, это могут быть разные пакеты со своими интерфейсами.
6. В каждом из пакетов мы вычищаем то, что не относится к конкретному контексту, то есть проводим рефакторинг. Рефакторинг это ровно потому, что поведение не меняется, меняется только структура.
7. Получаем в рамках все того же монолита два пакетета, в рамках каждого из которых только сущности и методы, имеющие смысл в рамках определенного контекста.
Теперь о неточностях в изображении.
Возможно автор поторопился и есть нюанс, который вызывает вопросы, а именно, то, что на изображении (3) отсутствует сервис ContractService, хотя на последущих слайдах он указывает, что такой сервис существует. Это нисколько не меняет сути описанного подхода. Можно мысленно представить, что на изображении (3) есть еще один сервис ContractService, смысл не меняется совершенно, так как смысл ровно в том, каким образом разорвать зависимость.
Менее безопасный вариант:
Мы сразу выносим физически сервис ContractService в отдельный контекст, теперь у нас по инстансу ContractService в Sales и Risk Assessment, и проводим рефакторинг двух сервисов параллельно.
Что здесь изображено?
По пунктам:
1. Существует бекенд, в котором сервисы Calculator и PartnerService зависят друг от друга неявным образом через сервис ContractService. То есть в изображенной структуре все зависят ото всех и изменения в любом из компонентов прямо или косвенно оказывает влияение на все 5 компонентов.
2. Посредством моделирования (этот процесс за скобками, можно использовать классический DDD, можно Event Storming, можно Domain Storytelling, да даже исходя из Business Capabilities) были определены границы и эти границы наложены на существующее решение. Мы видим на изображении, что Contract, Partner и ContractService по текущей внутренней реализации одновременно востребован и в контексте Sales и в контексте Risk Assessment.
3. Здесь изображеная целевая картинка, как может выглядеть декомпозиция. В Sales остается ContractService, в Risk Assessment остается PartnerService. Но остается вопрос: «а что делать с общей сущностью?». И ответ далеко не очевиден, потому что если посмотреть только на данные, то вроде как они нужны и там и там. Проблема в том, что зачастую в самих данных, в самих атрибутах нет метаданных об использовании этих атрибутов в тех или иных бизнес-операциях, контекстах, бизнес-процессах. Эту информацию приходится воссоздавать, чтобы определить какие данные в каком контексте какой смысл несут. Это важнейший аспект и как раз его нарушение ведет к появлению тех самых распределенных монолитов.
Как с этим быть?
4. В рамках моделирования и определения Ubiquitous Language (по сути языка, в котором каждый термин имеет однозначеное значение в заданной границе) мы выясняем, что в контексте Risk Assessment нет понятия signContract(), соответственно в этом контексте нет и термина для атрибута signatureDate. При этом исследуя Sales мы видим, что в этом контексте, контексте Продаж, нет понятия voteContract и в нем не определены термины ceditRating и votingResult. То есть здесь явным образом в одном сервисе и в одной сущности смешаны понятия из двух разных моделей. Негативное следствие этого – увеличение общей сложности, зависимости, размытие ответственности, ну и как следствие – подобная реализация сдерживает развитие каждой модели в отдельности. Что с этим делать?
Есть два варианта, безопасный и менее безопасный.
Безопасный показан на изображении:
5. Мы явно в рамках существующего сервиса делаем дубликат сущности Contract и сервиса ContractService и проводим рефакторинг внутри существующего сервиса. Например, это могут быть разные пакеты со своими интерфейсами.
6. В каждом из пакетов мы вычищаем то, что не относится к конкретному контексту, то есть проводим рефакторинг. Рефакторинг это ровно потому, что поведение не меняется, меняется только структура.
7. Получаем в рамках все того же монолита два пакетета, в рамках каждого из которых только сущности и методы, имеющие смысл в рамках определенного контекста.
Теперь о неточностях в изображении.
Возможно автор поторопился и есть нюанс, который вызывает вопросы, а именно, то, что на изображении (3) отсутствует сервис ContractService, хотя на последущих слайдах он указывает, что такой сервис существует. Это нисколько не меняет сути описанного подхода. Можно мысленно представить, что на изображении (3) есть еще один сервис ContractService, смысл не меняется совершенно, так как смысл ровно в том, каким образом разорвать зависимость.
Менее безопасный вариант:
Мы сразу выносим физически сервис ContractService в отдельный контекст, теперь у нас по инстансу ContractService в Sales и Risk Assessment, и проводим рефакторинг двух сервисов параллельно.
Микросервисы / распределенные системы
Декомпозиция наглядно.
/// продолжение
В чем тут потенциальные проблемы?
- Двойные усилия, – параллельно из двух сервисов вычищается ненужный код
- Цена ошибки, – если мы допустили ошибку в определении места того или иного понятия, то в рамках единой кодовой базы мы просто перебросим код средствами IDE, если же это разные сервисы, то нужно будет перекидывать логику из одного сервиса в другой, физически из одного репозитория в другой. Если вспомнить, что сервисы не живут в изоляции, то нужно будет перенести и тестовые сценарии, а возможно и изменить какие-то внешние интерфейсы. Это очень дорого.
- Миграция данных, – опять же, следствие физического разграничения, – нужно будет не только бизнес-логику передать в другой сервис, но и физически мигрировать данные, а это могут быть в принципе даже совершенно разные базы данных (PG и Mongo, например).
Вывод
Несмотря на то, что изображение действительно может вызвать неоднозначное толкование, процесс на нем показан корректный с точки зрения иллюстрации того, каким образом происходит разрыв зависимостей на уровне предметной области, а именно, – устранение множественных, несовместимых на уровне моделей/контекстов, ответственностей и атрибутов. Несовместимых здесь означает, что есть одна сущность, например Contract, используется в двух моделях и в каждой из моделей у этой сущности есть атрибуты или поведение, которые не определены в этой модели или имеют собственное определение в каждой из моделей. Последнее означает, что каждая модель использует атрибут по-своему в своем контексте и изменения в одной модели могут привести (и часто приводят) к некорректному поведению в другой модели.
Надеюсь, что после этого пояснения станет немного понятнее, спасибо за внимание 🙂
PS: сама презентация: https://speakerdeck.com/hschwentner/domain-driven-transformation
В чем тут потенциальные проблемы?
- Двойные усилия, – параллельно из двух сервисов вычищается ненужный код
- Цена ошибки, – если мы допустили ошибку в определении места того или иного понятия, то в рамках единой кодовой базы мы просто перебросим код средствами IDE, если же это разные сервисы, то нужно будет перекидывать логику из одного сервиса в другой, физически из одного репозитория в другой. Если вспомнить, что сервисы не живут в изоляции, то нужно будет перенести и тестовые сценарии, а возможно и изменить какие-то внешние интерфейсы. Это очень дорого.
- Миграция данных, – опять же, следствие физического разграничения, – нужно будет не только бизнес-логику передать в другой сервис, но и физически мигрировать данные, а это могут быть в принципе даже совершенно разные базы данных (PG и Mongo, например).
Вывод
Несмотря на то, что изображение действительно может вызвать неоднозначное толкование, процесс на нем показан корректный с точки зрения иллюстрации того, каким образом происходит разрыв зависимостей на уровне предметной области, а именно, – устранение множественных, несовместимых на уровне моделей/контекстов, ответственностей и атрибутов. Несовместимых здесь означает, что есть одна сущность, например Contract, используется в двух моделях и в каждой из моделей у этой сущности есть атрибуты или поведение, которые не определены в этой модели или имеют собственное определение в каждой из моделей. Последнее означает, что каждая модель использует атрибут по-своему в своем контексте и изменения в одной модели могут привести (и часто приводят) к некорректному поведению в другой модели.
Надеюсь, что после этого пояснения станет немного понятнее, спасибо за внимание 🙂
PS: сама презентация: https://speakerdeck.com/hschwentner/domain-driven-transformation
Очень интересный ресурс, для общего развития «40 maps that explain the internet»
https://www.vox.com/a/internet-maps
https://www.vox.com/a/internet-maps
vox.com
40 maps that explain the internet
The internet increasingly pervades our lives, delivering information to us no matter where we are. It takes a complex system of cables, servers, towers, and other infrastructure, developed over decades, to allow us to stay in touch with our friends and family…
Пошел удивительный тренд (впервые был замечен на хабре), что микросервисы – это не распределенная система (а земля, видимо, все-таки плоская). Достаточно взять определение Таненбаума: «Распределенная система — это набор независимых компьютеров, представляющийся их пользователям единой объединенной системой. В этом определении оговариваются два момента. Первый относится к аппаратуре: все машины автономны. Второй касается программного обеспечения: пользователи думают, что имеют дело с единой системой.»
Если так подумать, то у нас сейчас практически любая система – распределенная система :)
Но что касается микросервисов, – это не просто распределенная система, у этого архитектурного стиля есть ряд важных особенностей, а именно в микросервисном архитектурном стиле должна быть обеспечена:
- Независимость на уровне моделей предметных областей, что дает независимое, но в то же время полное понимание отдельно взятого микросервиса
- Возможность одновременного сосуществование нескольких версий одного сервиса
- Независимое эволюционное развитие за счет сокрытия внутренней реализации (независимая реализация, независимое развертываение, независимое тестирование, независимая возможность выбора используемых технологий)
- Изоляция сбоев на уровне отдельных микросервисов
- При необходимости – изменение топологии в режиме реального времени
- Отдельный микросервис может быть изменен без влияния на работу других микросервисов
Это свойства микросервисного архитектурного стиля, если какие-то свойства не заложены, то это не микросервисный архитектурный стиль. Поэтому, когда вам говорят или вы слышите на конференциях, что «один микросервис упал и все сломалось», «сложно провести полный регресс всех микросервисов», «необходимость внесения изменений во всех микросервисах для реализации одной фичи приводит к тому, что нельзя зарелизить ничего, пока все не сделают», – это про какой-то другой архитектурный стиль и на самом деле такие выступления в большей степени указывают не на недостатки микросервисов, а на то, что пишут или рассказывают про что-то другое.
Это равнозначно, что сказать - борщ - это фигня и рассказывать про вермишелевый суп. Вроде суп, но ведь не тот же :)
Микросервисы - это совсем не просто. Это большая и сложная работа как раз потому, что включает в себя и околостоящие инженерные практики и изменение процессов и порой смену самой парадигмы разработки. Нередко с моего курса по микросервисам уходят с осознанием, что вроде как они и не нужны в конкретном проекте.
Не бывает правильных или неправильных архитектурных решений, бывают подходящие и не подходящие и если пихать везде что-то из-за хайпа, то где-то оно покажет хороший результат, но это будет, скорее случайность, чем осознанный выбор.
Если так подумать, то у нас сейчас практически любая система – распределенная система :)
Но что касается микросервисов, – это не просто распределенная система, у этого архитектурного стиля есть ряд важных особенностей, а именно в микросервисном архитектурном стиле должна быть обеспечена:
- Независимость на уровне моделей предметных областей, что дает независимое, но в то же время полное понимание отдельно взятого микросервиса
- Возможность одновременного сосуществование нескольких версий одного сервиса
- Независимое эволюционное развитие за счет сокрытия внутренней реализации (независимая реализация, независимое развертываение, независимое тестирование, независимая возможность выбора используемых технологий)
- Изоляция сбоев на уровне отдельных микросервисов
- При необходимости – изменение топологии в режиме реального времени
- Отдельный микросервис может быть изменен без влияния на работу других микросервисов
Это свойства микросервисного архитектурного стиля, если какие-то свойства не заложены, то это не микросервисный архитектурный стиль. Поэтому, когда вам говорят или вы слышите на конференциях, что «один микросервис упал и все сломалось», «сложно провести полный регресс всех микросервисов», «необходимость внесения изменений во всех микросервисах для реализации одной фичи приводит к тому, что нельзя зарелизить ничего, пока все не сделают», – это про какой-то другой архитектурный стиль и на самом деле такие выступления в большей степени указывают не на недостатки микросервисов, а на то, что пишут или рассказывают про что-то другое.
Это равнозначно, что сказать - борщ - это фигня и рассказывать про вермишелевый суп. Вроде суп, но ведь не тот же :)
Микросервисы - это совсем не просто. Это большая и сложная работа как раз потому, что включает в себя и околостоящие инженерные практики и изменение процессов и порой смену самой парадигмы разработки. Нередко с моего курса по микросервисам уходят с осознанием, что вроде как они и не нужны в конкретном проекте.
Не бывает правильных или неправильных архитектурных решений, бывают подходящие и не подходящие и если пихать везде что-то из-за хайпа, то где-то оно покажет хороший результат, но это будет, скорее случайность, чем осознанный выбор.