Архитектура цифровых платформ. От настоящего к будущему

Цифровые платформы и открытый код

В «Архитектуре цифрового мира» уже указывалась дата 17 сентября 1991 года, когда публикация Линусом Торвальдсом исходного кода ядра операционной системы Linux стала отсчетом новой эры развития программных продуктов. Широкому кругу потребителей были представлены и заявили о себе программные продукты с открытым исходным кодом. Тем самым идеи разделения труда в цифровой сфере (пусть тогда и поднимались «лишь» вопросы частичной автоматизации) вышли на сцену. Но мало просто выйти на сцену. На сцену выходят миллионы актеров, но звездами становятся лишь единицы. И открытый код, несомненно, стал такой звездой.

Есть и вторая дата, значимая для истории открытого кода и всего цифрового мира: 28 октября 2018 года корпорация IBM объявила о покупке компании RedHat. Официальная стоимость сделки составила 34 миллиарда долларов. При этом результатом покупки стало не закрытие ранее открытых технологий (компания RedHat является ключевым игроком на рынке открытого кода), а выход на рынок открытого кода IBM в качестве не просто участника, но флагмана, развивающего решения с открытым исходным кодом на новом качественном уровне. Чем важна эта дата? Произошедшее событие стало знаковым и показало глобальные изменения, происходящие в цифровом мире. Компания, создавшая экосистему продуктов на все случаи жизни (аппаратные платформы, операционные системы, системы управления базами данных, серверы приложений, интеграционные решения, системы управления контентом и т. д.), сделала выбор в пользу открытого кода. $34 млрд были вложены в экспертизу, в открытое сообщество, в перспективы развития, но не в заводы по производству электроники, закрытые лицензии или элитную недвижимость. Чуть больше 27 лет занял путь от публикации исходного кода до столь значимого корпоративного поворота – по меркам истории это произошло в исключительно короткие сроки.

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

Что же данный поворот означает для платформ? Безусловно, платформа не является информационной системой, платформа не является обособленным программным комплексом. Но программным комплексом она является, причем исключительно сложным – у автора и в мыслях нет пытаться убедить читателя в простоте современных платформ. И повышение производительности труда при создании столь сложных комплексов является одной из важнейших задач современности. Если мы говорим, что платформа является ценностным мультипликатором, то создание и последующее развитие такого мультипликатора не приемлют невынужденных издержек в производительности труда. Особенно при необходимости обеспечения развития интенсивного. А альтернативой интенсивному развитию, как мы помним, являются застой и деградация. Если платформа является ценностным мультипликатором при создании и развитии продуктов, предоставляемых организацией клиентам и партнерам, а открытый код является мультипликатором эффективности при создании программных продуктов, то объединение данных мультипликаторов становится требованием времени. То есть современная платформа должна базироваться на решениях с открытым исходным кодом.

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

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

Рисунок 4. Продукт, автоматизируемый при помощи

современной платформы

Предположим, что платформенные компоненты и предоставляемые при их помощи платформенные сервисы реализуются на основании программного обеспечения с открытым исходным кодом. При этом продукт, как и в примере, приведенном в главе, посвященной проблематике современных цифровых платформ (см. Рисунок 2), содержит учетную, частную учетную, процессную и фронтальную составляющие. Также примем за основу современный архитектурный mindset, детально представленный в «Архитектуре цифрового мира».

Основываясь на рассмотренном ранее примере продукта, отметим следующее:

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

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

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

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

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

Итак, требование к надежному и долговременному хранению информации, предъявляемое составляющими синтетического и аналитического учета, выполняется путем использования современных технологий хранения, обеспечивающих эластичное масштабирование. Более того, в случае если соответствующие технологии предоставляют возможность сегментации (раздельного и независимого хранения и управления массивами данных), то мы можем использовать общую технологическую базу при хранении соответствующей информации как для учетной, так и для частной учетной составляющих. Примерами подобных технологий, которые могут использоваться для решения указанной задачи, могут служить Apache Cassandra и Apache Hadoop, являющиеся продуктами с открытым исходным кодом. Указанные продукты используются технологическими гигантами и их клиентами и партнерами и доказали свою состоятельность. Для групповых операций может использоваться связанная технология – например, Apache Spark, также представляющая собой продукт с открытым исходным кодом. Более того, Apache Spark предоставляет возможности бесшовной интеграции с тем же Apache Hadoop, существенно снижая трудозатраты команд разработки.

Обеспечение высокой скорости записи возможно при использовании технологий как распределенного хранения, так и потоковой интеграции; примерами последних могут выступать Apache Kafka или Apache Pulsar. Указанные технологии обеспечивают высокую скорость записи и множество доступных смежных технологий, отлаженных сообществом разработчиков и готовых к применению. Отметим, что интеграция может быть вертикальной (с точки зрения Рисунка 4) и пронизывать все составляющие автоматизации продукта сквозным образом. Также Apache Kafka и Apache Pulsar (в меньшей степени) поддерживают бесшовную интеграцию (с использованием открытых компонентов) с современными технологиями долговременного хранения информации. Нельзя не отметить, что приведенные технологии потоковой интеграции представляют собой продукты с открытым исходным кодом.

Требования по созданию гибких и эффективных пользовательских интерфейсов являются общими для всех составляющих продукта (в современном мире даже синтетический учет нуждается в развитом пользовательском интерфейсе). Поэтому резонным становится общий подход к созданию как фронтального представления продукта в целом, так и интерфейсных элементов каждой составляющей продукта, предоставление готовых компонентов в виде библиотек, их переиспользование, а также общие подходы к дизайну. И основные фреймворки создания фронтальных компонентов, применяемые на сегодняшний день, – React, Angular, Vue. js – также отвечают принципам открытого кода.

Высокая производительность работы с данными для фронтального слоя может обеспечиваться как кэширующими элементами, применяемыми для обеспечения эффективности индексирования данных, использования быстрого поиска при работе, например, со статическими массивами информации, так и сложными программными комплексами, применяемыми для кэширования, предполагающего частое обновление данных, так называемый «прогрев кэша». Также во втором случае (сложные программные комплексы и связанные с ними задачи) актуальным будет не просто кэширование информации (формат In-Memory Data Grid, IMDG), а полноценная работа с ней в оперативной памяти (формат In-Memory Data Base, IMDB), предполагающая в том числе поддержку языков работы с данными, привычных многим современным разработчикам. Примерами таких инструментов могут служить Apache Ignite или Infinispan; в качестве примера инструмента, поддерживающего первый случай кэширования (индексирование данных и быстрый поиск), можно привести OpenSearch. Указанные продукты являются решениями с открытым исходным кодом. И применяться соответствующие инструменты могут не только для повышения производительности фронтальной составляющей, но и, например, в процессной составляющей автоматизации продукта.

Дело в том, что традиционно инструменты, обеспечивающие гибкую настройку и исполнение бизнес-процессов, их мониторинг, выставление и расчет КПЭ, имеют не самую высокую производительность, а потому нуждаются в дополнительных компонентах, упомянутую производительность повышающих. И это могут быть уже приведенные выше компоненты, применяемые одновременно и для обеспечения корректной автоматизации фронтальной составляющей продукта. А их (компонентов) распределенное исполнение, эластичное масштабирование и опции сегментации позволяют проводить тонкую настройку, адресно применимую для каждой составляющей автоматизации продукта. В свою очередь, для непосредственной автоматизации процессной составляющей продукта могут использоваться самые разные решения с открытым исходным кодом: Activiti, Camunda, Kogito и другие. Указанные инструменты активно применяются огромным количеством самых разных мировых корпораций, для них разработаны различные топологии развертывания, адекватные тем или иным вариантам использования.

Читатель может задать вопрос в лоб: «Неужели достаточно просто развернуть набор технологий, например приведенный автором, чтобы достичь современного платформенного подхода?» Ответ на подобный вопрос может быть только отрицательным: развертывание технологий является промежуточным и не определяющим, хоть и важным, этапом работы с цифровыми платформами. Более того, этот этап может быть применен и в случае следования парадигме SOA, и в случае применения «платформенного» подхода, разобранного в предыдущей главе, посвященной проблематике современных цифровых платформ. Что же отличает современный платформенный подход?

Во-первых, мы должны исходить из того, что платформа не существует сама по себе, она является средой создания и исполнения приложений. Платформа не является ни информационной системой, ни выделенным программным комплексом, по факту платформа является основой прикладной экосистемы организации. Отсюда может следовать первый вывод: многообразие решений с открытым исходным кодом не означает, что каждая составляющая продукта, рассматриваемого в примере, автоматизируется независимым технологическим стеком. В «Архитектуре цифрового мира» мы говорили о том, что единственным критерием выбора технологических решений является целесообразность. И когда мы говорим об экосистеме платформенных приложений, о продуктах, предоставляемых указанными приложениями, то крайне неразумно будет рассуждать о том, что каждый продукт, каждая составляющая продукта автоматизируется независимо от других. Да, жизненный цикл продуктов различен, каждый продукт обладает собственным P&L, каждый продукт может получать совершенно разные импульсы к развитию, основанные на множестве факторов. Но платформа помогает им развиваться, она, как мы уже отмечали, является ценностным мультипликатором. И архитектор, занимающийся проектированием платформы, приходит к выводу, что технологический стек, использующийся при проектировании и реализации платформы и платформенных приложений должен быть согласованным. Нет никакого смысла использовать собственные системы управления базами данных для каждого продукта и каждой составляющей такого продукта, если это не диктуется объективными потребностями. Если мы говорим о решениях по обработке данных в оперативной памяти, позволяющих обеспечить требуемые производительность и надежность для процессной и фронтальной составляющих, то имеет смысл рассматривать технологическую унификацию данных решений, а также проектировать и реализовывать унифицированные платформенные сервисы инфраструктурного и инфраструктурно-прикладного характера (подробнее о платформенных сервисах – в соответствующей главе) для обеспечения работы указанных продуктовых составляющих. Разумеется, отсюда вовсе не следует необходимость использования единственно правильной технологии, мы утверждаем необходимость решения схожих технологических задач схожими технологиями. Представим себе, что обработка данных в оперативной памяти производится на уровне процессной составляющей продукта средством решения Infinispan, фронтальной – Apache Ignite, при этом для выделенного подмножества дистанционных каналов – Redis. Поддерживать и развивать подобную конфигурацию будет непомерно затратно. Таким образом, мы приходим к логике технологической унификации платформы и ее сервисов. При этом унификация проводится в логике решений с открытым исходным кодом: выбор используемых в рамках унификации технологий может производиться как выделенно, то есть с точки зрения максимально эффективного технологического решения, так и совместно, когда оценивается эффективность экосистемы технологий (например, с точки зрения возможностей упрощения технологической интеграции).

Во-вторых, структура платформы определяется теми прикладными вариантами использования, исполнение которых планируется для продуктов, создаваемых с применением платформы. А варианты использования диктуют те характеристики платформы, которые обеспечат требуемый P&L продуктов. То есть в рамках технологической унификации, представленной выше, топологии развертывания технологических решений, применяемых в платформе, могут существенно различаться. Например, упомянутый выше Apache Ignite может иметь различные топологии развертывания и сервисное окружение для вариантов автоматизации процессной и фронтальной составляющих. И указанные топологии диктуются вариантами использования. Здесь мы видим очередную синергию платформенного подхода и философии открытого кода: успешные решения с открытым исходным кодом используются огромным числом организаций по всему миру, изменения в данные решения вносятся аналогично огромным числом пользователей, поэтому количество доступных вариантов топологий оказывается априори большим, нежели у закрытых (vendor-lock) решений, даже если последние являются собственностью крупнейших корпораций. И для каждого частного платформенного решения может выбираться (а в случае необходимости и создаваться) собственная топология развертывания технологического продукта. То есть мультипликативный ценностный эффект платформы накладывается на мультипликатор эффективности открытого кода. Мы можем создавать множество топологий в рамках технологической унификации применяемых решений в зависимости от требований к той или иной составляющей продуктовой автоматизации.

Резюмируя вышеизложенное, мы можем отметить, что при использовании современного платформенного подхода обеспечиваются:

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

• Подсистемы платформы предоставляют сервисы (и сами могут предоставляться в виде сервиса) разного уровня платформенным приложениям, в ходе реализации которых создаются продукты организации, предоставляющие ценность клиентам и партнерам.

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

• Многообразие подсистем и их топологий основывается на развитии решений с открытым исходным кодом, так как не может ограничивать себя привязкой к некоему выделенному поставщику программного обеспечения.

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

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

Попробуем ответить на вопрос, обязательно ли использование технологий с открытым исходным кодом для приведенного выше решения задач продуктовой автоматизации с использованием платформенного подхода. Да, можно обойтись без решений с открытым исходным кодом. Можно применять закрытые технологические решения, подключить соответствующих поставщиков. Можно разработать как платформу, так и платформенные приложения, обеспечивающие продуктовую автоматизацию, с нуля, не подключать базис открытого кода. Оба приведенных варианта представляют собой альтернативы использованию решений с открытым исходным кодом. Но что же произойдет, если следовать подобным альтернативам? Фактически что в одном, что в другом случае мы отвергнем возможность повышения эффективности за счет увеличения длины цепочки разделения труда. В одном случае мы доверимся некому поставщику программного обеспечения, который априори не может обеспечивать эффективность, сопоставимую с сообществом разработчиков открытого кода (при использовании ведущих решений), ограничим число как применяемых технологий, так и топологий их развертывания. Во втором случае взвалим на себя тяжкую ношу разработки всех компонентов собственными силами, игнорируя достижения ведущих мировых технологических игроков. В таком случае логично и компиляторы не использовать внешние, а разработать самостоятельно. А там и до реализации собственной электронной компонентной базы недалеко. Мы сознательно доводим примеры до абсурда, показывая, что именно следование открытому коду как ментально (при проектировании и реализации платформенных решений), так и технологически является той золотой серединой, позволяющей организациям добиться максимальной производительности труда и эффективности на пути цифровой трансформации.