Привет! Я Георгий Трегубов, руководитель отдела развития продуктов облачного оператора GigaCloud. На днях начал пересматривать сериал Silicon Valley. В последней серии первого сезона есть легендарная сцена, в которой главному герою приходит продуктовая идея, во время абсурдного разговора его команды. Воодушевленный этой историей, я решил написать сценарий собственного мини-сериала. Ведь в марте этого года мы запустили важный для украинского рынка продукт. И он тоже родился в диалогах.
В семи эпизодах я расскажу, как мы в GigaCloud создали первое украинское PaaS-решение ― S-Cloud 2.0. И да, я готов к вашему сарказму. PaaS — это не только у AWS. Украинские облачные операторы существуют, а разработчики активно используют наше решение.
Когда в 2016 году мы начали завоевывать долю украинского облачного рынка, взяли за основу стратегию низкой цены. Создали облако на VMware для размещения IT-сервисов клиентов, сделали его таким же качественным, как у основного конкурента, но немного дешевле. Некоторое время эта стратегия приносила необходимый результат. Но спустя четыре года появились новые компании, предоставляющие облачные услуги, и наше ценовое преимущество стало размываться.
По классике есть три стратегии: низкой цены, дифференциации и ниши. Низкая цена уже перестала работать. Стратегия ниши нам не подходила, потому что рынок облачных сервисов в Украине относительно небольшой. На тот момент он составлял около 40 млн долларов. Для сравнения: в соседней Польше рынок был в 15 раз больше. Чтобы успешно строить доходный бизнес и конкурировать, мы не могли ограничивать аудиторию. В итоге выбрали стратегию дифференциации. Простыми словами, стратегия дифференциации ― это когда ты делаешь ту же задачу, что и другие компании, но другим способом. В нашем случае это другое облако. А другое облако ― другой гипервизор.
На одной из рабочих встреч, на которой присутствовали специалисты отдела R&D, эксплуатации, Pre-sale Manager и я как Product Manager, мы провели scoring. Собрали все функции нашего флагмана публичного облака на VMware и облака на OpenStack и выделили самые необходимые, которые должны быть реализованы в новом продукте. Те фичи, которые набрали наибольшее количество баллов, взяли в разработку первыми. И сделали минимально жизнеспособный продукт (MVP).
После этого мы разбились на команды и начали искать product-market fit для нового облака. Оно должно было вписаться в наш продуктовый портфель и при этом не повлиять на продажу публичного и частного облака. В процессе поиска мы столкнулись с двумя историями.
Проанализировав все клиентские сделки за год, мы поняли, что в украинском облаке нет украинских разработчиков. Бизнесы есть, даже госструктуры есть, а разработчиков — нет. Походив по рынку, мы узнали, что им не хватает инфраструктуры с готовой развернутой средой, куда можно деплоить. И чтобы инфраструктура была привычной, похожей на ту, что есть у зарубежных провайдеров: контейнеры, софтовые роутеры, объектные хранилища и тому подобное.
Также обнаружили, что 70% контрактов у нас не доходили до реального проекта и внедрения на этапе цены. Заказчикам нравилось публичное облако на VMware, но когда они получали коммерческое предложение и видели цену, оставались на собственном «железе» или уходили к конкурентам.
С одной стороны, этот факт сбивал нас с толку, поскольку нужно было сделать функциональный технологичный сервис и одновременно где-то ужиматься в себестоимости. Но с другой, у нас появился шанс сегментировать рынок и выделить тех заказчиков, для которых VMware не в приоритете. При этом создать облако, которые бы решило запросы пользователей. И тут у нас родилась формулировка: «Для тех, кому не нужна „варя“ и КСЗИ, а функционала S-Cloud слишком мало».
Мы получили от рынка примерную ценовую оценку и начали думать, как сделать сервис функциональным, но при этом более доступным.
Как известно, истина рождается в дискуссии. В итоге мы пришли к выводу, что нам хватит экономии на роялти. Поскольку OpenStack и KVM ― оpen source решения, а значит нет необходимости платить вендору за использование его программных продуктов. Это окупает часть себестоимости серверов.
На оборудовании же решили не экономить. И на это есть две причины. Во-первых, чтобы упростить обслуживание и улучшить надежность облака. Мы используем такие же сервера, как и в публичном облаке на «варе» и частных облаках. Но есть одно отличие. Мы построили хранилища JBOD (Just Bunch Of Disks) на Ceph, а не на выделенных СХД. Это шасси, в которое помещается большое количество дисков, два контроллера для надежности и Ceph ― программно-определяемое хранилище, которое обеспечивает резервирование данных и устойчивость к поломкам. Когда пользователь записывает информацию, Ceph ее дублирует (делает несколько копий), фрагментирует и расписывает частями на разные диски. Если какой-то диск перестает работать, хранилище восстанавливает потерянные фрагменты с других.
Во-вторых, поскольку мы покупаем серверы промышленного уровня, то в одно шасси можем поместить много процессоров и много оперативной памяти. Это дает возможность получить приемлемую цену в перерасчете на единицу ресурсов.
Тестирование проходило следующим образом. Если какую-то функцию партнеры не находили, мы писали инструкцию, отдавали ее и смотрели на их реакцию. Если все шло хорошо, делали документацию, если по-прежнему у партнеров возникали трудности, то функцию либо куда-то переносили, либо переделывали.
Если партнеры легко находили все функции, но при этом они не работали, то их запросы передавали сразу же архитектору. Минуя отдел технической поддержки и эксплуатации.
Мы впервые попробовали написать документацию о том, как решить конкретную задачу с помощью облака, а не просто как пользоваться конкретной функцией. Мы спрашивали у партнеров, какие типовые задачи они решают, а нашу техническую поддержку ― какие запросы они чаще всего получают. На основе этой информации писали кейсы. Так родились инструкции, как, например, разместить 1С в облаке, как сделать сайт или как настроить балансировку. Теперь после того как специалист техподдержки выполнит задачу партнера или клиента, может дать ему инструкцию, чтобы дальше он мог делать это сам.
Наш архитектор OpenStack вручную переписал панель Horizon. Сделал так, чтобы функции облака были доступны не только через API или консоль, но и в графическом интерфейсе. Благодаря тому, что наш архитектор изменил панель и доработал ее, любой админ-линуксоид сможет легко с ней работать.
Именно благодаря тестированию продукт и приобрёл финальный облик.
3 марта 2021 года состоялся релиз облака S-Cloud 2.0, которое мы с уверенностью называем первым украинским PaaS-решением. Оно состояло из виртуальных машин, инфраструктуры для запуска приложений, виртуального маршрутизатора с VPN-сервером и возможностью объединения виртуальных машин во внутренние сети, балансировщика сетевых соединений, запуска нод с docker-контейнерами, Firewall и снепшотов.
После релиза сервиса наши специалисты отдела R&D добавили в него полноценные бекапы, софтовые роутеры (поскольку пользователям не хватало встроенных маршрутизаторов), оркестрацию и объектное хранилище.
Фактически мы используем ту же платформу, что и Amazon. Ресурс модернизации платформы большой, нам есть куда расти и над чем работать. В ближайших планах ― разработка базы данных как сервиса.
Удобство сервиса и возможность получить поддержку ― это важная составляющая при выборе облачной платформы. А для нас как облачного оператора ― возможность поддерживать и совершенствовать один бизнес-процесс на всех. Поэтому мы предоставляем техническую поддержку такого же уровня, как и для нашего флагмана публичного облака E-Cloud на VMware.
В 20-х годах Ford выпустил свой Ford Model T. Это был недорогой автомобиль, каждый американский рабочий мог накопить денег и купить его. При этом все автомобили этой модели были одинаковыми. Но, если посмотреть фото тех лет, можно увидеть массу модификаций Ford T: маленькие грузовички, автомобили с твёрдой или мягкой крышей всех возможных цветов. Причиной этому стало появление большого количества мастерских, которые зарабатывали на переделке стоковых машин под клиента. Ничего не напоминает?
В случае с облаком S-Cloud 2.0 у нас есть OpenStack и KVM. Разработчики смогут собрать под клиентов все, что нужно, используя этот базовый функционал.
dou.ua
В семи эпизодах я расскажу, как мы в 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. Разработчики смогут собрать под клиентов все, что нужно, используя этот базовый функционал.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua