Мейнфрейм и модернизация среднего порядка с помощью Azure Logic Apps

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

Для организаций с инвестициями в мейнфреймы и системы среднего порядка это означает, что лучше всего использовать платформы, которые помогли отправить людей на луну или помогли построить текущие финансовые рынки и расширить свою ценность с помощью облака и искусственного интеллекта (ИИ). В этом сценарии Azure Logic Apps и ее собственные возможности для интеграции с мейнфреймами и системами среднего порядка вступают в игру, открыв дверь в мир ИИ для устаревших инвестиций. Помимо других функций, Azure Logic Apps включает основные возможности сервера интеграции узлов (HIS), который использовался для мейнфрейма и средней интеграции в основе наиболее стратегических клиентов Майкрософт более 20 лет. В результате Azure Logic Apps стала платформой интеграции как услуга (iPaaS) для мейнфреймов и систем среднего порядка.

Когда корпоративные разработчики создают рабочие процессы интеграции с Azure Logic Apps, они могут быстрее доставлять новые приложения, использующие мало кода или меньше пользовательского кода. Разработчики, использующие Visual Studio Code и Visual Studio, могут быть более продуктивными, чем те, кто использует инструменты и технологии разработки мейнфреймов IBM, так как они не требуют знаний о системах и инфраструктуре мейнфреймов. Azure Logic Apps позволяет бизнес-аналитикам и лицам, принимающим решения, быстрее анализировать и сообщать важные устаревшие сведения. Они могут напрямую получать доступ к данным в источниках данных мейнфрейма, что позволяет разработчикам мейнфреймов создавать программы, которые извлекают и преобразуют сложные структуры мейнфреймов.

Собственные возможности облака для интеграции с мейнфреймом и средой интеграции системы

С 1990 года корпорация Майкрософт обеспечила интеграцию с мейнфреймами и системами среднего порядка через Microsoft Communications Server. В 2000 году в 2000 году в 2000 году был создан сервер интеграции узлов (HIS). В то время как ЕГО начал работать в качестве шлюза системной сетевой архитектуры (SNA), ЕГО расширился для включения хранилищ данных IBM (DB2, VSAM и Informix), систем транзакций IBM (CICS, IMS и IBM i) и обмена сообщениями IBM (серии MQ). Стратегические клиенты Майкрософт использовали эти технологии более 20 лет.

Чтобы предоставить клиентам возможность запускать приложения и данные в Azure для продолжения использования этих технологий, Azure Logic Apps и Visual Studio постепенно включили эти возможности. Например, КОНСТРУКТОР HIS для Logic Apps, работающий в Visual Studio, и средство разработки 3270, помогает создавать артефакты метаданных, необходимые встроенным соединителям, которые используются для интеграции с мейнфреймом и средой интеграции в Azure Logic Apps. Эти встроенные соединители выполняются с помощью таких же вычислительных ресурсов, что и рабочие процессы приложения логики уровня "Стандартный". Эта конструкция не только позволяет достичь сценариев низкой задержки, но и расширяет возможности для решения более аварийного восстановления и потребностей клиентов с высоким уровнем доступности.

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

Microsoft HIS Designer for Logic Apps

Это средство создает артефакты мейнфреймов и системных метаданных для Azure Logic Apps и работает с Microsoft Visual Studio, предоставляя графический конструктор, позволяющий создавать, просматривать, изменять и сопоставлять объекты метаданных с артефактами мейнфрейма. Azure Logic Apps использует эти карты для зеркало программ и данных в мейнфреймах и системах среднего порядка. Дополнительные сведения см. в конструкторе HIS для Logic Apps.

Средство разработки Microsoft 3270

Это средство записывает экраны, пути навигации, методы и параметры для задач в приложении, чтобы можно было добавлять и запускать эти задачи как действия соединителя 3270. Хотя конструктор HIS для Logic Apps предназначен для транзакционных систем и данных, средство разработки 3270 предназначено для 3270 приложений. Дополнительные сведения см. в средстве разработки 3270.

Соединители Azure Logic Apps для систем мейнфрейма IBM и среднего порядка

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

IBM 3270

Этот соединитель Azure Logic Apps для 3270 позволяет рабочим процессам уровня "Стандартный" получать доступ к приложениям мейнфреймов IBM, которые обычно выполняются путем навигации по экрану эмулятора 3270. Соединитель использует поток TN3270. Дополнительные сведения см. в статье Интеграция приложений на основе экрана в мейнфреймах IBM с Azure с помощью Azure Logic Apps и соединителя IBM 3270.

Ibm Customer Information Control System (CICS)

Этот соединитель Azure Logic Apps для CICS предоставляет стандартные рабочие процессы с возможностью взаимодействия и интеграции с программами CICS с помощью нескольких протоколов, таких как TCP/IP и HTTP. Если вам нужно получить доступ к средам CICS с помощью LU6.2, необходимо использовать СЕРВЕР интеграции узлов (HIS). Дополнительные сведения см. в статье Интеграция программ CICS на мейнфреймах IBM с рабочими процессами уровня "Стандартный" в Azure Logic Apps с помощью соединителя IBM CICS.

IBM DB2

Этот соединитель Azure Logic Apps для DB2 позволяет подключаться между рабочими процессами уровня "Стандартный" и базами данных DB2, которые находятся в локальной среде или в Azure. Соединитель предлагает корпоративным ИТ-специалистам и разработчикам прямой доступ к жизненно важной информации, хранящейся в системах управления базами данных DB2. Дополнительные сведения см. в статье Access и управление ресурсами IBM DB2 с помощью Azure Logic Apps.

Файлы узлов IBM

Этот соединитель Azure Logic Apps для файлов узлов предоставляет тонкие оболочки вокруг функции "Синтаксический анализ файлов" в сервере интеграции узла. Этот автономный соединитель предоставляет операции синтаксического анализа или создания двоичных данных в файлы узла и из нее. Для этих операций эти данные должны поступать из любого триггера или другого действия, создающего двоичные данные. Дополнительные сведения см. в статье "Анализ и создание файлов узлов IBM с помощью Azure Logic Apps".

IBM i

Этот соединитель Azure Logic Apps для IBM i позволяет рабочим процессам уровня "Стандартный" взаимодействовать и интегрироваться с программами COBOL и РОГО, работающими в системах IBM i с помощью TCP/IP. Если вам нужно получить доступ к средам IBM i с помощью LU6.2, необходимо использовать сервер интеграции узлов (HIS). Дополнительные сведения см. в статье Интеграция программ COBOL и РОЛЕВОЙ системы в средах IBM с рабочими процессами уровня "Стандартный" в Azure Logic Apps с помощью соединителя IBM i.

IBM Information Management System (IMS)

Этот соединитель Azure Logic Apps для IMS использует компонент IBM IMS Подключение, который обеспечивает высокий уровень производительности рабочих процессов от стандартных рабочих процессов к транзакциям IMS с помощью TCP/IP. Эта модель использует очередь сообщений IMS для обработки данных. Дополнительные сведения см. в статье Интеграции программ IMS на мейнфреймах IBM с рабочими процессами уровня "Стандартный" в Azure Logic Apps с помощью соединителя IBM IMS.

IBM MQ

Этот соединитель Azure Logic Apps для MQ позволяет подключаться между рабочими процессами уровня "Стандартный" и серверами IBM MQ в локальной среде или в Azure. Корпорация Майкрософт также предоставляет возможности интеграции IBM MQ с сервером интеграции узла и BizTalk Server. Дополнительные сведения см. в статье Подключение на сервер IBM MQ из рабочего процесса в Azure Logic Apps.

Проблемы модернизации мейнфреймов и систем среднего порядка

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

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

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

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

• Большой взрыв

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

• Гибкие волны

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

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

Большой взрыв или водопад

Миграция большого взрыва обычно имеет следующие этапы:

1. Создание: Kickoff

2. Планирование. Определение и подготовка результатов планирования, таких как область, время и ресурсы.

3. Сборка: начинается после утверждения конечных результатов планирования

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

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

5. Развертывание. После утверждения всего миграция переходит в рабочую среду.

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

• Миграция может занять несколько месяцев или даже лет.

• Развертывания в рабочей среде являются более рискованными.

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

• Организации обычно сосредоточены на наличии комплексной документации по снижению рисков доставки для доставки.

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

Гибкие волны

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

Миграция волн Agile обычно имеет следующие спринты:

• Спринт ноль (0)

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

• Спринт 1, 2, ..., N

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

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

Корпорация Майкрософт рекомендует модернизировать мейнфреймы и промежуточные системные рабочие нагрузки, следуя итеративной итеративной модели на основе волн Гибкой обработки, акцентируя внимание на инвестициях в новую платформу, ограничивая рост устаревших систем. Этот подход значительно снижает риски реализации, сохраняя существующую бизнес-ценность, при этом внедряя модернизируемую среду. Таким образом, ваша команда также может использовать технологические навыки, которые помогают вашему бизнесу быть более конкурентоспособными. Этот сценарий позволяет Azure Logic Apps помочь вам в модернизации.

Шаблоны модернизации

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

Центр архитектуры Azure предоставляет проверенные шаблоны проектирования и реализации, описывающие проблему, которую они рассматривают, рекомендации по применению шаблона и пример на основе Microsoft Azure. Хотя существуют несколько шаблонов проектирования и реализации, некоторые из наиболее соответствующих шаблонов модернизации мейнфреймов включают в себя "Уровень борьбы с коррупцией", "Strangler Fig", "Сага" и "Хореография" шаблонов.

Шаблон уровня защиты от коррупции

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

Дополнительные сведения см. в разделе "Уровень борьбы с коррупцией".

Шаблон Strangler Fig

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

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

Дополнительные сведения см. в статье Strangler Fig pattern.

Сага и хореография шаблонов

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

Шаблон проектирования Saga — это способ управления согласованностью между службами в сценариях распределенных транзакций. Сага — это последовательность транзакций, которые обновляют каждую службу и публикуют сообщение или событие для активации следующего шага транзакции. Если шаг завершается ошибкой, сага выполняет компенсирующие транзакции, которые противодействуют предыдущим транзакциям. Дополнительные сведения см. в шаблоне распределенных транзакций Saga.

В Azure Logic Apps рабочие процессы могут выступать в качестве хореографов для координации sagas. Действия рабочего процесса являются атомарными, поэтому их можно повторно запустить по отдельности. Тип действия "Область " предоставляет возможность выполнять группу действий только после успешного выполнения или сбоя другой группы действий. Azure Logic Apps проводит компенсирующие транзакции на уровне область, а Сетка событий Azure и Служебная шина Azure обеспечить управление событиями, необходимыми для определенных доменов. Все эти службы, составляющие Службы Azure Integration Services, обеспечивают поддержку, необходимую клиентам, когда им нужна надежная платформа интеграции для критически важных сценариев. Дополнительные сведения см . в разделе "Шаблон хореографии".

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

Следующие шаги

• Центр архитектуры Azure для мейнфреймов и систем среднего порядка