Возможно, у вас была (или есть) потребность развернуть свой IT-проект, будь то простой бот, сайт, приложение или сложный высоконагруженный сервис. И, возможно, вы пользовались для этого AWS, MS Azure или другими провайдерами публичных облаков. 

Тогда вы знаете, что для использования таких облачных решений нужно иметь весьма «глубокие карманы». Так, чтобы развернуть обычный сервис распознавания речи на 20 потоков вы заплатите Яндексу за виртуальные машины и за СУБД 43500 руб. в месяц (расчет на основе нашего ASR). И это еще достаточно простой, пусть и требовательный к CPU сервис.  Кажется, облачные услуги должны быть более доступны с финансовой точки зрения. 

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

Мысль о том, чтобы сделать свое облако для бизнеса, появилась давно, но до определенного момента конкурировать с IT-гигантами казалось сумасшествием. Все изменилось в феврале-марте 2022 г.  Стало понятно, что с рынка уходят, как минимум, западные конкуренты, и на рынке остаются компании пусть и сильные, но не закрывающие все ниши. Возникла идея попытаться оседлать тренд импортозамещения. План выглядел привлекательно: делать новый, амбициозный проект на рынке PaaS, который растет более чем на 20% в год, в том числе заменяя классические ЦОДы, и с которого, при этом, уходит часть конкурентов. 

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

Итоги CustDev (иногда очевидные, но, тем не менее, полезные): 

Вопрос CustDev №1. Почему программисты выбирают облака, а не железные серверы или виртуальные машины? 

Основной ответ респондентов - не нужно самостоятельно администрировать СУБД, серверы и т.д.. Это высвобождает работу квалифицированных разработчиков. Люди хотят инвестировать свой ресурс в работу над продуктом, а не в администрирование среды для него. 

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

Вопрос CustDev №2. По каким критериям выбирают конкретное облако? 

Самое важное - наличие всех нужных сервисов.   

Второй фактор - цена. Потребители при выборе облака сравнивают решения между собой по цене. Также важно, чтобы образование было прозрачным. Встретился комментарий, что у AWS непрозрачное ценообразование. 

Третье - совместимость. Важно, чтобы все корпоративные сервисы можно было развернуть в одной облачной инфраструктуре и не пришлось придумывать «костыли».

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

Вопрос CustDev №3. Сервисы, которые точно нужны

Наши собеседники упомянули виртуальные машины, хранилище, СУБД (в т.ч. MongoDB) как сервис, DNS, очереди, Kubernetes. Упоминались и более редкие кейсы, например, различная идентификация/аутентификация. 

Вопрос CustDev №4. Для каких целей используют

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

Вопрос CustDev №5. Особенности дистрибуции

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

После CustDev предстояло выбрать технологический стек. Самым многообещающим нам показался проект с открытым исходным кодом – OpenStack. Но не все, что кажется оптимальным вначале, таким является впоследствии.

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

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

Также нужно помнить, что построив решение на OpenStack, вы становитесь от него зависимым. Траектория вашего развития будет опираться на парадигму развития самого OpenStack. А именно, вне зависимости от собственного видения системы придется использовать сервисы OpenStack. Если его поддержка сообществом прекратится, придется либо развивать и поддерживать данные сервисы самостоятельно, либо переходить на другую платформу. Хотя, с точки зрения функционала, OpeStack закрывает 90% задач для публичного облака. 

В итоге, от OpenStack мы решили отказаться, как бы больно это ни было.  

Обсудив сложившуюся ситуацию -  у нас фактически нет готового open source фундамента для построения публичного облака - мы решили, что нужно зайти на рынок не настолько «в лоб». Классические облака – это подрывная инновация под ЦОДы с собственными железными серверами. А что, если попробовать для начала «подорвать» рынок традиционного хостинга виртуальных машин? Да, чек небольшой, но и потенциальных клиентов больше. Плюс, можно сделать облачное решение действительно доступным по деньгам для пользователей!

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

И, действительно, у контейнеров есть ряд достоинств: 

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

- Надежность. Если ваш контейнер «упадет», система оркестрации контейнеров Kubernetes его просто автоматически перезапустит, а если вы используете дублирование, то и вовсе не заметите отказа в работе ваших приложений.  Это справедливо и для виртуальных машин, но с высокой вероятностью вам придется перезапускать весь сервис, а не отдельный модуль.

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

Учитывая плюсы такого подхода и собственный опыт использования облачных сервисов, было решено сделать облако на основе контейнеров.

К счастью, сейчас прошли те времена, когда Heroku писали свое собственное решение для контейнеризации. В качестве базы были выбраны широкоизвестные Docker и Kubernetes.

Дополнительно, для повышения удобства сервиса и пользовательского опыта, был реализован функционал деплоя путем простого push в мастер выделенного GIT-репозитория (да, эту механику мы подсмотрели у Heroku). Ведь разработчикам важно сосредоточиться на коде, а не на администрировании инфраструктуры.

В результате, к октябрю 2022 г. мы сделали облако на основе контейнеров, в котором легко масштабировать инфраструктуру, а также есть возможность накатывать обновления через push в GIT-репозиторий. Стоит оговориться, что пока у нас реализована только базовая часть, и облако подойдет не для любых проектов. А именно, если у вас сложный проект, которому нужна СУБД в кластере – пока это не к нам. Но если вам нужно разместить сайт, бот, небольшое приложение или что-то подобное, что можно обернуть в Docker-контейнер, то решение может вам подойти. 

P.S. Приглашаем желающих поучаствовать в закрытом бета-тесте нашей облачной платформы Amvera, который мы проводим с октября по декабрь 2022 г. Это бесплатно. Для участия в бесплатном бета-тесте вам необходимо зарегистрироваться в личном кабинете Amvera. После регистрации будет автоматически начислена 1 т.р. на использование сервиса. Если у вас высоконагруженный проект, напишите нам, и мы в рамках бета-теста выделим дополнительные бесплатные вычислительные мощности. Обещаем, что после завершения бета-теста (январь 2023 г.), сервис будет не дороже простой виртуальной машины, если вы захотите продолжить его использование. 

Ссылка на бесплатные вычислительные мощности для вашего проекта: https://amvera.ru/betatest

Будем рады, если оставите обратную связь и, тем самым, поможете сделать действительно полезный и удобный сервис!