Предприятия продолжают переводить в облако объекты инфраструктуры, в числе которых превалируют второстепенные объекты типа систем для применения практик DevOps или унаследованные системы с «нераспознанной» архитектурой, пишет на портале InformationWeek энтузиаст технологий Билл Клеймен. Особенно сложные вариации устаревших платформ переводятся из монолитной структуры в микросервисы. В облако также устремляются проекты, связанные с поглощением данных, IoT, мейнфреймами и даже ERP-системами.

По словам Клеймена, в прошлом году он стал свидетелем того, как несколько предприятий — причем из разных отраслей промышленности — приступили к частичному или полному переносу в облачные сервисы, например Google Cloud Platform (GCP), своих устаревших окружений, в т. ч. экосистем SAP или Oracle, а также ERP-систем на базе массивных архитектур IBM AS/400 и связанных с ними компонентов. Впрочем, пока что большинство компаний не спешат с переносом подобных систем в облако.

Существует несколько причин, которые препятствуют модернизации:

  • Страх, неуверенность, колебания. Пока что не так много компаний готовы к модернизации, потому что перспектива перевода в облако критически важных бизнес-систем может быть пугающей. Вдобавок в ИТ-прессе ощущается нехватка отраслевых примеров внедрения, что является дополнительным сдерживающим фактором. Все это не позволяет предприятиям окунуться в дорогостоящие эксперименты.
  • Сложность. Некоторые ERP-системы обладают жесткой привязкой к платформе AS/400 или другим проприетарным платформам, при этом их возраст может достигать нескольких десятилетий. Естественно, что многие компании к ним «приросли» и системы наподобие SAP продолжают справляться со своими задачами, но в режиме онпремис.
  • Стоимость и инвестиции. Некоторые компании вложили в свои ERP-системы или мейнфреймы миллионы, а то и десятки миллионов долларов. Годы инвестиций в разработку и развитие инфраструктуры, контракты, персонал и многое другое — все это подразумевает, что предприятия нуждаются в подтверждении окупаемости инвестиций (ROI) для перехода в облако.

Как видим, у предприятий имеются достаточно веские основания откладывать «переезд», однако они прекрасно понимают, что для закрепления на цифровом рынке им придется и самим «оцифроваться», отбросив устаревшие схемы развертывания и выискивая пути перевода мейнфреймов и ERP в облачные службы Amazon, Microsoft, IBM, Google или других провайдеров. В качестве альтернативы организации могут рассмотреть мощные гибридные решения.

Облачные сервисы манят

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

Миграция более 6 млн. строк устаревшего кода RPG/Synon в сервисно-ориентированную архитектуру, пригодную для облачного развертывания. Одна компания изъявила желание стать цифровой, для чего было решено перевести в облако массивную систему IBM AS/400, которая много лет выполняла свои функции онпремис. Учитывая масштабность проекта, все шаги были скрупулезно спланированы. Сначала был проведен аудит кода, который показал пригодность 6 млн. строк кода для связки с облаком. После того, как код был перенесен, программисты заново переписали 150 точек интеграции (стык в коде, который позволяет дописать код для добавления необходимого функционала).

Код проверялся при помощи утилиты для проверки RPG-кода, программы GS Analyzer и инструментов для анализа отслеживаемости и визуализации устаревшего кода X-2E. Планировка миграции также предусматривала перевод IBM DB2 на гораздо более гибкую БД MariaDB. В ходе второго этапа организация перенесла в облако платформу DevOps. Процесс миграции время от времени ставил новые задачи, требуя креативного подхода, но результат превзошел ожидания. К слову, они были повышенными, поскольку рассматриваемое предприятие хотело интегрировать несколько направлений бизнеса в одну цифровую среду.

Перенос SAP HANA и других компонентов в облако. Перемещение ERP-системы в облако — очень сложный процесс, поскольку любая ошибка может привести к серьезным последствиям. Не стоит забывать, что ERP-решения наподобие SAP являются основными платформами для обеспечения операционной деятельности для бизнеса. Клеймен советует избавиться от клейма «ERP — дойная корова» и делать упор на архитектуры нового поколения. Что касается SAP, то самые успешные миграции, за которыми он наблюдал, были проведены в форме параллельных проектов. Допустим, что организация хочет, например, переместить часть или всю свою экосистему SAP в GCP. Для этого ей необходимо:

  • узнать, как S/4HANA вписывается в рабочее окружение и какие преимущества это дает;
  • выявить ключевые требования для бизнеса, проанализировать базовый ландшафт;
  • виртуально спланировать прообраз целевого облачного решения и наметить план внедрения SAP.

Клеймен также рассказал о случае интеграции чрезвычайно сложного движка для электронной коммерции с SAP и GCP. Команда интегратора создала целевой дизайн с задействованием SAP HANA, Google BigQuery, Google DoubleClick и других компонентов, связав их в гибридную облачную архитектуру. В итоге была создана мощная мультиоблачная архитектура: команда перевела SAP Hybrid Marketing в AWS, тогда как 50 базовых систем, в т. ч. SAP ERP (IS-R и AFS), SAP Business Warehouse, Salesforce и многие другие были интегрированы с GCP и AWS. Главное в этом проекте — очень осторожный подход в связке с проработанной концепцией. Исходя из этого, системы были протестированы на производительность и возможности интеграции еще до внедрения.

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