Разработка микросервисов

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

Помимо обучающего материала, в курсе приводятся примеры проблем и удачных решений из мировой и личной практики тренера, а в перерывах и после курса мы иногда решаем насущные проблемы участников :)

Тренинг будет полезен, когда
1
Вы хотите понять, нужны вам микросервисы или нет
2
Вы уже решили перейти на микросервисную архитектуру, но не знаете с чего начать
3
У вас множество архитектурных зависимостей с кучей согласований и ожиданий других команд
4
Вы уже попробовали микросервисы, но что-то пошло не так и вы получили распределенный монолит
5
Вы не можете разделить большую базу данных под микросервисы

Этот тренинг для вас, если вы

  • Архитектор любого уровня
  • Разработчик, независимо от специализации
  • Специалист по тестированию
  • Специалист по эксплуатации

Программа тренинга

  • Моделирование на основе предметной области.
    Рассматриваются основные подходы к моделированию сервисов с учетом предметной области. Микросервис рассматривается как физическая реализация шаблона Bounded Context из Domain-Driven Design.
  • Интеграция микросервисов между собой и с внешними системами.
    Выбор способа интеграции зависит от нефункциональных требований, архитектурных ограничений и принципов, архитектурного профиля решения.
  • Переход от монолита к микросервисам
    Не всегда удача на нашей стороне и иногда приходится мигрировать систему с одного архитектурного стиля на другой. Рассматриваются три основных подхода к переходу от монолита к микросервисам.
  • Стратегии развертывания микросервисов
    Одно из преимуществ микросервисов — возможность автономность поставки. Разбираются основные стратегии, позволяющие воспользоваться этим преимуществом.
  • Тестирование микросервисов (+тестирование на проде)
    В микросервисах сложность предметной области нередко снижается за счет декомпозиции и инкапсуляции сложности за API отдельных сервисов. При этом происходит частичное смещение тестовой стратегии в сторону взаимодействия из-за распределенной природы микросервисов.
  • Мониторинг микросервисов
    После того, как удалось смоделировать, определится со стратегиями интеграции, развертывания и тестирования, следует озаботиться наблюдением за системой во время исполнения и своевременной реакцией на отклонения от нормального поведения.
  • Безопасность в микросервисной архитектуре
    Безопасность рассматривается с двух сторон: безопасность отдельного сервиса и безопасность экосистемы сервисов.
  • Надежность в микросервисной архитектуре
    Сервисов становится все больше и гипер-распределенные структуры требуют иных подходов к изоляции и обработке сбоев.

Во время тренинга вы:

  • Научитесь проводить моделирование микросервисов вокруг бизнес-концепций применяя практики предметно-ориентированного проектирования
  • Построите готовую к применению стратегию перехода к автоматизации тестирования и развертывания
  • Научитесь проектировать лаконичные, удобные и обратно-совместимые API с одновременной поддержкой нескольких версий
  • Научитесь изолировать сбои в сильно распределенной среде
  • Получите пошаговую инструкцию постепенного перехода от монолитной системы к микросервисной архитектуре

Групповые скидки:

  • От 2 до 4 участников - скидка 5 %
  • От 5 и больше участников - скидка 10 %

В стоимость тренинга входит:

  • Кофебрейки
  • Раздаточный материал

Оплата тренинга возможна:

  • По счету от юридического лица (выдается акт об оказании услуг)
  • Банковской картой (выдается электронный кассовый чек)

Подробнее о том, как проходит тренинг

Вы пришли на тренинг. После того, как все познакомились друг с другом мы знакомимся с микросервисами: что это такое, где стоит применять, а в каких случаях можно обойтись другими методами. Сразу после этого собираем ожидания. Это важный этап, так как он задает позволяет выделить наиболее важные темы через практический интерес участников. Почему ожидания собираем не сразу? Чтобы они были конкретными, а не вида «Узнать, подходят ли мне микросервисы».

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

И сразу же первая практика — Event Storming. Каждая команда строит событийную модель, итеративно эта модель дополняется деталями и в итоге мы получаем модель предметной области с четкими границами. В рамках этих границ — слабосвязанные, автономные микросервисы. Каждая команда презентует результат, обсуждаем, фиксируем ошибки и интересные идеи.

Микросервисам нужны другие микросервисы и мы переходим к вопросам интеграции. В деталях разбираем как передаются сообщения через границы сервисов и особенно акцентируем внимание на CQRS/ES и SAGA, так как этот простой на первый взгляд подход содержит множество подводных камней («как джойнить большие наборы данных» или «что делать, если произошла ошибка при выполнении компенсирующего события»). Это первые технические детали архитектурного решения.

Затем немного отвлекаемся от задания и разбираем подходы к переходу от монолита к микросервисам. Разбираем на практическом примере с применением полученных знаний по интеграции и организации данных в соответствии с предметной областью. Как итог — оптимальные стратегии под различные начальные условия.

Сервисы как-то нужно разворачивать. Разбираем 6 стратегий поставки и выбираем свою собственную (или комбинацию) под каждый микросервис из задания. Это важно, так как стратегии (Canary, Blue/Green, Shadow Traffic и прочие) отличаются по сложности и стоимости реализации и снижают риск поставки немного по-разному.

Следом — выбор стратегии тестирования. Она отличается от стратегии тестирования монолитного решения. Большой упор идет в контрактное тестирование и тестирование в боевом окружении. На стратегию тестирования влияет стратегия поставки. Каждая команда создает такую стратегию для своей архитектуры.

Переходим к мониторингу, но смотрим на него шире, — через Observability. Этот термин включает в себя и Alert'ы и мониторинг и логи и аудит, да еще и со сквозной трассировкой. В рамках этого блока мы строим архитектуру Observability-системы для своего продукта и выбираем технологический стек, удовлетворяющий поставленным требованиям (дополнение к основному заданию).

Модель угроз для микросервисов отличается от модели угроз для более традиционных систем и мы разбираем как конкретно. Дополняем техническую архитектуру системами аутентификации и авторизации, добавляем интеграционные точки безопасности и рассматриваем концепцию DevSecOps. Все вместе разбираем, что получилось и как и во всех предыдущих блоках — фиксируем удачные и неудачные решения.

В завершении разбираем как обеспечить надежность. Разбираем подход Chaos Engineering и так называемую Иммунную Систему микросервисов. Дополняем техническое решение.

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

В завершении смотрим на реальные стратегии компаний по переходу от монолита к микросервисам.

Жарихин ДмитрийООО «Хэдхантер»

Отличный тренинг для вхождения в область микросервисов и систематизации знаний в этой области.

Сергей ЛаптевSmartcat

Был шикарный материал, дает кругозор по тематике. Тренеру отдельное спасибо за конкретику и примеры из жизни.

Оксана ВигантеКОМПЭЛ

Структурированный вводный курс, позитивная атмосфера, которую поддерживает тренер. Объем знаний позволяет понять дальнейшее направление на новом для меня пути.

Андрей ЧебыкинООО "МТС ИТ"

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

Тренер

Сергей Баранов

Сергей имеет более чем 15-летний практически опыт в области проектирования и развития архитектур систем и управления продуктами различной степени сложности. В 15 лет написал первое коммерчески успешное приложение, что и послужило толчком к дальнейшему развитию. Долгое время проработал архитектором в проекте для Boeing, в котором были задействованы десятки систем и сотни людей. Был архитектором банковского многоканального решения, после чего занимался развитием направления по информационной безопасности в качестве консультанта.