Читать книгу Архитектура цифрового мира - Андрей Николаевич Трушкин - Страница 6

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

Как уже отмечалось, идеология развития программного обеспечения с открытым исходным кодом, создания решений на его основе позволили существенно увеличить цепочки разделения труда в сфере ИТ, что обеспечило кардинальное повышение эффективности реализации новых информационных систем. При этом при увеличении степени разделения труда растут риски отдельных участников цепочки, которые зависят от все большего числа поставщиков и потребителей. Данная тенденция характерна и для ИТ. Представим себе ситуацию, что информационную систему А разрабатывает команда из 100 человек. Но эти 100 человек не работают в одном офисе, выполняя заранее согласованные и спланированные блоки работ. Коллектив разбит на 10 команд по 10 специалистов, при этом каждая команда создает свой собственный блок функционала. Между блоками присутствуют зависимости как интеграционного (взаимодействие в рамках процессов обменов информацией), так и встраиваемого характера. Под последним традиционно понимается возможность включения результатов работы одной команды в рабочие блоки, создаваемые другой командой, в формате библиотеки. Современные технологии в части ИТ позволяют проводить тестирование функционала с помощью механизма «заглушек», эмулирующих функционал контрагентов, но указанный способ тестирования имеет известные пределы. Пример описываемой ситуации представлен на Рисунке 12.

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

Рисунок 12. Распределенная команда разработки программного обеспечения

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

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

Рисунок 13. Применение микросервисной архитектуры,

продуктового подхода и EDA распределенной командой

разработки

На Рисунке 13 представлены 2 продукта, создаваемых различными командами разработки в составе общей распределенной команды. Общее решение создается в рамках обслуживания клиентов – юридических лиц, которым доступны два продукта: кредитование и электронные банковские гарантии. Одна команда разрабатывает продукт кредитование, вторая – электронные банковские гарантии. Каждое продуктовое решение создается в соответствии с парадигмой микросервисной архитектуры, при этом каждый микросервис является самостоятельной единицей развертывания. Взаимодействие микросервисов осуществляется посредством платформы событийного обмена и подчиняется принципам EDA. В чем же преимущество представленного подхода?

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

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

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

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

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

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

При соблюдении озвученных выше принципов команды, представленные на Рисунке 13, могут работать независимо друг от друга и располагаться территориально таким образом, насколько это наиболее эффективно с точки зрения цепочки разделения труда. Команда 1 может работать в Москве, команда 2 в Екатеринбурге, команда 3 в Новосибирске. Инфраструктурная поддержка команд разработки может осуществляться из Санкт-Петербурга. Города представлены в качестве иллюстративного примера. В случае создания продуктов, имеющих меньшую зависимость от локализованных правил регулятора, возможно размещение команд в самых разных уголках Земли. Иллюстративно это представлено на Рисунке 14.

Рисунок 14. Географически распределенная команда

разработки

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

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

Как мы уже говорили выше, проводя обзор ключевых тенденций развития архитектуры, требования к распределенному функционированию современных ИТ-решений стали новыми с точки зрения рынка ИТ, что привело к существенному пересмотру подходов к проектированию. Рука об руку с распределенностью пришли требования по приоритетному развитию дистанционных каналов обслуживания клиентов и партнеров. Все эти требования возникли вследствие стремительного роста стартапов и формирования на их основе технологических гигантов. В фильме Дэвида Финчера «Социальная сеть» (The Social Network, 2010) режиссер вкладывает в уста героя Джастина Тимберлейка (играет Шона Паркера) пророческие слова: «Мы жили в деревнях, а потом в городах, а теперь будем жить в Интернете!» Безусловно, и сегодня можно встретить на просторах Интернета ехидные комментарии в адрес данных слов, утверждающие, что жизнь не ушла не только из городов, но и из деревень. Но речь шла не о физическом месте проживания (мы уже видели по ходу настоящего раздела, насколько иллюзорным может становиться его значимость в современном мире), а о mindset. Специально расшифровывая подобные аспекты, персонаж Рашиды Джонс (играет адвоката Мэрилин Делпи) замечает относительно проникновения современных технологий в нашу жизнь: «Босния… У них нет дорог, но есть Facebook». Разумеется, речь идет не о физическом исчезновении деревень и городов, отсутствии необходимости в инфраструктуре обеспечения жизнедеятельности, а о коренном изменении мышления, формировании совершенно нового mindset. Технологические решения проникают в нашу жизнь, причем доступны они в любой точке земного шара. Современный человек не мыслит свою жизнь без Интернета, без сервисов, предоставляемых самыми различными компаниями как в региональном, так и в глобальном масштабе. Но любая медаль имеет обратную сторону – технологические решения, прорвавшись в жизнь человека, связали себя новыми требованиями – они должны быть доступны из любой географической точки и предоставлять неизменно высокое качество сервиса. В противном случае они станут неконкурентоспособными. Подобные требования являются исключительно важными с точки зрения архитектуры.

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

Описанные ранее ключевые принципы микросервисной архитектуры имеют ряд следствий практического применения. Одним их них является то, что абсолютное большинство микросервисов проектируется и разрабатывается в формате stateless компонентов, то есть они не сохраняют свое состояние между вызовами – для выполнения данной функции служит внешнее по отношению к микросервису хранилище информации. Таким хранилищем может быть база данных, in-memory data grid (IMDG), платформа событийного обмена (и такие варианты реализации используются, например, The New York Times). С точки зрения самих микросервисов отсутствие сохранения состояния между вызовами позволяет создавать количество экземпляров микросервиса, необходимое для корректной обработки запросов, учитывая возможный рост числа последних. Отсутствие необходимости репликации сессий на уровне экземпляров микросервисов позволяет минимизировать внимание, уделяемое данному вопросу, и масштабировать микросервисы в допустимых инфраструктурой пределах. При этом крайне важным оказывается наличие располагаемых инфраструктурных мощностей для развертывания соответствующих программных компонентов в таких местах, где сетевая латентность не станет преградой для высокого качества сервиса. Например, финансовая организация, предоставляющая услуги в части продуктов по всей территории России, может быть заинтересована в нескольких центрах обработки данных, которые будут географически распределены.

Если функционирование прикладной логики, реализующей соответствующие продукты, достаточно хорошо ложится на распределенную модель, то возникают вопросы, на какой же уровень переносится растущая сложность исполнения ИТ-решений. Выше уже отмечалось, что для сохранения состояния решений используются внешние по отношению к микросервисам хранилища данных. И вопрос функционирования данных хранилищ в распределенной конфигурации становится исключительно важным. Традиционные решения с централизованными базами данных оказываются слабо применимыми в современных условиях – несколько мощных вычислительных узлов попросту не доставят данные микросервисам за приемлемые временные промежутки. В случае, если речь идет о доступности ИТ-решений по дистанционным каналам, когда время отклика и предоставления услуг (по крайней мере, их части) должно составлять несколько секунд, таковые задержки недопустимы. Создание территориально распределенных кластеров традиционных решений по хранению данных также оказывается проблематичным – используемые такими решениями методы синхронизации и поддержания целостности данных зачастую оказываются несостоятельными в условиях значительной сетевой латентности. Соответственно, мир оказывается заинтересован в принципиально новых хранилищах информации. И такие хранилища, опять же, пришли из стартапов. Например, одно из самых популярных на сегодняшний день решений по построению распределенных баз данных Apache Cassandra было создано в Meta Platforms (ранее Facebook). Аналогично распределенные конфигурации предлагают IMDG решения, такие как Apache Ignite. Отметим, что приводимые примеры современных технологий являются решениями с открытым исходным кодом.

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

Все сказанное касается не только хранения информации и использования распределенных СУБД. Платформа событийного обмена также должна обеспечивать возможность исполнения решений в распределенной конфигурации. Из современных решений первым кандидатом на подобную роль может считаться Apache Kafka, уже использующаяся в таких компаниях, как вышеупомянутый The New York Times, Linkedin, Uber, «Сбербанк России» и многих других. Решение изначально поддерживает распределенную топологию развертывания и предоставляет широкий спектр возможностей для «тонкой» настройки.

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

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

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

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