3.11 Облачная архитектура

Обзор и мотивация

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

Для больших команд ставки выше, потому что облако перераспределяет, кто что делает. Когда команда может развернуть базу данных, очередь и глобальный балансировщик нагрузки за минуты, узким местом становятся не закупки, а управление: стоимость, безопасность и согласованность между десятками команд, делающих это одновременно. Облако даёт каждому инженеру корпоративную кредитную карту и склад электроинструментов, что одинаково чудесно и опасно. Правильная архитектура означает использование выгод (скорость, эластичность, устойчивость) при установке ограждений, держащих под контролем расходы, положение защищённости и местонахождение данных.

Корпорации и государства ощущают оба края остро. Корпорации приходят с десятилетиями существующих систем, поэтому их облачная история обычно история миграции, полная гибридной связности и трудных решений «купить или построить». Государства несут дополнительный вес суверенитета, режимов авторизации и данных граждан, которые юридически не могут покидать определённые границы. Решения здесь (какая модель сервиса, сколько провайдеров, где лежат домены отказа, что работает как управляемый сервис, а что как ваш собственный код) определяют стоимость и риск на десятилетие.

Ключевые принципы

Проектируйте для облака, не фотографируйте свой центр обработки данных. Эластичность, управляемые сервисы и осведомлённость о доменах отказа причины быть здесь; перенос «как есть» их выбрасывает.
Всё разворачивается как код. Если человек щёлкнул это в существование, оно недокументировано, невоспроизводимо и непроверяемо.
Проектируйте по доменам отказа намеренно. Регионы, зоны доступности и сервисы отказывают; ваша архитектура решает, пожмёте ли вы плечами или получите сбой.
Модель совместной ответственности это контракт, а не лозунг. Знайте точно, какую линию обеспечивает провайдер, а какую вы.
Покупайте недифференцирующее, стройте дифференцирующее. Управляемые сервисы стоят реальных денег для сантехники; конкурентное преимущество держите в своих руках.
Привязка это цена, которую нужно оценить, а не грех, которого нужно избегать. У переносимости есть цена, а у рычага есть ценность; решайте намеренно, а не рефлекторно.
Стоимость это первоклассный атрибут качества. В облаке архитектура и счёт одно и то же решение.

Рекомендации

Выбирайте модель сервиса намеренно и по умолчанию берите управляемое

Облачные провайдеры продают вдоль спектра, охваченного моделями «как услуга»: инфраструктура как услуга (IaaS) арендует сырые вычисления, хранение и сети; платформа как услуга (PaaS) арендует управляемую среду выполнения, так что вы разворачиваете код, не ухаживая за серверами; программное обеспечение как услуга (SaaS) арендует готовые приложения. Бессерверные вычисления, включая функции и управляемые событийно-ориентированные сервисы, продвигают это дальше: вы поставляете код или конфигурацию, а провайдер выполняет всё развёртывание, масштабируясь до нуля в простое. Каждый шаг вверх по спектру меняет контроль на рычаг: от IaaS с наибольшим контролем и наибольшим эксплуатационным бременем до бессерверных вычислений с наименьшими обоими.

По умолчанию следует подниматься по этому спектру настолько высоко, насколько позволяют ваши требования. Управляемая база данных, берущая на себя патчи, резервные копии, переключение при отказе и масштабирование, почти всегда лучшее применение ваших инженеров, чем самостоятельно запускаемая. Оставляйте IaaS более низкого уровня для случаев, которым это действительно нужно: специализированное оборудование, необычные границы соответствия, ограничения лицензирования или производительность, которой управляемое предложение не может достичь. Записывайте причину как запись об архитектурном решении (глава 3.1), потому что «мы запускаем собственный брокер сообщений» это утверждение, которое следует переобосновывать каждый год.

Проектируйте по регионам и зонам доступности как явным доменам отказа

Облачный регион это географическая область; внутри него зоны доступности физически раздельные центры обработки данных с независимыми питанием, охлаждением и сетью, достаточно близкие для репликации с малой задержкой, но достаточно далёкие, чтобы отказ одного не утягивал другие. Это швы, по которым облако ломается, поэтому ваша архитектура должна воспринимать их как первоклассные. Базовый уровень для любой серьёзной нагрузки многозонность: распределяйте вычисления и данные минимум по двум, а лучше трём зонам, чтобы потеря одной снижала мощность, а не вызывала сбой. Это дешёвая страховка, редко имеющая хорошее оправдание для пропуска.

Многорегиональность более тяжёлое решение, связанное с вашими целями устойчивости и восстановления (глава 3.5) и планом аварийного восстановления (глава 9.5). Распределение по регионам покупает выживание при отказе целого региона и может приблизить данные к пользователям, но вносит реальные проблемы стоимости, задержки и согласованности, потому что межрегиональная синхронная репликация медленна, а асинхронная репликация означает принятие потери данных при переключении. Решайте на основе явных целевых времени и точки восстановления, а не смутного желания быть «высокодоступными». Большинству систем нужна надёжная многозонность и протестированный путь многорегионального восстановления; немногим действительно нужно «активное-активное» между регионами, а те, кто строит его без нужды, платят за сложность каждый день.

Воспринимайте модель совместной ответственности как архитектурную границу

Облачная безопасность работает на модели совместной ответственности: провайдер обеспечивает облако (физические помещения, гипервизор, внутренности управляемых сервисов), а вы обеспечиваете то, что кладёте в облако (ваши данные, контроль доступа, конфигурацию сети и код). Точная линия движется по мере вашего подъёма по спектру сервисов. С IaaS вы патчите операционную систему; с управляемой базой данных нет, но вы всё равно владеете тем, кто может подключаться и зашифрованы ли данные. Самые дорогие инциденты происходят от неверного прочтения этой линии, самый известный случай открытое хранилище, из которого утекают миллионы записей, потому что кто-то решил, что провайдер сделал его закрытым по умолчанию.

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

Разворачивайте всё как код внутри управляемой посадочной зоны

В зрелой облачной практике ни один производственный ресурс не существует потому, что человек щёлкнул консоль. Всё объявлено в инфраструктуре как коде (глава 8.2), хранится под контролем версий, рецензируется и применяется через конвейер, так что ваша инфраструктура воспроизводима, проверяема и сравнима. Именно это делает многозонность, многорегиональность и аварийное восстановление реальными, а не желаемыми: вы можете поднять идентичную среду в новом регионе, потому что среда это программа, а не воспоминание.

Оберните этот код в посадочную зону: готовый управляемый фундамент из учётных записей (или подписок или проектов), сети, идентичности, журналирования и ограждений, на котором строит каждая команда. Используйте раздельные учётные записи как границы радиуса поражения и биллинга, чтобы ошибка одной команды не достала данные другой, а каждый доллар прослеживался до владельца. Принудительно применяйте ограждения как политику-как-код, предотвращающую запрещённые конфигурации (публичная база данных, незашифрованный том, ресурс в запрещённом регионе), а не полагайтесь на рецензию постфактум. Центральная платформенная команда обычно владеет посадочной зоной, что связывает эту главу с платформенной инженерией (глава 8.4) и контейнерами и облачно-нативными средами выполнения (глава 8.3).

Оценивайте привязку честно и относитесь скептически к мультиоблаку

Привязка к поставщику это стоимость смены провайдера, и это спектр, а не бинарность. Использование управляемой очереди провайдера создаёт некоторую привязку; использование его проприетарной платформы машинного обучения создаёт много. Рефлекторный страх перед ней заставляет команды жертвовать реальным рычагом (управляемыми сервисами, делающими облако стоящим использования) ради сохранения переносимости, которой они никогда не воспользуются. Честный ход оценить её: для каждой значимой зависимости оценить, чего на самом деле стоил бы уход, и сопоставить с тем, что сервис экономит вам сейчас. Абстрагирование управляемого сервиса ради переносимости нередко обходится постоянно дороже, чем миграция, от которой вы страхуетесь, когда-либо обошлась бы.

Поэтому подлинное мультиоблако (запуск одной и той же нагрузки у двух провайдеров) обычно карго-культ, а не стратегия. Оно загоняет вас к наименьшему общему знаменателю, удваивает вашу эксплуатационную поверхность и умножает экспертизу, которую должны держать ваши команды, и всё ради хеджирования риска, который редко материализуется. Есть законные причины касаться более одного провайдера: лучший в классе SaaS от второго поставщика, мандат регулятора на устойчивость или намеренное требование суверенитета (глава 10.11). Гибридное облако, когда часть систем остаётся локально и подключена к облаку, часто неизбежно при корпоративной миграции и для данных, которые юридически нельзя переносить. Выбирайте это с ясными глазами и письменным обоснованием, а не потому, что слайд сказал «мультиоблако».

Проектируйте с учётом стоимости и принимайте мышление хорошо спроектированной архитектуры

В облаке архитектурное решение это решение о расходах: избыточное выделение «на всякий случай» проявится в счёте следующего месяца. Воспринимайте стоимость как атрибут качества, под который вы проектируете, и принимайте практики FinOps, дисциплину общей финансовой ответственности за облачные расходы (глава 9.4), чтобы инженерия, финансы и продукт владели счётом вместе. Помечайте каждый ресурс владельцем, делайте стоимость видимой по командам и сервисам, непрерывно подбирайте размеры, используйте автомасштабирование, чтобы платить за нагрузку, а не за пик, и пользуйтесь ценовыми рычагами (скидки за обязательство использования, спотовая мощность для прерываемой работы), которые предлагает облако.

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

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Перенос «как есть» (rehost)	Быстро, малые начальные усилия, быстрый выход из центра обработки данных	Сохраняет старую хрупкость, упускает эластичность и управляемые сервисы, часто стоит дороже
Облачно-нативная переделка	Полная эластичность, устойчивость, рычаг управляемых сервисов	Больше начальных усилий и навыков; крупнее изменение для усвоения
Одно облако, глубокая интеграция	Простота, максимальный рычаг, меньшая эксплуатационная поверхность	Сосредоточенная привязка и риск провайдера
Мультиоблако (одна нагрузка, два провайдера)	Хедж отказа провайдера, переговорный рычаг	Проект по наименьшему общему знаменателю, удвоенные эксплуатация и экспертиза
Гибрид (облако плюс локально)	Удовлетворяет ограничениям местонахождения данных и наследия, поэтапная миграция	Сложность сети, две модели эксплуатации одновременно
Бессерверное / высоко управляемое	Минимум рутины, масштабирование до нуля, быстрая поставка	Меньше контроля, специфично для провайдера, холодный старт и лимиты квот

Центральное напряжение это контроль против рычага, и оно проходит через каждую строку. Чем больше вы передаёте провайдеру, тем быстрее двигаетесь и тем меньше эксплуатируете, ценой более глубокого сцепления. Решение не в выборе одного полюса, а в намеренном размещении каждой нагрузки: поднимайтесь высоко по управляемому спектру для рядовой сантехники, оставайтесь ниже там, где контроль действительно оправдывает себя, и оценивайте привязку в обе стороны, а не воспринимайте переносимость как бесплатную, а зависимость как грех. Большие организации попадают в беду, когда позволяют страху (перед привязкой, перед облаком, перед стоимостью) делать этот выбор рефлекторно, а не по анализу.

Вопросы для обсуждения с командой

Какие из наших нагрузок перенесены «как есть» и не платим ли мы облачные цены за архитектуру центра обработки данных? Обычное дело мигрировать под сроком, перенести всё как есть и объявить победу, а затем обнаружить, что счёт выше, чем в центре обработки данных, и ни одной выгоды устойчивости или эластичности не материализовалось. Честный аудит перечислить основные нагрузки и отметить каждую как перенесённую, перенесённую на другую платформу или действительно переделанную, затем посмотреть, какие ещё работают на фиксированных, всегда включённых, однозонных мощностях. Некоторый перенос «как есть» законный первый шаг, поэтому вопрос не в том, делали ли вы это, а в том, есть ли у вас план и сроки для продолжения. Принесите стоимость по нагрузкам и историю инцидентов, потому что нагрузки одновременно дорогие и хрупкие это то, где переделка окупается быстрее всего. Если через год после миграции всё ещё имеет форму старого центра обработки данных, вы купили более дорогой центр обработки данных.
Что на самом деле происходит, когда отказывает зона доступности или целый регион и тестировали ли мы это? Многие команды считают себя устойчивыми потому, что развернулись в облаке, не проектируя свои домены отказа и ни разу не выдернув вилку, чтобы проверить. Конкретная версия: для каждой критичной системы сколько зон она охватывает, каковы документированные целевые время и точка восстановления и когда мы в последний раз проводили учения, отключая зону или репетируя региональное восстановление? Многозонность должна быть непримечательной базой, поэтому любая критичная однозонная нагрузка это находка; многорегиональность более тяжёлое, дорогое решение, связанное с явными целями восстановления, а не принимаемое по умолчанию. Принесите карту зависимостей, потому что сбой, который больно бьёт, обычно общий сервис (база данных, провайдер идентичности), чей домен отказа никто не нарисовал. Устойчивость, которую вы никогда не тестировали, гипотеза, а не свойство.
Чего на самом деле стоил бы уход от наших крупнейших зависимостей от провайдера и стоит ли эта цена того, чтобы её избегать? Споры о привязке склонны идти на идеологии, а не числах: один лагерь абстрагирует каждый управляемый сервис ради переносимости, другой вовсе игнорирует риск концентрации. Приземлите это: выберите три самые глубокие зависимости, оцените реальную инженерную стоимость и прошедшее время замены каждой и сопоставьте с тем, что сервис экономит вам сегодня и насколько вероятно, что вы когда-нибудь переключитесь. Добавьте риски, которых переносимость не исправляет, такие как требование регулятора о втором источнике или правило суверенитета о том, где могут жить данные, поскольку они могут оправдать мультиоблако или гибрид, даже когда чистая экономика не оправдала бы. Цель намеренная письменная позиция по каждой зависимости, а не общая политика. Оценив, вы обнаружите, что большую часть опасаемой привязки дешевле принять, чем уровень абстракции, построенный, чтобы её избежать.
Какие сервисы мы запускаем сами, хотя провайдер охотно эксплуатировал бы их для нас, и сколько инженерных часов стоит этот выбор? Весь рычаг облака в передаче патчей, резервных копий, переключения при отказе и масштабирования тому, чья постоянная работа именно это, однако команды регулярно держат самостоятельно запускаемую базу данных, брокер сообщений или кластер поиска по привычке или неуместной гордости. Для большой организации цена не рутина одной команды, а те же недифференцирующие операции, изобретённые заново в дюжине углов, каждая с дежурной ротацией и источником дрейфа. Противоположное соображение подлинно: специализированное оборудование, условия лицензирования, необычная граница соответствия или производительность, которой не достичь управляемому предложению, могут оправдать пребывание ниже по спектру, поэтому ответ по сервисам, а не общий. Принесите опись самостоятельно эксплуатируемых сервисов, инженерные часы, потребляемые каждым на сопровождение и инциденты, и цену управляемой альтернативы и требуйте запись об архитектурном решении для каждого «мы запускаем своё», пересматриваемую ежегодно. В корпоративной и государственной среде добавьте, действительно ли выбор самостоятельного запуска ограничение соответствия или лицензирования или просто инерция, наряженная в него, потому что аудиторы и владельцы бюджета зададут тот же вопрос.
Видим ли мы, что стоит нам каждая команда и сервис в этом месяце, и чувствует ли названный человек ответственность за это число? Облачные расходы тихо раздуваются, потому что тот же режим самообслуживания, позволяющий инженеру развернуть глобальную базу данных за минуты, позволяет ему оставить её навсегда работать в пиковом размере, и ни одна строка счёта не выглядит тревожной. В большой организации без видимости стоимости по командам и сервисам финансы обнаруживают проблему на месяцы позже, а реакция грубая заморозка, наказывающая дисциплинированных наряду с расточительными. Напряжение реально: погоня за каждым долларом замедляет поставку, поэтому цель ответственность и подбор размеров, а не жёсткая экономия, а стоимость воспринимается как атрибут качества, под который вы проектируете, а не отчёт, читаемый постфактум. Принесите разбивку стоимости по командам, долю расходов без меток или неотносимую, текущее использование относительно выделенной мощности и где скидки за обязательство или спотовая мощность остаются на столе. Для корпораций и государственных органов свяжите это с практикой FinOps и общественным контролем расходов, поскольку ресурс без метки не просто расточительство, а находка аудита, ждущая своего часа.
Может ли команда прямо сейчас поднять публичное хранилище данных, незашифрованный том или ресурс в запрещённом регионе и узнали бы мы об этом вообще? Большинство дорогих облачных инцидентов это неверные конфигурации, а не взломы провайдера, а модель совместной ответственности означает, что текущее хранилище или база данных, открытая в интернет, находятся строго на вашей стороне линии. Предотвращение этого в масштабе многих команд вопрос посадочной зоны: ограждения, применяемые как политика-как-код, блокирующие запрещённые конфигурации до их появления, а не рецензия постфактум, находящая их, когда записи уже утекли. Противоположное давление автономия разработчиков, потому что слишком жёсткие ограждения загоняют команды в теневые учётные записи, поэтому проект должен предотвращать действительно опасное, оставляя пространство для движения. Принесите опись реально применяемых ограждений, честную попытку развернуть несоответствующий ресурс в реальной учётной записи и задержку обнаружения, когда предотвращение отказывает. В регулируемой и государственной среде свяжите это с местонахождением данных и режимами авторизации, потому что ресурс в запрещённом регионе не нарушение стиля, а юридическое нарушение, которое аудитор воспримет как подлежащее отчёту событие.

Взгляд по секторам

Стартап. С первого дня идите облачно-нативно на одном провайдере и примите привязку намеренно. Работайте на бессерверных и управляемых сервисах, масштабирующихся до нуля, и позвольте двум инженерам владеть всей платформой, потому что ваш самый дефицитный ресурс внимание, а не переносимость. Жёстко ограничьте расходы, держите всё в инфраструктуре-как-коде, чтобы вирусный момент не стал сбоем, и запишите намеренное решение о привязке, чтобы пересмотреть в масштабе, а не притворяйтесь, что оно временное.

Малый бизнес. Без платформенного инженера и при ограниченном бюджете воспринимайте облако как то, что вы потребляете, а не эксплуатируете. Предпочитайте SaaS и полностью управляемые сервисы всему, что запускаете сами, опирайтесь на безопасные настройки провайдера по умолчанию и позвольте управляемой базе данных заниматься резервными копиями и переключением, чтобы этим не занимался никто. Формулируйте выбор как «купить или построить» с сильным нажимом на покупку, настройте оповещение о биллинге, чтобы забытый ресурс не мог истощить месяц, и тянитесь к low-code или управляемому варианту, прежде чем поднимать серверы, которыми вы не можете укомплектовать.

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

Государственный сектор. Правила закупок, прозрачность и суверенитет определяют каждое решение. Разворачивайтесь в авторизованном или государственном облачном регионе, документируйте линию совместной ответственности построчно для аудиторов и привязывайте хранение и обработку к зонам внутри страны политикой-как-кодом, блокирующей любой ресурс в запрещённом регионе. Добивайтесь требуемого режима авторизации, храните свидетельства аудита как историю git, а не суматоху, и отдавайте предпочтение управляемым сервисам, чью позицию соответствия провайдер подтвердит, самодельной инфраструктуре, которую вы должны сертифицировать сами.

Примеры

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

Крупная организация. Международная страховая компания с тремястами унаследованными приложениями ведёт многолетнюю миграцию, управляемую «6 R» (rehost, re-platform, repurchase, refactor, retire, retain). Малоценные рядовые приложения быстро переносятся «как есть», чтобы выйти из двух центров обработки данных к сроку; основная платформа полисов рефакторится под облачно-нативную; самодельные инструменты заменяются покупкой как SaaS; а устаревшие системы выводятся. Центральная платформенная команда владеет посадочной зоной с учётными записями по бизнес-подразделениям, ограждениями шифрования по умолчанию и политикой-как-кодом, блокирующей публичные хранилища данных, тогда как гибридная связность соединяет облако с мейнфреймовыми системами учёта, которые не переедут годами. Стоимость управляется практикой FinOps с показом расходов по подразделениям, а рецензия хорошо спроектированной архитектуры управляет запуском в эксплуатацию каждого приложения.

Государственный сектор. Национальное ведомство, оказывающее услугу пособий гражданам, по закону обязано держать данные резидентов в национальных границах и работать на авторизованной инфраструктуре. Оно разворачивается в государственном облачном регионе провайдера и добивается авторизации по режиму вроде FedRAMP в Соединённых Штатах (работа по соответствию в главе 4.6), документируя границу совместной ответственности построчно для аудиторов. Местонахождение данных и более широкие вопросы суверенитета (глава 10.11) определяют архитектуру, привязывающую хранение и обработку к зонам внутри страны и блокирующую политикой-как-кодом любой ресурс в запрещённом регионе. Система охватывает три зоны доступности с протестированным планом восстановления между зонами и разворачивает всё как код, так что свидетельство аудита это история git, а не суматоха.

Бизнес-обоснование: мотивы, ROI и TCO

Главное обещание облака превращение капитальных затрат в операционные: вместо покупки серверов за годы до спроса и работы на низкой загрузке вы платите за использованное и масштабируетесь вместе с бизнесом. Это реально, но более глубокая отдача скорость и фокус. Управляемый сервис, стирающий патчи, резервные копии и переключение при отказе, возвращает эти инженерные часы продуктовой работе, а развёртывание за минуты вместо месяцев сжимает время от идеи до эксплуатации. Эластичность означает, что вы перестаёте платить за пиковую мощность, используемую дважды в год. Когда архитектура верна, это складывается в совокупную стоимость владения, превосходящую центр обработки данных и по стоимости, и по возможностям.

Цена ошибки столь же реальна, поэтому бизнес-обоснование должно быть честным. Перенос «как есть» без переделки нередко повышает затраты, не давая ни одной выгоды, а неуправляемые расходы могут тихо раздуться по десяткам команд, пока финансы не забьют тревогу. Формулируйте обоснование для руководства вокруг трёх рычагов: скорость (быстрая поставка и более короткое развёртывание), устойчивость (меньше и короче крупных инцидентов) и вариативность (выход на новый рынок или регион без проекта центра обработки данных). Выразите числами избегнутое обновление центра обработки данных, сокращённую численность для рядовой инфраструктуры и предотвращённые минуты простоя и сопоставьте со стоимостью миграции и постоянными вложениями в FinOps и платформу. Сильнейший аргумент редко сырая экономия; это ценность опциона двигаться быстрее конкурентов, всё ещё ждущих оборудование.

Антипаттерны и ловушки

Перенос «как есть» под названием «облако». Перенос проекта центра обработки данных на арендованную инфраструктуру перенимает затраты и ни одной выгоды.
Инфраструктура, созданная щелчками по консоли. Ресурсы, созданные вручную, невоспроизводимы, недокументированы и невозможны для восстановления или аудита; воспринимайте любое ручное изменение производства как дефект.
Карго-культ мультиоблака. Запуск одной нагрузки у двух провайдеров для хеджирования редкого риска с ежедневной платой сложностью и проектом по наименьшему общему знаменателю.
Однозонная «высокая доступность». Вера, что облако устойчиво по умолчанию, при работе критичных нагрузок в одной зоне без протестированного переключения.
Неверное прочтение совместной ответственности. Допущение, что провайдер обеспечивает то, чем на самом деле владеете вы, классический путь к публичному хранилищу, из которого утекают миллионы записей.
Стоимость как запоздалая мысль. Проектирование без оглядки на расходы с последующим обнаружением, что счёт принял ваши архитектурные решения за вас.

Модель зрелости

Уровень 1, Начальный: Использование облака стихийно и реактивно. Команды щёлкают ресурсы в существование в общих учётных записях, нагрузки переносятся «как есть», нет ни посадочной зоны, ни видимости стоимости, а устойчивость предполагается, а не проектируется. Первый серьёзный сбой или шок от счёта становится сюрпризом.
Уровень 2, Развитие: Появляются базовые практики, различающиеся по командам. Часть основной инфраструктуры разворачивается как код, а часть нагрузок многозонна, несколько учётных записей разделены, но покрытие неравномерно: выбор модели сервиса и привязки делается по привычке, стоимость отслеживается постфактум, ограждения непоследовательны, а многорегиональное восстановление не тестировано.
Уровень 3, Стандартизация: Управляемая посадочная зона с ограждениями политики-как-кода документирована и соблюдается по организации. Платформенная команда владеет фундаментом, всё производство разворачивается как код, рецензии хорошо спроектированной архитектуры управляют значимыми проектами, а решения «купить или построить» и по доменам отказа намеренны и последовательно фиксируются каждой командой.
Уровень 4, Управление: Хозяйство измеряется и контролируется относительно базовых значений. Стоимость по командам и сервисам отслеживается через FinOps относительно целей, целевые время и точка восстановления проверяются, а не заявляются, нарушения ограждений и дрейф конфигурации выводятся как метрики, подбор размеров управляется данными об использовании, а каждое решение «пускать или нет» подкреплено свидетельствами панелей стоимости, надёжности и безопасности.
Уровень 5, Оркестрация: Облачная архитектура непрерывно улучшается и интегрирована с бизнес- и рисковым планированием. Домены отказа упражняются регулярными учениями, подбор размеров и ценообразование автоматизированы, суверенитет и местонахождение данных принуждаются политикой, позиции по модели сервиса и привязке переоцениваются регулярно, а портфель нагрузок адаптивно перебалансируется по мере сдвигов рынка, цен и картины рисков.

Идеи для обсуждения

Где на спектре от IaaS до бессерверных вычислений находится каждая из ваших основных нагрузок и могла ли какая-то подняться выше, сбросив эксплуатационную рутину без потери контроля, который вам действительно нужен?
Если бы ваш основной провайдер резко поднял цены или пережил многодневный региональный сбой, каков ваш реальный план и оправдывает ли он любую сложность мультиоблака или гибрида, которую вы несёте?
Кто владеет вашей посадочной зоной и её ограждениями и может ли команда сегодня выпустить несоответствующий ресурс (публичное хранилище данных, незашифрованный том, запрещённый регион)?
Для регулируемой или суверенной нагрузки можете ли вы предъявить границу совместной ответственности и авторизованную конфигурацию как свидетельство без аврала?

Главные выводы

Проектируйте для облака, а не фотографируйте свой центр обработки данных; эластичность, управляемые сервисы и осведомлённость о доменах отказа причины быть здесь.
Поднимайтесь по спектру моделей сервиса к управляемому и бессерверному для рядовой работы и держите контроль ниже только там, где он действительно оправдывает свою цену.
Делайте регионы и зоны доступности явными доменами отказа: многозонность как база, многорегиональность в связке с протестированными целями восстановления.
Разворачивайте всё как код внутри управляемой посадочной зоны с ограждениями политики-как-кода, раздельными учётными записями и платформенной командой, владеющей фундаментом.
Оценивайте привязку к поставщику честно в обе стороны и относитесь скептически к мультиоблаку, если только конкретная регуляторная причина, причина суверенитета или лучшего в классе этого не требует.
Воспринимайте стоимость как первоклассный атрибут качества через FinOps и проводите рецензии хорошо спроектированной архитектуры, чтобы ловить компромиссы, которые вы упустили.

Источники и дополнительное чтение

Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing (NIST Special Publication 800-145)
Amazon Web Services, AWS Well-Architected Framework
Microsoft, Azure Well-Architected Framework and Cloud Adoption Framework
Google Cloud, Google Cloud Architecture Framework
Stephen Orban, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT (and the “6 Rs” migration strategies)
J.R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
Gregor Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration
U.S. General Services Administration, FedRAMP programme documentation and security baselines
Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing