Представляем нулевой выпуск подкаста о технологиях, процессах, инфраструктуре и людях в IT-компаниях. Сегодня в гостях у “CTOcast” — Руслан Синицкий, CTO и сооснователь компании Jelastic.
.jpg "CTOcast #0: Руслан Синицкий (Jelastic)")
Руслан Синицкий родился в 1978 году. Живёт и работает в Житомире, Украина. С детства увлекался программированием, окончил Житомирский военный институт радиоэлектроники по специальности «Оборудование специального мониторинга». В 2001--2008 гг. работал в Национальном Космическом Агентстве Украины, где занимался разработкой программного обеспечения для контроля землетрясений на поверхности Земли. В 2008--2011 гг. — Senior UI Architect в iQueLab. Также работал фрилансером в различных аутсорсинговых компаниях.
Несколько слов о Jelastic:
В 2008 г. на Хабре Руслан Синицкий познакомился с Константином Александровым (программистом из Воронежа), вместе с которым придумал идею инструмента для Java-девелоперов, позволяющего упростить процесс разработки приложений и их масштабирования. Без единой личной встречи за 2 года Руслан и Константин создали прототип.
В 2010 г. основана компания Hivext Technologies, Inc., ставшая прородителем Jelastic. Приблизительно в это же время к команде присоединился Алексей Скутин, который занялся поиском потенциальных инвесторов и продвижением Jelastic на рынке. В декабре 2010 г. были получены инвестиции в посевном раунде от фонда Runa Capital, что позволило всем собраться в одном городе — Житомире и набрать команду разработчиков.
В 2012 г. прошёл следующий раунд инвестирования, в котором участвовал фонд Almaz Capital Partners. В этом же году компания Jelastic была награждена Duke’s Choice Technology Award — самой престижной наградой в мире Java.
В сентябре 2013 г. к команде инвесторов присоединился Maxfield Capital, а на позиции CEO Руслана сменил Джон Деррик.
На данный момент у компании порядка 80 тыс. пользователей по всему миру — в США, Европе, Азии и 24 партнёра — . Jelastic позиционирует себя как единственное в мире Platform-as-Infrastructure решение.
Текстовая версия подкаста (1-ая часть)
Павел Павлов: Сегодня уже была затронута тема Platform-as-Infrastructure. Хотелось бы более подробно узнать о том, какой смысл ваша компания вкладывает в этот термин?
Руслан Синицкий: Термин действительно новый, появился буквально недавно. Мы его, откровенно говоря, и создали. Изначально мы сделали некую платформу — Platform-as-a- Service, с которой позиционировали свою компанию и которая позволяла упростить жизнь разработчикам. Но бизнес-модель нашего продукта отличалась от подобных решений, к примеру, Heroku и других похожих продуктов. Наше основное отличие было в том, что свой софт мы ставили не на Amazon, а в дата-центры партнёров. Соответственно, нам приходилось решать и задачи Infrastructure-as-a-Service. Так получилось, что сами поначалу не понимая этого, в одном продукте мы решили две проблемы: Platform-as-a-Service и Infrastructure-as-a-Service. Поэтому наш продукт более комплексный и сложный, чем у наших конкурентов.
Из коробки вы получаете полный спектр — Platform-as-a-Service и Infrastructure-as-a-Service. У нас две панели администрирования: одна для разработчиков, другая — администраторов кластеров. И для нашей платформы не обязательно иметь какой-то нижний слой, достаточно предоставить голое железо и мы можем поставить поверх него платформу и решать те задачи, которые решают наши конкуренты, но на базе Amazon.
Поэтому, если в двух словах, Platform-as-Infrastructure — это гибрид Platform-as-a-Service и Infrastructure-as-a-Service.
Александр Астапенко: Очень удачно это отражено и в дизайне вашего сайта, где два понятия сливаются и образуют Platform-as-Infrastructure.
Руслан Синицкий: Да, на самом деле мы убрали некую неэффективность. Наш продукт призван ликвидировать неэффективность: постоянные повторения одних и тех же действий администраторами, два слоя. Люди не парятся об Infrastructure-as-a-Service или Platform-as-a-Service, им нужно решение конкретных задач. И наш продукт упрощает сложные вещи.
Александр Астапенко: Непосредственными клиентами и теми, кто, собственно, платит за продукт, являются B2B-компании, то есть какой-то средний слой, а не конечные пользователи, которые будут работать с Jelastic. Это, к примеру, . Так? Несколько слов о том, кто ваши клиенты?
Руслан Синицкий: Вы правильно заметили, что есть несколько уровней клиентов. Если мы будем говорить о клиентах, платящих нам деньги непосредственно, то на сегодняшний день это хостеры и компании, которые хотят поставить Jelastic на своё железо. Это могут быть банки, аутсорсинговые компании, интеграторы, компании, предоставляющие телекоммуникационные услуги, то есть B2B-сектор. Эти люди, те же хостеры, продают Jelastic разработчикам или SMB. Если говорить об интеграторах и аутсорсинговых компаниях, то они никому не продают, а решают свои задачи внутри компании, упрощают процессы разработки.
Александр Астапенко: Правильно ли я понимаю, что и продвижение продукта идёт в двух направлениях: для конечных пользователей, которые будут работать с результатами, то есть самим Jelastic-продуктом, и тех, кто будет устанавливать Jelastic на свои серверы?
Руслан Синицкий: Изначально мы создавали продукт для бизнес-клиентов, для хостеров, но в принципе всегда маркетировали его для конечных потребителей. То есть наша маркетинговая стратегия всегда была в основной своей массе нацелена на конечных потребителей. Мы изначально создавали бренд Jelastic, объясняли почему Jelastic хорошо, как он упрощает разработку, экономит время, ресурсы. Таким образом мы привлекали конечных разработчиков, SMB на наш сайт и им объясняли. К нам шёл большой трафик, дальше этот трафик мы уже распределяли между нашими партнёрами. Естественно, мы делали маркетинг и в хостинг-индустрии, ездили по конференциям, объясняли почему хостерам необходимо установить платформу, как они могут открыть новую ветку бизнеса. Но основные ресурсы, порядка 80%, тратились на создание бренда, узнаваемость Jelastic среди разработчиков, тех людей, которые непосредственно будут пользоваться этим продуктом для решения своих проблем. На сегодняшний момент мы начинаем расширять маркетинговую стратегию и использовать больше ресурсов для продвижения нашего продукта в B2B, потому что теперь нам необходимо общаться с enterprise-клиентами, объяснять почему им необходим Jelastic, как он может упростить жизнь. Появляется необходимость общаться с аутсорсинговыми компаниями, то есть это ещё один дополнительный клиент.
Павел Павлов: Это контекст интереса к продукту, платформе, а как формировалось доверие к тому, что вы делаете, в начале развития компании и при работе с крупными корпоративными клиентами?
Руслан Синицкий: Обычно люди с недоверием относятся к новым продуктам, но всегда есть те, кто готовы попробовать рискнуть. Это в основном те люди, которые ищут новые рынки, которые понимают, что вовремя подключив какую-то инновацию к своему бизнесу, можно выиграть хороший сегмент рынка. В нашем случае немаловажными оказались контакты с компанией Parallels. Они представили нас хостерам, своим знакомым людям. И, грубо говоря, определённые люди поручились своим именем. К примеру, Сергей Белоусов представлял нас своим знакомым по бизнесу в хостинг-индустрии и люди, зная Сергея и доверяя ему, стали нас хотя бы слушать. Это не значит, что они с закрытыми глазами будут делать то, что им говорил Сергей. Это значит, что они хотя бы приняли нас в гости и послушали. Я поездил на начальном этапе по разным хостинговым компаниям. И большинство из них послушали и сказали: “Хорошо, приходите попозже”. Тем не менее удалось зацепить одного хостера, с которого всё и началось. Это Host Europe — третий в Германии. В принципе, первая сделка основывалась на личных отношениях. После этого мы запустили бету, начали публиковать о Jelastic, сравнивать себя с конкурентами, привлекать аудиторию. Соответственно, пошёл трафик. Тот , который нам доверился, увидел, что у конечного пользователя есть интерес, и мы начали это использовать как юз-кейс для других потенциальных партнёров и так стали их привлекать. Потом появился в Америке . А когда было уже два, третьего гораздо проще подключить. Когда появилось три — четвёртый, пятый и двадцатый пошли по накатанной дорожке. Первые сделки основывались на более личностных отношениях.
Второй момент, который нужно подчеркнуть в развитии Jelastic — в основе нашего продукта лежало техническое решение, которого не было у наших конкурентов. У них была большая проблема с этим — совместимость со стандартными приложениями. С Jelastic вы можете задеплоить любое стандартное приложение и Jelastic упростит его масштабирование. Во многих случаях он может сделать это автоматически. Практически всегда вам не нужно ничего переписывать, потому что вы можете писать на файловую систему, подгружать свои любимые библиотеки, изменять конфигурационные файлы, если считаете, что Jelastic не оптимальным образом предоставляет настройки по умолчанию. Мы стараемся не ограничивать конечных потребителей в использовании их наработанного опыта, переиспользовании их библиотек, скажем так. Это техническое решение очень понравилось конечным потребителям и мы начали быстро расти.
Павел Павлов: Вам удалось достичь определённого компромисса между универсальностью платформы, которая бы подходила многим группам пользователей, и пространством для гибкости и тонкой настройки.
Руслан Синицкий: Да, мне кажется нам удалось найти баланс.
Павел Павлов: Долго к этому приходили?
Руслан Синицкий: Шли к этому на уровне интуиции. Я не скажу, что мы всё до конца осознавали. Интуитивно. Даже наша сделка с Runa Capital, которая, по сути, получилась случайно. Но мы уже знали, что окей, заключим сделку с Runa Capital и получим доступ к компании Parallels — одному из лидеров в области виртуализации. Получив доступ к этим технологиям и поговорив с ребятами-технарями внутри этой компании, мы оценили какой большой потенциал есть у этой компании с очень хорошим продуктом виртуализации. И мы положили его в основу. Потом оказалось, что у продукта есть преимущество, которого нет у других Platform-as-a-Service — вертикальное масштабирование, возможность автоматически масштабировать приложения, полная изоляция ресурсов, то есть каждому приложению можно выделить изолированные ресурсы и можно разрешать записывать файлы на файловую систему, возможность миграции приложения между железными серверами без downtime. То есть в процессе мы начали находить наши достоинства. Я не скажу, что это был изначально чёткий план. Изначально было спланировано желание избежать каких-либо требований к изменениям в пользовательском приложении.
Когда мы создали первую версию нашего продукта Hivext, мы собрали 5000 пользователей, и этот Hivext был похож на Google App Engine — Backend-as-a-Serivce. Недостатком этого подхода является то, что пользователи не могут задеплоить стандартное приложение, они не могут использовать накопленный опыт — им приходится писать заново приложение. Соответственно, для маленького стартапа — это дорога в никуда. Большие компании не пойдут туда, только маленькие стартапы, которые в принципе не способны платить деньги на начальном этапе. Научившись на этом, мы решили основной недостаток в следующей версии нашей платформы сделать основным достоинством. Мы сказали, что будем делать такую платформу, которая не требует переписывания вашего кода.
Мы постоянно учимся, что-то создаём, тестируем это на маркете, получаем фидбэк и улучшаем наш продукт. И даже последние наши изменения в сторону Platform-as-Infrastructure случились, благодаря накопленному за всё время работы опыту.
Александр Астапенко: Очень похоже на Lean-подход.
Руслан Синицкий: Да, практически похоже. Честно говоря, не читали его изначально, но потом уже, когда прошло время и я нашёл книжку, почитал и понял, что мы очень близки к этому.
Александр Астапенко: Но когда вы приходите к хостерам или каким-то корпоративным клиентам, то не у всех установлены продукты Parallels, с которыми вам необходимо проводить интеграцию. У каждого из них своя среда. Я так понимаю, что вы сталкиваетесь всякий раз с новым отдельным кейсом, который нужно решить — как же интегрироваться с тем или иным партнёром? Можешь рассказать немного про это?
Руслан Синицкий: Особенно это было актуально для первых версий Jelastic. Мы не понимали какие ещё необходимы требования для железа. До конца не понимали, где пространство будет для манёвра. Если говорить по поводу виртуализации, мы также не понимали можно ли запускать наш продукт внутри других слоёв виртуализации, на базе того же Amazon или Rackspace. Действительно, система биллинга у каждого партнёра зачастую самописная, некоторые используют какие-то стандартные решения, но этих решений определённое количество. Со временем мы улучшали наш продукт и на текущий момент получили коробочное решение. Мы приходим к хостеру и говорим: “Чтобы запустить Jelastic необходимо железо вот с такими требованиями...”. Виртуализация, не виртуализация — его это не интересует, он вообще не прикасается к системе виртуализации Parallels. Если говорить про биллинг, то мы создали свой внутренний виртуальный биллинг, все процессы происходят внутри Jelastic и теперь интегрируемся на уровне API, говорим любой биллинговой системе хостера, что в конце месяца с пользователя нужно снять столько-то денег. Как они снимают — это их вопросы.
Чем дальше продукт развивается, тем более универсальным он становится, тем легче его обслуживать, появляется больше документации, юз-кейсов, меньше требований к начальным ресурсам для запуска Jelastic.
Александр Астапенко: А как происходит сам процесс? Кто проводит интеграцию? Специалисты со стороны хостера или кто-то с вашей стороны? И насколько процесс контролируется хостером? Насколько они хотят его контролировать?
Руслан Синицкий: Первые интеграции были практически вслепую. Когда мы прошли так несколько раз, то поняли, что процессы повторяются. Соответственно, был создан мастер-план. Это не только установка софта, но и тонкий тюнинг, подготовка маркетинговых материалов, подготовка сайта, кастомизация шаблонов писем, которые отправляются пользователям, локализация. Поэтому интеграция расписана на чёткие шаги на каждой стороне: на стороне Jelastic или хостера. Для интеграции Jelastic выделяются два человека. Это аккаунт-менеджер, который ведёт проект (в основном нетехнический специалист). Это человек, который хорошо разговаривает на английском языке, у которого хорошие коммуникационные способности. И второй человек — это технарь, непосредственно выполняющий технические работы: установка Jelastic, конфигурация, анализ, если что-то пошло не так. Есть действия, которые должны быть произведены на стороне хостера. Этот список выдаётся хостеру и аккаунт-менеджер проходит с менеджером проекта на стороне хостера по каждому пункту, объясняет, что нужно сделать, ведёт хостера по проекту. На сегодняшний день это полностью предсказуемый процесс и мы может примерно оценить сколько времени займёт интеграция с тем или иным хостером, спланировать собственные ресурсы.
Александр Астапенко: Видно, что процесс уже подготовлен за годы работы. Я так понимаю, что в начале это было совсем не так. Вы проходили через собственный опыт. Правильно?
Руслан Синицкий: Было кошмарно изначально, честно говоря. Нам повезло, что мы нашли человека, который когда есть хаос, его бросаешь в этот хаос и там сразу становится порядок. Такой человек обязательно нужен компании.
Александр Астапенко: В России такого человека в конце 90-х кинули на управление страной, мы слышали об этом.
Руслан Синицкий: Ну, да)
Александр Астапенко: Хочу сейчас вернуться к самому продукту, который также развивался, как и процесс интеграции. Кто занимается в компании вопросами, связанными с продуктом? Как принимается решение будет та или иная фича входить в продукт, оценивать её перспективность, какой жизненный цикл она проходит. Как ты говорил, вы что-то запускаете, тестируете на рынке, получаете фидбэк, изменяетесь и так далее в этом цикле. Кто это делает и как выглядит процесс?
Руслан Синицкий: Когда нас было 5--7 человек, то вопрос этот решался проще, меньше людей и большие вещи были более очевидными. Когда людей становится больше и начинает появляется больший объём работы, то всё усложняется. Поэтому необходимо внедрять определённые процессы. Мы приглашали специалистов, которые приезжали в нашу команду и настраивали процессы. Это касалось процесса определения приоритетности того или иного функционала. На сегодняшний день мы используем Agile, используем бэклог.
Есть много источников информации, откуда мы черпаем направления по потенциальному развитию нашего продукта. В первую очередь, это конечные пользователи. Мы всегда слышим конечных разработчиков: что удобно, что неудобно, что нравится, что не нравится, какие есть ограничения. Анализируем периодически суппорт-канал. Суппорт-инженеры присылают отчёт по тому или иному направлению каждую неделю, какие функции были наиболее запрашиваемы. Мы слышим наших партнёров-хостеров, у которых тоже есть определённые запросы по менеджменту кластера, или у них не получается привлечь дополнительный сегмент пользователей, потому что они не могут предоставить ту или иную функцию. У нас есть понимание, куда мы хотим развивать свой продукт. У нас есть потребности внутренние, рефакторинг модулей. Кому-то в команде может не нравится как устроено архитектурно то или иное решение и у него имеется лучшее предложение. Есть потребности команды operations, производящей установку, они хотят сократить время, которое на это тратится. Направлений становится все больше и больше.
На текущий момент я общаюсь с каждым лидом направлений (по суппорту, общению с хостерами и т.д.) и мы собираем фидбэк, некий плоский список. В нём проводим голосование, то есть каждый человек по направлению определяет наиболее приоритетные функциональности. Это потом анализируется и мной составляется финальный roadmap на релиз. Мы ещё раз обсуждаем этот roadmap с ключевыми сотрудниками и приходим к тому, что все понимают почему именно эти фичи являются наиболее критичными в текущем релизе.
Александр Астапенко: То есть можно сказать, что ты тот человек, который формирует продукт Jelastic?
Руслан Синицкий: Можно сказать так, но я хочу акцентировать внимание на том, что продукт формируется всей командой. Просто я тот человек, который собирает информацию с разных источников, выслушивает доводы разных сторон почему это важно, слышу боль разных людей и пытаюсь правильно расставить приоритеты. Объяснить одним людям почему, к примеру, фича, предложенная другим отделом, важнее, чем та, которая предлагается ими. Тогда в команде будет понимание куда развивается продукт, не будет каких-то внутренних конфликтов, войн. Это очень важно. То есть я являюсь неким медиатором на текущей стадии.
Александр Астапенко: Хорошо, фичи собрались, выстроились приоритеты, попали в релиз и на рынок. Как ты принимаешь решение фича нужная и она остаётся или убираем её из продукта? Или вы вообще не убираете те фичи, которые попадают туда?
Руслан Синицкий: Мы стараемся сделать MVP (Minimum viable product) — что-то, что легко сделать за одно приседание, что является в принципе законченным и решает какую-то конкретную проблему. Стараемся выдать это конечным пользователям и посмотреть на их реакцию, то есть мы собираем фидбэк. Посмотреть в правильном ли направлении мы идём, проанализировать насколько интересна одна фича по сравнению с другой, правильно ли выбрано архитектурное решение. На следующий релиз мы уже вносим какие-то изменения, в соответствии с собранным фидбэком по разным фичам мы выставляем приоритеты. Мы никогда не выпускали одну фичу от начала и до конца за один релиз. Потому что иначе мы бы фокусировались только конкретно на этой фиче, а направлений очень много. Во-вторых, если ты сделаешь что-то не так, когда ты зарелизишься и попробуешь это на конечных пользователях, переделывать будет очень сложно и проблемно. Вы потеряете кучу времени в неправильном направлении, что будет очень дорого для компании. Поэтому мы стараемся идти мелкими, итерационными шагами. К примеру, Ruby мы недавно зарелизили в приватной бете, хостеры не сдержались и опубликовали в паблик бете. Собрали фидбэк и мы точно знаем чего не хватает в текущей реализации Ruby. 100% знаем, что наиболее критично, и делаем это в следующем релизе. Опять релизим и смотрим: ага, мы покрывали 80%, теперь мы покрываем 90% кейсов. Что надо сделать для того, чтобы покрыть 95% кейсов?
Павел Павлов: А как вообще возникла идея такого перехода к новым платформам для PHP, Ruby? Мотивировала популярность платформы или что-то ещё?
Руслан Синицкий: Эта мультиязычность была спланирована и заложена изначально в архитектуру. У нас даже был спор внутри команды, что делать первым — PHP или Java. И спор был между инвесторами и основателями компании. У инвесторов был доступ к хостинг-индустрии, а хостинг-индустрия вся в основном про PHP. И говорилось: “Вот, хостеры знают PHP и хотят PHP”. А мы со своей стороны говорили: “Они знают PHP — у них есть PHP, они не знают Java — у них нет Java”. Я поездил по хостинговым компаниям и спрашивал: “Почему вы, ребята, Java не продаёте?”. И они в один голос говорили: потому что это трудно, потому что мы не умеем это делать. Не было нормального решения. И мы начали с этого. Java сама по себе более сложный язык, больше серверов приложений, баз данных, комбинаций различных. Поэтому мы всё-таки решили начать с Java. Понимали, что если мы решим вопрос для Java, то для PHP и других языков будет гораздо проще уже расширять архитектуру. Но изначально базовые принципы были заложены так, что платформа будет поддерживать много языков программирования.
Павел Павлов: А Ruby как возник?
Руслан Синицкий: Мы добавили PHP, у нас PHP запущен коммерческий, нормально работает, освободились ресурсы и дальше пошли в Ruby.
Павел Павлов: То есть шаг за шагом?
Руслан Синицкий: Да. Следующий у нас node.js, после него — .NET. Я думаю Python добавится вместе с node.js. Буквально пару дней назад мы объявили сотрудничество с компанией Red Hat, в принципе, с нашим конкурентом — OpenShift (Platform-as-a-Service) о том, что мы будем поддерживать унифицированный формат шаблонов для стека языков программирования, для серверов приложений, баз данных. Между двумя этими платформами будет унифицированный формат. Это означает, что, к примеру, разработчики баз данных, серверов приложений или просто приложений могут запаковать свои приложения в этот формат и приложение можно будет легко развернуть либо в OpenShift, либо в Jelastic и его не нужно будет переписывать под конкретную платформу. Таким образом, экосистема вырастет очень сильно в ближайшее время. Это очень серьёзный шаг к унификации, что очень хорошо для всех игроков на рынке.
Продолжение текстовой версии подкаста — в ближайшие дни.
Автор: ViktoryiaFedzkovich
