Я вспомнил времена, когда никак не мог понять serverless, и засыпал доктора вопросами.

Сервер исчез? Кто же этот волшебник

🧙‍♂️（博士）「🐣, сегодня будем разбираться с serverless. Название звучит как ‘магия исчезнувшего сервера’, но на деле всё куда прозаичнее, хоть и довольно глубоко.」

🐣（学生）「Сервера нет? Вы что, как Гарри Поттер, выкрикнули 『Сервер, исчезни!』 — и он реально пропал?」

🧙‍♂️（博士）「Ха-ха, так думают девять из десяти. Но серверы никуда не деваются. Они вкалывают где-то в недрах облака, просто пользователю не нужно о них думать.」

🐣（学生）「То есть обман? Как надпись ‘без пестицидов’, а на самом деле всё залили химией?」

🧙‍♂️（博士）「Сравнение странное, но по сути верное. В слове serverless ’less’ означает ‘меньше управления’. Раньше мы сами ‘держали’ сервер, ставили ОС, дежурили при авариях — как ухаживать за хомяком. В serverless всё это на себя берёт облачный провайдер.」

🐣（学生）「Хомяк если умрёт — плачешь, а сервер если упадёт — клиенты орут. Ещё тяжелее.」

🧙‍♂️（博士）「И хомяк не поднимает тебя в три ночи с сообщением ‘база данных не отвечает’.」

📌 Заметка: базовые принципы serverless Serverless не означает «серверов нет». Это архитектура, где управление серверами берёт на себя облачный провайдер.

  • Классический подход: покупаем, размещаем и обслуживаем сервер сами
  • Serverless: провайдер ведёт всю инфраструктуру, а мы концентрируемся на коде

Как работает serverless: ниндзя, который появляется по вызову

🐣（学生）「Звучит сложно. Чем это отличается от обычного сервера?」

🧙‍♂️（博士）「Да, есть нюансы. В serverless ресурс ‘появляется’ только когда его вызывают, выполняет работу и исчезает. Поэтому приложения надо проектировать как ‘спринтеров’. Марафонцам тут не место.」

🐣（学生）「То есть крикнули ‘срочно посчитай!’ — он выпрыгнул, а как только сказали ‘готово’ — растворился?」

🧙‍♂️（博士）「Именно! Прям как ниндзя, которого вызывают по требованию. Пока он прячется в облаке, платить за простой не нужно.」

🐣（学生）「Но ниндзя каждый раз появляются из разных мест. Что с IP-адресом?」

🧙‍♂️（博士）「Остро подмечено. Постоянного адреса нет: каждый раз работает другой сервер. Поэтому облако ставит API Gateway — такого ‘привратника деревни ниндзя’, который распределяет внешние запросы нужному ниндзя.」

🐣（学生）「Понятно. А если ниндзя меняется, значит, он ничего не помнит?」

🧙‍♂️（博士）「Так и есть. Нужен stateless-дизайн. Никаких ‘привет, продолжаем вчерашний разговор’. Каждая сессия — как знакомство с золотой рыбкой заново.」

🐣（学生）「Неудобно. А как быть с логином и сессиями?」

🧙‍♂️（博士）「Хранить состояние вовне: база данных, Redis и прочее. Сам ниндзя память не держит, но складывает важные свитки в ‘архив свитков’.」

📌 Заметка: почему важен stateless-дизайн Serverless-функции стартуют в новом контейнере при каждом вызове, так что локальное состояние (переменные, файлы, сессия) не сохраняется.

  • Состояние: внешняя БД, Redis, S3 и т. п.
  • Сессии: JWT-токены или внешние хранилища
  • Файлы: всё долговременное нужно класть во внешнее хранилище

Чем отличается от обычного сервера: питомец против ниндзя

🐣（学生）「Приведите пример.」

🧙‍♂️（博士）「Возьмём обработку ‘создать миниатюру при загрузке изображения’. В классическом варианте 24/7 стоит сервер: 『ну что, кто-то пришёл?』. Электричество жрёт, да ещё и падать может.」

🐣（学生）「Как охранник, который у двери дежурит и ждёт посетителей.」

🧙‍♂️（博士）「Верно! И иногда охранник простывает и падает. В serverless же, как только прозвенел звонок 『загружено изображение!』, ниндзя выскакивает, быстро делает миниатюру и снова исчезает.」

🐣（学生）「А ждать ниндзя долго не приходится?」

🧙‍♂️（博士）「Вот она, проблема cold start. Пока ниндзя спит, ему нужно несколько секунд, чтобы проснуться и подготовиться. С тяжёлыми языками вроде Java это как сонный ниндзя, который сперва растягивается на коврике и готовит завтрак.」

🐣（学生）「Бесит. Значит, для реального времени не подходит?」

🧙‍♂️（博士）「Есть механизмы прогрева, но в целом serverless силён в батчевых и асинхронных задачах. 『Ответь немедленно!』 — не его стихия.」

Разберёмся на примере: приложение для обмена фотографиями

🐣（学生）「Поясните на примере. Хочу сделать фотосервис.」

🧙‍♂️（博士）「Отлично. Классическая схема:」

Классический сервер:

Веб-сервер работает 24/7 (5000 иен в месяц)
↓
«Фотография загружена»
↓
Генерация миниатюры на сервере
↓
Сохранение в базе данных

🧙‍♂️（博士）「Так ты платишь 5000 иен каждый месяц, даже если никто ничего не загружает. Как арендовать магазин без посетителей.」

🐣（学生）「Пустая трата.」

🧙‍♂️（博士）「А в serverless будет так:」

Serverless-версия:

Изображение попадает в S3
↓
Событие S3 триггерит функцию Lambda
↓
Lambda запускается (0,1 секунды)
↓
Создаёт миниатюру и кладёт в другой бакет S3
↓
Lambda завершается
↓
Оплата: только за время выполнения (около 0,001 иены за вызов)

🐣（学生）「То есть если никто не пользуется — ничего не платим?」

🧙‍♂️（博士）「Именно. Платишь за фактическое использование. Но если проект взорвётся, счёт взорвётся тоже. Видео стало вирусным — миллион вызовов…」

🐣（学生）「Получим счёт на 1000 иен!」

🧙‍♂️（博士）「Счёт посчитан верно, но не забывай про трафик, API Gateway, базы данных. Легко набегают десятки тысяч иен. Современная трагедия: 『завирусилось — и банкротство』.」

📌 Заметка: плюсы и минусы поминутной оплаты

Преимущества

  • Почти нулевые стартовые затраты
  • Автоскейл по фактической нагрузке
  • Нет необходимости управлять инфраструктурой

Риски

  • Непредсказуемые большие счета (особенно при вирусном росте)
  • Сложные тарифные модели
  • Сложно увидеть совокупную стоимость связки сервисов

Что делать

  • Настроить оповещения о расходах
  • Ограничить частоту запросов
  • Делать нагрузочные тесты и расчёт стоимости заранее

Виды serverless: специализация ниндзя

🐣（学生）「Говорят, serverless бывает разным?」

🧙‍♂️（博士）「Есть три главных школы: FaaS (Function as a Service), BaaS (Backend as a Service) и serverless-контейнеры.」

🐣（学生）「Что такое FaaS?」

🧙‍♂️（博士）「Это сервис 『мы берём на себя только функцию』. AWS Lambda, Google Cloud Functions, Azure Functions. Пишешь функцию, а они 『запускают по вызову и берут деньги за фактическое время』 — почти как суши-бар.」

🐣（学生）「А BaaS?」

🧙‍♂️（博士）「Это 『и базу, и аутентификацию, и пуши сделаем за тебя』. Firebase, Supabase, AWS Amplify. Как жить дома с родителями: 『мама всё сделает』.」

🐣（学生）「Дома уютно, но правила родителей соблюдать надо.」

🧙‍♂️（博士）「Вот-вот. Это риск vendor lock-in. Не заметишь, как окажешься 『на игле сервиса』.」

Где serverless силён, а где пасует

🐣（学生）「Может, проще попыхтеть вручную? Зачем тогда serverless?」

🧙‍♂️（博士）「Главный плюс — скорость. Придумал идею — быстро выкатил. Пока аудитория маленькая, платишь почти ничего. Можно вечером придумать сервис, а утром уже запустить.」

🐣（学生）「Но для любых задач он не годится?」

🧙‍♂️（博士）「Конечно. У него очень чёткие сильные и слабые стороны.」

Сильные стороны

  • Обработка изображений (upload → миниатюра)
  • Трансформация данных (CSV → JSON)
  • Отправка уведомлений (почта, push)
  • Регулярные батчевые задачи (ежедневные отчёты)
  • Лёгкие API (поиск пользователя, выдача данных)

Слабые стороны

  • Реалтайм (чаты, игры)
  • Долгие задачи (видеоэнкодинг, ML)
  • Сложное управление состоянием
  • Тесная связка со старыми системами

🐣（学生）「То есть『мощный спринт, но слабая выносливость』.」

🧙‍♂️（博士）「В точку! На 100 метров — чемпион, на марафоне — нет.」

Ловушка тарифов: ниндзя на почасовой оплате

🐣（学生）「Если силачам он не нужен, а счёт может убить, значит, выгодно только умным?」

🧙‍♂️（博士）「Так. Serverless — это 『выигрывает тот, кто думает, а кто расслабился — взрывается』. Не понимаешь тарификацию — попадёшь в ад.」

🐣（学生）「Какой ад?」

🧙‍♂️（博士）「Например, написал бесконечный цикл. На обычном сервере просто всё тормозит. В serverless же 『ниндзя вызываются бесконечно』.」

🐣（学生）「Армия ниндзя пашет без остановки и присылает счёт? Жуть.」

🧙‍♂️（博士）「И узнаешь ты об этом по счёту в конце месяца: 『Как так — миллион иен?』 У AWS полно реальных историй про сотни тысяч иен.」

🐣（学生）「Страшно. Можно защититься?」

🧙‍♂️（博士）「Конечно. Настраиваешь бюджетные оповещения, ограничение времени выполнения, лимиты на параллелизм. Это как грамотно прописать 『контракт найма ниндзя』.」

Реальные провалы: ужас, когда стало вирусно

🐣（学生）「А есть живые примеры огромных счетов?」

🧙‍♂️（博士）「Хоть отбавляй. Например, 『фотоприложение, которое взлетело и получило счёт на 3 миллиона иен』.」

🐣（学生）「Ого… Что случилось?」

🧙‍♂️（博士）「Стартап сделал приложение, которое 『улучшает фото с помощью ИИ』. Расчитывали на 0,1 иены за снимок.」

🐣（学生）「И?」

🧙‍♂️（博士）「Вирусный рост: миллион фото в день. Каждое обрабатывалось дольше, чем думали, и фактическая цена стала 3 иены за фото.」

🐣（学生）「1.000.000 × 3 иены = 3.000.000…」

🧙‍♂️（博士）「И так 30 дней подряд. 『Прославились и обанкротились』 — типичная трагедия.」

🐣（学生）「Не подстраховались?」

🧙‍♂️（博士）「Никаких лимитов. 『Не ожидали такого вируса』. Сейчас уже считается нормой задавать 『потолок успеха』.」

🐣（学生）「Забавно — ограничивать успех.」

🧙‍♂️（博士）「Иронично. 『Радостный вопль』 превращается в настоящее рыдание.」

Опыт разработки: магическое удовольствие и боль ограничений

🐣（学生）「А разработка? Это же что-то другое?」

🧙‍♂️（博士）「Сначала кайф. Написал функцию, нажал кнопку — и она в проде. Чувствуешь себя волшебником.」

🐣（学生）「Звучит классно.」

🧙‍♂️（博士）「Но потом всплывает обратная сторона. Локально тестировать трудно, отладка мучительная. Подумал 『почему не работает?』 — а ниндзя уже исчез, остаются лишь логи.」

🐣（学生）「Как прийти на место преступления и найти только улики.」

🧙‍♂️（博士）「Точно. И логи разбросаны по куче сервисов: CloudWatch, X-Ray, CloudTrail — целый детектив.」

🐣（学生）「Нудно. Может, проще свой сервер держать.」

🧙‍♂️（博士）「Вот она ловушка serverless. Сначала простая магия, потом сложное проклятие. Но привыкнув, назад к ‘уходу за сервером’ возвращаться не хочется.」

🐣（学生）「Значит, вызывает зависимость?」

🧙‍♂️（博士）「Ага. 『Не думать о серверах』 — наркотик. Но вместо этого появляются 『страх перед счётами』 и 『архитектурные ограничения』.」

Serverless и классика: каков реальный ценник

🐣（学生）「В итоге что дешевле?」

🧙‍♂️（博士）「Зависит от объёмов и предсказуемости. Представь график:」

Классический сервер

  • Фикс: 50 000 иен в месяц
  • Переменные: почти ноль
  • Модель «столовая с комплексными обедами»

Serverless

  • Фикс: почти ноль
  • Переменные: пропорционально нагрузке
  • Модель «конвейер суши»

🐣（学生）「Дешевле будет там, где ты ешь ‘больше или меньше’.」

🧙‍♂️（博士）「Именно. Мало ‘ешь’ — конвейер суши (serverless). Ешь много — столовая (классика). Конкретно:」

До 1 миллиона запросов в месяц: serverless заметно дешевле
Выше 10 миллионов запросов: классический сервер выгоднее
Между ними: зависит, учитывай и операционные расходы

🐣（学生）「А если ошибиться в прогнозе?」

🧙‍♂️（博士）「Получается лотерея. 『Собирался объесться в столовой, а аппетита нет』 или 『думал перекусить в суши-баре, а вышел чемпионат по обжорству』.」

Победит ли serverless?

🐣（学生）「Так serverless победит или проиграет?」

🧙‍♂️（博士）「Ни тотального триумфа, ни провала. Классика, контейнеры и serverless будут жить рядом. 『В мире нужны и ниндзя, и рыцари, и маги』.」

🐣（学生）「Значит, одна технология всё не решит.」

🧙‍♂️（博士）「Верно. 『Серебряной пули』 нет. Но в подходящих задачах это очень мощный инструмент.」

🐣（学生）「Кому вы бы советовали?」

🧙‍♂️（博士）「Вот таким людям:」

Кому подходит serverless

  • Нужно быстро выкатить рабочий прототип
  • Хорошо понимает тарифы и расчёт расходов
  • Предпочитает простоту управления полному контролю
  • Радуется новым технологиям

Кому не подходит

  • Мастера, которые хотят контролировать всё
  • Те, кто плохо управляет бюджетом
  • Те, кто ставит стабильность превыше всего
  • Те, кто привязан к легаси

🐣（学生）「То есть для 『новаторов-экономистов』.」

🧙‍♂️（博士）「Отличная формулировка: нужно и инновации любить, и копейку считать.」

Финал: жить по-serverless

🐣（学生）「И всё-таки вы рекомендуете serverless?」

🧙‍♂️（博士）「Я говорю не ‘берите’, а ‘разберитесь и применяйте осознанно’. Это современное заклинание: взвешиваешь соблазн удобства и риск счетов.」

🐣（学生）「Заклинание… Если прочитать неправильно, ударит по тебе.」

🧙‍♂️（博士）「Так и есть. Нужно учиться ‘правильному произношению’. Serverless — это 『выиграешь, если думаешь, а расслабишься — взорвёшься』. Силачам не по пути, а умному даёт мощное оружие.」

🐣（学生）「То есть так:

  • Классический сервер: ад выносливости для мышц
  • Serverless: интеллектуальное выживание в счетах Верно?」

🧙‍♂️（博士）「Прекрасное резюме. Выбор зависит от ситуации. Но 『ничего не выбирать』 уже нельзя. Современный инженер должен решить, он рыцарь, ниндзя или маг.」

🐣（学生）「Поняла. Сначала база, до ниндзя ещё доберусь.」

🧙‍♂️（博士）「С таким подходом станешь отличным ‘повелителем ниндзя’. Только со счётом не прозевай.」

🐣（学生）「Есть! Настрою уведомления о расходах!」

📌 Финальная заметка: как принимать решение о serverless

Перед внедрением serverless оцените совокупность факторов:

Технические

  • Характер нагрузки (батч против реалтайма)
  • Частота вызовов (редко против часто)
  • Нужда в хранении состояния
  • Интеграция с легаси

Бизнесовые

  • Бюджет на старт
  • Компетенции операционной команды
  • Точность прогнозов роста
  • Готовность к vendor lock-in

Вывод: serverless — не универсальная таблетка, а специализированный инструмент, который раскрывается в верном контексте. При понимании и подготовке это мощное оружие; при легкомысленном подходе — дорога к огромным счетам.

Для современного инженера serverless — обязательная опция в арсенале и технология, которую стоит применять там, где она уместна.