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

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

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

• Охватывать множество продуктов и поддерживать распределенное исполнение предоставляющих их платформенных приложений.

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

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

Для рассматриваемого примера можно выделить следующие варианты совместного исполнения приложений, автоматизирующих предоставляемые продукты (с учетом вышеприведенных характеристик технологических решений):

• Для обеспечения высокой производительности фронтальной составляющей может использоваться решение по обработке и хранению данных в оперативной памяти (IMDG/IMDB). При этом данное решение должно быть технологически общим, дабы при поддержке и развитии продуктов не приходилось учитывать «зоопарк технологий». Примером неудачного проектирования может служить вариант, при котором в роли IMDG/IMDB-решения для высокопроизводительного продукта выступает Apache Ignite, а для продукта, требования к производительности которого ниже, Redis. В дальнейшем при появлении еще одного продукта с высокими требованиями по производительности команда развития внедрит Hazelcast, после чего драматически возрастет стоимость обеспечения непрерывности, поддержки и развития подобного «унифицированного» решения. Но выбором общей технологии работы (например, Apache Ignite ввиду наличия требований по высокой нагрузочной способности) дело не ограничивается. На первый план выступает вопрос использования топологий. И платформа должна предоставлять возможность развернуть топологию, поддерживающую исполнение продукта в соответствии с требованиями. Например, соответствующее число узлов, правила репликации, даже сложность и развитость встраиваемого платформенного API могут различаться в зависимости от требований, предъявляемых к продукту. Таким образом, и варианты использования платформенного сервиса также могут различаться. В конце концов, и обеспечение групп продуктов может осуществляться множеством платформенных сервисов, каждый из которых отвечает своему подмножеству требований.

• Подобное технологическое решение по обеспечению высокой производительности может (и должно) применяться при автоматизации процессной составляющей рассматриваемых продуктов. Как мы уже отмечали ранее, стандартные средства автоматизации бизнес-процессов, как правило, не отличаются высокой производительностью. В них закладываются возможности гибкого моделирования процессов, их быстрой сборки и развертывания, возможности мониторинга, но производительность отказывается не самым передовым показателем данного класса инструментов. Одновременно (и мы также обращали внимание читателя на данный факт) в современной архитектуре бизнес-процессы не могут характеризоваться низкой производительностью, в противном случае организация потеряет конкурентоспособность на рынке. Поэтому (так как базовый инструмент управления процессами не может сам по себе обеспечить адекватную требованиям дистанционного обслуживания производительность) на уровне реализации процессной составляющей продуктовой автоматизации могут применяться упомянутые выше IMDG/IMDB-инструменты. С их помощью, например, может осуществляться высокоэффективная работа с контекстом экземпляра процесса, его бизнес-данными, обеспечиваться надежность и т. д. Конкретные топологии (и сущности) развертывания могут различаться как от продукта к продукту, так и в зависимости от той продуктовой составляющей, к которой они относятся. Но технологическая унификация, а также специфика платформенных сервисов должны быть общими на уровне платформенных приложений и предоставляемых ими продуктов организации клиентам и партнерам последней. Фактически множество платформенных сервисов, обеспечивающее исполнение фронтальной составляющей продукта, пересекается с множеством платформенных сервисов, обеспечивающих исполнение процессной составляющей продукта, по принципу кругов Эйлера. Аналогичным образом пересекаются множества платформенных сервисов, обеспечивающих исполнение различных продуктов (даже при аналогичной структуре последних). А требования к платформенным сервисам, режимам их функционирования, топологиям развертывания технологической составляющей предъявляют продукты. Отметим, что указанные требования не являются статическими. Например, при добавлении новых продуктовых бизнес-процессов или расширении использования существующих требования к инструментальной поддержке высокой производительности процессов могут кардинально измениться – как вариант, возрасти. Подобное происходит при добавлении новых каналов лидогенерации, привлекающих большие объемы клиентов. Соответственно, используемые в платформах технологии, а также предоставляемые платформами сервисы должны быть адаптируемыми к подобным изменениям требований, что, в свою очередь, напрямую следует из свойства отсутствия замкнутости платформ.

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

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

Поддержка той или иной технологией эластичного масштабирования подразумевает, что соответствующая технология обеспечивает:

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

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

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

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

Отметим, что приводимые нами в качестве примеров в течение настоящей книги технологии Apache Ignite, Apache Cassandra, Apache Kafka и многие другие ведущие решения с открытым исходным кодом обеспечивают вышеприведенные характеристики.

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

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