# Облако — это чужой компьютер Экспресс-курс об облаке и serverless. 19 понятий — Cloud computing, CapEx → OpEx, On-demand, IaaS, PaaS, SaaS, Elasticity, Pay-as-you-go, Region, Availability zone, Managed service, Vendor lock-in, Serverless, Cold start и другие — у каждого английское название, схема и карточка «что это → пример → подвох → связи». В конце — шпаргалка на одной странице. Только суть: облако — не модное слово, а аренда вычислений по требованию и набор ясных разменов между удобством, контролем и стоимостью. - **Author:** Фёдор Чищин - **Level:** intro - **Reading time:** ~30 минут чтения - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/ru/learn/cloud-express --- ## 1. Арендованные компьютеры Сними мистику — и облако окажется простой бизнес-идеей: пользоваться компьютерами, которыми ты не владеешь. Всё остальное — детали о том, сколько работы владелец делает за тебя. ### Карта: 19 понятий в шести группах > Карта метро: сначала видишь линии целиком, потом едешь по станциям. Все понятия курса делятся на шесть групп. Каждая отвечает на свой вопрос: что такое облако вообще, сколько провайдер делает за тебя, как растёт ёмкость и счёт, где физически работает твой код, какие куски можно отдать провайдеру целиком и как запускать код совсем без серверов. _Diagram: Шесть групп понятий — по ним идут главы 1–6. Глава 7 — как применять всё вместе._ ### Как читать курс > Паспорт: одинаковые поля у всех, поэтому их легко сравнивать. У каждого понятия дальше одно и то же: **английское название** (запомни его — это термин из документации AWS, Google Cloud и Azure), образ из жизни, **схема** и **карточка** с полями: _что это_, _пример_, _подвох_ и _связи_ с другими понятиями. Главная мысль курса: каждое облачное модное слово — это точка на шкале «сколько за тебя делает кто-то другой» и цена, которую ты за это платишь. ### Cloud Computing — облако как чужие компьютеры > Такси вместо покупки машины: автомобиль реален и поездка реальна, но ты не владеешь им, не паркуешь, не страхуешь и не чинишь — просто едешь, когда нужно. **Облако (cloud computing)** — это компьютеры в чужом дата-центре, которые ты арендуешь через интернет вместо того, чтобы покупать и обслуживать свои. Когда приложение работает «в облаке», оно работает на настоящих, физических машинах — просто они принадлежат провайдеру вроде Amazon, Google или Microsoft, а тот отвечает за здание, питание и железо. Ты получаешь вычислительную мощь как услугу — как электричество, не владея электростанцией. _Diagram: Твоё приложение работает на машинах провайдера: серверы, диски, сеть и здание — его забота._ #### Cloud Computing (облачные вычисления) - **Что это:** Аренда чужих компьютеров через интернет вместо покупки своих. - **Пример:** Сайт работает на серверах AWS: Amazon следит за зданием, питанием и железом, ты — за своим кодом. - **Подвох:** Серверы никуда не делись — они просто чужие. Ты меняешь владение на зависимость от провайдера. - **Связи:** Основа всего курса; насколько много делает провайдер — решают **IaaS / PaaS / SaaS**. ### CapEx → OpEx — аренда вместо покупки > Ты не строишь электростанцию, чтобы запитать дом, — ты подключаешься к сети и платишь за то, что используешь. Владеть всей станцией имеет смысл только в огромном масштабе. Владеть серверами — значит покупать дорогое железо заранее, гадать, сколько его понадобится, и держать комнату машин, даже когда они не нужны. Это **капитальные затраты (CapEx)**. Аренда всё переворачивает: нет большой предоплаты, нет простаивающего железа, физикой занимается кто-то другой — это **операционные затраты (OpEx)**. Почти для всех этот размен — превратить огромную покупку в счёт по факту использования — и есть причина, почему облако победило. Ты тратишь деньги, когда пользуешься ресурсом, а не за годы до этого. _Diagram: Слева — купить железо заранее и гадать с ёмкостью. Справа — арендовать и платить по мере использования._ #### CapEx → OpEx (аренда вместо покупки) - **Что это:** Замена большой покупки железа заранее (CapEx) на регулярный счёт за использование (OpEx). - **Пример:** Стартап не покупает стойку серверов на всякий случай, а платит за пару облачных машин, пока клиентов мало. - **Подвох:** В огромном и ровном масштабе своё железо может выйти дешевле — как своя электростанция. - **Связи:** Работает благодаря **On-demand** и **Pay-as-you-go**. ### On-demand — ресурсы за секунды > Открываешь кран — и вода течёт сразу: не ждёшь поставки неделями, не затеваешь ремонт труб. Вода есть в ту секунду, когда ты её просишь. Главная черта облака — ресурсы **по требованию (on-demand)**: новый сервер, база или целая среда поднимаются за секунды парой кликов или строкой кода — и так же быстро выключаются. Сравни с тем, чтобы заказать, дождаться и установить физическое железо. Этот мгновенный **self-service** и делает облако похожим не на покупку машин, а на открытый кран: ёмкость есть, когда ты её попросил. _Diagram: Своё железо — недели от заказа до работы. Облако — один вызов API, и через секунды всё готово._ #### On-demand (по требованию, self-service) - **Что это:** Поднять или выключить ресурс за секунды самому, без заявок и ожидания поставки. - **Пример:** Нужна тестовая среда на день — поднял её строкой кода утром, удалил вечером. - **Подвох:** Так же легко поднять и забыть — отсюда сюрпризы в счёте (**Bill shock**). - **Связи:** Основа для **Elasticity** и **Serverless**. > **Вопрос рамки:** «Хочу ли я владеть физическими машинами и обслуживать их — стоимость, гадание, обслуживание — или арендовать вычисления по требованию и платить только за то, что реально использую?» > Облако — это аренда чужих компьютеров по требованию вместо покупки своих. Ты превращаешь огромную предоплату в оплату по факту и получаешь ёмкость за секунды. ## 2. IaaS, PaaS, SaaS Облачные сервисы идут слоями и различаются одним: сколько управляет провайдер, а сколько — ты. Три аббревиатуры называют главные точки на этой шкале. ### Cloud Service Models — шкала «сколько делают за тебя» > Получить ужин: арендовать кухню и приготовить всё самому, получить кухню с уже нарезанными продуктами или просто заказать готовое блюдо с доставкой. Ужин тот же, усилия — совсем разные. **Модели облачных сервисов (cloud service models)** стоят на шкале от «ты управляешь почти всем» до «ты управляешь почти ничем». На одном конце ты арендуешь голые машины и делаешь остальное сам; на другом просто пользуешься готовым софтом. Известный способ запомнить — **«pizza as a service»**: испечь с нуля, купить заготовку и запечь или заказать доставку. Три именованных слоя — **IaaS, PaaS, SaaS** — это точки вдоль этой линии. _Diagram: Слева направо провайдер берёт на себя всё больше слоёв. Свои данные и настройки остаются твоими везде._ #### Cloud Service Models (модели сервиса, pizza as a service) - **Что это:** Шкала того, сколько слоёв (от железа до приложения) ведёт провайдер, а сколько — ты. - **Пример:** Своя серверная → IaaS → PaaS → SaaS: с каждым шагом твоя зона ответственности меньше. - **Подвох:** Чем больше делают за тебя, тем меньше у тебя контроля — бесплатного удобства нет. - **Связи:** Точки на шкале — **IaaS**, **PaaS**, **SaaS**; дальше всех — **Serverless**. ### IaaS и PaaS — голые машины или готовая платформа > Аренда пустой мастерской, куда ты сам ставишь каждый инструмент (IaaS), против полностью оснащённой мастерской, куда ты просто приносишь свой проект и начинаешь работать (PaaS). **IaaS (Infrastructure as a Service)** сдаёт тебе сырые строительные блоки — виртуальные машины, хранилище, сеть, — а всё сверху ты ставишь и ведёшь сам: максимум контроля, максимум работы. **PaaS (Platform as a Service)** даёт готовую среду: ты просто деплоишь свой код, а провайдер под капотом ведёт серверы, масштабирование и патчи: меньше контроля, гораздо меньше работы. Выбор сводится к тому, сколько «сантехники» ты хочешь держать у себя. _Diagram: IaaS: провайдер даёт только виртуальные машины. PaaS: провайдер ведёт всё, кроме твоего кода._ #### IaaS (Infrastructure as a Service) - **Что это:** Аренда виртуальных машин, дисков и сети; ОС, рантайм и приложение — твои. - **Пример:** Виртуальная машина в AWS EC2: ты сам ставишь программы, настраиваешь систему и обновляешь её. - **Подвох:** Максимум контроля = максимум работы: патчи и масштабирование на тебе. - **Когда брать:** Когда нужен полный контроль над тем, как всё устроено. - **Связи:** Нижняя точка шкалы **Cloud Service Models**; выше — **PaaS**. #### PaaS (Platform as a Service) - **Что это:** Готовая платформа: ты приносишь код, провайдер ведёт серверы, масштабирование и патчи. - **Пример:** Push в Heroku или похожую платформу — и приложение работает, без настройки серверов. - **Подвох:** Меньше контроля: живёшь по правилам платформы и зависишь от её возможностей. - **Когда брать:** Когда хочешь просто деплоить код и не думать о машинах. - **Связи:** Между **IaaS** и **SaaS**; родственник **Managed Service**. ### SaaS — готовый софт, которым просто пользуешься > Ты не выращиваешь пшеницу и не печёшь хлеб, чтобы съесть сэндвич в кафе, — ты просто заказываешь и ешь. Каждый шаг до тебя сделал кто-то другой. **SaaS (Software as a Service)** — дальний конец шкалы: готовый софт, которым ты пользуешься через интернет, а провайдер ведёт абсолютно всё — Gmail, Slack, твоя CRM. Ты управляешь только своими данными и настройками. Большинство программ, которыми ты пользуешься каждый день, — это SaaS. Как строитель ты _потребляешь_ SaaS для частей, которые не хочешь строить, и _строишь_ на IaaS или PaaS то, что и есть твой продукт. Зная слой, ты знаешь, кто за что отвечает. _Diagram: Почту, чат и CRM берёшь готовыми (SaaS); свой продукт строишь сам на IaaS или PaaS._ #### SaaS (Software as a Service) - **Что это:** Готовое приложение через интернет; ты управляешь только данными и настройками. - **Пример:** Gmail, Slack, CRM — ничего не ставишь и не обслуживаешь. - **Подвох:** Почти никакого контроля: как работает софт, решает провайдер. - **Когда брать:** Для всего, что не является твоим продуктом. - **Связи:** Верхняя точка **Cloud Service Models**; противоположность **IaaS**. > **Вопрос модели:** «Для каждой части — сколько я хочу управлять: голыми машинами (IaaS), готовой платформой (PaaS) или ничем, кроме своих данных (SaaS), — и сколько контроля мне на самом деле нужно?» > Облачные слои отличаются тем, сколько провайдер делает за тебя: IaaS — голые машины, которыми управляешь ты, PaaS — готовая платформа под твой код, SaaS — готовый софт, которым просто пользуешься. ## 3. Эластичность и оплата по факту Суперсила облака в том, что ёмкость не фиксирована. Она растёт и сжимается вместе с нуждой, а платишь ты за то, что используешь, — это подарок, а при небрежности — ловушка. ### Elasticity — вверх под всплеск, вниз после > Концертная площадка, которая может добавить тысячу мест на большой вечер и убрать их на следующее утро: ёмкость совпадает с толпой и не тратится на пустой зал. **Эластичность (elasticity)** — способность облака добавлять ресурсы, когда спрос растёт, и убирать их, когда падает. Распродажа, вирусный момент, час пик — облако поднимает больше серверов, а потом сворачивает их, так что ты не платишь за лишнюю ёмкость. Со своим железом пришлось бы купить его под самый загруженный момент и держать без дела всё остальное время. Эластичность подгоняет то, что работает, под то, что реально нужно, минута за минутой. Механизм, который делает это автоматически, называют **autoscaling**. _Diagram: Ёмкость ступеньками идёт за спросом. Красная линия — своё железо, купленное под пик и простаивающее остальное время._ #### Elasticity (эластичность, autoscaling) - **Что это:** Ёмкость растёт под всплеск спроса и сжимается, когда он спадает. - **Пример:** В распродажу магазин работает на десяти серверах, ночью — на двух. - **Подвох:** Масштабирование без потолка может само раздуть счёт (**Bill shock**). - **Связи:** Требует **On-demand**; оплачивается через **Pay-as-you-go**; крайняя форма — **Scale to Zero**. ### Pay-as-you-go — счётчик, а не покупка > Счёт за свет: платишь за электричество, которое реально потратил в этом месяце, а не фиксированную плату за владение сетью. Тратишь больше — платишь больше; не тратишь — не платишь. Облако выставляет счёт как коммуналка: **оплата по факту (pay-as-you-go)** — за вычисления, хранилище и трафик, которые ты реально потребил. Нет предоплаты, нет платы за простаивающую ёмкость — счётчик крутится, только пока ресурс работает. Именно это делает облако доступным: можно начать крошечным и дешёвым, а расходы растут вместе с использованием, а не являются огромной ставкой, сделанной до первого клиента. Счёт отражает реальность. _Diagram: Вычисления, хранилище и трафик идут через счётчик; в конце месяца счёт равен тому, что ты использовал._ #### Pay-as-you-go (оплата по факту) - **Что это:** Плата за фактически потреблённые вычисления, хранилище и трафик. - **Пример:** Маленький проект стоит копейки, пока у него мало пользователей; растёт трафик — растёт счёт. - **Подвох:** «Платишь только за то, что используешь» = «платишь за всё, что используешь». - **Связи:** Финансовая сторона **CapEx → OpEx** и **Elasticity**. ### Bill Shock — счётчик режет в обе стороны > Счётчик такси честен на короткой поездке и страшен, если ты забыл, что он крутится часами: та же поминутная цена, что экономит деньги, может тихо накрутить целое состояние. Оплата по факту — палка о двух концах. Тот же счётчик, что экономит деньги при малой нагрузке, может выдать шокирующий счёт, когда что-то выходит из-под контроля: процесс оставили включённым, масштабирование убежало, ошибка зациклилась. Такой сюрприз называют **bill shock**. Он случается часто именно потому, что вещи так легко поднять и так легко забыть. Отсюда правило: за счётчиком надо следить — например, через **budget alert**, оповещение при превышении бюджета. _Diagram: Обычные дни — ровные траты. Потом что-то убегает, и расходы растут; оповещение о бюджете ловит это рано._ #### Bill Shock (шок от счёта) - **Что это:** Неожиданно огромный облачный счёт из-за того, что что-то убежало. - **Пример:** Тестовый сервер забыли выключить на месяц; цикл в коде без конца вызывает платный сервис. - **Как избежать:** Мониторь траты как производительность; ставь оповещения о бюджете и потолки масштабирования. - **Связи:** Обратная сторона **Pay-as-you-go**, **On-demand** и **Elasticity**. > **Вопрос стоимости:** «Растёт ли моя ёмкость с реальным спросом и сжимается ли, когда он падает, — и слежу ли я за счётчиком, чтобы оплата по факту экономила деньги, а не тихо накручивала сюрприз-счёт?» > Эластичность масштабирует ёмкость вверх под всплески и вниз после; оплата по факту берёт только за то, что используешь. Тот же счётчик, что экономит деньги, может накрутить шок-счёт — так что следи за ним. ## 4. Регионы и доступность Облако — не одно место, а дата-центры по всему миру. Где работает твой код, влияет и на то, насколько быстро всё ощущается, и на то, как система переживает сбой. ### Region — вычисления рядом с пользователем > Служба доставки со складами на каждом континенте отправляет посылку с ближайшего склада — для всех быстрее, чем слать всё из одного хаба. Провайдеры держат дата-центры в **регионах (regions)** по всему миру. Ты выбираешь, где работает приложение, и регион рядом с пользователями срезает **задержку (latency)** — данным ехать меньше, поэтому приложение ощущается быстрее. Европейское приложение из европейского региона быстрее, чем то же приложение из-за океана. Выбор региона — это географический рычаг: держи вычисления и данные близко к людям, которые ими пользуются. _Diagram: Пользователи из Европы ходят в европейский регион — путь короткий. Далёкий регион означает долгий путь через океан._ #### Region (регион, latency) - **Что это:** Группа дата-центров провайдера в одной части мира, которую ты выбираешь для своего кода. - **Пример:** Приложение для европейцев разворачивают в европейском регионе. - **Подвох:** Один регион — одно место: пользователям с другого края мира будет медленнее. - **Связи:** Внутри региона — несколько **Availability Zones**; вместе дают **High Availability**. ### Availability Zone — пережить сбой одного здания > Банк, который хранит копии записей в нескольких отдельных зданиях: если одно затопит, остальные работают дальше, и ничего не потеряно. Внутри региона есть несколько **зон доступности (availability zones)** — физически отдельных дата-центров. Ты запускаешь копии системы в нескольких зонах сразу. Если одна зона теряет питание или ломается, остальные продолжают обслуживать, и приложение остаётся живым. _Diagram: Три зоны — три отдельных дата-центра. Зона B потеряла питание, но копии в A и C продолжают отвечать._ #### Availability Zone (зона доступности, AZ) - **Что это:** Физически отдельный дата-центр внутри региона. - **Пример:** Копии приложения в трёх зонах: одна теряет питание — две другие продолжают работать. - **Подвох:** Защищает от сбоя одного здания, только если ты реально запустил копии в нескольких зонах. - **Связи:** Часть **Region**; кирпичик для **Redundancy / High Availability**. ### Redundancy и High Availability — близко к людям, устойчиво к сбою > Магазин с филиалами в каждом городе, и у каждого филиала есть второй неподалёку: близко к покупателям и крепко против того, что одна точка погаснет. **Избыточность (redundancy)** — значит ни одно здание, машина или зона не становятся фатальной **единой точкой отказа (single point of failure)**. Из этого получается высокая **доступность (high availability)** — система остаётся живой сквозь сбои, которые положили бы одно место. Две идеи вместе — ядро облачной архитектуры: **регионы** рядом с пользователями ради скорости и **зоны** ради устойчивости. Глобальный сервис ощущается локальным везде и переживает неизбежный отказ железа где-то. Ты больше не ставишь весь продукт на одну машину в одном здании — ты распределён по замыслу, и это и есть бо́льшая часть того, что значит «облако надёжно». _Diagram: Два региона рядом с двумя группами пользователей; в каждом — копии в двух зонах. Ни одной единой точки отказа._ #### High Availability (redundancy, высокая доступность) - **Что это:** Система живёт сквозь сбои, потому что у каждой части есть копия в другом месте. - **Пример:** Глобальный сервис: регион в Европе и в США, в каждом копии в двух зонах. - **Подвох:** Копии стоят денег и усложняют систему — каждая копия в счёте. - **Связи:** Складывается из **Region** (скорость) и **Availability Zone** (устойчивость). > **Вопрос размещения:** «Работают ли мои вычисления в регионе рядом с пользователями ради низкой задержки и разнесены ли по зонам доступности, чтобы отказ одного дата-центра не положил всё целиком?» > Регионы ставят вычисления рядом с пользователями и срезают задержку; зоны доступности разносят их по отдельным дата-центрам ради избыточности — близко к людям, устойчиво к любому одному сбою. ## 5. Управляемые сервисы Кроме аренды машин облако может вести за тебя целые куски инфраструктуры — базу, очередь, кэш, — чтобы ты ими пользовался, не эксплуатируя их. Это удобство — настоящий размен. ### Managed Service — пусть провайдер ведёт трудные части > Сервисная квартира, где сантехникой, отоплением и ремонтом занимается кто-то другой: ты просто живёшь, а не работаешь своим же управдомом. **Управляемый сервис (managed service)** — это инфраструктура, которую провайдер ведёт за тебя: управляемая база, очередь сообщений или кэш. Он берёт на себя настройку, масштабирование, бэкапы, патчи и переключение при отказе (**failover**). Ты пользуешься сервисом через интерфейс и никогда не трогаешь машины под ним. Вместо того чтобы стать экспертом по надёжной эксплуатации базы в масштабе, ты арендуешь эту экспертизу. _Diagram: Своя база: всё на тебе. Управляемая база: на тебе только приложение и запросы, остальное — у провайдера._ #### Managed Service (управляемый сервис) - **Что это:** База, очередь или кэш, которые провайдер настраивает, масштабирует, бэкапит и патчит за тебя. - **Пример:** Управляемый Postgres (например, AWS RDS) вместо своей базы на виртуальной машине. - **Подвох:** Меньше контроля и привязка к провайдеру (**Vendor Lock-in**). - **Связи:** Снимает **Undifferentiated Heavy Lifting**; следующий шаг — **Serverless**. ### Undifferentiated Heavy Lifting — меньше эксплуатации, больше продукта > Владелец фудтрака покупает хлеб в пекарне, а не мелет муку сам: он сосредоточен на блюдах — своём настоящем бизнесе, — а не на том, чтобы стать ещё и пекарем. Смысл управляемых сервисов — **фокус**. Надёжная эксплуатация инфраструктуры — бэкапы, масштабирование, патчи безопасности, аварии в три часа ночи — это тяжёлая, специальная работа, и для большинства команд она не создаёт их ценности. Такую работу называют **undifferentiated heavy lifting** — тяжёлый труд, который не отличает тебя от конкурентов. Каждый час, не потраченный на то, чтобы база жила, — это час на твой продукт. Отдав эту работу провайдеру, маленькая команда бьёт далеко выше своего веса: строит фичи, а не нянчит серверы. Во многом поэтому современные продукты выходят быстро с маленькими командами. #### Undifferentiated Heavy Lifting (тяжёлый труд без отличий) - **Что это:** Трудная эксплуатационная работа, которая нужна всем, но не делает твой продукт особенным. - **Пример:** Бэкапы, патчи безопасности и ночные аварии базы — вместо работы над фичами. - **Подвох:** Если эксплуатация и есть твоя ценность, отдавать её наружу — ошибка. - **Связи:** Повод брать **Managed Service** и **Serverless**. ### Vendor Lock-in — удобство против контроля > Набор-полуфабрикат чудесно удобен — пока ты не захочешь поменять один ингредиент и не обнаружишь, что рецепт решает набор. Удобство оплачено контролем. Размен реален: управляемый сервис забирает часть контроля и привязывает тебя к тому, как всё устроено у этого провайдера. Чем глубже ты встраиваешь его особые сервисы, тем труднее и дороже уйти. Это **привязка к вендору (vendor lock-in)**. Ты выбираешь удобство и скорость сейчас против гибкости и независимости потом. Часто это верный ход — но делай его осознанно, держа по-настоящему критичные куски сменными. Это то же суждение, что и выбор между управляемым API и самохостингом. _Diagram: Приложение опирается на базу, очередь и уникальные API одного провайдера — и переезд к другому становится дорогим._ #### Vendor Lock-in (привязка к вендору) - **Что это:** Чем глубже ты в сервисах одного провайдера, тем дороже от него уйти. - **Пример:** Приложение завязано на уникальные API провайдера — переезд означает переписывание. - **Как жить:** Принимай привязку осознанно; держи по-настоящему критичные куски переносимыми. - **Связи:** Цена **Managed Service** и **Serverless**. > **Вопрос управляемого:** «Эксплуатация этой части — моя ценность, или лучше отдать её управляемому сервису и потратить силы на продукт, приняв некоторую привязку ради фокуса?» > Управляемые сервисы дают провайдеру вести базу, очередь или кэш, чтобы ты сосредоточился на продукте, а не на эксплуатации. Размен — меньше контроля и некоторая привязка к вендору. ## 6. Serverless Самый дальний шаг «не управляй машинами» — serverless: ты даёшь только свой код, а облако запускает его по требованию, масштабирует и берёт плату за запрос. Это мощно — для работы правильной формы. ### Serverless — только твой код, никаких серверов в голове > Переговорка, которую бронируешь на полчаса: ты ею не владеешь, не отапливаешь и не убираешь — пришёл, поработал, и она вылетает из головы, как только ты вышел. **Serverless** позволяет запускать код, вообще не управляя серверами. Ты отдаёшь провайдеру **функцию** — маленький кусок кода, — и он запускает её каждый раз, когда приходит событие: запрос, загрузка файла, расписание. Все машины, масштабирование и ёмкость он ведёт незаметно. Такой вариант ещё называют **FaaS (Function as a Service)**. Серверы, конечно, есть; ты просто о них не думаешь. Это логичный конец облачного пути: от владения машинами — к аренде — к тому, чтобы даже не знать о них. _Diagram: Событие (запрос, файл, расписание) запускает твою функцию; серверы и масштабирование спрятаны у провайдера._ #### Serverless (FaaS, Function as a Service) - **Что это:** Ты даёшь функцию, провайдер запускает её на каждое событие и сам ведёт все машины. - **Пример:** Функция в AWS Lambda сжимает картинку каждый раз, когда пользователь её загружает. - **Подвох:** **Cold Start**, плохо подходит для долгой ровной работы, привязка к провайдеру. - **Когда брать:** Короткие задачи по событиям, всплесковая нагрузка. - **Связи:** Крайняя точка **Cloud Service Models**; масштабируется до нуля (**Scale to Zero**). ### Scale to Zero — ноль запросов, ноль денег > Свет с датчиком движения: выключен и ничего не стоит, когда в комнате пусто, и сразу включается, как только кто-то вошёл. Платишь за свет, только пока он горит. Serverless **масштабируется до нуля (scales to zero)**: когда функцией никто не пользуется, ничего не работает и ты платишь ноль; когда запросы льются, она сама поднимает столько копий, сколько нужно. Счёт идёт **за запрос** и за доли секунды вычислений, а не за сервер, который простаивает в ожидании. Это идеально для всплесковой, редкой или непредсказуемой нагрузки: масштабирование без усилий и ноль в тишине — постоянно работающий сервер так не умеет. _Diagram: Сверху — запросы, снизу — копии функции. Нет запросов — ноль копий и ноль в счёте; наплыв — столько копий, сколько нужно._ #### Scale to Zero (оплата за запрос) - **Что это:** Без запросов не работает ничего и счёт нулевой; под наплыв копии поднимаются сами. - **Пример:** Внутренний отчёт, который зовут пару раз в день, почти ничего не стоит. - **Подвох:** После тишины первый запрос ждёт запуска (**Cold Start**). - **Связи:** Крайняя форма **Elasticity** и **Pay-as-you-go**. ### Cold Start — цена за «ничего не работает» > У света с датчиком движения есть крошечная задержка при включении — нормально для коридора, раздражает, если нужна мгновенная и постоянная яркость. Serverless не обходится без разменов. У функции, которая простаивала, есть **холодный старт (cold start)** — короткая задержка, пока провайдер её поднимает. Это может вредить работе, чувствительной к задержке. Serverless подходит коротким задачам по событиям лучше, чем долгим или ровным высоконагруженным — там постоянно работающий сервер бывает проще и дешевле. И он опирается на сервисы конкретного провайдера, так что привязка тоже есть. Serverless — острый инструмент для правильной задачи (всплесковой, событийной, с масштабированием до нуля), а не универсальный выбор по умолчанию. _Diagram: Холодная функция сначала поднимается и только потом отвечает; тёплая отвечает сразу._ #### Cold Start (холодный старт) - **Что это:** Задержка на первом запросе, пока провайдер поднимает уснувшую функцию. - **Пример:** Редкая функция отвечает на первый запрос заметно медленнее, чем на следующие. - **Как жить:** Для работы, чувствительной к задержке, или ровного трафика бери постоянно работающий сервер. - **Связи:** Цена **Scale to Zero** у **Serverless**. > **Вопрос serverless:** «Эта работа всплесковая или событийная, где масштабирование до нуля и оплата за запрос блистают, — или ровная и чувствительная к задержке, где работающий сервер избегает холодных стартов?» > Serverless запускает только твой код, масштабируясь до нуля и беря плату за запрос, — идеально для всплесковой, событийной работы. Следи за холодными стартами и привязкой: это острый инструмент, а не выбор по умолчанию. ## 7. Применять хорошо Облако — это ящик с инструментами-разменами, а не один верный ответ. Применять его хорошо — значит подбирать под каждый кусок подходящую модель и помнить о двух вещах, которые кусаются: счёт и привязка. ### Подбирай модель под задачу > Ты не везёшь детей в школу на грузовике и не переезжаешь на велосипеде — ты выбираешь транспорт под поездку, а не один на всё. Единственно верного слоя нет. Бери **SaaS** для возможностей, которые не являются твоим продуктом, **managed services** — чтобы сбросить undifferentiated heavy lifting, **serverless** — для всплесковой событийной работы и **голые машины (IaaS)** — когда нужен полный контроль. Навык в том, чтобы подобрать под каждую часть системы свою модель: контроль там, где он важен, удобство там, где нет. Хорошая облачная архитектура — обычно намеренная смесь, а не одна модель везде. _Diagram: Каждый тип задачи — своя модель: SaaS, управляемый сервис, serverless или голые машины._ ### Следи за счётом и остерегайся привязки > Аренда освобождает, пока ты не перестаёшь читать выписки, — а самая удобная аренда та, что устроена так, чтобы ты никогда не съехал. Две вещи стабильно кусают облачных пользователей. Первая — **счёт**: ресурсы по требованию так легки, что расходы ползут вверх или скачут незаметно (**bill shock**), поэтому траты мониторят так же, как производительность. Вторая — **привязка (lock-in)**: чем глубже ты врос в уникальные сервисы одного провайдера, тем труднее и дороже уйти. Ни то ни другое не значит «избегай облака» — это значит «пользуйся им с открытыми глазами»: следи за счётчиком и не давай по-настоящему критичным кускам навсегда прирасти к одному вендору. ### Как всё связано > Пазл: каждая деталь сама по себе мало что значит, вместе они дают картинку. Понятия курса — одна система. **Cloud computing** — это аренда вместо владения. Из неё растут три ветки. Первая — деньги: **on-demand** даёт **elasticity**, та оплачивается через **pay-as-you-go**, а у счётчика есть тёмная сторона — **bill shock**. Вторая — сколько делают за тебя: **IaaS → PaaS → SaaS**, **managed services** и **serverless**, который **масштабируется до нуля** ценой **cold start** и **vendor lock-in**. Третья — где всё работает: **region**, **availability zones** и вместе — **high availability**. _Diagram: Облако делится на три ветки: деньги, доля работы провайдера и размещение. Красным — подводные камни каждой ветки._ #### Прежде чем строить в облаке - **Арендовать или владеть** — подходит ли «по требованию и по факту» лучше покупки железа? - **Какая модель для каждого куска** — IaaS, PaaS, SaaS, serverless — под нужный контроль? - **Масштабируется ли это** эластично со спросом — вверх под всплески и вниз после? - **Регион и зоны** — вычисления рядом с пользователями и разнесены ради устойчивости? - **Управляемое или своё** — эксплуатация этой части правда моя ценность? - **Счёт и привязка** — слежу ли я за тратами и держу ли критичные куски переносимыми? #### Признаки, что ты используешь облако хорошо - Ты **арендуешь по требованию** и платишь за использование, а не покупаешь под самый загруженный час. - Каждый кусок использует **подходящую модель** — от голых машин до serverless. - Твоя система **масштабируется эластично**, работает в **регионах рядом с пользователями** и разнесена по **зонам**. - Ты отдаёшь тяжёлую рутину **управляемым сервисам** и сосредоточен на продукте. - Ты **следишь за счётом** и держишь критичные куски переносимыми против **привязки**. ## Шпаргалка: все 19 понятий ### Арендованные компьютеры - **Cloud Computing** (облако): Аренда чужих компьютеров через интернет вместо покупки своих. - **CapEx → OpEx** (аренда вместо покупки): Огромная предоплата за железо превращается в счёт по факту использования. - **On-demand** (по требованию): Поднять или выключить ресурс за секунды, самому. ### Модели сервиса - **Cloud Service Models** (pizza as a service): Шкала того, сколько слоёв ведёт провайдер, а сколько — ты. - **IaaS** (Infrastructure as a Service): Голые виртуальные машины, диски и сеть; всё сверху — твоё. - **PaaS** (Platform as a Service): Готовая платформа: ты приносишь код, провайдер ведёт серверы. - **SaaS** (Software as a Service): Готовый софт; на тебе только данные и настройки. ### Эластичность и деньги - **Elasticity** (autoscaling): Ёмкость растёт под всплеск и сжимается после. - **Pay-as-you-go** (оплата по факту): Платишь за реально потреблённые вычисления, хранилище и трафик. - **Bill Shock** (шок от счёта): Неожиданно огромный счёт, когда что-то убежало. Лечится мониторингом трат. ### Где всё работает - **Region** (регион, latency): Дата-центры в одной части мира; ближе к пользователю — меньше задержка. - **Availability Zone** (AZ): Отдельный дата-центр внутри региона; копии в нескольких зонах переживают сбой. - **High Availability** (redundancy): Нет единой точки отказа: система живёт сквозь сбои. ### Управляемые сервисы - **Managed Service** (управляемый сервис): База, очередь или кэш, которые провайдер ведёт за тебя. - **Undifferentiated Heavy Lifting** (тяжёлая рутина): Трудная эксплуатация, которая не делает продукт особенным, — её стоит отдать. - **Vendor Lock-in** (привязка к вендору): Чем глубже в сервисах одного провайдера, тем дороже уйти. ### Serverless - **Serverless** (FaaS): Только твой код; провайдер запускает его на каждое событие. - **Scale to Zero** (оплата за запрос): Нет запросов — ничего не работает и ничего не стоит. - **Cold Start** (холодный старт): Задержка первого запроса, пока функция поднимается после простоя. > Облако — это аренда вычислений по требованию, слоями от голых машин до serverless. Применяй его хорошо: подбирай под каждый кусок правильную модель — и держи глаз на счёте и привязке. Конец экспресс-курса · 7 глав · 19 понятий Дальше — практика: возьми маленькое приложение и задеплой его в облако — выбери PaaS или serverless, чтобы просто пушить код, и посмотри, как оно масштабируется и как растёт счёт по использованию. Потом добавь один управляемый сервис, например базу, вместо своей. Размены становятся конкретными в ту минуту, когда ты чувствуешь, как мало тебе нужно эксплуатировать, и замечаешь, как тикает счётчик. Но держи одну мысль выше остальных: облако — это просто чужой компьютер, арендованный по требованию. Каждое модное слово — точка на шкале того, сколько за тебя делает кто-то другой, а применять облако хорошо — значит решать, кусок за куском, сколько удобства менять на сколько контроля.