Service Mesh на стероидах, часть 2: Zero Deployment Downtime в корпоративных приложениях

Enterprise-системы

Доклад принят в программу конференции

Мнение Программного комитета о докладе

Вторая часть эпической трилогии Алексея, посвященной деплою толп микросервисов в кубер без даунтайма и чтобы кубер не лопнул. Вторая часть фокусируется на работе с message bus.

Тезисы

Представляю вторую часть триптиха на тему "Service Mesh в Enterprise-grade-приложениях". В первой части я рассказал о построении управляемого многоуровневого Service Mesh и дал основные паттерны его использования для обеспечения версионирования и структурирования приложений. Вторая часть будет посвящена техникам ВlueGreen и Canary-деплоймента для обеспечения Zero Deployment Downtime.

Основная проблема с выкатыванием обновления на работающее приложение возникает тогда, когда меняется контракт между частями приложения — путь API, структура данных в REST-запросе, тело message в Kafka и т.п. И нам нужно обеспечить плавность перехода от предыдущего контракта к новому.

Service Mesh в данном контексте является "системным интегратором", который, помимо управления непосредственно REST-взаимодействием, также управляет другими средами — Messaging и DB. Особенностью решения является то, что управление версиями происходит за счёт фреймворка с минимальным участием со стороны прикладных микросервисов — они зачастую могут и не знать, что работают в мультиверсионной среде.

Первая часть: https://www.youtube.com/watch?v=XtvwZqdtfgI

Системный архитектор, руководитель отдела Cloud Core.
Пришел в Netcracker из аэрокосмической отрасли уже больше 15 лет назад. Участвовал как архитектор в разработке десятка продуктов и их внедрении по всему миру. Всегда тяготел к построению крупных низкоуровневых платформ и фреймворков. На волне интереса к облакам в 2015 году стоял у истоков следующего поколения продуктов — Netcracker Cloud Native, реализовав системную архитектуру и ядро решения. С тех пор руководит отделом, который разрабатывает это ядро.

Netcracker

.

Видео