В апреле Google открыл App Engine – платформу, на которой приложение запускается прямо в инфраструктуре Google, без собственных серверов и администрирования ОС. Это не аренда виртуальной машины, как в Amazon EC2, а уровень выше: вы пишете код, а платформа сама масштабирует его под нагрузку. Такую модель уже называют PaaS – Platform as a Service. Для системного интегратора важно трезво понять, где она применима, а где пока нет.

Что именно даёт App Engine

Сейчас платформа поддерживает один язык – Python и собственный веб-фреймворк webapp, совместимый с WSGI; работает и Django с оговорками. Хранилище данных – не реляционная СУБД, а Datastore поверх Bigtable. Это принципиальный сдвиг: привычных JOIN и произвольных SQL-запросов нет, есть язык GQL и индексы, которые надо проектировать заранее. Аутентификацию можно делегировать Google Accounts, исходящие запросы идут через URL Fetch, почта – через отдельный API. Прямого доступа к файловой системе, сокетам и фоновым процессам нет – приложение живёт только внутри HTTP-запроса.

Взамен вы получаете автоматическое масштабирование и эксплуатацию уровня Google. Бесплатная квота сегодня – около 500 МБ хранилища и порядка 5 млн просмотров страниц в месяц; платная тарификация по потреблению анонсирована, но ещё не запущена. Для пилота или небольшого публичного сервиса этого достаточно.

Где это работает, а где нет

App Engine хорошо ложится на лёгкие веб-приложения с непредсказуемой нагрузкой: формы обратной связи, каталоги, маркетинговые кампании, публичные кабинеты с простой логикой. Там, где раньше под всплеск трафика приходилось держать запас серверов, платформа снимает эту заботу.

Ограничения тоже жёсткие и их надо называть прямо. Запрос обязан завершиться за несколько секунд, иначе платформа его прервёт. Долгие вычисления, пакетная обработка, интеграция по «тяжёлым» протоколам, работа с локальными файлами – всё это мимо. Отказ от реляционной модели означает переписывание привычного слоя данных, а не перенос. И ключевой риск для корпоративного и государственного заказчика – vendor lock-in: код, завязанный на Datastore и сервисы Google, не переедет на свой сервер без переработки.

Что это значит для российского B2B и госсектора

Для госструктур и регулируемых отраслей публичное облако американского провайдера пока не вариант: данные физически уходят за пределы контура заказчика, а требования к хранению и доступу этого не допускают. Здесь по-прежнему уместны собственные мощности и контролируемая ИТ-инфраструктура внутри контура заказчика, особенно когда речь о юридически значимых документах и архивах, о чём мы писали в материале про электронный архив с юридической значимостью.

При этом сама модель PaaS заслуживает внимания. Мы наблюдаем тот же сдвиг, что и в дистрибуции приложений: централизованная платформа берёт на себя инфраструктуру и правила игры, а разработчик концентрируется на продукте – мы разбирали это на примере запуска App Store. App Engine применяет тот же принцип к серверной части.

Вывод

Google App Engine – зрелая заявка на массовый PaaS, но сегодня это инструмент для публичных, нетребовательных к данным приложений и быстрых прототипов. Для корпоративных систем и тем более госсектора в России решающими остаются контроль над данными и независимость от одного поставщика. Мы советуем тестировать платформу на пилотах, а не закладывать её в основу критичных сервисов и проектировать архитектуру так, чтобы уход с платформы не стал переписыванием с нуля.