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

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

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

В условиях встраивания платформенного API мы вновь сталкиваемся с тем, что подобная задача не реализуется исключительно средствами BPM-движка. Лишь ограниченное количество технологических решений непосредственно поддерживают (или поддерживали) встраивание в формате библиотеки в код приложения потребителя. При этом даже существующее встраивание не обеспечивает решения всего спектра задач, возникающих при автоматизации бизнес-процессов (процессных составляющих продуктов, предоставляемых организацией). В качестве примера можно привести BPM Camunda. До 8-й версии продукт обеспечивал встраиваемую топологию (отмечалась в качестве рекомендуемой для поддержки микросервисной архитектуры), считался едва ли не эталоном встраиваемости и распределенности. Но даже применение данного продукта фактически ограничивало потребителей шаблоном оркестровки: процессный микросервис с встроенным BPM-движком выступал в роли центрального узла управления процессом, масштабирование осуществлялось наращиванием числа экземпляров упомянутого процессного микросервиса. Применение шаблона хореографии требовало дополнительных средств, при этом локальные процессы оркестрировались процессными микросервисами, взаимосвязь которых осуществлялась внешними инструментами – например, потоковой платформой и взаимодействием по принципам EDA. При указанной реализации хореографии в любом случае требовалась дополнительная реализация сквозного мониторинга (системного и прикладного), поддержка интеграционных взаимодействий и т. д. Альтернативные BPM-движки предоставляли еще более бедную поддержку встраиваемых топологий. При этом с 8-й версии указанная топология в инструментарии Camunda была помечена как «deprecated», фактически произошел отказ от нее. Мы не будем рассуждать о причинах подобного отказа, принимаем его как данность.

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

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

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

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

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

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

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

Мы уже приводили примеры технологий (делая упор на свободно распространяемые продукты с открытым исходным кодом), которые весьма часто используются в современном платформенном подходе. Многие из указанных технологий не оперируют классическим понятием транзакции, предполагая обеспечение «согласованности в конечном счете» (eventual consistency). Управление подобной согласованностью исключительно сложная и трудоемкая задача, и если все продуктовые команды будут «творить» (суть данного термина мы раскрывали выше) указанное управление состоянием, то резко возрастут затраты на цифровую трансформацию, при этом увеличится и количество ошибок, допускаемых на данном непростом пути. Отсюда возникает возможность сформулировать требования к платформенным сервисам и компонентам (требования к предоставляемому ими платформенному API мы раскрыли чуть выше), отвечающим за исполнение бизнес-процессов: необходимо обеспечить работу с современными технологическими решениями (архитектурно поддерживающими распределенность) в формате классической транзакционной (или подобной ей) логики. Разумеется, технологическое разнообразие современных платформ поражает воображение (в хорошем смысле, разнообразие в плохом смысле представляет собой «зоопарк технологий»). И для каждой выбранной технологии должен быть определен платформенный сервис, который выступит соответствующей «оберткой», облегчающей жизнь платформенным приложениям и предоставляющей необходимый платформенный API. При расширении спектра используемых технологий (что обязательно произойдет в условиях современного цифрового мира) следует расширять набор платформенных сервисов. Одновременно с этим необходимо наличие таких сервисов платформы, которые будут отвечать за унифицированное представление, исполнение, описание и доступность частных платформенных сервисов, сопоставляемых конкретным технологиям.

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

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

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

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

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

Как и в «Архитектуре цифрового мира», прежде всего мы должны обратить внимание читателя на тот факт, что любая современная организация генерирует и использует огромное количество данных в ходе собственной деятельности. Это могут быть как собственные данные, так и данные, которые получаются из открытых или партнерских источников. При этом объемы используемых данных постоянно возрастают. Одновременно с этим данные могут быть как структурированными (описываемыми уже столь привычными табличными представлениями), так и неструктурированными (множество объектных моделей, описывающих данные, а также сложный контент, используемый организацией). Большие данные (Big Data) характеризуются наличием как структурированных, так и неструктурированных составляющих, большими объемами (отметим, что с каждым годом объемы, при превышении которых данные можно называть большими, заметно возрастают), высокой скоростью поступления. Все приведенные аспекты необходимо учитывать при проектировании и реализации современных цифровых платформ.

Любая современная компания, стремящаяся сохранять и развивать собственную конкурентоспособность, обязана обеспечивать корректное и эффективное управление собственными данными, что предполагает:

• Определение ролей (сотрудников и/или партнеров организации), ответственных за данные и их качество.

• Формирование, адаптация и поддержка актуальности критериев, на основании которых можно утверждать, что данные организации «качественные».

• Правила, обеспечивающие разрешение конфликтов по данным в информационных системах.

• Правила управления источниками получения данных.

• Правила очистки данных.

• И ряд иных методологических вопросов.

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

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

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

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

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

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

У внимательного читателя, тщательно изучившего «Архитектуру цифрового мира», уже наверняка возник каверзный вопрос: «В предыдущей книге говорилось, что шаблон канонической модели данных (КМД) является устаревшим ввиду сложности поддержания его согласованности и неадекватности затрачиваемых на его создание и развитие ресурсов получаемым преимуществам. Но это говорилось в абстрактном контексте архитектуры. Возможно, теперь, когда у организации есть единая платформа, она и станет источником КМД?» Краткий ответ мы дадим сразу же: платформа не может являться источником канонической модели данных, она в принципе не может являться источником какой-либо модели данных, кроме системной (используется для технических нужд), – а ниже дадим развернутое описание.

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

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

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

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

Когда мы говорим о данных, мы не можем уйти от ответов на вопросы о способах их хранения, передачи и обработки. В эпоху монолитных приложений (как и в период SOA) вопросы передачи данных не были настолько масштабными, поскольку удаленный характер взаимодействия не носил такого преобладающего характера, каковым он является сегодня (плюс дистанционные каналы обслуживания не были столь развиты). Однако в условиях современного цифрового мира подобное пренебрежение вопросами передачи информации невозможно. Увы, и сегодня на рынке присутствуют компании, которые подходят к условиям архитектурной трансформации следующим (откровенно деструктивным) образом: в составе классических информационных систем формируются функциональные подсистемы, которые распределяются по выделенным сетевым узлам, объявляются распределенными компонентами (или, что еще хуже, микросервисами), после чего делается глубокомысленный вывод о свершении цифровой трансформации. Даже оставляя за скобками вопрос неизменного mindset, отметим, что к проблемам высокой связности указанных подсистем добавляется еще и проблема сетевой латентности. В этом случае объемы передачи информации, ранее не вызывавшие вопросов (обработка данных происходила локально), теперь становятся насущными (а зачастую и первоочередными) проблемами компаний. Приведенный пример представляет собой лишь один из многих по построению так называемого «распределенного монолита», являющегося одним из классических антипаттернов проектирования. Как же мы должны поступать в случае современной архитектуры, одной из ключевых тенденций развития которой является распределенность?

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

Рисунок 8. Обмен данными между микросервисами

В приведенном на Рисунке 8 примере каждый микросервис выполняет необходимые действия в рамках локальной транзакции, результаты которой фиксируются. По итогам выполнения он передает информацию связанному с ним другому микросервису, который выполняет уже собственную локальную транзакцию. Из совокупности подобных локальных транзакций складывается транзакция глобальная, выполнение которой несет непосредственную ценность клиентам и/или партнерам организации.

При этом рассматриваемый пример содержит признаки высокой связности между микросервисами, а также предполагает выполнение большого числа синхронных вызовов между ними. Указанные характеристики ведут к сложностям в масштабировании и развитии системы, а также к избыточным ресурсным затратам на поддержание ее работоспособности (особенно в условиях актуальных в современном цифровом мире высоких нагрузок). Устранение подобных недостатков в современных архитектурных практиках достигается путем сегментации функционально близких микросервисов по группам (как правило, продуктовым, то есть сегментированным в соответствии с принятой в организации продуктовой логикой), а также применением практик событийно-ориентированной архитектуры (Event-Driven Architecture, EDA).

Для обеспечения последней зачастую применяются технологии потоковой передачи информации – например, Apache Kafka или Apache Pulsar. Отметим, что данные программные решения являются продуктами с открытым исходным кодом. Пример подобного развития приведен на Рисунке 9 (за основу взят аналогичный рисунок из «Архитектуры цифрового мира»).

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

Рисунок 9. Обмен данными между микросервисами

с применением практик EDA

В то же время управление указанным «ансамблем» технологий усложняется, что повышает требования к профессиональному уровню команд развития и зрелости применяемых DevOps-практик. И здесь на помощь приходит платформенный подход, который обязана применять организация, ставящая себе целью обеспечение перманентного интенсивного развития. Именно платформа должна взять на себя практики предоставления командам развития технологий потоковой передачи информации, поддержки практик EDA, предоставление понятных и унифицированных API (как уже отмечалось, в формате встраиваемых библиотек) платформенным приложениям, которые будут (в соответствии с требованиями распределенности) отвечать, например, практикам микросервисной архитектуры. Платформа предлагает и варианты использования сервисов потоковой передачи информации, что снижает избыточные трудозатраты для команд развития, а также стандартизирует работу DevOps-специалистов. Пример указанного подхода схематично приведен на Рисунке 10.

Рисунок 10. Обмен данными между микросервисами

с применением практик EDA при платформенном подходе