Построение Azure, который выдерживает реальный мир — с Майком Мартином [MVP]

Архитектура Azure выглядит простой, когда всё работает. Настоящая проверка начинается, когда отказывают зависимости, регионы становятся недоступны, возникают всплески трафика, оказываются неверными допущения, меняются требования и кто-то в конце концов задаёт неудобный вопрос: почему мы вообще спроектировали это именно так?В этом выпуске M365.FM Мирко Петерс беседует с Майком Мартином [MVP] о том, как выглядит архитектура Azure, когда она должна выдерживать реальные производственные условия, а не просто хорошо смотреться на схеме.Майк имеет десятилетия опыта в разработке, инфраструктуре, архитектуре, руководстве, коучинге, обучении и Microsoft Azure. Одно из его самых сильных наблюдений: многие проблемы, с которыми сталкиваются архитекторы сегодня, на самом деле не новые. DNS по-прежнему ломается. Зависимости от IP-адресов по-прежнему важны. Затраты по-прежнему становятся проблемой. Интеграции по-прежнему дают сбои. Зависимости по-прежнему исчезают в самый неподходящий момент.Изменилась сложность того, что мы строим вокруг этих проблем.

ОТ VISUAL BASIC ДО СОВРЕМЕННОЙ АРХИТЕКТУРЫ AZURE
Майк оглядывается на почти три десятилетия в ИТ: начинал он разработчиком на Visual Basic в 1990-х, затем работал с распределёнными системами, сетями, корпоративным ПО, инфраструктурой и, в конце концов, с Azure.Его ключевое наблюдение простое: отрасль продолжает решать многие одни и те же фундаментальные задачи, но архитектуры вокруг них стали намного сложнее.Современные системы перешли от клиент-серверных приложений к распределённым архитектурам, облачным платформам, контейнерам, микросервисам, Kubernetes, гибридным средам и теперь к разработке с помощью ИИ.Это открывает огромные возможности, но создаёт и новый риск: избыточное проектирование.Майк утверждает, что многие команды сегодня усложняют простые задачи без необходимости. Хорошая архитектура часто заключается не в добавлении новых технологий, а в понимании того, что не нужно добавлять.

ЧЕМ НА САМОМ ДЕЛЕ ЗАНИМАЕТСЯ АРХИТЕКТОР AZURE?
По мнению Майка, архитектура — это не выбор наибольшего количества служб Azure и не создание впечатляющей диаграммы.Речь идёт о понимании того, какие компоненты должны работать вместе, каких следует избегать, какие необходимы, и о построении решения, которое остаётся поддерживаемым, масштабируемым, безопасным и устойчивым.Архитектура включает гораздо больше, чем вычислительные ресурсы.

• Идентификация
• Сеть
• Потоки данных
• Безопасность
• Мониторинг
• Интеграция
• Зависимости
• Масштабируемость
• Эксплуатация
• Восстановление
• Развёртывание
• Стоимость

Майк также оспаривает идею, что облачно-нативный подход автоматически означает Kubernetes или контейнеры. Azure предоставляет множество управляемых и встроенных служб, которые могут решать задачи без лишних эксплуатационных издержек.Роль архитектора — понять решение целиком и выбрать самую простую архитектуру, которая при этом удовлетворяет реальным требованиям.

НАЧИНАЙТЕ С БИЗНЕС-ТРЕБОВАНИЙ, А НЕ СО СЛУЖБ AZURE
Один из важнейших уроков этого выпуска прост: не начинайте с технологий.Прежде чем выбирать между Azure Kubernetes Service, App Service, Azure Functions, контейнерами, Service Bus или другой платформой, команде следует понять, что решение на самом деле должно делать.Вопросы, которые стоит задать:

• Является ли решение внутренним или ориентированным на клиентов?
• Сколько пользователей будут от него зависеть?
• Нужно ли масштабирование на весь мир?
• Как долго можно допустить его недоступность?
• Сколько данных бизнес может позволить себе потерять?
• Какие требования соответствия применимы?
• Что произойдёт, если приложение будет недоступно несколько часов?
• Кто будет затронут?
• Какой уровень операционной поддержки необходим?

Эти вопросы напрямую ведут к таким понятиям, как SLA, SLO, RTO и RPO. Они также определяют, должна ли архитектура быть однорегиональной, многорегиональной, active-active, active-passive или значительно более простой.

RTO И RPO БЕЗ ЛИШНЕЙ ТЕРМИНОЛОГИИ
RTO и RPO часто обсуждают как технические аббревиатуры, но их реальный смысл ориентирован на бизнес.

• RTO — Recovery Time Objective: как быстро система должна восстановиться после сбоя?
• RPO — Recovery Point Objective: какая потеря данных допустима?

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

УСТОЙЧИВОСТЬ — НЕ ТО ЖЕ, ЧТО ВЫСОКАЯ ДОСТУПНОСТЬ
Майк использует простую аналогию, чтобы объяснить разницу между доступностью и устойчивостью.Высокодоступная система может иметь другой компонент, готовый взять на себя работу при отказе основного.Устойчивая система спроектирована так, чтобы выдерживать проблемы, продолжать работу, корректно восстанавливаться и возвращаться в нормальное состояние, не разрушаясь полностью.Это различие важно.Приложение может формально быть доступным и при этом предоставлять плохой пользовательский опыт.Оно может быть:

• Медленным
• Ограниченным по пропускной способности
• Частично недоступным
• Зависимым от неисправного бэкенда
• Затронутым проблемой интеграции
• Под давлением, связанным с регионом

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

AZURE НЕ ДЕЛАЕТ ВАШЕ ПРИЛОЖЕНИЕ УСТОЙЧИВЫМ АВТОМАТИЧЕСКИ
Одно опасное допущение заключается в том, что раз сам Azure высокодоступен, любое приложение, работающее в Azure, автоматически наследует эту устойчивость.Это не так.Microsoft предоставляет службы и возможности, которые делают устойчивые архитектуры возможными.Заказчики по-прежнему должны проектировать устойчивость.Здесь важны архитектурные шаблоны:

• Circuit breakers (автоматические выключатели)
• Слабая связанность
• Асинхронная обработка
• Независимое масштабирование
• Несколько зон доступности
• Несколько регионов
• Механизмы отказоустойчивого переключения
• Мониторинг
• Infrastructure as Code
• Проверенные процедуры восстановления

Microsoft предоставляет строительные блоки. Архитектура определяет, создадут ли эти блоки действительно устойчивую систему.

ПОЧЕМУ ВАЖЕН АСИНХРОННЫЙ ДИЗАЙН
Один из самых сильных примеров в беседе относится к системам, испытывающим предсказуемые всплески трафика, например к налоговым порталам государственных органов.Распространённая проблема проектирования возникает, когда каждое действие зависит от синхронной операции бэкенда.Пользователь нажимает кнопку.Фронтенд ждёт бэкенд.Бэкенд ждёт другую службу.Другая зависимость замедляется. В итоге страдает весь пользовательский опыт.Майк объясняет, почему слабосвязанные системы часто более устойчивы.Вместо того чтобы заставлять фронтенд ждать каждой операции бэкенда, приложения могут помещать работу в очереди или событийные системы и позволять компонентам независимо обрабатывать задачи.Это даёт несколько преимуществ:

• Разные компоненты могут масштабироваться независимо
• Одна служба может выйти из строя, не остановив всю платформу
• Бэкенды могут обрабатывать работу асинхронно
• Всплески трафика становится легче выдерживать
• Пользовательские компоненты становятся менее зависимыми от времени отклика бэкенда
• Сбои легче изолировать

МИФ О 100-ПРОЦЕНТНОМ АПТАЙМЕ
Ещё одна крупная тема обсуждения — одержимость стопроцентной доступностью.Майк недвусмыслен: 100-процентный аптайм — не реалистичная цель для архитектуры.Решение обычно состоит из нескольких служб.У каждой службы есть собственный SLA.Когда объединяется несколько зависимостей, совокупная