Совершенствование технологий привело к рождению новой экономики с иными законами и новыми возможностями, а это, в частности, означает, что проприетарные экосистемы, не получающие развития, которое обеспечивается обширным живым сообществом, начинают все больше отставать от рынка. Однако и в репозиториях Open Source нет готовых программных продуктов на все вкусы, там лежат проекты, которым еще предстоит стать продуктами. О перипетиях этого пути рассказывает Роман Шапошник, эксперт в области Open Source, активист Apache Software Foundation и Linux Foundation. Роман — участник Совета Apache Software Foundation Legal Committee, директор направления Open Source в компании Pivotal, вице-президент Linux Foundation по ODPi — некоммерческой организации по стандартизации экосистемы больших данных. Кроме того, он один из разработчиков проекта Apache Hadoop и сооснователь проекта Apache Bigtop — ядра всех коммерческих дистрибутивов, построенных вокруг экосистемы Apache Hadoop. Помимо этого, он отвечает за Apache Incubator и любит хорошее пиво.
Ваш послужной список весьма обширен. Но каково ваше самое крупное личное достижение на данный момент?
Это проект Apache Bigtop. Для меня важно, что созданный для него код широко распространился и присутствует сегодня во множестве проектов. Тот факт, что мое имя фигурирует во многих популярных проектах Open Source, позволяет не заботиться о поиске работы, давая свободу в отношениях с работодателями.
Что сейчас происходит на рынке дистрибутивов Hadoop, заметно ли движение к общему знаменателю?
Еще совсем недавно таких дистрибутивов было великое множество: Cloudera, Hortonworks, MapR, IBM, Pivotal — и это только наиболее известные клоны. Такая ситуация часто приводила к несовместимости решений на базе Hadoop и, как следствие, требовала немало времени на поддержку различающихся между собой дистрибутивов со стороны разработчиков приложений. На первых порах казалось, что Hadoop, как и Linux, станет некой универсальной платформой. Но этого не случилось, и проекты экосистемы Hadoop от Apache просто заняли свою нишу в иерархии компонентов для сбора инфраструктуры, предназначенной для управления данными. Попутно вокруг образовалось много кусков, имеющих весьма опосредованное отношение к Hadoop. Поэтому и появился проект ODPi, и сегодня корневая часть для всех дистрибутивов Hadoop стандартизирована. Последней свой нетривиальный дистрибутив собрала корпорация IBM, но затем она свернула эти разработки, сделав выбор в пользу ODPi. Правда, остались еще Cloudera и MapR, но, по сути, они дистанцировались от Hadoop. Первая компания стала публичной, а значит, она должна объяснять инвесторам, в чем состоит ее бизнес, и в этом объяснении нет слов про Hadoop, зато часто встречаются слова «data scientists». Рыночные позиции второй сегодня крайне неустойчивы. Как результат, теперь все ключевые продукты, созданные на базе стека Apache Hadoop (Hortonworks, IBM IOP, Arenadata и т. д.), полностью совместимы между собой. Это и есть главная заслуга ODPi.
Как строятся взаимоотношения Apache Software Foundation и Linux Foundation?
Эти организации хорошо дополняют друг друга. Apache Software Foundation создавалась для обеспечения взаимодействия разработчиков ПО, которые сотрудничают так, как будто бы забыли про своих работодателей. Здесь изначально нет какой-либо аффилированности разработчиков с компаниями: все приходят работать в Apache Software Foundation только в качестве индивидуумов, а не сотрудников той или иной компании. Это общественная организация, и за работу в ней не платят, что отражает очень распространенную в США идею самоорганизации, предполагающую не анархию, а наличие структуры, в которой должен быть человек, отвечающий за подготовку отчетов, координацию деятельности и пр. Apache Software Foundation выросла из Internet Engineering Task Force — организации, по сути подарившей нам Интернет и еще в 70-е годы заложившей принципы, по которым до сих пор живет Сеть. Apache Software Foundation имеет плоскую организационную структуру, в ней отсутствует какой-либо принудительный менеджмент, в том числе технологический. Никто не может, пользуясь своим авторитетом, приказать делать что-то. Это типичный пример меритократии, высвобождающей творчество по принципу «пусть расцветают сто цветов», поэтому в Apache Software Foundation возможно появление нескольких проектов, решающих одну задачу разными способами. Например, есть HBase и Accumulo — два совершенно разных проекта, решающих одну задачу, причем даже совместимых.
Возникает вопрос: а что же делать с этими «цветами»? Наверное, их надо собирать в «букеты», которых также может быть множество. Обычно этим занимались вендоры. Они выбирали, взять ли, скажем, Hbase или Accumulo, и делали на их основе коммерческие продукты, которые решали конкретную задачу и, возможно, включали проприетарный код. Именно вендоры были «судьями» проектов, выходящих из недр Apache Software Foundation, однако для продуктов, предназначенных не для корпоративного, а для массового рынка, еще требуется обеспечить их совместимость. Поэтому мнение о том, как собирать «букеты», хотелось бы иметь не на уровне отдельного вендора, а на уровне всей индустрии. Эту задачу и берет на себя Linux Foundation: в рамках этой организации вендоры договариваются о том, как должна выглядеть общая для всех продуктов платформа. Здесь обычно используется понятие value line («водораздел»), или линия генерации дохода. Выше нее лежит зона конкуренции вендоров, предлагающих свои коммерческие продукты, построенные на платформе, а обсуждение спецификаций происходит ниже линии — здесь вендоры сотрудничают, решая вопросы совместимости. В этом смысле ODPi — яркий пример такого подхода применительно к Hadoop, когда базовая часть продукта, предназначенного для работы с большими данными, должна быть унифицирована. По сути, Linux Foundation — мудрый метавендор, надзирающий за тем, чтобы отдельные вендоры не занимались дележом зарождающегося небольшого рынка, а совместными усилиями расширяли его с целью заработать больше. Многие ошибочно думают, что фонд до сих пор занимается только операционной системой Linux, на самом же деле его давно пора переименовать в Open Source Foundation. Под эгидой фонда выполняется очень много проектов — например, проект построения мультиоблачной среды Cloud Foundry или ODPi, которые имеют мало общего с Linux. Кстати, и ODPi как организация также уже переросла Hadoop, и ее следует, возможно, переориентировать с Hadoop на стандартизацию лучших в своем классе архитектур анализа данных.
Критики Open Source утверждают, что «вольные» разработчики участвуют в проекте, пока им интересно, а когда начинается рутина, переключаются на другое. А ведь продукт уже вышел на рынок...
Наличие сильного сообщества, развивающего продукт, — один из основных сегодня факторов, влияющих на решение о приобретении ПО. Если раньше при покупке продукта учитывались цена, соответствие стандартам, дееспособность вендора в обозримой перспективе, то сейчас на первый план выходят размер и жизнеспособность соответствующего сообщества Open Source. Гарантии того, что сообщество вдруг не свернет такую работу и не займется чем-то другим, нет, однако вероятность этого обратно пропорциональна размеру сообщества. Кроме того, часто вендоры сами инвестируют в сообщество, поддерживая его жизнеспособность. Например, корпорация IBM привлекла тысячу разработчиков для поддержки Apache Spark, она же поддерживает Cloud Foundry Foundation.
Сегодня много говорится о том, что Open Source становится одним из определяющих факторов цифровой трансформации. Так ли это и почему?
Проприетарные экосистемы устаревают без развития, обеспечиваемого обширным живым сообществом. По сути, Open Source играет сегодня ту же роль, какую в 70–80-е годы играла стандартизация. Но если тогда, к примеру, продукт IBM должен был удовлетворять стандартам IEEE, которые были результатом многолетнего труда относительно небольших экспертных групп, то сейчас индустрия не может годами ждать появления спецификаций, иначе она просто не успеет за рынком. Сегодня роль такого института по стандартизации де-факто и стало играть сообщество Open Source. Однако имеется один нюанс. Главная ошибка заказчиков состоит в том, что они считают, будто все, что лежит в репозиториях Open Source, уже является программным продуктом, но на самом деле там находятся проекты, которые по мере своего развития, роста популярности и проверки временем накапливают в себе черты фактических стандартов. Считать, что можно сразу эксплуатировать проект, — это все равно что применять «бумажный» стандарт. Что-то, конечно, можно будет сделать, но остается еще масса вещей, которыми должен заниматься вендор, выпускающий продукт на основе конкретного проекта.
Цифровизация привела к тому, что традиционные ИТ-вендоры стали чувствовать себя очень неуверенно. Как утверждают в Gartner, к 2020 году 70% программного обеспечения, используемого в корпорациях Fortune Global 500, будет написано внутри них самих, а не приобретено извне. Иначе говоря, традиционный бизнес, не связанный с ИТ, будет сам создавать себе ПО. Конечно, сервисная поддержка останется, но высокомаржинальный бизнес продажи лицензий на ПО уходит. Кроме того, всеобщая автоматизация, роботизация и широкое применение систем искусственного интеллекта, способных принимать более эффективные решения, чем человек средней квалификации, потенциально могут привести к массовой безработице. Даже далекие от ИТ люди ощущают (хотя еще и не полностью осознают), что технологии породили грандиозный сдвиг.
Останется ли в цифровую эпоху пресловутая «стена» между бизнесом и ИТ?
Если на поле, где до сих пор работали лишь ИТ-компании, приходят вендоры из других бизнесов, то стена рушится сама собой — бизнес самостоятельно делает себе ПО. Наиболее прогрессивные компании во всех отраслях уже активно работают в этом направлении, переобучая сотрудников, переформатируя организационную структуру и т. п. Компания Amazon из обычного, по-сути, онлайн-ретейлера превратилась в ведущего ИТ-игрока, а IBM из ведущего поставщика ИТ-решений — в провайдера цифровых сервисов. Таких примеров миграции в обе стороны можно привести немало.
Ваш нынешний визит в Россию связан и с участием в третьей международной конференции по базам данных PG Day’17 Russia. Какие вы видите тенденции в области СУБД?
В рамках этой конференции, прошедшей в Санкт-Петербурге в начале июля, мы провели Greenplum Day, в ходе которого рассказали о Greenplum, одной из успешных баз данных с массовым параллелизмом (MPP), построенных на основе PostgreSQL, а также об опыте ее эксплуатации в России. На мой взгляд, само понятие «СУБД» устарело, и так уже не говорят; точнее другой термин — «платформы по управлению данными». Самая главная тенденция состоит в том, чтобы на месте «СУБД» появилось некое почти «коробочное», но в то же время максимально гибкое решение для управления данными. Долгое время проработав в компании Cloudera, я считал, что такой «коробкой» станут Hadoop, Cassandra, Kafka, но вдруг выяснилось, что ближе всех к ней подошла компания SAP со своей системой HANA. Однако и в ней еще недостает многих «запчастей» — например, систем глубинного обучения, интегрированных непосредственно в базу данных. Сегодня, вместо того чтобы покупать, как говорят аналитики Gartner, best-of-breed («лучшее в своем классе коробочное решение»), принято самим строить архитектуру, которую описывают словами best-of-fit («решение, наиболее приспособленное для
конкретной задачи»), взяв популярные стандартные компоненты и интегрировав их в рамках информационной системы заказчика под его конкретные требования. Многообразные облачные сервисы в одной коробке не уместятся, поэтому логичнее говорить не о коробочном решении, а о конструкторе, из которого ребята из компаний типа Arenadata создают кастомизированное решение (правда, совсем «правильные» ребята, условно из «Тинькофф Банка», могут все это сделать и поддерживать самостоятельно). Все коды и спецификации открыты, и ничто не мешает взять и сделать. В этом и состоит основная тенденция в области платформ управления данными, и здесь ключевую роль играет Linux Foundation.
Что, по вашему мнению, требуется российскому ИТ-сообществу, чтобы играть более заметную роль в мировом движении Open Source?
В стране очень много умных людей и хороших программистов, но почему-то они слабо интегрированы в мировое сообщество. Есть версия, что этому не учат в вузах — учат научному подходу, думать, но не работать. Лично мне повезло: с четвертого курса СПбГУ я подрабатывал в Sun Microsystems с подачи профессора Владимира Олеговича Сафонова, который был очень озабочен проблемой слабой интеграции российских специалистов в мировое ИТ-сообщество. Некоторое количество российских программистов есть и в Apache Software Foundation, но все-таки россиянам трудно понять, по каким законам существуют все эти сообщества и фонды: этому кто-то должен научить, либо надо самому поработать в западной ИТ-компании — и чем раньше, тем лучше.
Какими навыками должен владеть современный разработчик?
Разработчик должен обладать тремя главными качествами.
Первое — знать инструментарий: системы управления кодом, такие как Git; системы командной разработки кода, такие как GitHub или Gerrit; системы непрерывного производства и развертывания кода (continuous delivery and deployment). Если раньше хорошему программисту достаточно было владеть теоретическими знаниями (математика, алгоритмы), то сегодня в программировании наступил век постмодернизма: большие идеи встречаются все реже, и для решения задачи достаточно скомбинировать готовые куски. Но в этом случае растет коммуникативная роль архитектуры по использованию в ней готовых форм. Часто клиенты приходят к нам именно за сквозной платформой, позволяющей всем разработчикам их компании работать как единый организм. Успешные компании, в том числе Google, Facebook и LinkedIn, подчеркивают, что их успех был обусловлен именно наличием платформы ускорения создания ПО. Все это подразумевает обязательную эрудицию разработчика в алгоритмической сфере и понимание окружающего пространства, а этого сложно достичь в России, программисты которой не погружены в сообщество. Например, в Кремниевой долине за один день можно обойти несколько митапов и понять, что происходит в конкретной области.
Второе — умение работать в команде, навык, который даже в США далеко не всем просто дается. Время одиночек прошло.
Третье — хороший разработчик должен обладать технологическим вкусом. Это, пожалуй, одно из самых важных, но и самых эфемерных требований, которое сложно определить. Но, прочитав код, можно сразу понять, есть вкус или нет. Причем желательно, хотя и необязательно, чтобы стилистика написания кода совпадала с командной.
Если же говорить о требованиях к команде, то очень важно иметь разнообразие мнений, культур и подходов, поэтому на собеседованиях, кроме традиционных вопросов по технологиям, я обязательно спрашиваю кандидатов, что им нравится помимо работы, чем они занимаются в свободное время.
Все чаще говорят еще об умении общаться, понимать запросы бизнеса и менталитет сообщества; якобы это даже важнее умения кодировать...
В Америке обучение общению — обычная практика, в выходные мы часто проводим такое обучение для студентов, предлагая им сделать свой первый вклад в проект Open Source по их выбору. Важно не просто написать программу или предложить алгоритм решения задачи, а сделать так, чтобы эта работа попала в один из проектов. Мы объясняем, каким инструментарием пользоваться, раскрываем социальные аспекты взаимодействия. Однако и в традиционных американских компаниях нередко слабо понимают, как взаимодействовать с сообществом Open Source. В этом смысле показателен известный эксперимент исследователей из МТИ, которые, собрав две группы, предложили им сделать горшок из глины. Первая группа получила возможность сделать лишь один горшок без права на ошибку, а второй группе было позволено сделать множество горшков и обещано какое-то вознаграждение, даже если они не создадут самый хороший экземпляр. Именно во второй группе и был произведен объективно самый хороший горшок. Мир динамичен, ни в одной сфере нет чего-то незыблемого. Например, если еще совсем недавно любителям пива я бы рекомендовал отправиться в Прагу, то теперь — в Портленд (штат Орегон), где, конечно, есть свои стандарты пивоварения (но минимально возможные) и где, как и в Open Source, царит атмосфера активного движения и поиска лучшего среди разнообразного.
Сегодня в России модно создавать национальные программные системы. Помогает ли это достижению технологической независимости страны?
Мне кажется, здесь налицо терминологическая путаница. Россия до сих пор живет понятиями 90-х годов, когда считалось, что продукт обязательно должен быть сертифицирован, соответствовать формальному стандарту на него, поэтому должен быть вендор — кто-то, кто этот сертификат получит. А если есть такой субъект, то тут уже начинается бюрократия: на какой территории он размещается, кто внес доли в его уставный капитал и пр. Все это мешает. На самом деле говорить надо не о развитии самостийного национального продукта, продвигаемого конкретным «вендором», занесенным вместе со своим изделием в некий реестр, а об инвестициях в сообщество Open Source. В этом смысле, например, далеко продвинулось правительство Германии, которое пошло не по пути создания немецкой операционной системы или национальной офисной платформы, а приняло решение перейти на свободное ПО. В этой связи я бы порекомендовал Минобрнауки на уровне университетов инвестировать в открытое ПО; этого будет достаточно и для интеграции выпускников российских вузов в мировое ИТ-сообщество, и для формирования конкурентоспособных команд разработчиков, способных в современных реалиях создавать продукты для цифровой экономики.
Почему в Apache Software Foundation появился проект Apache IoT?
Кремниевая долина, наподобие индустрии моды, живет трендами. Находясь там, глупо их игнорировать — хотя бы потому, что не о чем будет поговорить за обедом. Если недавно таким трендом были большие данные, то сейчас в Долине считают эту проблему в целом решенной, за исключением незначительных деталей. А вот Интернет вещей, причем на его границах (на оконечных устройствах), — это горячая сегодня тема: какой должна быть архитектура окружающих нас устройств, как ими управлять и защитить от кибератак, как связать между собой и с облаком, как сделать автономными и способными самостоятельно распознавать себе подобных, как стандартизировать. Никто не понимает, как это будет выглядеть, поэтому все инвестируют в эту сферу огромные средства, а как только появится понимание того, как все это должно быть устроено, появится какой-нибудь новый тренд. Естественно, на фоне того, что различные венчурные фонды все больше инвестируют именно в компании, связанные с Интернетом вещей, и Apache Software Foundation, чтобы не отстать, начинает работать в этом направлении.
Что в планах у Apache Software Foundation и Linux Foundation?
Один мой друг из НАСА как-то позвонил мне и спросил, есть ли у меня алгоритмы для запуска на квантовых компьютерах. Я спросил: вы что, D-Wave купили? — Да. — У меня нет. — Вот и у нас нет. Как бы то ни было, это интересное направление. Возвращаются старые добрые времена, когда профессора в белых халатах — создатели первых ЭВМ — снова работают вместе, переждав эпоху, в которую произошло разделение на оборудование и ПО. Кроме того, грядет четвертая индустриальная революция, обещающая, что предприятия обезлюдят. Например, недавно Amazon открыла магазин без продавцов и без касс: покупатель идентифицируется при входе в торговый зал, а стоимость выносимых им товаров списывается с его банковского счета. Хочется надеяться, что, в отличие от предыдущих технологических революций, приводивших к общественным катаклизмам, человечеству хватит ума пережить ее и мы увидим ее плоды. Технологии в этой революции, конечно, сыграют огромную роль, и Apache Software Foundation и Linux Foundation, безусловно, не останутся в стороне, однако не стоит забывать, что мы все ответственны за то, что создаем.
