Концепция гибкой интеграции

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

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

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

Для доставки программного обеспече­ния на современных скоростях компа­ниям нужен фундамент гибкой инфра­структуры. В данном случае в термин Agile вкладывается более традицион­ный смысл, чем обычно при разработ­ке программ. Agile означает «гибкий», «способный быстро двигаться».До настоящего времени гибкие мето­дики были направлены на разработку программного обеспечения в стремле­нии усовершенствовать и упростить процесс создания программ. Методы DevOps представляли собой попытку перенести эти методики на разверты­вание приложений.

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

Компания, которая может в одно­часье изменить цепы или быстро начать выпускать новые продукты, имеет огромное преимущество перед конкурентом, использующим трехмесячную многоэтапную процедуру с последовательностью ручных опе­раций проверки.Мы называем это гибкой интеграци­ей. Интеграция не является частью инфраструктуры — это концептуальный подход к инфаструктуре, который охватывает данные и приложения наряду с оборудованием и платформами. Совмещая техно­логии интеграции с гибкостью и тех­нологиям и DevOps, можно создать платформу, которая позволяет рабо­чим группам вносить изменения так быстро, ка к того требует рынок.

Конец планирования

«Планирования, каким мы его знаем, больше не существует, — заявил в своем выступлении на конферен­ции Red Hat Summit Джим Уайтхерст, главный управляющий Red Hat.— Планирование в малоизученной среде неэффективно». В стремительно развивающейся бизнес-срсде неспо­собность лавировать, своевременно корректируя свои действия, может обойтись чрезвычайно дорого. Это означает, что чем меньше информа­ции вы имеете или чем менее стабиль­на среда, тем ниже ценность планов.

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

Рабочим группам, привычным к полу­годовым или даже двухлетним циклам разработки, непросто приспособить­ся к быстрым переменам. Проблема усугубляется, когда традиционно структурированные компании бывают вынуждены конкурировать с начи­нающим и компаниями , которые используют совершенно новые под­ходы. Очевидные примеры — N etflix и Blockbuster или Uber и традицион­ное такси, но подрыв устоявшегося порядка молодыми компаниям и прослеживается с начала информа­ционного века, с Amazon в 1993 году и персональных компьютеров в 1980-х (таблица 1).

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

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

Что необходимо для успеха

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

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

Технические и культурные измене­ния не обеспечивают гибкость. О ни создают фундамент для гибкости. Марти Каган , менеджер продукта компании eBay, облагает каждый проект « налогом » — некоторое время и ресурсы из каждого обыч­ного проекта выделяются для работы над новыми инфраструктурным и проектам и. Таким образом, новые проекты и новации становятся при­оритетными.

Инфраструктура гибкости

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

Три столпа гибкой интеграции

Подход к гибкой интеграции базиру­ется на трех основных технологиях:

• Распределенная интеграция. Нес­колько десятков высокоуровневых шаблонов интеграции отражают потоки данных и рабочих процессов на предприятии. Если эти шаблоны интеграции развернуты в контейне­рах, то их можно развернуть в нуж­ных масштабах и там, где необхо­димо для конкретных приложений и рабочих групп. Это архитектура распределенной интеграции, отличная от традиционной архитектуры централизованной интеграции. Благодаря ей отдельные рабочие группы могут гибко определять и развертывать требуемые шабло­ны интеграции.
• API-интерфейсы. Стабильные, хоро­шо управляемые A P I-интерфейсы имеют решающее значение для взаимодействия между рабочи­ми группам и, разработчиками и специалистами по эксплуата­ции. A P I-интерфейсы заключают важнейшие активы в стабильные, повторно используемые интерфей­сы, позволяя этим интерфейсам служить строительными блоками для многократного применения в масштабах компании, с партне­рами и клиентами. API-интерфейсы можно размешать вместе с контей­нерами в различных средах, что позволяет пользователям взаимо­действовать с разными наборами API-интерфейсов.
• Контейнеры. Это базовая платфор­ма развертывания как для API, так и для технологий распределенной интеграции. Контейнеры позво­ляют развернуть нужную службу в определенной среде простым и единообразным для разработ­ки, тестирования и обслуживания способом. Поскольку контейне­ры являются доминирующей платформой для среди микро ­служб DcvOps, их использование в качестве платформы интеграции обеспечивает более прозрачное и тесное сотрудничество между группами разработчиков и специ­алистами по инфраструктуре.

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

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

Распределенная интеграция

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

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

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

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

Критическое значение имеет согла­сование процессов и инструментов разработчика. Главная особенность распределенной интеграции состо­ит в том, что это не централизованная программная инфраструктура, разработанная и управляемая спе­циализированной группой поль­зователей водном подразделении и развернутая отдельно от процесса разработки программного обеспе­чения. Благодаря распределенности архитектуры интеграции, с обшей платформой и инструментарием, она доступна всем разработчикам на уровне проекта и поддерживает компактные развертывания всегда и везде, где необходима интеграция.

Чтобы использовать ESB, рабочей группе приходится в течение всего жизненного цикла применять инструменты ESB наряду с любы­ми инструментами, используемыми в средах разработки и эксплуатации (таблица 2).

Результатом становятся неудобство, потери в эффективности и ошибки при эксплуатации.

Обмен сообщениями способствует интеграции

Архитектурно точки интеграции при распределенной интеграции рас­сматриваются как микрослужбы. Их можно заключать в контейнеры, легко развертывать локально и часто обновлять выпуски. Технология интеграции должна под­держивать такого рода компактную архитектуру на основе микрослужб. С помощью, например. Red Hat Fuse пользователи могут рассматривать интеграции как программный код, пригодны й для запуска повсюду, втом числе в контейнере.

Кроме того, Fuse поставляется с Red Hat J Boss A M Q , чтобы обеспечить инфраструктуру обмена сообщения­ми. Мощная инфраструктура обмена сообщениями гарантирует эффек­тивную марш рутизацию событий и данных между системами. Обмен сообщения ми — важный архитектур­ный инструмент для микрослужб, поскольку его асинхронная природа не требует зависимостей.

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

Следим за тенденциями

Контейнеры применяются все чаще, но насколько и почему? Аналитики компании 451 Research прогнозиру­ют рост рынка на 250%, но это объем затрачиваемых средств, а не развертывания. Оценить развертывания несколько сложнее. В результате опроса, выполненного компанией Bain по заказу Red Hat. выяснилось, что около 20% клиентов сегодня развертывают контейнеры в производ­ственной среде и примерно столько же в средах разработки и тестирования, но более 30% оценивают контейнеры и выполняют проверку концепции.

Что означает «использовать контей­неры»? В Enterprisers Project обрисованы четыре различных варианта применения контейнеров: в каче­стве общей платформы разработки и развертывания; ка к «облачной» платформы или платформы микро­служб; в гибридном «облаке» и для инновационных проектов. От спосо­ба использования контейнеров зави­сит, как пользователь рассматривает их внедрение.

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

Источник: журнал «Windows IT Pro/RE»