У команды, с которой я работал, была простая конфигурация: небольшой API, база данных Postgres и пара cron-задач. Всё это работало на одной виртуальной машине, которая стоила около 4 000 ₽ в месяц. Затем кто-то прочитал статью о serverless и переписал всё на управляемые функции, управляемую базу данных, очередь сообщений и API-шлюз. Два месяца спустя счёт был уже около 60 000 ₽ — не потому, что serverless дорог, а потому что они перенесли стабильную, предсказуемую нагрузку на модель с оплатой за запрос и за секунду выполнения, и никто не следил за логами. Архитектура стала современнее. Экономика стала хуже.
Эта история — вся причина, по которой облачную архитектуру стоит изучать как следует. Это не список сервисов для запоминания. Это набор компромиссов — между управляемым и самостоятельно развёрнутым, между оплатой за запрос и за час, между удобством и привязкой к поставщику — и тот, кто видит эти компромиссы до написания первой строки инфраструктурного кода, экономит деньги и нервы. Подробнее об этом — в статье DevOps и облачная инфраструктура.
Что на самом деле меняется при переходе в облако
На собственном оборудовании мощность — это покупка. Вы покупаете сервер, он стоит, и его стоимость одинакова, обслуживает ли он один запрос или миллион. В облаке мощность — это тариф. Каждое проектное решение становится решением о том, сколько вы платите за единицу времени или за единицу работы, и это меняет образ мышления.
Из этого следуют три вещи, и они составляют реальное содержание дисциплины:
- Эластичность — это выбор при проектировании, а не значение по умолчанию. Автомасштабирование и управляемые балансировщики нагрузки помогают только в том случае, если ваше приложение может работать в нескольких экземплярах. Монолит, который хранит сессии в локальной памяти и пишет файлы на локальный диск, не может масштабироваться горизонтально, сколько бы экземпляров вы ни добавили.
- Управляемые сервисы смещают поверхность отказов. Управляемая база данных избавляет вас от установки исправлений и настройки резервного копирования, но также лишает возможности настраивать движок на уровне ядра и добавляет почасовую наценку к стоимости сырых вычислений.
- Идентификация — это новый периметр. В центре обработки данных вы защищаете сетевой периметр. В облаке политики IAM — в AWS, Google Cloud и Entra ID в Azure — решают, кто что может делать, и одна слишком широкая роль — больший риск, чем открытый порт.
Один разбор: публичный API, который должен пережить всплеск трафика
Возьмём конкретную задачу: API, который отдаёт данные о товарах, обычно 20 запросов в секунду, а маркетинговая кампания поднимет нагрузку до 400 на несколько часов. Как практик на самом деле принимает решения, по порядку.
Шаг 1 — выберите модель вычислений по форме нагрузки. Для нагрузки, которая большую часть дня простаивает и резко взлетает, привлекательны функции (Lambda, Cloud Functions) или контейнерный сервис, масштабирующийся до нуля: в простое вы почти ничего не платите. Для нагрузки, которая занята круглосуточно, зарезервированные экземпляры или скидки за обязательства на фиксированном парке обходятся дешевле в час. Ошибка — выбирать модель по моде, а не по кривой нагрузки.
Шаг 2 — решите, где хранится состояние. Если приложение хранит сессии в памяти, масштабирование означает, что пользователи будут разлогинены, когда попадут на другой экземпляр. Перенесите сессии в общее хранилище или сделайте API не сохраняющим состояние с помощью токенов. Это одно решение часто определяет, будет ли автомасштабирование работать вообще.
Шаг 3 — поставьте базу данных за бюджет соединений. У управляемой реляционной базы данных есть максимальное количество соединений. Десять экземпляров, каждый из которых открывает 50 соединений, исчерпают его. Решение — пул соединений или уровень базы данных, дружественный к serverless, — и именно здесь проект, который выглядит нормально на ноутбуке, рушится под всплеском.
Шаг 4 — кэшируйте на периферии, а не только в приложении. CDN (CloudFront, Cloud CDN) перед статическими и кэшируемыми ответами резко снижает нагрузку на источник. Если 80% из этих 400 запросов в секунду приходятся на одни и те же страницы товаров, CDN превращает их в погрешность на источнике.
Шаг 5 — задайте политику масштабирования и сигнал тревоги до запуска, а не после. Отслеживание целевых показателей по CPU или количеству запросов плюс сигнал тревоги по бюджету — это минимум. Без сигнала тревоги первым признаком проблемы будет счёт.
Выполните шаги в другом порядке — скажем, сначала автомасштабирование, а о соединениях подумаете позже — и вы получите всплеск, который уронит базу данных, в то время как все экземпляры будут сообщать о здоровье. Проверка работоспособности экземпляра проходит; приложение мертво. Этот разрыв между работоспособностью инфраструктуры и работоспособностью приложения — одно из самых распространённых слепых пятен.
Вопрос о провайдере: AWS vs Google Cloud vs Azure
Люди тратят на это недели, и обычно ответ оказывается менее драматичным, чем они ожидают. Три провайдера пересекаются в основах — виртуальные машины, объектное хранилище, управляемый SQL, функции, Kubernetes, идентификация, CDN — и различаются главным образом акцентами и экосистемой вокруг них.
| Критерий | AWS | Google Cloud | Azure |
|---|---|---|---|
| Широта сервисов | Самая широкая; почти для любого шаблона есть нативное решение | Сильна в данных и аналитике (BigQuery) | Сильнейшая, если вы уже живёте в инструментах Microsoft и Entra ID |
| Управляемый Kubernetes | EKS | GKE, часто считается самым гладким | AKS |
| Модель идентификации | Политики и роли IAM | IAM, иерархия ресурсов по проектам | Entra ID, знаком IT-отделам предприятий |
| Где обычно выигрывает | Универсальность, большие экосистемы, пул специалистов | Нагрузки с интенсивной работой с данными, команды, ориентированные на Kubernetes | Предприятия с существующими соглашениями с Microsoft |
Что на практике решает дело, в примерном порядке весомости:
- За что ваша компания уже платит. Существующее корпоративное соглашение или обязательства по расходам обычно перевешивают предпочтения по функциям.
- Где знания вашей команды. Команда, свободно владеющая одним провайдером, будет работать на нём быстрее, чем на чуть более подходящем, но незнакомом.
- Конкретный управляемый сервис, который вам нужен. Если ваш продукт сильно нагружен аналитикой, BigQuery — реальный аргумент. Если ваша идентификация живёт в Entra ID, Azure снижает трение.
Мультиоблако — это вариант, который люди переоценивают. Запуск одной и той же нагрузки у двух провайдеров удваивает операционную поверхность и требуемые навыки и редко даёт ту отказоустойчивость, которую люди воображают, если нагрузка не была спроектирована для этого с самого начала. Честная версия избегания привязки — не «использовать три облака», а сохранение переносимости архитектуры на стыках: контейнеры вместо проприетарных сред выполнения, стандартный SQL там, где можно, Terraform вместо кликов в консоли и объектное хранилище за собственной абстракцией. Что касается стоимостной стороны этих решений, FinOps — оптимизация облачных затрат — правильное следующее чтение. Подробнее об этом — в статье Terraform и IaC.
Serverless vs контейнеры vs виртуальные машины
Это сравнение сбивает с толку больше всего людей, потому что все три могут запускать один и тот же код, а разница проявляется только в масштабе и в счёте.
Виртуальные машины дают полный контроль и фиксированную почасовую цену. Вы устанавливаете исправления ОС, управляете средой выполнения, владеете режимами отказов. Правильный выбор для устаревшего ПО, для нагрузок с необычными потребностями ядра и для стабильной нагрузки, где зарезервированный экземпляр — самый дешёвый вариант.
Контейнеры с оркестрацией (ECS или EKS в AWS, GKE в Google Cloud, AKS в Azure) находятся посередине: вы упаковываете приложение один раз, масштабируете горизонтально и позволяете платформе заниматься планированием. Цена — операционная сложность: кластер Kubernetes — это система, которую нужно обслуживать, с собственными обновлениями, сетью и service mesh, если вы зайдёте так далеко.
Serverless-функции — самый дешёвый вариант при низком и пиковом объёме и самый ограниченный: лимиты времени выполнения, холодные старты, отсутствие постоянного локального состояния и модель ценообразования, которая наказывает за длительную работу. Режимы отказов здесь достаточно специфичны, чтобы заслуживать отдельного рассмотрения — Серверлесс-архитектура подробно разбирает их.
Где люди на самом деле ошибаются
Слишком широкий IAM с первого дня. Кто-то выдаёт сервисной учётной записи роль администратора, «чтобы разблокировать развёртывание», и она остаётся. Шесть месяцев спустя никто не знает, какая роль на самом деле нужна. Исправление скучное и эффективное: начните с минимальной политики, добавляйте разрешения по мере появления ошибок и пересматривайте роли по расписанию.
Игнорирование уровня данных, пока не станет больно. Приложение масштабируется прекрасно; база данных — единственный экземпляр без реплик для чтения и без пула соединений. Это самый частый производственный инцидент в облачных системах, и он полностью предсказуем. Если вы проектируете вокруг реляционных данных, SQL и базы данных: как научиться работать с базами данных охватывает индексы и проектные решения, которые определяют, выживет ли база данных под нагрузкой.
Сеть по настройкам по умолчанию. VPC, где всё в публичных подсетях, или группы безопасности, разрешающие 0.0.0.0/0 на порт управления, — это уязвимость, ждущая, когда её найдёт сканер. Частные подсети для всего, что не должно быть доступно из интернета, и бастион или менеджер сессий для доступа — это базовая линия.
Отсутствие дисциплины тегирования. Без согласованных тегов вы не можете ответить на вопрос «сколько стоит окружение этой команды?» — и оптимизация затрат превращается в догадки. Теги дешево добавлять при создании и больно восстанавливать позже.
Отношение к инфраструктуре как к кликам. Всё, что построено вручную в консоли, дрейфует и не может быть воспроизведено. Terraform (или эквивалент) превращает инфраструктуру в код, подлежащий проверке, — единственный надёжный способ запускать более одного окружения.
Кому подходит эта область, а кому нет
Облачная архитектура вознаграждает людей, которым нравятся системы и последствия. Если вам нравится выяснять, почему запрос медленный, почему счёт подскочил или почему развёртывание сломало одно окружение, а не другое, вам будет интересно. Она также подходит разработчикам, которые устали передавать инфраструктуру кому-то другому и хотят владеть всем путём от кода до работающего сервиса.
Она меньше подходит вам, если вы хотите чисто визуальную, немедленную работу без неоднозначности. Большая часть работы — это чтение документации, которая иногда ошибается, сравнение двух вариантов, каждый из которых имеет право на существование, и принятие решения, которое вам придётся обосновывать позже. На вопрос «должно ли это быть контейнером или функцией» нет единственно правильного ответа — только лучшее или худшее соответствие для этой нагрузки, этой команды и этого бюджета.
Полезная самопроверка перед тем, как посвятить этому месяцы:
- Можете ли вы прочитать панель выставления счетов и объяснить, куда ушли деньги?
- Можете ли вы описать, что происходит с запросом от DNS-запроса до записи в базу данных?
- Комфортно ли вам быть человеком, который решает, а не только реализует?
Если два из трёх вызывают сомнения, это именно тот пробел, который закрывает структурированный путь.
Учебные пути и чего они на самом деле вам стоят
Самостоятельное обучение бесплатно в деньгах и дорого во времени и ошибках. Документация хорошая и бесплатная, но она не говорит, какой из пяти сервисов подходит вашему случаю, и никто не проверяет ваш проект. Дорогие уроки — переизбыточный кластер, оставленная открытой группа безопасности, счёт за передачу данных между регионами — оплачиваются в производстве.
Практика в личном аккаунте даёт наибольшую отдачу на час: постройте небольшую систему от начала до конца, сломайте её, наблюдайте за метриками, читайте счёт. Риск в том, что без цели вы будете повторно строить одну и ту же комфортную вещь и никогда не коснётесь того, чего избегаете.
Структурированные курсы сжимают принятие решений. Ценность не в программе — а в том, что кто-то проходит через компромиссы с примерами и даёт обратную связь по вашим выборам, что самообучение дать не может. Именно здесь вписывается Облачная архитектура (AWS/GCP/Azure): курс прорабатывает проектирование, serverless и событийно-ориентированные шаблоны, базы данных, сети, безопасность и оптимизацию затрат у всех трёх провайдеров, с уроками, адаптированными к вашему текущему уровню, так что вышеописанные компромиссы прорабатываются, а не просто читаются.
Если вы уже глубоко в одном провайдере и стремитесь к старшей роли, путь, ориентированный на сертификацию, — разумная параллельная траектория, и угол FinOps стоит изучить глубже — разборы AWS Solutions Architect Professional (SAP-C02): FinOps на практике и Архитектор Google Cloud показывают, как одна и та же логика затрат работает на каждой платформе.
Одно предупреждение о сертификационном пути: сдача экзамена доказывает, что вы можете отвечать на вопросы о сервисах. Это не доказывает, что вы можете спроектировать систему, которая переживёт всплеск и останется в рамках бюджета. Относитесь к экзамену как к принудительной мере для широты, а к проектной работе — как к настоящему навыку.
Короткое замечание о том, что строить в первую очередь
Если вы начинаете, постройте одну небольшую систему, которая затрагивает весь путь: публичная конечная точка за балансировщиком нагрузки, управляемая база данных в частной подсети, объектное хранилище для статических ресурсов за CDN, идентификация с наименьшими привилегиями и сигнал тревоги по бюджету. Затем сломайте её намеренно — убейте экземпляр во время нагрузочного теста, отзовите разрешение, превысьте бесплатный уровень. Отказы учат большему, чем любая диаграмма, и при небольшом масштабе почти ничего не стоят.
Это одно упражнение охватывает то, вокруг чего большинство людей кружат месяцами: выбор вычислений, состояние, сеть, идентификация и стоимость. Всё остальное — вариации на эту тему.
Облако вознаграждает не знание наибольшего числа сервисов. Оно вознаграждает умение видеть компромисс до того, как он станет счётом или инцидентом. Курс проходит через эти компромиссы с проработанными примерами в AWS, Google Cloud и Azure и даёт обратную связь по принимаемым вами решениям — подробности и запись на странице курса.