Где разворачивать приложения: пять платформ — пять подходов
Представьте ситуацию: вы в одиночку или вместе с командой запускаете своё приложение или сервис, и через какое-то время инструмент, с которого вы стартовали для проверки гипотезы (например, тот же Lovable) становится тесен. Это значит, что пора переходить на другой. Но какой? Vercel? Railway? Fly.io? Porter? Или всё же остановить свой выбор на Heroku? Эти платформы обещают примерно одно и то же — «просто дай код, нажим кнопку, чтобы задеплоить, а мы разберёмся». И уже потом внезапно оказывается, что один инструмент не подходит под ваш профиль трафика, у другого философия релизов не ложится на культуру команды, у третьего управляемая БД — это на самом деле не совсем managed.
Герои магии и меча этой статьи: Heroku, Vercel, Fly.io, Railway и Porter. Они появлялись на рынке именно в этом порядке, и такая последовательность отражает то, как менялись подходы к построению приложений за последние пятнадцать лет. Каждая платформа в своё время решала конкретную боль индустрии, и это намертво вшито в архитектуру решения.
В прошлой статье я описал четыре этапа зрелости приложения и их влияние на команды разработки - в этой рассмотрю платформы последовательно с учетом их времени их появления, вводимых ими абстракций, постараюсь раскрыть смысл данных абстракций и как это влияет на архитектуру разрабатываемых приложений.
