Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Как построить PaaS-решение: от идеи до первого пользователя

Привет! Я Георгий Трегубов, руководитель отдела развития продуктов облачного оператора GigaCloud. На днях начал пересматривать сериал Silicon Valley. В последней серии первого сезона есть легендарная сцена, в которой главному герою приходит продуктовая идея, во время абсурдного разговора его команды. Воодушевленный этой историей, я решил написать сценарий собственного мини-сериала. Ведь в марте этого года мы запустили важный для украинского рынка продукт. И он тоже родился в диалогах.

В семи эпизодах я расскажу, как мы в GigaCloud создали первое украинское PaaS-решение ― S-Cloud 2.0. И да, я готов к вашему сарказму. PaaS — это не только у AWS. Украинские облачные операторы существуют, а разработчики активно используют наше решение.

Эпизод 1. One Way or Another

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

По классике есть три стратегии: низкой цены, дифференциации и ниши. Низкая цена уже перестала работать. Стратегия ниши нам не подходила, потому что рынок облачных сервисов в Украине относительно небольшой. На тот момент он составлял около 40 млн долларов. Для сравнения: в соседней Польше рынок был в 15 раз больше. Чтобы успешно строить доходный бизнес и конкурировать, мы не могли ограничивать аудиторию. В итоге выбрали стратегию дифференциации. Простыми словами, стратегия дифференциации ― это когда ты делаешь ту же задачу, что и другие компании, но другим способом. В нашем случае это другое облако. А другое облако ― другой гипервизор.

Эпизод 2. Turn on the light

Мы поняли, что нам нужно строить новое облако на другом гипервизоре. Следующий этап ― решить, на каком именно. На тот момент в нашем продуктовом портфеле было уже облако, построенное на OpenStack с KVM ― S-Cloud. То, что это динамично развивающаяся платформа с широкими возможностями, а наши технические специалисты умеют с ней работать, стало главным фактором при выборе гипервизора. Опыт работы с оpen-source решениями ― ключевой момент, поскольку у них нет вендорной поддержки.

Эпизод 3. Scoring

На одной из рабочих встреч, на которой присутствовали специалисты отдела R&D, эксплуатации, Pre-sale Manager и я как Product Manager, мы провели scoring. Собрали все функции нашего флагмана публичного облака на VMware и облака на OpenStack и выделили самые необходимые, которые должны быть реализованы в новом продукте. Те фичи, которые набрали наибольшее количество баллов, взяли в разработку первыми. И сделали минимально жизнеспособный продукт (MVP).

Эпизод 4. Search

После этого мы разбились на команды и начали искать product-market fit для нового облака. Оно должно было вписаться в наш продуктовый портфель и при этом не повлиять на продажу публичного и частного облака. В процессе поиска мы столкнулись с двумя историями.

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

Также обнаружили, что 70% контрактов у нас не доходили до реального проекта и внедрения на этапе цены. Заказчикам нравилось публичное облако на VMware, но когда они получали коммерческое предложение и видели цену, оставались на собственном «железе» или уходили к конкурентам.

С одной стороны, этот факт сбивал нас с толку, поскольку нужно было сделать функциональный технологичный сервис и одновременно где-то ужиматься в себестоимости. Но с другой, у нас появился шанс сегментировать рынок и выделить тех заказчиков, для которых VMware не в приоритете. При этом создать облако, которые бы решило запросы пользователей. И тут у нас родилась формулировка: «Для тех, кому не нужна „варя“ и КСЗИ, а функционала S-Cloud слишком мало».

Мы получили от рынка примерную ценовую оценку и начали думать, как сделать сервис функциональным, но при этом более доступным.

Эпизод 5. And again the brainstorm

Как известно, истина рождается в дискуссии. В итоге мы пришли к выводу, что нам хватит экономии на роялти. Поскольку OpenStack и KVM ― оpen source решения, а значит нет необходимости платить вендору за использование его программных продуктов. Это окупает часть себестоимости серверов.

На оборудовании же решили не экономить. И на это есть две причины. Во-первых, чтобы упростить обслуживание и улучшить надежность облака. Мы используем такие же сервера, как и в публичном облаке на «варе» и частных облаках. Но есть одно отличие. Мы построили хранилища JBOD (Just Bunch Of Disks) на Ceph, а не на выделенных СХД. Это шасси, в которое помещается большое количество дисков, два контроллера для надежности и Ceph ― программно-определяемое хранилище, которое обеспечивает резервирование данных и устойчивость к поломкам. Когда пользователь записывает информацию, Ceph ее дублирует (делает несколько копий), фрагментирует и расписывает частями на разные диски. Если какой-то диск перестает работать, хранилище восстанавливает потерянные фрагменты с других.

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

Эпизод 6. Time to test

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

Тестирование проходило следующим образом. Если какую-то функцию партнеры не находили, мы писали инструкцию, отдавали ее и смотрели на их реакцию. Если все шло хорошо, делали документацию, если по-прежнему у партнеров возникали трудности, то функцию либо куда-то переносили, либо переделывали.

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

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

Наш архитектор OpenStack вручную переписал панель Horizon. Сделал так, чтобы функции облака были доступны не только через API или консоль, но и в графическом интерфейсе. Благодаря тому, что наш архитектор изменил панель и доработал ее, любой админ-линуксоид сможет легко с ней работать.

Именно благодаря тестированию продукт и приобрёл финальный облик.

Эпизод 7. Day X

3 марта 2021 года состоялся релиз облака S-Cloud 2.0, которое мы с уверенностью называем первым украинским PaaS-решением. Оно состояло из виртуальных машин, инфраструктуры для запуска приложений, виртуального маршрутизатора с VPN-сервером и возможностью объединения виртуальных машин во внутренние сети, балансировщика сетевых соединений, запуска нод с docker-контейнерами, Firewall и снепшотов.

После релиза сервиса наши специалисты отдела R&D добавили в него полноценные бекапы, софтовые роутеры (поскольку пользователям не хватало встроенных маршрутизаторов), оркестрацию и объектное хранилище.

Фактически мы используем ту же платформу, что и Amazon. Ресурс модернизации платформы большой, нам есть куда расти и над чем работать. В ближайших планах ― разработка базы данных как сервиса.

Conclusion

Мне кажется, что создание облака S-Cloud 2.0 напрашивалось уже давно. И его ждет большой успех, потому что это рабочая лошадь для среднего бизнеса. Крупный бизнес, который занимается микросервисами или платформенными сервисами по типу объектных хранилищ, также может использовать S-Cloud 2.0. Его главная фишка ― каждый может доработать платформу под себя и получить такой сайт или приложение, какое он хочет.

Удобство сервиса и возможность получить поддержку ― это важная составляющая при выборе облачной платформы. А для нас как облачного оператора ― возможность поддерживать и совершенствовать один бизнес-процесс на всех. Поэтому мы предоставляем техническую поддержку такого же уровня, как и для нашего флагмана публичного облака E-Cloud на VMware.

В 20-х годах Ford выпустил свой Ford Model T. Это был недорогой автомобиль, каждый американский рабочий мог накопить денег и купить его. При этом все автомобили этой модели были одинаковыми. Но, если посмотреть фото тех лет, можно увидеть массу модификаций Ford T: маленькие грузовички, автомобили с твёрдой или мягкой крышей всех возможных цветов. Причиной этому стало появление большого количества мастерских, которые зарабатывали на переделке стоковых машин под клиента. Ничего не напоминает?

В случае с облаком S-Cloud 2.0 у нас есть OpenStack и KVM. Разработчики смогут собрать под клиентов все, что нужно, используя этот базовый функционал.

Лучше один раз протестировать, чем сто раз прочитать девять тысяч знаков. На нашем сайте можно заказать бесплатный тест облака S-Cloud 2.0. Буду рад всем отзывам, а особенно конструктивным.

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Следующий текст не воспринимайте как хейт, просто отзыв.

NAME                                              STATUS   ROLES    AGE     VERSION
master.novalocal                                  Ready    master   8m57s   v1.16.2
node-f6d443v0gofyvkf0n0jllapely8a5u0f.novalocal   Ready    <none>   5m16s   v1.16.2

И это final версия которая уже год как дропнута, а 1.16.2 — я даже не знаю на сколько старая....

MINOR VERSION 	FINAL PATCH RELEASE 	EOL DATE 	NOTE
1.16 	                1.16.15 	                                2020-09-02

При обращении в саппорт — тикет, что специалист будет с 9 утра... Простите что?

Доброго дня.
Ваш запит було переадресовано на профільного фахівця.
З Вами зв'яжуться вранці з 9.00 для уточнення деталей. 

Если вы хотите хотя бы сравняться с Hetzner, то стоит иметь 24/7 поддержку техническую хотя бы по тому же email/text chat в кабинете. Конечно если речь идёт об Клиентах уровня VIP/etc то там есть гарячая линия, но простите — зачем мне в 5 утра или ночью звонить в датацентр, когда я могу сам решить вопрос, но кнопки удалить кластер нет, в документации этого нет. Только в средине файла pdf где-то указано, что там нужно отменить заказ... Он даже не гуглится этот текст, т.к. pdf содержимое Файла не идексируется. Дока должна быть публична и в html к.м.к.

За конструктив могу только поблагодарить :) У вас лично можно детали уточнить?

конечно, можно даже прям в линкедине, который в профиле

При всій повазі, ви все ж програєте по ціні з Hetzner Cloud, якщо не помиляюсь під капотом в них також OpenStack + Ceph. Хоча в цілому продукт класний, не вистачає технічний деталей, в ідеалі статті-гайда як наприклад на ansible або terraform розгорнути реальний проект

Це цілком можна виправити. Якщо ви зможете сказати яка реальна задача, якийсь плюс мінус типовий проект з якими ви працюєте, то ми залюбки напишемо як його можна розгорнути у нас.

PaaS — это

OpenShift
а

OpenStack

это IaaS
продакту, хотя бы базовую терминологию, стоило бы знать

До OpenShift нам тоже рукой подать. Партнерство с Red Hat у нас уже есть.

но второе не значит, что есть уже первое или я не прав?

Скажіть, яка у вас ціна на
— vps mem:512mb hdd:5gb network:1gbit 1core.
— 1Tb storage/mon

А також чи є у вас власний датацентр чи суто орендуєте?

Мовчить шото ТС. тому я нагуглив

vps mem:512mb hdd:5gb network:1gbit 1core.

По оптимістичному сценарію це буде коштувати ~$10 у гігаклауда)

1Tb storage/mon

А оце $36 !

Власний датацентр походу є. але в Україні і тільки.

Пока преимущественно тем, что дешевле

Що і де тут дешевше?

Якщо брати одну ВМ на півгіга то сенсу немає. Давайте спробуємо порахувати якийсь реалістичний запит. Я рахував пересічну конфігурацію для малого бізнесу — під 5 користувачів 1С: 2 ВМ з Windows: термінальний сервер та БД, 15 GB SSD,1 IP адреса, інтернет канал, і в мене вийшло 3300 у нас і приблизно така сама конфігурація на AWS — 6508 грн.
При чому для локального бізнесу зручніше оплачувати рахунки безналом в гривні, ніж платити на Амазон валютною карткою. Якщо я помиляюся і у нас вартість рішення буде вища — то це для мене цінна інформація.

Конкретизуйте свою конфігурацію за 3300грн.
2 ВМ з віндовс — це скільки cpu/ram/hdd? БД окремо чи на тому ж одному з вм? термінальний сервер — це рдп до тих двох вм?

А ще таке питання хоститься у вас дія чи ні?

Одна ВМ cpu 4 ram 50 SSD, друга з БД 4 cpu 8 ram 100 SSD. На першій термінуються клієнтські RDP сесії.
Дія хостить у нас один з двох майданчиків, які працюють active-active, але це приватна хмара, окрема.

1с вполне себе работает в браузере,а сервер на debian/centos + для терминального сервера давно уже многие использую Ubuntu Desktop linux/etc

а сравнивать себя и качество услуг с aws — к.м.к., пока рановато, т.к. по цена/качество/кол-во сервисов явно вы проигрываете

это я к тому, что ваш пример не совсем корректен и больше строится на стереотипах сетапов с 2015го года, хотя даже я в 2015 перевел 1с на linux полностью

дешевле чем у digitalocean\linode?

Проблема с украинскими хостинг/облачными сервисами в том, что серваки располагаются в Украине.

И тут даже хорошая «крыша» не особо решит (разве что, крышует Коломойский или Ахметов самолично).

Чем вы лучше AWS?

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

Звучит неплохо! А как у вас с поддержкой общественности? AWS выдает гранты $2000-$300 виртуальных кредитов для неприбыльных организаций. Есть ли у вас подобная услуга?

Прямо Charity as a Service нет, с общественностью мы обычно общаемся напрямую, и помогаем там где можем. Например, covid19.com.ua и vaccination.covid19.gov.ua хостятся у нас бесплатно, до победного конца.
А не общественным заказчикам, как и в AWS, всегда доступен триал на 2 недели. Ну или до победного, в особо сложных случаях.

Понятно. Только триал у AWS не 2 недели а 12 месяцев :)

Ну, у нас все же коммерческий заказчик более склонен взять всю инфраструктуру на 2-4 недели, а микрокусочек (как AWS 5 Гб S3) сервиса на год.

За 2-4 недели облако не протестировать, если это облако на не FTP для заливки сайта на хостинг в новой обвязке.

В целом да, но 9 из 10 заказчиков — это перенос в облако сайта, БД, бухгалтерии, ERP, и так далее. Более сложные проекты или более крупные заказчики тестятся до победного.

Картинки красивые — но конкретики мало :( Пока что я не понял чем ваше «облако» или PaaS-решение существенно отличается от того, что раньше называлось «хостинг»? Помимо возможности развернуть виртуалки — что еще есть интересного?
Ну и главное не написали: облака это про надежность — сколько у вас датацентров и где? Потому что если в Украине — то готовьтесь что СБУ обвинит вас в том, что вы воровали электроэнергию и майнили биткоины. Все оборудование, естественно, вывезут.

А что Вы называете «хостингом»? Просто если то что «раньше» называлось хостингом для меня — это выкладывание сайтов в фтп папку у хостинг провайдера, но то может возрастное :)
Помимо виртуалок из интересного — контейнеры, работа по API с terraform, ansible, балансировщик, группы ВМ с аффинити правилами, фаервол с микросегментацией, разные софтовые роутеры, от опенсенса до Cisco CSRv, бэкап-служба которая делает полные и инкрементальные бэкапы по расписанию, объектное хранилище на SWIFT.
По поводу площадок — пока конкретно PaaS живет в Украине на одной площадке и запускается вторая, а так у нас три ЦОДа, два в Киеве (Гигацентр и Бимобайл) и Атман в Варшаве. Вывоз оборудования — это распространенное опасение, но с облаком это так не работает.

А что Вы называете «хостингом»? Просто если то что «раньше» называлось хостингом для меня — это выкладывание сайтов в фтп папку у хостинг провайдера, но то может возрастное :)

Ну а сейчас выкладывают контейнеры или виртуалки. Пока что ваша система мне кажется скорее IaaS, чем PaaS. Вот примерно картинка про разницу:
anarsolutions.com/...​-iaas-vs-paas-vs-saas.png
То есть «платформа», это не просто возможность запускать виртуалки, а полноценное решение для развертывания приложений.
Для примере можете рассказать: если у меня есть приложение на .Net Core — то что мне нужно сделать что бы развернуть его в вашем облаке?

В этом случае скорее всего все как с виртуалкой. Какого-то образа с уже развернутым дотнетом и автоматически стартующими службами еще нет. Мы, собственно, сюда за такими вопросами и пришли, чтобы получше себе представить куда развивать функционал. «Сделать все что есть у AWS» — не самый эффективный путь.

«Сделать все что есть у AWS» — не самый эффективный путь.

Тогда возможно вы не совсем правильно себя позиционируете. Когда вы говорите про облака и PaaS то большинство представляет себе именно «как у AWS или GCP». А у вас, насколько я понял, недорогой хостинг для внутреннего рынка — без надежности 0.99 и всех остальных «плюшек».
И главная проблема, которую я здесь вижу: если бы у меня был бизнес в Украине — то я старался бы хостить свои сайты и держать данные в другой стране.

В крайнем случае, нам поможет оPaaSить сервис RedHat :) А почему старались бы хоститься и держать данные не в Украине, при этом ведя в Украине бизнес? Ну то есть, физически находиться тут, держать деньги на счетах украинских банков, но сайт и БД за границей?
На мой взгляд, других рисков столько, что сайт на AWS не особо и спасает. Хотя если есть план побега, то чтобы начать с чистого листа, бэкапы лучше все же сложить в какой-нибудь заграничный cold storage.

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

Цікаве питання — при тому що ваш же gigacloud dot ua на ажурі а не на власному клауді)

По-перше, оскільки ми партнер майкрософту, то у нас і Azure є, то чому б і ні :) І на випадок DDoS атаки, то краще вже хай DDoS’ять Azure ніж продуктив. Він то захищений, але не дуже хочеться зайвий раз пробувати.

По поводу вывоза оборудования отдельный коммент хочу написать. Это распространенное опасение, и понятно почему, но с облаком это так не работает. Если выдернуть хост из кластера и увезти — то машины рестартнутся на другом хоесте. Нужно вынимать весь кластер, а значит потушить сервисы кучи других клиентов. PaaS мы стартанули сравнительно недавно, там еще не стартанули продуктив у крупных клиентов, но если брать наше же облако на VMware, то там вывозя оборудование под предлогом наезда на ЧП «Аквалабеан», есть риск потушить сервисы например КМДА, медицинских информационных систем, ряда госов, и т.п.
Представить себе такой сценарий я могу только в каком-то очень чрезычайном случае типа военного вторжения, но тогда уже это будет явно не самой большой проблемой.

Нужно вынимать весь кластер, а значит потушить сервисы кучи других клиентов. PaaS мы стартанули сравнительно недавно, там еще не стартанули продуктив у крупных клиентов, но если брать наше же облако на VMware, то там вывозя оборудование под предлогом наезда на ЧП «Аквалабеан», есть риск потушить сервисы например КМДА, медицинских информационных систем, ряда госов, и т.п.

Вот об этом и речь! У нас правовая система очень прямолинейная: если какой-то судья дал добро на изъятие — то грести будут все сервера подряд. Откроют дело на какой-то «Лабеан», чьи данные вы храните — а вывезут весь ваш кластер!
И хорошо если у вас настроена гео-распределенная репликация, и данные и машины останутся и смогут стартовать в другом городе. Но при этом все равно данные на дисках, которые заберут СБУ получается «утекут».

Вывоз всего кластера — это нереальное ЧП в рамках страны было бы. Такого еще в истории не случалось, конкретно с облаком. В ЦОДе где понятно где чье оборудование — это еще возможно, но в облаке это задевает всех подряд. Обычно происходит так: приходит киберполиция с запросом, и самим клиентом, который предоставляет полицейским авторизационные данные, и при участии нашей юридической службы и техперсонала, эта трехсторонная группа выкачивает данные конкретного клиента.
Без клиента и его авторизационных данных мы выкачать ничего не можем, потому что данные фрагментированно лежат по всему массиву, а доступа внутрь клиентского проекта openstack или vDC в облаке VMware у нас даже у саппорта нет.

Без клиента и его авторизационных данных мы выкачать ничего не можем

Я думаю как раз такой ответ приведет к тому, что СБУ скажет: мы забираем все железо и будем сами искать. Скорее всего с правовой точки зрения невозможно разграничить где в вашем датацентре данные одной компании — а где другой. Есть железо, на нем есть какие-то данные, есть подозрение что там что-то запрещенное, есть ордер — значит или вы даете полный доступ что бы они искали по всем дискам (и данным всех клиентов), или они забирают диски и ищут сами.

Вывоз всего кластера — это нереальное ЧП в рамках страны было бы.

это была шутка?

Вовсе нет. В облаке хватает и крупного бизнеса, и медицины, и объектов критичной инфраструктуры, и это только публичное облако. Если Урфин Джюс и его деревянные солдаты поломают что-то из частных, то можно уложить одну из площадок Prozorro, НСЗУ или Дии. Простой этого всего одновременно невозможно не заметить.
В целом, повторюсь, случаев того, чтобы выносили облако целиком — мне неизвестно. А отдельного клиента из облака вынести невозможно технически.

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

У того, кто хостится в Германии или Штатах — от военного вторжения рашки в Украину вообще никаких проблем не будет.
По крайней мере, с серваками.

Кто хостится, и в идеале — живет в Германии или Штатах :)

Підписатись на коментарі