OpenStack нужна не одна «шляпа»

в 11:03, , рубрики: ceilometer, Hadoop, linux, open source, openstack, red hat, Блог компании Mirantis/OpenStack, мирантис, открытый код, метки: , , , , ,

Автор: Ник Чейс

Похоже, становится модным ругать OpenStack. Это естественно, каждая технология испытывает болезнь роста, когда она уже достаточно продвинутая, чтобы люди захотели ее использовать, но не настолько продвинутая, чтобы оправдать 100% ожиданий всех и каждого.

OpenStack, кажется, сейчас находится на этом этапе. Gartner жалуется на то, что OpenStack не хватает сфокусированности. Один из бывших участников сетует на то, что Ceilometer представляет собой … меньше, чем должен. А теперь и Мэтт Эсей (Matt Asay) из ReadWrite присоединился к этому большинству, считая, что в OpenStack должен быть лидер, и номинируя на эту позицию компанию Red Hat (англ. красная шляпа).

Мэтт считает, что OpenStack не может развиваться должным образом без сильной руки и что Red Hat лучше всего подходит на роль такой сильной руки, которая бы руководила направлением развития OpenStack (или даже контролировала его).

Я никоим образом не отрицаю значимость Red Hat в проекте OpenStack. Все-таки это участник №1 по объему вносимого в базу кода; с этим никто не спорит. Но я бы определенно не согласился с некоторыми из доводов Мэтта.

«Нет» – не всегда правильный ответ


Мэтт считает, что на нынешнем пути развития OpenStack имеются серьезные проблемы.

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

С одной стороны, урон OpenStack наносит хаотичное управление продуктами. Лучшие проекты по разработке открытого ПО, такие как Linux, имеют сильную команду немногочисленных управленцев, которым известна цена слова «Нет». Но OpenStack стремится говорить «Да» каждой новой функции, которая не гарантирует ни совместимости, ни решения сложных и нудных проблем. Это может быть вызвано отсутствием ясного видения того, чем является, а чем не является OpenStack, согласно Gartner.

Частично проблема, упомянутая в данном утверждении, может быть обусловлена некоторой неразберихой не с тем, чем является/не является OpenStack, а, скорее, с тем, что относится, а что не относится к OpenStack. Тот факт, что какой-то проект начат и над ним ведется работа, еще не означает, что он включен в состав OpenStack.

Кроме того, не жаловались ли всего несколько месяцев назад те же самые эксперты, которые сейчас сетуют на то, что OpenStack делает слишком много, на то, что мы вводим новшества недостаточно быстро, чтобы конкурировать? Даже Мэтт недоволен тем, что в OpenStack недостаточно инноваций. Инновация является результатом возможности развивать проект, поскольку он видится важным. Нельзя иметь поистине инновационную среду, в которой один вендор может завернуть проект в одностороннем порядке.

Участники OpenStack – не разработчики-любители


Отчасти, полагает Мэтт, проблема заключается в том, что разработчики OpenStack работают над тем, что их интересует, а не над решением упомянутых «сложных и нудных проблем». Но он делает предположение, которое в целом неверно по отношению к OpenStack.

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

Я не намекаю на то, что OpenStack не может лучше удовлетворять потребности пользователей и операторов; это совсем другая задача. Но представление разработчиков OpenStackкак людей, которые участвуют в проекте «из любви к разработке» в корне ошибочно. Да, почти все они делают свое дело с большим энтузиазмом. И почти всем им платят за это.

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

Победитель получает самый большой куш


Мэтт также утверждает, что любой проект, который начинается, как OpenStack, в итоге приведет к ситуации «победитель получает все».

Разработка свободного ПО обычно осуществляется по принципу «победитель получает все». В компании Linux победитель (Red Hat) получил все. В Android победитель (Samsung) получил все. Проекты на базе открытого кода, реализуемые организациями с участием большого количества вендоров продуктов, в дальнейшем подлежащих доработке, почти всегда заканчиваются сценарием «победитель получает все». Да, этого еще не произошло в Hadoop, но это исключение, а не правило.

Знаете, как говорят на фондовом рынке: «прошлые показатели не говорят о будущих результатах». OpenStack является проектом по разработке свободного ПО под эгидой некоммерческой организации, это правда. Но по ряду причин он отличается от Linux или Android.

Во-первых, в нем просто слишком много ведущих игроков, чье будущее определенным нетривиальным образом зависит от OpenStack. IBM, Dell, AT&T, Cisco, HP и 23 другие компании (в том числе, конечно, Red Hat) взяли на себя обязательства не только по оказанию финансовой поддержки OpenStack, но и «по согласованию стратегий с миссией OpenStack». И HP, и IBM запустили публичные облака, как минимум, отчасти работающие на базе OpenStack. Они не собираются уступать и не позволят какому-то другому вендору диктовать им направление развития проекта.

Также есть ряд индивидуальных участников, с которыми нужно считаться. Несмотря на невероятные оценки, согласно которым над ядром Linux работало несколько тысяч человек, на самом деле после 20 лет его существования в файле CREDITS версии Linux 3.10 перечислено менее 600 имен. Всего за 3 года в OpenStack приняло участие почти в два раза больше людей, и это за один цикл разработки.

Что касается Android, он изначально не был проектом с рядовыми участниками, будучи запущенным внутри Google.

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

Делая то, что лучше всего


Я много говорил на тему того, может ли Red Hat взять на себя роль «лидера» OpenStack, но только время даст ответ на этот вопрос. Вместо него основной вопрос, который необходимо задать, – хорошо ли это было бы?

Очевидно, это было бы хорошо для Red Hat. Мэтт прав, говоря о том, что OpenStack имеет лучшие шансы (по крайней мере, на данный момент) в сфере частных облаков, где мы не конкурируем с Amazon, и, безусловно, Red Hat является вендором, который получил бы наибольшую выгоду на этом рынке. И, конечно, для OpenStack было бы неплохо иметь такого пропагандиста с большими возможностями, который бы привел ее в клуб компаний-участников.

Но это не есть контроль над направлением развития проекта. Является ли разработка OpenStack хаотичной? Безусловно. Является ли каждая идея хорошей? Конечно, нет. Но великие идеи обычно не появляются в упорядоченном процессе «запланированной поездки». Если они и возникают, то из подобного хаоса, поскольку этот хаос питают потребности реальных клиентов, которым нужны реальные решения прямо сейчас. Если бы один вендор попытался оказать влияние на то, чтобы проект развивался в правильном, на его взгляд, направлении, мы бы получили проект, который был бы достаточно хорош в одном, – в том, чего хотел один вендор. Но чьи-то еще сценарии использования могли быть с легкостью проигнорированы и даже приказать долго жить.

OpenStack как раз и интересен тем, сколько компаний, которые при обычных обстоятельствах являются конкурентами, сотрудничают, чтобы сделать OpenStack как можно лучше. Сколько из них покинули бы проект, если бы им пришлось подчиниться желанию Red Hat создать продукт, подогнанный под нужды Red Hat?

Когда вопрос о «лидерстве» возник в последний раз, наш генеральный директор Адриан Ионел (Adrian Ionel) отметил, что, несмотря на то, что лидерство важно, оно не настолько важно, как импульс. Мэтт утверждает, что проекты, развитию которых придали импульс, могут провалиться, приводя в пример OS/2 и OpenOffice. Что касается OS/2, это не был проект с открытым исходным кодом; за ним стояли две компании (Microsoft и IBM), одна из которых также была конкурентом. А что насчет OpenOffice? Да, это правда, что, купив Sun, компания Oracle (также единственный вендор) не захотела дальше нести эту ношу. Поэтому она передала ее Apache Foundation, которая анонсировала в октябре, что количество скачиваний ее версии ПО превысило 75 миллионов менее чем за полтора года.

Невероятно, что может сделать импульс развития.

Отвечая на жалобы


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

Поэтому, несомненно, круто ругать OpenStack и говорить, что «что-то обязательно нужно сделать», чтобы изменить проект. Но факт в том, что OpenStack пройдет через этот «трудный подростковый» период, когда он еще неуклюж и когда старшие думают, что «кто-то должен взять мальчика за руку». Можно ли усовершенствовать нынешний процесс? Безусловно. Но сообщество может сделать это самостоятельно, без того, чтобы «папа» (или «мама») говорили ему «прибраться в комнате».

Оригинал статьи на английском языке

Автор: Mirantis_OpenStack

Источник

Поделиться

* - обязательные к заполнению поля