AmveraCloud Хостинг

Раньше я считал, что публичные облака дорогие, и как я заблуждался! Да что говорить, многие мои знакомые так и считают. Но я попробую объяснить, почему это совсем не так и я изменил свое мнение!

Cразу сделаю оговорку — все очень сильно зависит от вашего проекта. Но постановку вопроса это не меняет — так как облака, как правило, дорогие для тех проектов, где они не нужны. А какая разница, сколько стоит продукт, который вам не нужен! Но стоит вам начать реализовывать сложный проект, как раз в этот момент облачные сервисы и оказываются полезны.

Раскрытие информации: я основатель облака Amvera, в котором можно развернуть проект через git push, введя три команды в терминале. Потому я могу быть предвзят в этом вопросе и рассмотрю кейс, не относящийся к нашему облаку.

Давайте представим такой проект. SaaS-сервис. У вас 20 — 25 микросервисов. Некоторые из них масштабируются горизонтально, количеством инстансов. Основная база данных — PostgreSQL. Проект — прод, вам нельзя эту базу данных потерять. Плюс, вы пишете логи в Elastic, запускаете приложения в Kubernetes и используете брокер очередей сообщений Kafka. Да, это не монолит, который можно на VPS/железном сервере запустить, но и не космический корабль c несколькими зонами доступности и тысячами приложений.

А теперь посчитаем, где и за сколько это можно развернуть. Допустим, проект потребляет 100 vCPU, 400 Гб ОЗУ и 2 Тб SSD. Вернее, потребляет он меньше, но нужно брать с запасом.

Если взять любое публичное облако, получим очень примерно 70 000 руб. за CPU, 80 000 руб. за ОЗУ и 20 000 руб. за диск. Добавим еще 10 000 руб. на бэкапы и 50 000 руб. на managed PostgreSQL, Kafka, Kubernetes и OpenSearch. Итого получилось 230 т.р./месяц. Кажется, что это очень много.

А теперь попробуем это сделать на своем железе. Старый ноутбук или одноплатник с алиэкспресса тут не подойдут.

Если вам нужен новый (а смысл брать старый нет) сервер со 100 vCPU, 400 Гб ОЗУ и 2 Тб SSD это вам выйдет в 1,2-1,5 млн. руб. Хорошо, хорошо, вы нашли дешевле и взяли за 700 000 руб.

Решили развернуть на нем все сразу. И сразу столкнулись с тем, что Kubernetes нужно ставить на 3 ноды минимум. Это значит, вам надо либо на вашей железке поднять несколько виртуальных машин, либо использовать что-то вроде minikube, который можно и на одной запустить.

Железку нужно где-то ставить. Арендуем колокейшн на 2U за 10 000 -15 000 руб./месяц.

Ставим Elastiс и понимаем, что мощности не хватает. Плюс еще нужен стейджинг. Идем и покупаем еще один сервер за 700 000 руб.

Но вы получили не отказоустойчивое решение. Любой сбой и все пропало. Особенно это касается дисков.

Тогда вы идете и докупаете еще пару серверов за 700 000 руб. Нарезаете виртуалки, настраиваете сеть, поднимаете Ceph …

И вот, наконец, у вас спустя пол года и 2,8 млн. рублей почти отказоустойчивая инфраструктура. Если учесть, что года через 3-4 вы их спишите, то стоимость владения с учетом инфляции будет около 60 000 руб. в месяц.

И за колокейшн вы платите каких-то «жалких» 60 000 руб. в месяц.

Но есть нюанс. За железными серверами надо следить. Вдруг диск полетит, надо заменить, да и много что может случиться. И для этого вы выделяете половину времени одного из членов команды. Зарплаты бывают разными. Но мы же экономим, поэтому заложим “всего” 75 т.р. в месяц.

Итог — мы получили сумму, аналогичную публичному облаку.

Но давайте будем честны, самостоятельно развернуть Kubernetes, Ceph, Kafka, PostgreSQL c бэкапами и т.д. проблематично. Вам понадобится пару инфраструктурных/DevOps инженеров. Хорошо, один “сын маминой подруги” за 300 000 руб/месяц.

Это я не говорю, что услуги по сопровождению и построению инфраструктуры могут и 1 млн. руб. в месяц стоить.

Но даже если брать по минимуму, мы получим 495 000 руб/мес против 230 000 руб/мес за публичное облако.

Тогда может брать сервера в аренду?

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

Из плюсов своих серверов вы получите

• Запас по вычислительной мощности.
• DevOps в штате. Есть вероятность, что специалист будет вам полезен и при использовании публичного облака.

А из минусов

• Неэластичность. Докинуть железный сервер в кластер, не то же, что виртуалку у провайдера.
• Вы маловероятно настроите инфраструктуру также хорошо, как провайдеры с сотнями клиентов на которых они набили шишки. И все обязательно упадет, возможно, просто еще время не пришло…
• В облаке вы получаете множество скрытых преимуществ из разряда защиты от DDoS, пулов IP, геораспределенности, нормальных бэкапов и много другого, что очень сложно реализовать самостоятельно.

Но не работают же облака в минус? Нет, конечно. Просто самые большие затраты это администрирование и построение общей инфраструктуры. А эти затраты теряются на масштабах провайдеров. Для них себестоимость чуть выше стоимости владения железом. Но «что позволено Юпитеру, не позволено быку», поэтому, пока ваш бюджет на инфраструктуру не миллиард в месяц, баланс затрат себестоимости будет не в вашу пользу если вы решите сделать что-то подобное самостоятельно.

Но давайте вернемся к вопросу — а вам облако реально нужно?

• Если у вас небольшой сайт, и вы редко вносите в него изменения, проще воспользоваться простым хостингом. Хостинг в несколько раз дешевле виртуалки у PaaS облачного провайдера.
• Если нагруженный сайт, но шаблонный, и вы не вносите много изменений, ваш выбор — хостинг или аренда железного сервера плюс настройка бэкапа в другое место.
• Если вы банк, вам безопасники не дадут в облаке развернуться.
• Если у вас стартап с частыми изменениями и вам нужно легко все развертывать из коробки и каждый день доставлять обновления, воспользуйтесь Heroku, или нашим сервисом Amvera;) Это даст вам сразу CI/CD, бэкапы, алерты и максимально абстрагирует от инфраструктуры.
• И вот только если у вас сложный сервис, который должен работать в разных регионах или использовать сложную, нагруженную инфраструктуру, вам путь в классические, публичные облака.

Публичные облачные провайдеры берут деньги за то, что снимают с вас тяжесть развертывания и администрирования сложных инфраструктурных сервисов, разделяя эти издержки на множество клиентов. Если вы решите все делать самостоятельно, делить эти издержки будет не с кем. И на самом деле на выходе вы получаете относительно «дешевый» продукт. А сравнивать облако просто со стоимостью покупки железного сервера, это как сравнивать стоимость автомобиля со стоимостью металла, из которого он сделан. Но выбор, где разворачивать сервисы, за вами.



amvera.ru

Уже 1 год мы разрабатываем облако, в котором проекты можно развертывать и обновлять через PUSH в мастер-ветку GIT. Это проще, чем использование VPS (виртуальных машин).

Что у нас было:

• максимально сырой прототип, позволяющий запускать проекты в контейнерах через отправку кода в выделенный или привязанный Git-репозиторий.

Чего у нас не было:

• Документации — я искренне удивляюсь, как наши пользователи справлялись с развертыванием, используя лишь несколько абзацев краткой инструкции. Приношу извинения за ваши страдания! Но многие справились.
• Отображения логов. Но и без логов были пользователи, которые успешно разворачивали проект.
• Поддержки баз данных, за исключением SQLite.
• Возможности добавлять свой домен.
• Возможности скачивать загруженные данные.
• Возможности добавлять переменные и секреты.
• Возможности ставить проект на паузу
• Возможности развертывать проекты из графического интерфейса
• CLI

Как можно убедиться, на момент старта у нас отсутствовало почти все из полезного функционала. Но нам помог наш основной конкурент — Heroku. Они закрыли бесплатные тарифы 28 ноября 2022 (через пару недель после нашего старта), а оплатить российской картой их было нельзя. Плюс к этому, мы объявили, что работаем бесплатно в рамках бета-теста. Это помогло привлечь некоторое количество пользователей, ищущих замену Heroku и готовых смириться с отсутствием гарантий в рамках бета-теста.

Правильно ли мы сделали, что запустились со столь сырым продуктом? Мы в команде до сих пор спорим на этот счет, но я считаю, что да. Это позволило поймать момент перехода пользователей от Heroku и получить обратную связь, чтобы понять как развивать сервис.

Первые сложности
Первое, с чем мы столкнулись, — это тот факт, что без документации и логов пользователи испытывают некоторые сложности с развертыванием (мягко говоря). Но это было не так сложно исправить: мы написали на коленке за несколько дней свой стриминг логов и пару страниц документации. Правда, логи работали нестабильно, с ужасными задержками (задержка отображения остается по сей день, но уже минимальная), да и документация была самая базовая. Но это лучше чем ничего.

Пока у нас были только единичные пользователи, мы еще не осознавали проблем, возникающих с ростом нагрузки. И тут наступил день Х: 29 ноября Heroku закрыл бесплатные тарифы, и мы запустили рекламу по этому поводу. В итоге, к нам пришло больше пользователей, чем мы могли “вывезти”.

Сначала мы уперлись в лимит по выписке SSL-сертификатов Let’s Encrypt. Проблема решилась достаточно просто: купили Wildcard и немного переделали логику генерации внутренних доменов.

Далее наши сервисы начали по очереди отказывать. Отваливалось буквально все. Пришлось в экстренном порядке все переписывать. Ближе к концу декабря мы поправили почти все и даже успели выпустить функционал переменных и секретов.

Нокаут
На новогодние праздники мы ушли с почти чистой совестью. Сервис работал, и первые пользователи разместили свои проекты. Но 3 января 2022 утром я увидел, что ничего не работает.

Попробовали восстановить работоспособность разными способами, но ничего не получалось. Уже постфактум можно сказать, что наложилось сразу несколько серьезных проблем, основной из которых было потеря нами etcd.

Почему это произошло?
Мы развернули сервис на bare-metal, а именно, на арендованных серверах у одного известного провайдера. Сделано это было из-за того, что, как показывали расчеты, при использовании managed-инфраструктуры (kubernetes в облаке и т.д.) могла не сойтись экономика проекта. Согласитесь, странно делать бизнес, отдавая всю выручку облачному провайдеру.

Однако на этих арендованных серверах были более медленные диски, чем требуется, из-за чего возникла критическая ошибка. Но главная ошибка была в том, что не стоит все делать на собственной инфраструктуре, если у вас нет человеческого ресурса ее качественно администрировать и сразу правильно настроить. А с этим ресурсом у нас была проблема: после запуска почти все силы были брошены на “тушение пожаров”, а все, что осталось, мы направили на доработку функционала.

Мы почти сразу поняли, что если мы просто заново развернем сервис, то получим ту же проблему с потерей данных и пользователей в самое ближайшее время. Стали пробовать переписать сервис так, чтобы новая архитектура была более устойчива к подобным инцидентам и содержала меньше “узких” мест. Но по самым разным причинам что-то не получалось. Время шло, а мы так и не могли запуститься. Особенно мучительно было оттого, что некоторые пользователи успели запустить у нас свои проекты, и теперь они не работали.

В итоге было принято волевое решение запустить наш сервис поверх managed-облака одного из провайдеров и править архитектуру уже после этого.

Результат метаний — большой даунтайм в несколько недель, что неприемлемо даже для бета-теста. Мы сохранили данные проектов пользователей, но за время даунтайма большинство первых клиентов ушли, и мы их понимаем. Это было самое тяжелое время для нас.

Но мы решили “вернуться в игру”, перезапуститься, и продолжить бета-тест. И, на удивление, обнаружили, что экономика проекта может сходиться даже при использовании мощностей облачного провайдера, хотя и не так хорошо, как на своих серверах.

Жаркие майские
За месяцы после перезапуска мы повысили стабильность работы и немного улучшили функционал. А затем наступили майские праздники. Ночью и утром 9 мая стали поступать сообщения от пользователей, что не работает развертывание новых проектов. Данные мониторинга тоже указывали на катастрофу.

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

И хотя большинство пользователей не заметили даунтайма и их проекты продолжали работать, нам пришлось все майские внепланово все поднимать и восстанавливать.

Из этого мы извлекли два урока. Урок первый: даже на облачных провайдеров с громким именем нельзя полагаться на 100%. Урок второй: все нужно хранить на сетевых дисках с репликацией, полным покрытием бэкапами и так, чтобы восстановление не затрагивало работающие проекты.

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

Помните, как один облачный провайдер стер нам прод? Мы тоже помнили, и мигрировали на другого провайдера через несколько месяцев. Не буду говорить, что новый провайдер работает без нареканий. Бывают проблемы с сетью, есть подозрения на избыточную переподписку по CPU и другие шероховатости, но, в целом, все работает.

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

Мы доработали некоторый функционал, закончили режим бета-теста, начислили пользователям обещанный стартовый баланс и включили биллинг.

Финансовые показатели раскрывать не буду, только отмечу, что пока выручка не очень большая, но показывает планомерный рост.

Работа над ошибками
Даже когда мы перешли на платный режим для пользователей, было понятно, что сервис еще очень “сырой”. Было много мелких багов, которые затрудняли развертывание проектов и делали неудобным процесс эксплуатации.

Где-то не загружались все файлы, где-то не удалялись артефакты, где-то сам интерфейс вводил в заблуждение.

И основная работа в сентябре-декабре была как раз посвящена борьбе с ошибками, мешающими пользователям. Работа еще не закончена, но уже сейчас мы видим, что в два раза сократился отток и в два раза выросла конверсия в развертывания.

Вывод — качество продукта важно, и часто качество кроется в мелочах.

Про поиски венчурных инвесторов
Сразу скажу, что от внешних инвестиций наш проект зависит не сильно. Изначально был расчет на то, что мы будем тратить не больше, чем получается зарабатывать на прошлых проектах. Это хоть и скромный ресурс, но достаточно устойчивая стратегия.

Но быстро стало понятно, что если мы хотим не просто выживать, но и активно развиваться, дополнительный капитал будет полезен.

Про венчурных инвесторов из России и опыт общения с ними можно писать отдельную статью, в которой будут забавные истории. Главный вывод: венчурного капитала в России практически нет, но ключевое слово тут — практически.

Пару раз были просто смешные (я бы даже сказал, немного оскорбительные) предложения, сводящиеся к следующей фразе: “Давайте вы нам отдадите компанию, а мы команде будем зарплаты платить…”. Даже интересно, людям не кажется, что если бы основатели хотели получать зарплату, они бы … устроились на работу? Логика таких инвесторов заключается в принципе “а вдруг прокатит”.

Но это скорее исключения. Чаще встречается примерно такая постановка вопроса: “Покажите нам выручку и ее динамику, которая гарантирует возврат наших инвестиций через N лет дивидендами”. И тут я понимаю, что люди ищут дивидендный бизнес, и в этом нет ничего плохого. Но это никак нельзя назвать венчурными инвестициями. И если есть “гарантии” возврата через дивиденды, то в таком случае основателю выгоднее брать обычный банковский кредит, чем отдавать кому-либо долю в бизнесе. Еще раз повторю, что в такой модели нет ничего плохого, только не нужно при этом называть себя венчурным фондом.

При этом на рынке есть профессионалы, с которыми приятно и полезно общаться. Они понимают бизнес и технологии и грамотно подходят к стратегии.

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

Вывод: если поставить себе такую цель, то даже в текущих условиях “венчурной зимы” инвестиции найти можно.

Текущий статус
Сервис уже полгода работает в штатном режиме без глобальных сбоев. Случаются лишь небольшие неполадки, например, неработающий биллинг или временные проблемы с сетью на одной ноде. Добавили поддержку баз данных, возможность загружать проект прямо из интерфейса, поддержку доменов и другой полезный функционал.

Для стабильности работы мы сделали следующее. И возможно, вам это может пригодиться в ваших проектах.

• Разнесли ноды с нашими сервисами и с проектами пользователей в отдельные группы. Это повысило безопасность и позволило избежать случаев, когда из-за проблем на одной пользовательской ноде, вызванных проектом конкретного пользователя, страдает весь сервис.
• Допустимая нагрузка по CPU на ноде должна быть, в среднем, не выше 50%, с редкими небольшими превышениями. Если у вас процессор будет почти полностью загружен, его производительность будет ухудшаться не прямо пропорционально уровню загрузки. И все проекты, размещенные на ноде, будут очень медленно работать.
• Стали использовать сетевые диски везде, где это возможно. Да, присутствует небольшая latency, но для наших задач задержка оказалась некритичной. При этом сетевые диски проще реплицировать, масштабировать и покрывать бэкапами.
• Использование постоянного мониторинга. Для себя мы выбрали стек продуктов Grafana + OpenSearch.
• Перевели все на очень быстрые SSD диски. Диск может быть узким местом, и практика показывает, что тут лучше не экономить.
• Изменили архитектуру, чтобы такие процессы, как стриминг логов и т.д. не перегружали систему.
• Добавили удаление неиспользуемых ингресс-контроллеров, что важно для разгрузки Kubernetes.
• Помимо реплицирования дисков, покрыли все бэкапами, так как потеря данных — более серьезная проблема, чем кратковременная недоступность сервиса. И реализовали сохранение копии самых ценных данных у независимого провайдера в другом ЦОДе.

Наши ошибки, и что сделать вам, чтобы их не повторить

• Попытка реализации сложного проекта полностью на своей инфраструктуре. Если вы развиваете проект на свои деньги и у вас нет отдельной команды опытных инфраструктурных инженеров, воспользуйтесь услугами одного из публичных облаков. Это будет дешевле, чем отвлекать всю команду разработки на администрирование и восстановление сервиса.
• Полное доверие облачному провайдеру, когда вы решили отказаться от части своей инфраструктуры по п.1. Надо помнить, что проблемы облачного провайдера — это ваши проблемы, а ваши проблемы — это ваши проблемы. Даже самые именитые компании не гарантируют вам почти ничего, даже при SLA. Выход — полное многократное покрытие бэкапами, которые хранятся в разных ЦОДах и у разных провайдеров, резервирование и продуманная архитектура проекта, рассчитанная на самое худшее. Детали того, как мы повышали надежность архитектуры, достойны отдельной технической статьи, и мы ее обязательно напишем в ближайшее время.
• Планирование бюджета. Изначально мы хотели закончить бета-тест и включить монетизацию в январе 2022, но продлили тестовый режим почти до августа. Если бы не строгий контроль расходов, я бы писал не эту статью, а про “полученный бесценный опыт закрытого бизнеса”. И нужно учитывать, что в России венчурных денег почти нет. Большинство тех, кто называет себя венчурными инвесторами, требуют гарантий дивидендов, которые за N времени отобьют вложения. Это противоречит самой сути высокорисковых инвестиций. Поэтому надо сразу считать деньги так, чтобы вам хватило до точки безубыточности. Но если получится привлечь инвестиции, будет только лучше.
• Неполное покрытие бэкапами. Либо невозможность их применения из-за нарушения согласованности пользовательских данных, когда часть системы продолжила работать и генерировать новые данные. Мало все покрыть бэкапами, нужно еще иметь возможность их применить.
• Старт с маленьким бюджетом. Если у вас сложный продукт, он будет ломаться, а первое время — ломаться часто. И если у вас маленькая команда, то команда будет заниматься не разработкой функционала, а “тушением пожаров”, администрированием инфраструктуры и написанием извинений недовольным пользователям в поддержке. И тут совет простой — либо переплачивать за сторонние managed-решения, либо расширять команду.

Планы на будущее
Нам еще предстоит большой путь для того, чтобы сделать такое облако, которое мы задумали. Это и новые продукты в рамках текущего сервиса (тестовые среды, мониторинг, кластеры баз данных и т.д.), и B2B версия, и, главное, дальнейшее повышение уровня стабильности и удобства сервиса.

Мы планируем расширять команду и достаточно оптимистично смотрим в будущее. Если вам нужно облако с функционалом простого развертывания, регистрируйтесь в нашем сервисе, а если есть вопросы, пишите мне на почту kkosolapov@amvera.ru

amvera.ru/cloud
https://id.amvera.ru/auth/