Где разворачивать приложения: пять платформ — пять подходов
<img src="https://habrastorage.org/getpro/habr/upload_files/4e1/9d2/0cd/4e19d20cdea5a07eee5802d17ce05a77.png" /><p>Представьте ситуацию: вы в одиночку или вместе с командой запускаете своё приложение или сервис, и через какое-то время инструмент, с которого вы стартовали для проверки гипотезы (например, тот же Lovable) становится тесен. Это значит, что пора переходить на другой. Но какой? Vercel? Railway? <a href="http://Fly.io" rel="noopener nofollow">Fly.io</a>? Porter? Или всё же остановить свой выбор на Heroku? Эти платформы обещают примерно одно и то же — «просто дай код, нажим кнопку, чтобы задеплоить, а мы разберёмся». И уже потом внезапно оказывается, что один инструмент не подходит под ваш профиль трафика, у другого философия релизов не ложится на культуру команды, у третьего управляемая БД — это на самом деле не совсем managed.</p><p>Герои <s>магии и меча </s>этой статьи: Heroku, Vercel, <a href="http://Fly.io" rel="noopener nofollow">Fly.io</a>, Railway и Porter. Они появлялись на рынке именно в этом порядке, и такая последовательность отражает то, как менялись подходы к построению приложений за последние пятнадцать лет. Каждая платформа в своё время решала конкретную боль индустрии, и это намертво вшито в архитектуру решения.</p><p>В этой статье я рассмотрю платформы последовательно с учетом их времени их появления, вводимых ими абстракций, постараюсь раскрыть смысл данных абстракций и как это влияет на архитектуру разрабатываемых приложений.</p> <a href="https://habr.com/ru/articles/1075514/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1075514#habracut">Читать далее</a>