Свои сервера vs Vercel: подскажите, где разворачивать свою инфраструктуру

 Публичный пост

Мне кажется, разработчики новой волны, которые молятся на vercel, kubernetes, и распределенные edge сервера (это все речь про бесконечно горизонтально расширяемые serverless и lambda функции и PaaS провайдеров), не всегда и не вполне себе отдают отчёт, как круто может раздавать одна нормальная машина с nginx и каким-нибудь node.js на борту.

ScrapeNinja это не самый простой SaaS с несколькими тысячами пользователей, 1M+ длительных API запросов (с latency 2-20 sec!!) в день, и оно все крутится на двух хетцнер облачных инстансах. За сорок долларов. Суммарно. Вместо кубернетеса и динамического горизонтального скейлинга используется пять строчек в nginx. И это все работает как часики!

Не нужен вам этот DevOps и микросервисы, если вы только начинаете SaaS пилить, делайте монолит и будьте счастливы. Если бизнес начнет зарабатывать, то всегда потом разберётесь, как решить проблему масштабирования. Если начнет. Ведь главное и самое сложное бутылочное горлышко - это когда 100 лидов сконвертировались в 0 платящих, а не вот эта вся фигня с серверами.

Отказоустойчивость? Пара часов даунтайма еще ни один нормальный продукт не убивали, а вот недостаток денег в кармане - вполне.

перед вами жертва серверлесс
перед вами жертва серверлесс

Навеяно это все одним Реддит топиком, где парнишка за лямды отдал облаку весь свой MRR (Monthly Recurring Revenue) и ещё докинул сверху. И это ведь еще не единственная проблема Vercel / Netlify / Cloudflare workers (когда используются serverless backend функции), это еще и vendor lock-in, когда менять провайдера инфраструктуры - неприятно и больно.

Vercel пытается балансировать между своим облачным офферингом и имиджем белых и пушистых ребятишек, ведь можно next.js деплоить не только к ним в облако, но и на обычный сервер… В теории. На практике мало кто понимает, как это делать в настоящем продакшне, да и много фич работать не будет (не скажу что глубоко копал, это все следует из моего довольно поверхностного изучения next.js)

Хотелось бы послушать людей, которые хорошо разбираются в разворачивании своей инфраструктуры, и при этом активно пользуются Vercel / Netlify и аналогами. Как там дела, какие плюсы, какие проблемы?

Это репост из моего тг канала https://t.me/saas_founders

20 комментариев 👇

Юзаю Cloudflare Pages когда не нужен бэк, в основном для лендингов на реакте. Просто закинул ему приватный гит репозиторий и он сам билдит сайт. Настроил и забыл. И все это бесплатно.
Serverless functions удобно когда тебе нужен допустим обработчик формы какой-нибудь. Нормальную логику на них я не думаю что можно делать.

Сам много пишу на Next.js, хощу на впске у того же Hetzner. За 5 евро у меня там и фронт и бэк и даже бд. Юзаю Caprover чтобы управлять контейнерами. Это этакий селф хостед PaaS с веб мордой. Туда же у меня настроен CI/CD через github actions. Минусы у такого подхода есть и существенные - никакой отказоустойчивости и плохая масштабируемость. Если бд сожрет все место на диске - умрут все сервисы. Ну и скиллы админить линукс тут очень нужны. Зато дешево и своими руками.

С кубернетесом не работал, но собираюсь вкатываться и переводить свой зоопарк на него. Когда у тебя 10 впсок с кучей сервисов на них, встает вопрос как этим делом нормально управлять.

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

  Развернуть 1 комментарий

@AlexBs, Cloudflare Pages прикольный, да. Я только workers у них использовал.
100 custom domains per project - бесплатно! Халява.
CF вообще недорогие ребята, в целом, я за это их люблю и много лет мы довольны (главное, чтобы они не осознали, что пора уже зарабатывать и на мелочи пузатой тоже, вот тогда бежать некуда уже будет).

Конечно, на своем серваке есть риски. Отказостойчивость ниже, мониторинг надо настроить, бекапы базы опять же. Но это вообще не такой rocket science чтобы платить десятки тысяч баксов в год за относительно несложный сервис (это я про кейс из реддита), пока ты мелкий и нищий (5-15 часов даунтайма за год тебе погоды не сделают, клиенты от такого не разбегутся, вопреки расхожему мнению, если у тебя мало-мальски полезный продукт), а когда ты уже крупный - уже тоже дешевле нанять своего devops, мне кажется.

https://caprover.com/ не знал, спасибо за ссылку!

  Развернуть 1 комментарий

А какой сервис можно использовать для своих пет проекто, куда полноценное приложение и с фронтов, и с беком можно закинуть?
Пишу на vue и react, для этого достаточно github pages, но вот как можно задкплоить с беком на go

  Развернуть 1 комментарий

@Jolli, digitalocean, не плох. Хоть пет-проект, хоть прод. Разобраться чуток с gitops и забыть на долгое время про проблемы с развертыванием.

  Развернуть 1 комментарий

@Jolli, fly.io - это такой современный heroku, отличные бесплатные лимиты

  Развернуть 1 комментарий

@ngalaiko, ещё есть Render.com ( не работал с ним )

  Развернуть 1 комментарий

@ngalaiko, у меня как раз есть пара умерших heroku apps, попробовал за пару минут перенести на fly.io - не получилось. Почему нельзя просто дать доступ к github repos, как у Heroku или Vercel!

  Развернуть 1 комментарий

@Zigger, я как раз минут за пять перенес, следуя этой доке: https://fly.io/docs/rails/getting-started/migrate-from-heroku/

  Развернуть 1 комментарий

@Jolli, Если говорить про обычные инстансы, мы использовали hetzner bare metal, GCE, AWS, Linode, Digitalocean и когда хетцнер запустил cloud я его всем рекомендую - дёшево, крутой лк, стабильно. До этого рекомендовал океан, всё ещё там держим пару десятков машин, но сейчас они уже не так молоды и задорны, да и ЛК с постоянными тормозами совсем не выглядит таким инновационным и изящным как раньше.

  Развернуть 1 комментарий

@Jolli, Supabase, CapRover - их можно поднять на своем сервере. Как раз сейчас экспериментирую с CapRover.

  Развернуть 1 комментарий

@nightlord189, supabase вроде совсем про другое, не? Это self hosted firebase, с беком на го оно разве поможет?

  Развернуть 1 комментарий

@Jolli, adaptable.io можно попробовать. там закрытый бета-тест, надо заявку отсылать, благо довольно оперативно отвечают

  Развернуть 1 комментарий
Mikhail Mikhailov Site Reliability Engineer 7 мая 2023

У продукта есть жизненный цикл, на старте у тебя нет ни команды, ни бюджета, ни понимания market fit. Важно быстро запуститься и поставлять, вот тут все эти реселлеры лямбд от амазона и нужны.
Если поперло, то заливаешь проблемы деньгами сейчас и занимаешься cost saving в фоне.
Поэтому практически во всех крупных софтверных компаниях используют hybrid cloud в том или ином виде т.к. одновременно кто-то стартует новый продукт, а кто-то доживает до EOL.
Вот недавний поучительный пример https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

Комментировать про 5 строчек в конфиге Nginx не буду.

  Развернуть 1 комментарий

@setox, ну вот с колокольни мелких компаний и адепта "делаем из говна и палок, KISS" мой совет начинающим предпринимателям - аккуратнее себя ведите со "взрослым" микросервисным devops и serverless подходом, time to market оно вам сократит на пять копеек (если вообще сократит - может и резко увеличить), расширяемость бесконечная вам не понадобится, а проблем получите с хорошей вероятностью, если продукт чуть-чуть начнет взлетать. Переписывать сервис через два месяца, когда только-только начался рост, потому что жировой прослойки в виде денег на косты нет, а вендор уже начал свои счета радостно выставлять - это неприятный сценарий, риски которого не все осознают.

Колокольни более-менее крупной компании касаться не будем - там свои правила и они сами знают что им делать :)

  Развернуть 1 комментарий

@setox, так не проще ли в таком случае написать на старте монолит, докеризировать и частично автоматизировать такие процессы как provisioning нового инстанса и деплой?

Как вариант можно балансировать между «дешево и сердито» до «дорого, но по уму». Например БД сразу вынести в отдельный managed database сервис.

Далеко не факт что проект ожидает взрывной рост. Он может так годами и жить на одном инстансе.

  Развернуть 1 комментарий

Согласен, проще. Более того можно вообще уместиться во free tier облачного провайдера и жить-поживать, или выпросить грант. Я ратаю за иметь возможность быстрого масштабирования, что на барметале часто рукотворный процесс.

  Развернуть 1 комментарий

Запилил тут веб-сокет бекенд на питоне и фронт на реакте, как быстрее всего задеплоить? Я даже готов платить до 5$/мес

  Развернуть 1 комментарий

@Zigger, если есть хотя бы базовое понимание linux, то Hetzner Cloud позволит такое запустить за полчаса. Если хочется PaaS и умеешь докер, то fly.io

  Развернуть 1 комментарий

@pixeljetter, умею докер. Кажется, что на fly.io будет проще деплоить много разных apps. Честно говоря, я хотел вообще без докера, а с автоматическими buildpacks, типа heroku/dokku - подключить репозиторий на гитхабе и всё.

  Развернуть 1 комментарий

@Zigger, я держу как раз на fly.io поxожий сетап. проблемы с автодеплоем нет, но нужно писать экшн небольшой https://fly.io/docs/app-guides/continuous-deployment-with-github-actions/

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб