Великая миграция PaaS: что выбор платформы значит для вашего стартапа

Буду откровенен: новость от Heroku застала сообщество врасплох. Когда Salesforce объявила об отмене бесплатных dyno и изменении тарифов, гул разочарования прокатился по всем dev-чатам и Twitter-лентам. Платформа, которая просто работала — та самая, куда многие деплоили и side projects, и production-проекты — внезапно стала напоминать дорогие отношения, из которых хотелось выйти по-человечески.

И понеслось. Render, Railway, Fly.io и другие вдруг оказались в центре внимания. Разработчики массово задавали один вопрос: «Ты та самая?»

Я наблюдал за этой волной миграции изнутри и у меня есть что сказать о том, что ждёт вас за пределами уютного мира Heroku.

Чем завлекают: ценник

Главный аргумент звучит так: «Переходите к нам и сэкономите 30-40% на хостинге».

Да, математика сходится. Если у вас серьёзная конфигурация на Heroku — несколько dyno, воркеров, базы данных — строчки в счёте действительно уменьшаются. Приятно.

Но вот что в маркетинге обычно умалчивают: вы мигрируете не только хостинг. Вы меняете модель мышления, рабочие процессы и берёте на себя операционную ответственность, которую раньше Heroku закрывал молча.

Сдвиг парадигмы

Здесь начинается самое интересное — и порой самое раздражающее.

Heroku работает на так называемой «app-centric» модели. Вы создаёте приложение, а в нём — процессы (web, worker, clock и прочие), которые работают вместе как единое целое. Платформа понимает, что эти процессы связаны. Конфигурация окружения, pipelines деплоя — всё это уважает эту связь.

Многие современные платформы идут другим путём. Вместо приложения первичной сущностью становятся отдельные сервисы или процессы. Это даёт больше гибкости — можно масштабировать и деплоить компоненты по отдельности. Но теперь вы становитесь координатором.

Сравните это с арендой меблированной квартиры и постройкой собственного tiny house. Квартира (Heroku) — мебель есть, коммуналка подключена, управляющая компания решает проблемы. Tiny house (современный PaaS) — полная свобода, но вдруг вам нужно разбираться в сантехнике, электрике и где вообще поставить диван.

Реальность миграции

Поговорим о том, что происходит на практике.

Большинство платформ здорово поработали над опытом первого деплоя. Подключили GitHub, настроили переменные окружения, нажали кнопку — и вот ты уже в production. Это действительно впечатляет, и конкуренты явно учились у раннего успеха Heroku.

Но ваше приложение — это не один сервис. Их пять. Или десять. Каждый нужно настроить, задеплоить и поддерживать. У каждого свой процесс сборки, свои правила масштабирования, свои health checks.

И вот вы уже не просто деплоите код — вы управляете созвездием сервисов, которые должны работать вместе, но ничего не знают друг о друге.

Где становится сложно

Вот сценарий, который я видел не раз: вы создаёте blueprint.yaml или похожий файл для описания инфраструктуры. Отлично! Всё задокументировано, лежит в git, воспроизводимо.

Потом заходите в веб-панель что-то проверить и замечаете настройку, которая не совпадает с вашим YAML. Исправляете прямо через UI. И теперь вопрос: что является источником истины — файл в репозитории или настройка в панели?

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

Скрытая цена «владения большим»

Современные PaaS-платформы часто говорят: «Вы будете владеть большей частью инфраструктуры». Подаётся это как расширение возможностей, и во многом так и есть. Больше контроля, больше видимости, больше кастомизации.

Но владение имеет свою цену. Когда у Heroku проблемы с routing layer — открываете тикет в поддержку. Когда у вашего Render-деплоя сетевая проблема — разбираетесь с конфигурацией load balancer. Когда приложению на Fly.io нужны специфичные kernel parameters — читаете документацию, которая предполагает глубокое знание инфраструктуры.

Вопрос не в том, плохие ли эти платформы. Нет. Вопрос в том, есть ли у вашей команды время, экспертиза и желание брать на себя эту операционную сложность в обмен на экономию.

Как сделать правильный выбор

Так мигрировать или нет? Ответ, к сожалению: зависит от ситуации.

Оставайтесь ближе к простоте Heroku, если:

• Ранняя стадия, нужно двигаться быстро
• Команда маленькая или вы носите много шляп
• Инфраструктурные требования стандартные
• Developer experience и скорость важнее экономии

Принимайте современную PaaS-сложность, если:

• Есть выделенные DevOps-ресурсы
• У инфраструктуры уникальные требования
• Оптимизация costs — критическая метрика
• Команда комфортно чувствует себя с infrastructure-as-code и debugging распределённых систем

Итог

Миграция платформ редко бывает такой простой, как обещает quick start guide. Настоящая цена ухода с Heroku — это не только effort по переезду. Это постоянный trade-off между простотой и контролем, между managed services и собственной инфраструктурой.

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

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

Знайте себя. Знайте свою команду. Выбирайте осознанно.

А у вас есть история миграции? Делитесь в комментариях — интересно, как Great PaaS Transition проходит у вас.