Створення Azure, який витримує реальні умови — з Майком Мартіном [MVP]

Архітектура Azure виглядає простою, доки все працює. Справжнє випробування починається, коли відмовляють залежності, регіони стають недоступними, навантаження різко зростає, припущення виявляються хибними, вимоги змінюються і хтось зрештою ставить незручне запитання: чому ми взагалі побудували це саме так?У цьому епізоді M365.FM Mirko Peters розмовляє з Mike Martin [MVP] про те, якою має бути архітектура Azure, коли вона має витримувати реальні умови продуктивного середовища, а не лише добре виглядати на діаграмі.Mike має десятиліття досвіду в розробці, інфраструктурі, архітектурі, керівництві, коучингу, навчанні та Microsoft Azure. Одне з його найсильніших спостережень полягає в тому, що багато проблем, з якими стикаються архітектори сьогодні, насправді не є новими. DNS досі ламається. Залежності від IP досі важливі. Витрати досі стають проблемою. Інтеграції досі відмовляють. Залежності досі зникають у найгірший момент.Змінився рівень складності, який ми будуємо навколо цих проблем.

ВІД VISUAL BASIC ДО СУЧАСНОЇ АРХІТЕКТУРИ AZURE
Mike озирається на майже три десятиліття в IT, починаючи з розробника Visual Basic у 1990-х і переходячи через розподілені системи, мережі, корпоративне програмне забезпечення, інфраструктуру і зрештою Azure.Його ключове спостереження просте: галузь продовжує розв'язувати багато тих самих фундаментальних проблем, але архітектури навколо них стали значно складнішими.Сучасні системи перейшли від клієнт-серверних застосунків до розподілених архітектур, хмарних платформ, контейнерів, мікросервісів, Kubernetes, гібридних середовищ і тепер до розробки з підтримкою ШІ.Це відкриває величезні можливості, але також створює новий ризик: надмірне ускладнення.Mike стверджує, що багато команд сьогодні роблять прості проблеми непотрібно складними. Хороша архітектура часто полягає не в додаванні технологій, а в розумінні того, чого не треба додавати.

ЩО НАСПРАВДІ РОБИТЬ АРХІТЕКТОР AZURE?
Для Mike архітектура — це не вибір найбільшої кількості сервісів Azure і не створення вражаючої діаграми.Це розуміння того, які компоненти належать разом, які слід уникати, які необхідні та як побудувати рішення, яке залишатиметься підтримуваним, масштабованим, безпечним і стійким.Архітектура охоплює значно більше, ніж обчислювальні ресурси.

• Ідентичність
• Мережі
• Потоки даних
• Безпека
• Моніторинг
• Інтеграція
• Залежності
• Масштабованість
• Експлуатація
• Відновлення
• Розгортання
• Вартість

Mike також ставить під сумнів ідею, що хмарна нативність автоматично означає 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: скільки втрати даних є прийнятним?

Система, що використовується для некритичного моніторингу, може терпіти кілька годин простою або втрати даних. Система, яка підтримує екстрених працівників, фінансові операції, комерцію чи критичну інфраструктуру, може вимагати відновлення за лічені хвилини.Важливо, що ці цифри не має вигадувати архітектор.Вони мають походити з реального бізнес-впливу відмови.Щойно ці вимоги зрозумілі, їх можна перетворити на технічні рішення дизайну.

СТІЙКІСТЬ НЕ ТЕ Саме, ЩО ВИСОКА ДОСТУПНІСТЬ
Mike використовує просту аналогію, щоб пояснити різницю між доступністю і стійкістю.Висока доступність може означати, що інший компонент готовий перейняти роботу, коли основний відмовляє.Стійка система спроєктована так, щоб поглинати проблеми, продовжувати функціонувати, коректно відновлюватися і повертатися до нормального стану, не руйнуючись повністю.Ця відмінність важлива.Застосунок може технічно бути доступним, але все ще давати погані враження.Він може бути:

• Повільним
• Обмеженим за швидкістю
• Частково недоступним
• Залежним від backend, що відмовляє
• Постраждалим від проблеми інтеграції
• Під тиском регіонального збою

Тож справжня стійкість вимагає більше, ніж аптайм.Вона потребує архітектури, здатної витримувати навантаження, помилки застосунку, часткові збої, регіональні проблеми, зламані залежності, операційні інциденти і відновлення після того, як інцидент минув.

AZURE НЕ РОБИТЬ ВАШ ЗАСТОСУНОК СТІЙКИМ АВТОМАТИЧНО
Одне небезпечне припущення полягає в тому, що оскільки сам Azure високодоступний, будь-який застосунок, що працює на Azure, автоматично успадковує цю стійкість.Це не так.Microsoft надає сервіси й можливості, що роблять стійкі архітектури можливими.Клієнти все ще мають проєктувати стійкість.Тут важливі архітектурні шаблони:

• Circuit breakers
• Слабке зв'язування
• Асинхронна обробка
• Незалежне масштабування
• Кілька зон доступності
• Кілька регіонів
• Механізми відмовостійкого перемикання
• Моніторинг
• Infrastructure as Code
• Перевірені процедури відновлення

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

ЧОМУ ВАЖЛИВИЙ АСИНХРОННИЙ ДИЗАЙН
Один із найсильніших прикладів в епізоді стосується систем, які переживають передбачувані сплески трафіку, наприклад податкових порталів держави.Типова проблема дизайну виникає, коли кожна дія залежить від синхронної операції backend.Користувач натискає кнопку.Frontend чекає на backend.Backend чекає на інший сервіс.Інша залежність сповільнюється. Зрештою на весь користувацький досвід впливає одна ланка.Mike пояснює, чому слабко зв'язані системи часто стійкіші.Замість того, щоб змушувати frontend чекати кожної операції backend, застосунки можуть ставити роботу в черги або в event-driven системи і дозволяти компонентам обробляти завдання незалежно.Це дає кілька переваг:

• Різні компоненти можуть масштабуватися незалежно
• Один сервіс може відмовити, не зруйнувавши всю платформу
• Backend може обробляти роботу асинхронно
• Сплески трафіку легше поглинати
• Компоненти для користувача менше залежать від часу backend
• Збої легше ізолювати

МІФ ПРО 100-ВІДСОТКОВИЙ АПТАЙМ
Ще одна важлива тема в дискусії — одержимість 100-відсотковою доступністю.Mike чітко каже: 100-відсотковий аптайм не є реалістичною ціллю архітектури.Рішення зазвичай складається з кількох сервісів.Кожен сервіс має власний SLA.Щойно поєднуються кілька залежностей, сукупна...