Нужно ли экспериментировать в процессе разработки?

Каждый успешный проект софтверной компании начинается с идеи, но перед тем, как она станет реальным продуктом, необходимо пройти большой путь проб и ошибок. Сегодня мы хотим рассказать о некоторых проектах Virtuozzo, которые смогли (или не смогли) стать востребованными на рынке продуктами

Софтверным компаниям постоянно нужно принимать решения о направлении девелопмента. У нас в Virtuozzo есть такое подразделение — отдел менеджмента программ. В нем работают люди, которые отвечают за дорожную карту существующих продуктов, выпуск релизов и апдейтов, планирование разработок. Таким образом, деятельность менеджеров программ можно разделить на три больших сектора:

• Разработка согласно запросам рынка. Это создание продуктов под уже существующие тренды, адаптация релизов под отраслевые тенденции. Например, когда на рынке сформировалась потребность в работе с контейнерами Docker, мы приступили к разработке механизма их поддержки на уровне нашего гипервизора.
  
  
• Разработка под потребности текущих клиентов – это доработка релизов, согласно полученной обратной связи от пользователей. Она может быть как явной «Ребята, помогите нам решить проблему со стеком» или приходить в виде периодических запросов в техподдержку, которые помогают обрисовать очевидную потребность в улучшениях.
  
  
• И самое неоднозначное – это экспериментальное направление. Очень часто, мы не знаем, удастся ли решить определенную задачу, или нет, и насколько востребованным будет это решение. Иногда, если у кого-то из сотрудников рождается идея, и коллектив расценивает ее, как хорошую идею, мы пробуем выпустить прототип и сделать из этого продукт.

Эксперименты и реальность

Наличие такого направления в работе компании создает шанс для появления спонтанных, нередко успешных продуктов и инструментов, которые не только оказываются успешными на рынке, но еще и меняют отрасль в определенной степени. Кстати, именно так рождался проект Virtuozzo Storage, который было принято решение развивать в виде распределенной системы хранения данных. В 2010 году было предложено использовать диски серверов для объединения в распределенную систему хранения данных виртуальных машин, а сегодня Virtozzo Storage – один из трех краеугольных камней нашей экосистемы.

Можно привести еще несколько примеров, когда продукт, оказавшийся на рынке, начинался с прототипа. Скажем, полностью переработанная архитектура продукта Power Panel, который мы выпустили в марте, тоже началась с подобного проекта. Но далеко не всегда эксперименты приводят к появлению продукта. Впрочем, негативный результат – это тоже результат. Ведь без него невозможно было бы найти более перспективные проекты. Для того, чтобы проверить ту или иную возможность, мы выделяем 1-2 разработчика – тех людей, которым интересно это направление – и проводим исследование на протяжении нескольких недель или месяцев. Дальше возможно или появление отдельного продукта, либо «фишки» в одном из существующих решений, либо закрытие направления как неперспективного.


Неудачные пробы

На рубеже 2006-2007 годов у наших разработчиков возникла идея создать виртуализационное решение для MAC серверов, аналогичное продукту PSBM (parallels server bare metal). Интересно, что продукт вышел из research-состояния, прошел этап разработки и даже добрался до тестирования. Но дальше выяснилось два неприятных нюанса. Во-первых, Apple всегда славилась закрытостью части критически важных элементов систем, например BIOS, что в свою очередь приводило к проблемам на определенных вариантах аппаратных конфигураций. Полностью решить эти проблемы никак не удавалось. Кроме этого стало известно, сначала на уровне слухов, что Apple не будет развивать серверную линейку, и мы решили закрыть проект. Что же, оказалось, что решение было правильным – и в 2010 году Apple действительно отказалась от серверов, а разработанный нами продукт так и не был анонсирован.

Второй проект, о котором хочется рассказать, увы, не вышел даже из стадии research, хотя изначально казался весьма привлекательным. Мы работали над созданием прототипа так называемого Meta-PC – инструмента, который позволил бы создавать среду исполнения для одновременной работы на нескольких серверах, используя их общие мощности для одного приложения. При успешной реализации такой продукт давал бы возможность вертикально масштабировать приложения, а также предоставлять одному процессу больше CPU и RAM, чем может предоставить один компьютер или сервер.

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

Существуют примеры проектов, закрытых и на более поздних стадиях, после многих успешных лет на рынке Так, например, решение для работы с контейнерами ОС в экосистеме Microsoft Windows было в составе нашей продуктовой линейки около 10 лет! Система была разработана, опробована и запущена, у нее были свои пользователи, проект развивался. Но чем дальше – тем больше, работать с закрытым ядром Windows было все сложнее, и более комплексные запросы клиентов оказывалось просто невозможно реализовать. Да, Windows имеет достаточно много API, но они предназначены не для таких задач. И попытки использовать элементы ядра для запуска контейнеров ОС стали напоминать попытки найти что-то в черном ящике, когда в него можно лишь засунуть руку через отверстие и перебирать содержимое вслепую. Поэтому в 2015 году проект было решено закрыть, сосредоточившись на контейнеризации в Linux, где исходный код ядра доступен и поэтому может быть легко использован из контейнеров операционных систем.

Заключение

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

Еще тогда многие говорили о том, что подобную схему не удастся реализовать, но у нас получилось! Когда это заработало, мы пытались предложить инструменты для «живой миграции» включить в ядро Linux. Но практика показала, что сообщество далеко не всегда принимает все предлагаемые новшества, а вносить их в каждую последующую версию ядра самостоятельно очень накладно. И тогда было решено развивать систему резервного копирования в пользовательском пространстве. Так и получился проект CRIU (www.criu.org), который не только стал ведущим инструментом в сфере «живой миграции», но и смог все же сделать свой вклад в ядро Linux, чтобы инструментарий работал во всех версиях Linux. Так что экспериментировать полезно, даже если вы не знаете, будет ли отдача от проекта.