Software ecosystems: принципы построения

У этой статьи тяжелая судьба. Пару месяцев назад меня попросили написать обзор на предмет построения программных экосистем для разных архитектур. Я поначалу отнекивался да отшучивался в том духе что, экосистема –это не биология. Это — даже не технология. Это — исключительно про деньги. И иногда про политику. Потом собрал волю в кулак, мысли в кучу, cел и написал все буквально за один день. На английском. Затем обзор перевели на китайский и опубликовали. “По дороге” переводчик существенно улучшил текст и добавил пару интересных мыслей. Потом я решил, что текст может быть небезынтересен аудитории Хабра, а также полезен мне, чтобы ссылаться на него в дальнейшем. И начал ваять русский вариант, вооружившись английским оригиналом и китайским переводом. Это была та еще борьба со специфичными английскими терминами (SW ecosystem ?= программная экосистема, enabling ?= продвижение, application engineer ?= инженер по приложениям) и малопонятными пока иероглифами. В итоге русский текст занял больше времени, чем английский и китайский вместе взятые… Так бывает.

Преамбула.

За последние четыре или пять десятилетий мы наблюдали много усилий по выводу на рынок новых процессорных и микроконтроллерных архитектур. Очень немногие из них оказались успешными в долгосрочной перспективе. Два наиболее показательных примера: архитектура х86 для серверов и ПК и ARM для мобильных телефонов и микроконтроллеров. Остальные либо занимают (занимали) небольшую нишу, либо существовали недолго. Безусловно, одним из ключевых компонентов успеха вычислительной архитектуры в целом является её способность удовлетворять наиболее важные запросы клиентов в соответствующем сегменте. Для серверов таким запросом является производительность, для мобильных устройств – низкое энергопотребление/длительное время автономной работы. Но еще одним важным фактором является наличие богатой программной экосистемы, которая позволяет эффективно разрабатывать новый софт, а также портировать существующий. Создание экосистемы является очень длительным и дорогостоящим процессом, поскольку необходимо разработать все необходимое прикладное программное обеспечение. Ho только таким образом архитектура может занять целевой сегмент рынка. Однако, как только экосистема разработана, она начинает служить в качестве естественного защитного механизма, предотвращая проникновение конкурирующих архитектур на рынок. В этой статье автор обобщает ключевые выводы из опыта, в применении к задаче построения ARM-экосистемы в серверном сегменте рынка.

Сегодняшний вызов:

Сегодня мы, возможно, наблюдаем самое интересное время на рынке микроэлекторники. В отличие от того, что было 5 лет назад, когда Intel контролировал 95% корпоративного рынка, сегодня у нас больше архитектурных инноваций, чем когда-либо. Первым упомянем чипы серии Ryzen, которыe составляют серьезную конкуренцию Intel. Однако эта инновация не является архитектурной: процессоры AMD используют разработанную экосистему х86. Их преимущество заключается в эффективной имплементации. Другие инновации интересннее, так как они требуют построения новой программной экосистемы.
«Революция искусственного интеллекта», начатая и возглавляемая NVidia, кардинально изменила ландшафт серверного рынка. Она создала совершенно новый сегмент, почти исключительно контролируемый его создателем. В основе его ― платформа параллельного программирования CUDA. CUDA (впервые представленная в 2007 году) является одним из интересных примеров построения экосистемы, мы рассмотрим его более подробно позднее. В свою очередь, Intel пытается представить свой собственный графический процессор (частично основанный на графической системе Gen), чтобы конкурировать в области искусственного интеллекта. Для создания среды программирования Intel представил набор инструментов OneAPI. Это амбициозная концепция универсального метода программирования ускорителей (GPU, AI, FPGA и т.д.). Кроме того, Intel использует для OneAPI открытый исходный код, что делает интерфейс более привлекательным, чем у моделей с закрытым исходным кодом. В концепции OneAPI центральную роль играет Data Parallel C++. Это ― набор C++ расширений на основе стандарта CYCL. Мне кажется, успех этой интересной попытки будет зависеть от включения данных расширений в будущие стандарты C++. А также от эффективной реализации интеловского GPU. Последним примером является проникновение архитектуры ARM в область искусственного интеллекта, облачных и высокопроизводительных вычислений. Архитектура ARM известна своим успехом на рынках низкого энергопотребления и имеет значительную экосистему ПО. Поэтому попытка проникнуть в более высокие сегменты рынка выглядит естественно. Это самый интересный для нас случай, и мы рассмотрим его более подробно с различных точек зрения.

Технология.

Технологические предпосылки я приводил тут.

Экономика.

Усиление конкуренции Intel со стороны AMD привело к существенной «ценовой войне» между процессорными гигантами. Это урезает доходы производителей, но облечгает жизнь конечным пользователям. Напротив, в области искусственного интеллекта мы наблюдаем доминирование NVidia, которая диктует цену рынку. И здесь потребители активнее ищут альтернативные системы.

Политика.

В связи с усилением геополитической напряженности Китай и Россия взяли курс на развитие 100% независимой экосистемы. Однако это означает не только независимость аппаратного обеспечения. Не менее важную роль играет софт. Многие приложения должны быть перенесены или заменены для обеспечения истинной независимости. Нижеприведенная картина иллюстрирует ситуацию в России.

Политический фактор создает сильный спрос на ресурсы для устранения пробелов в ПО и долгосрочную поддержку для этих усилий. Существует несколько мощных сил, стоящих за созданием экосистемы ARM. Но есть и очень серьезные проблемы. Позвольте мне назвать несколько из них:

Типичная для ранних стадий «проблема курицы и яйца»:

Некоторые коммерческие приложения с закрытым исходным кодом становятся де-факто стандартом для важных сегментов. Например, SAP-Hana, Oracle для баз данных, VMWare для виртуализации и т.д. Обычно разработчики не заинтересованы в переносе и сопровождении своих продуктов на архитектуре, которая не имеет достаточной доли рынка. С другой стороны, конечные пользователи не покупают оборудование, которое не поддерживает это ПО. Существует несколько способов разорвать этот «порочный круг». Первый ― заплатить (огромные) деньги компаниям-разработчикам ПО за портирование. Второй ― создать конкурентное решение, которое либо вытеснит продукт с рынка либо вынудить желательное портирование. Третий ― убедить кого-то из больших кастомеров разработчика “надавить” на него. Однако ни один путь не является ни простым, ни дешевым.

Legacy Software.

Большая часть приложений на серверном рынке десятилетиями писалась и оптимизировалась для доминирующей архитектуры х86. Явно или неявно ставка в большей степени делалась на однопоточную производительность, чем на массивный параллелизм. Таким образом, даже если исходный код доступен, может потребоваться значительная переделка и оптимизация для успешной работы на ARM серверах.

На горизонте стоит немало проблем, и для их решения нам следует изучить

Уроки прошлого.

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

В самом начале.

Когда Intel выпускала свой первый 8-битный процессор 8080 в середине 70-х годов, у нее не было особых архитектурных преимуществ по сравнению со своими конкурентами Motorola 6800 или Zilog Z80. Тем не менее Intel впервые осознал важность программного обеспечения для продвижения железа. Она также первым представил собственный компилятор для ускорения, упрощения и удешевления разработки софта. Именно инструменты создали важное конкурентное преимущество для Intel, и позволили ей добиться успеха на ранних этапах. Позже Intel представила MKL для линейной алгебры, VTune для оптимизации программ и многие другие инструменты, которые играли важную роль в формировании х86 экосистемы. Более того, Intel гарантировала совместимость своих инструментов. Позже Intel была осознана важность ОС, которая управляет работой железа. Её тандем с Microsoft (Wintel) стал доминирующей силой на рынке ПК в течение примерно трех десятилетий. Однако с развитием серверного рынка ОС Linux и открытый исходный код в целом, стали очень актуальны. Таким образом, Intel стал главным контрибьютором в ядро Linux, и до сих пор занимает позицию номер 1 (угадаете кто номер 2?). Самое главное — Intel всегда строго придерживалcя бинарной совместимости (Backward compatibility) своих платформ. Тот факт, что бинарные файлы, созданные для любого предыдущего поколения архитектуры, работают на более позднем поколении «из коробки», и позволил х86 стать доминирующей силой. Создание экосистемы требует времени, но оно того cтоит.

Восход и закат Солнца.

Это единственный контрпример, когда развитая экосистема сыграла против своего создателя. В начале 2000-х Sun Microsystems занимала значительную нишу на рынке серверов с архитектурой SPARC. Компания инициировала и развила экосистему Java. Проблема однако в том, что Java-машина основана на интерпретаторе, а не на компиляторе. Так что, когда обстоятельства заставили Sun открыть Javа, это стало началом конца. Реализовав интерпретатор Java для х86, Intel постепенно вытеснил Sun с серверного рынка. Урок, который можно извлечь — интерпретированные языки (столь популярные сегодня) не являются эффективной защитой рыночной доли.

Успех ARM на рынке низкого энергопотребления.

Архитектура АРМ лидирует на рынке сотовых телефонов и планшетов с начала 2000-х годов. Характер его доминирования сильно отличается от х86 в ПК и серверах. ARM это открытое сообщество – лицензия стоит относительно недорого, что создает предпосылки для вступления в игру большого числа игроков. А открытая операционная система Android, дополнительно снижает входной барьер. Так же свою роль сыграло то, что ведущие игроки (Samsung, Qualcomm, Huawei и т.д.) осознали необходимость индустриального альянса для создания экосистемы. Это позволило построить ее в очень сжатые сроки.

Попытка корпорации Intel вторгнуться на мобильный рынок.

Примерно в 2007 году Intel (или чуть раньше) осознал потенциал рынка мобильных телефонов и планшетов и предприняла попытку его завоевания. В основе проекта лежали архитектура Atom (х86 с низким энергопотреблением) и бинарная трансляция с ARM на х86 (Houdini). Этот механизм позволяет использовать существующую экосистему программного обеспечения. Приложения были запущены на устройствах Intel в рекордно короткие сроки. Однако против Intel сыграли два факта. Первый — неспособность догнать ARM в области энергопотребления. Второе — сложность бинарной трансляции из RISC в более сложный набор инструкций CISC. Такая трансляция предполагает значительные накладные расходы, которые могут быть неприемлемы для некоторых классов приложений. Таким образом, можно рассматривать бинарную трансляцию как инструмент входа на рынок, но он вряд ли может служить как долгосрочное решение.

Экосистема CUDA.

Хотя успех Nvidia в сегменте искусственного интеллекта неоспорим, развитие собственной экосистемы CUDA по-прежнему вызывает у меня вопросы. Например, в области высокопроизводительных вычислителений доля приложений, использующих CUDA, по-прежнему остается низкой. Причиной является высокая стоимость портирования и сопровождения (maintenance) таких приложений. Некоторые разработчики портировали (со значительной помощью инженеров NVidia) свои коды, но позже отказались от них из-за стоимости поддержки. Напротив, в сегменте искусственного интеллекта позиция NМidia чрезвычайно сильна. Тем не менее исследователи в основном используют структуры более высокого уровня (TensorFlow, PyTorch и т.д.) и не занимаются непосредственным программированием на CUDA. Это подводит нас к выводу, что правильный выбор уровня абстракции “софтовой обвязки” имеет большое значение для продвижения железа.

Назад в будущее.

Теперь давайте вернемся к нашей задаче, вооружившись уроками прошлого.

Индустриальный альянс.

Самая большая проблема экосистемы ARM в серверном сегменте, в отличие от мобильного, заключается в том, что она все еще очень фрагментирована. Нужен какой-то центр притяжения для согласования усилий. Альянс представляется вполне естественным, учитывая, что доля всех ARM-вендоров на серверном рынке составляет около 1%. У них просто нет причин конкурировать. Задача совместного построения экосистемы должна иметь приоритет над дифференциацией между собой. Был предпринят ряд попыток создания подобного альянса. Можно упомянуть Open Green Computing Consortium (openGCC – для программиста трудно придумать более дурацкое название), и наши недавние усилия в рамках ARM Advanced Technology Committee в рамках АПКИТ. Это может быть хорошим началом, однако оба эти альянса являются локальными. Open GCC ― является китайской организацией, а АПКИТ — российской. Индустрия диктует необходимость глобального альянса, который может служить нескольким целям:

Синхронизация и влияние на регулирующие органы.

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

Работа с поставщиками операционных систем и приложений.

Как мы видели из опыта, операционные системы играют центральную роль в создании программной экосистемы. Можно также заметить, что ОС, разрабатываемые поставщиками железа, исторически не были очень успешными (за исключением Apple). Так что работа с поставщиками ОС стратегически очень важна. Частично это происходит сейчас — патчи, обновления, появляющиеся в последних версиях ядра Linux, компиляторов и glibc, повышают производительность ARM-систем для самых разнообразных ворклоадов. Но эти усилия все еще очень фрагментированы, каждый поставщик делает это сам по себе, что обычно занимает довольно много времени. Альянс может помочь синхронизировать эти усилия и ускорить принятие обновлений.
Мы также увидели, что разрешение проблемы «курицы и яйца» на ранних стадиях продвижения архитектуры может быть очень сложным. Альянс сможет предоставить дополнительный вес в переговорах с поставщиками ПО и помочь разделить бремя раннего продвижения между производителями железа.

Система дистрибуции софта

Третьим важным моментом здесь является распространение программного обеспечения. Сейчас серверное программное обеспечение для ARM как правило собирается из исходных кодов, что требует времени и аппаратных ресурсов. В то время как для х86 есть удобная схема на основе RPM, используемая для дистрибуции. Создание чего-то подобного потребует огромной работы с независимыми поставщиками приложений и операционныx систем. И альянс может быть очень полезным для содействия в этом направлении.

Создание эффективного инсрументария.

В прошлом программные инструменты зарекомендовали себя надежным средством развития экосистемы. Поэтому сегодня внимание к ним имеет критическое значение. Один из лучших примеров ― это корпорация Intel, которая объединила разработчиков программных средств и инженеров по приложениям (application engineers) в одну организацию, как показано ниже. Красным отмечено критическое взаимодействие, зеленым -регулярное, желтым -спорадическое.

Это обеспечивает тесное сотрудничество между разработчиками инструментов. Это дает возможность аппликейшн инженерам (AE) использовать лучшие инструменты в отрасли. AE, работающие с одинаковыми ворклоадами обмениватются знаниями друг с другом и предоставляют консолидированную обратную связь архитекторам железа. И тд. И тп. Все это привело к интересным явлениям: инженеры, работающие в такой организации, начали думать не только о своей продукции, но и о широкой экосистемной картине. Они учитывают взаимозависимость между собой, а также влияние на экосистему в целом
Но чтобы создать такую организацию, нужен некий «общий язык», который все стороны смогут использовать для общения. В какой-то момент метод анализа микроархитектуры TMAM, стал таковым.

ТМАМ обеспечивает способ сбора, интерпретации и использования событий микроархитектуры для профилировки и оптимизации приложений.

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

Вывод.

Построение экосистемы ARM на серверном рынке выглядит перспективно с экономической, политической и технологической точки зрения. Однако, оно происходит на фоне серьезной конкуренции с доминирующей архитектурой x86. К тому же ранние проблемы продвижения архитектуры еще далеки от того, чтобы назвать их решенными. Однако я верю, что в будущем ARM сможет стать серьезной силой на серверном рынке. Создание глобального индустриального альянса и эффективной организации по построению экосистемы представляется очень желательным.
Построение экосистемы ARM на серверном рынке выглядит перспективно с экономической, политической и технологической точки зрения. Однако, оно происходит на фоне серьезной конкуренции с доминирующей архитектурой x86. К тому же ранние проблемы продвижения архитектуры еще далеки от того, чтобы назвать их решенными. Однако я верю, что в будущем ARM сможет стать серьезной силой на серверном рынке. Создание глобального индустриального альянса и эффективной организации по построению экосистемы представляется очень желательным.
Россия видится одной из самых перспективных арен для построения ARM –экосистемы со многих точек зрения. Правительственный курс на информационную независимость обеспечивает долгосрочную поддержку этой инициативы. Однако потенциал ARM-экосистемы еще даже полностью не осознан на правительственном уровне. Нужна серьезная работа для того, чтобы наш голос был услышан. Еще одна причина – сравнительно большой рынок и разнообразие кастомеров как частных, так и государственных. Например, здесь можно назвать ресурсодобывающих гигантов (Газпром, Лукойл, Роснефть), ведущие банки (Сбер, ВТБ, Aльфа), провайдеров мобильных услуг (MTC, Meгафон, Билайн, Tеле2). Растет осознание необходимости альтернативы существующей инфраструктуре (x86, IBM, Oracle) как с точки зрения безопасности, так и с точки ценообразования.
Ну и последнее по счету, но не по значимости ― человеческий ресурс. В России много программистов, имеющих опыт решения экосистемных задач и думающих в этих терминах.