Лого vc.ru

Wodby — платформа для разворачивания сайта на сервере в один клик

Wodby — платформа для разворачивания сайта на сервере в один клик

Сегодня в рубрике «Стартапы» — сервис Wodby, который помогает развернуть сайт в один клик на любой сервер. Передаём микрофон.

Меня зовут Чингис Санданов, мне 27 лет. Я сооснователь и руководитель компании Wodby.

Это мой первый собственный стартап, до этого у меня был пятилетний опыт работы в компании i20 (тоже своего рода стартап), где я начинал работать как junior developer, а заканчивал топ-менеджером.

За эти 5 лет я успел поучаствовать в конкурсе «Стартовый Капитал» на «Дожде», создать с партнерами Сибирское друпал комьюнити, выиграть тендер для World Bank Group, перевести все сайты правительства Новосибирской области с MS SharePoint на Drupal и даже создать фотовидеостудию с циклорамой.

Но ближе к сути.

Wodby — это платформа, которая помогает вам развернуть ваше веб-приложение (сайт — это частный случай) на любой сервер за пару минут вместо часов, если бы вы это делали вручную.
Обычно, когда вы разворачиваете приложение, вам приходится устанавливать и конфигурировать множество зависимостей, а также инфраструктуру для последующей непрерывной интеграции (CI/CD). А это отдельная специализация, которая называется DevOps (development + operations), хотя надо заметить, что этот термин имеет очень широкое значение.

Крупные компании обычно имеют своих DevOps-инженеров, а иногда даже DevOps-команды и отделы. В компаниях поменьше всем этим занимаются либо сами разработчики, которые плохо секут в конфигурациях, или сисадмины (operations guy), которые плохо знают платформу, для которой они это конфигурируют. Наша задача — заменить весь этот сложный DevOps-процесс с помощью нашей NoOps-платформы (no operations).

Wodby не является хостинг-провайдером, это платформа (Platform as a Service), которая выступает прослойкой между вашими веб-приложениями и сервером. Платформа работает следующим образом: подключаете свой сервер (с помощью одной команды в терминале) к нашей платформе и после разворачиваете ваши приложения через нашу панель управления.

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

Пока мы поддерживаем только Drupal и WordPress. В ближайших планах поддержка NodeJS, Ruby on Rails и Django. В будущем, мы позволим вам развернуть любой тип приложения, стэк контейнеров для которого вы сможете собрать вручную через интерфейс, но пока мы фокусируемся только на CMS и фреймворках.

У нас распределенная команда: я сам в Калифорнии, где участвую в программе акселерации от Plug&Play, а мой партнёр с R&D-командой находятся в Новосибирске.

Кстати, горячо рекомендую Кремниевую долину для стартапов, тут совершенно другой уровень и потрясающие люди. Правда, надо знать, куда идти и что делать.

Сейчас мы быстро растем и ведем переговоры с потенциальными инвесторами (скоро у нас demo day).


Возвращаем слово читателям.

Хотите получить слово и рассказать о своем стартапе? Добро пожаловать за трибуну.

Теги
Статьи по теме
Анонс рубрики: «Стартапы»
Ускоряем рост, открываем новые рынки. Заявки в Акселератор — до 18 октября. 🏁 Подать заявку

Регулярно разворачиваю сайты на разных cms и не вижу проблемы в том, чтобы сконфигурировать сервер под задачи и движок, который выбрал клиент. На мой взгляд потребность в таком сервисе "высосана из пальца".

Не понятно, кто будет за это платить? У всех нормальных хостеров уже лет 5 существуют скрипты для подготовки окружения под cms в 1 клик.

Написать набор скриптов и упаковать это в веб-интерфейс только пол дела. Как Вы это будете монетизировать?

Конфигурировать можно по-разному, к примеру собрать Drupal с правильно сконфигурированным Varnish/Redis/MariaDB/Nginx не так уже просто. Одно дело когда трафик пару десятков человек в день, другое дело когда это десятки тысяч.

Также, более подробный список фич я указал ниже.

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

>>другое дело когда это десятки тысяч.

Когда наступает такой момент, они наймут сисадмина, который настроек сервер.

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

Возможно я вам открою глаза этой фразой: "Клиенту плевать, что внутри их сайта, какая там технология и как там всё круто настроено ему важна конверсия и обращения клиентов с сайта или с группы сайтов".

0

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

Эммм... А десятки тысяч в день - это проблема?! Есть сервак с такой нагрузкой, пока ни разу ничего не пришлось настраивать, до сих понятия не имею, что, как и зачем ngnix надо менять.

0

Видимо у вас уже все хорошо настроено. А вы используете какой-то кэш для анонимных посетителей, типа varnish?

0

Как я уже писал, я понятия не имею, что там в настройках. Выделенный сервак от FastVPS с ятак понимаю дефолтными настройками. А, вспомнил! Самое главное - никакого друпала или WP ))

Если они в один клик будут разворачивать node js или руби или питон или ионик в связке с кордовой - я буду платить за этот сервис. вордпресс пока что и сам могу развернуть из хостинг панели))

Любой нормальный хостер это делает бесплатно.
Нам даже с руби помогали, хотя это вообще не их специализация.

0

Аналогично с Джиной. Прям в веб админке в пару кликов разворачивается всё.

0

Расписал ниже все фичи, мы не только про первоначальную установку

0

Интересно, а как это будет работать на сайты созданные на конструкторах? У меня, допустим все сайты собраны на профипейджес

Насколько я понимаю профипейджс это закрытый сервис для сборки сайтов со своим собственным конструктором. Вряд ли они предоставляют доступ к серверу, где все это размещено. Так что ответ – скорее всего никак не будет работать.

0

А когда RoR будет доступен?

А chef recipe нынче не модно уже?

Chef/Puppet/Ansible отличные инструменты для DevOps инженеров. Но мы считаем, что разработчику ни к чему изучать еще дополнительные инструменты. Пусть занимается разработкой. Ну и к тому же мы не только про установку.

docker это немного другой угол зрения, отличный от чифа/паппета/ансибла.

0

Хм, подумал про meteorJS, и вспомнил про mup. Один раз заполняешь конфиг файл, запускаешь команду mup Setup (настраивает сервер ставит нужный софт), mup deploy (выгружает билд на сервак и запускает)

0

А умеет ли mup поднимать новый изолированный инстанс приложения?

0

А чем django на Digital Ocean от Woodby будет отличаться от гарантированно работающих собственных сборок django от самой Digital Ocean, разворачиваемых буквально за две минуты? Или речь всё-таки не про сервера у серьёзных хостеров, а про отдельные машинки, на которых надо развернуть фреймворк? Вряд ли у хозяев отдельных машинок не будет маломальски-грамотного админа, способного развернуть фреймворк. Опять не сходится.

0

Расписал подробнее ниже.

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

– Развертка инстансов на каждое приложение: Dev > Stage > Prod с инструментами деплоя
– Бэкапы файлов и базы
– Автоматическое применение обновлений безопасности приложения (например у Drupal часто выходят обновления ядра и модулей) и зависимостей
– Удаленное рабочее место (вместо конфигурации окружения локально, просто подключаешься к удаленному инстансу из IDE по SFTP)
– Инструменты continuous delivery (деплой через билды с последующим запуском сценария)
– Специализированные инструменты (например для друпала это drush)
– Управление кэшами
– Управление скейлом (горизонтальный, вертикальный)
– Управление командой (кто имеет какой доступ к какому приложению)
– Мониторинг приложения (контейнеров)
– Просмотр логов
– Сторонние интеграция с Slack/GitHub/BitBucket/Shippable/

0

Мы сами очень любим ансибл и даже кое-где его используем. Но сравнивать нашу платформу с orchestration tool не совсем корректно, выше уже отвечал.

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

0

Под любым сервером имеются ввиду в том числе и облачные провайдеры, например у нас есть хорошая интеграция с DigitalOcean.

В чем отличие от cloud66?

0

В отличие в том, что мы делаем NoOps платформу для разработчиков, с высоким уровнем абстракции. А они делают инструмент для DevOps инженеров. Ну и насколько я знаю они переключились на контейнеры не так давно, так что можно сказать мы в одно время стартанули.

Мне нравится, сделай ещё поддержку jvm и интеграцию со вскими CircleCI. :) И панельку интерактивную, что бы элементы кубиками перетаскивать.

0

Как мне кажется, лучше чем vagrant в данной сфере придумать сложно.
Надеюсь Ваш проект займёт своё место на данном рынке

Вот тут есть хороший ответ про то, когда надо использовать вагрант, а когда докер stackoverflow.com/questions/16647069/should-i-use-vagrant-or-docker-io-for-creating-an-isolated-environment
если коротко, то преимущество докера в изоляции, что для dev > stage > prod воркфлоу необходимо

0

а что мешает разработчику самому засунуть парой команд приложение в контейнер и отправить его запускаться хоть куда через docker-machine (в дигитал океан и еще кучу облаков)

0

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

Ведь было время когда программисты не ставили LAMP из репозитория, а компилили все сами, мол я лучше знаю какие экстеншены мне нужны. Но время идет: все усложняется, разделения труда углубляется, уже невозможно все делать самому вручную. Life is too short to build your own infrastructure.

Возможно, для контор которые потоково пилят друпал-проекты это удобно - эдакий сервис собирающий все в одном месте и не нужен файлик в котором расписаны все доступы. Я к тому, что я способен поверить, что devops-процессы в drupal-like среде однородны.

Но меня очень смущает привлечение RoR/Django. Я не devops-специалист, так, только начинаю, но мне видится, что у серьезного RoR-проекта всегда критично много специфики. Не в том, _как_ надо сделать, а в том _что_ надо сделать в плане devops.

1) Например, локальный запуск проекта - vagrant или docker конфиг вы будете генерировать? Ибо без этого это уже урезанный devops - у разработчика должно быть идентичное серверам окружение.

2) Heroku абстрагирован настолько, что мне это порой неудобно. Приходится идти на некоторую магию, чтобы запилить хитрую JVM-поделку на Scala слева от проекта. В RoR "мультиязычность" среди крупных проектов не редкость. А чем выше абстракция - тем сложнее подобное проворачивать. Или вы не нацелены на столь специфичные проекты?

3) Для небольших же проектов - heroku прост как два пальца. Любой адекватный разработчик разберется в нем не более чем за 2-3 часа. А потом git push и радуйся жизни и клевому деплою. Я к тому, что для адекватного разработчика heroku прост. И нет смысла делать его проще. Поэтому я не понимаю - что нового вы хотите привнести?

In suma, убедите меня использовать ваш продукт. Я в него не верю. Я считаю, что крупным проектам и претендующим на профессионализм конторам в RoR-среде жизненно необходимо взращивать своего devops-специалиста.

Спасибо за развернутый фидбек.

Безусловно есть множество вопросов, которые нам прийдется решать по ходу развития продукта и да, я согласен, что у Django/RoR есть своя специфика.

Если смотреть глобально на то, куда движется вся веб-разработка, то очевидно, что она будет становится сложнее и сложнее, вследствие чего будет происходить более глубокое разделение труда и специализация. Как например 5 лет назад не было как такового разделения на front-end/back-end разработчиков. Как решить проблему сложности? Через стандартизацию, ее будет становиться больше и больше, и людям нужны будут качественные понятные инструменты для управления этим все более стандартизованным процессом.

Вместе с тем сложнее будет становиться и DevOps, через пару-тройку лет разработчики даже не будут суваться в эту часть, также как например бэк-энд разработчик не лезет править стили верстальщика. Я вижу, что множество задач DevOps вполне можно решить с помощью cloud infrastructure services и огромный толчок в этом направлении дает контейнерная виртуализация, которая позволяет разделить провайдеров вычислительных мощностей (или IaaS по типу AWS/GCP) от cloud infrastructure services за счет агностичности контейнеров. В общем, рынок будет трансформироваться, развитие провайдеров вычислительных мощностей скорее всего пойдет в сторону bare metal (посмотрите на rackspace), а cloud infrastructure services очевидно будут основаны на контейнерной виртуализации. За последний год-два появилось множество container-based cloud infrastructure стартапов, рынок зарождается.

Теперь отвечая более конкретно на ваши вопросы:

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

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

3. Думаю ответил в предыдущем посте, разница между нами и heroku концептуальна. Ну и непонятно, что вы имеете ввиду под адекватными разработчиками. Для некоторых адекватных разработчиков vim и arch linux тоже просты.

In suma, я ничего о вас не знаю, возможно наш продукт конкретно для вас никакой ценности не принесет, поэтому убеждать бессмысленно. Согласен, что с определенного размера наличие in-house DevOps специалиста возможно необходимо просто чтобы минимизировать риски, но наличие оного не означает, что нет смысла использовать DevOps/NoOps платформы, скорее наоборот.

0

Спасибо за ответ. Я понял ход ваших мыслей и то, что на основе этой статьи рано судить о применимости к RoR/Django - вам предстоит еще очень много работы и изменений. Будет интересно посмотреть на это в действии.

0

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

"перевести все сайты правительства Новосибирской области с MS SharePoint на Drupal"
Боже, а напишите большой пост, нахрена вы это сделали?

0

Если коротко, то мы запилили мульти-сайтинговую платформу на друпале, которая позволяет поднимать новый сайт для органов власти за пару минут с готовым шаблоном и если вдруг какому-то органу муниципального управления понадобится сайт (а таких к удивлению много), то они не размещают закупку на создание сайта (как в большинстве регионах), а обращаются в департамент информатизации и те поднимают им готовый сайт за пару минут и сажают на домен *.nso.ru

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

В итоге на нашей платформе крутится более 70 сайтов.

0

Если коротко, все так делают, только без Друпала вполне обходятся.

0

В чем отличие от Heroku?

0

интересный сервис, молодцы.

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

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

успехов и удач!

Прямой эфир
Команда калифорнийского проекта
оказалась нейронной сетью
Подписаться на push-уведомления