О преобразовании унаследованных систем принято говорить так, как будто существует только один путь для их модернизации. Но в действительности преобразование унаследованных систем похоже на навигацию по разветвленной сети автострад: существует множество маршрутов, которые потенциально могут привести ваши унаследованные системы туда, где вы хотите их видеть, пишет на портале TechBeacon Мэтью Клементе, исполнительный вице-президент по глобальным операциям компании Lemongrass.

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

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

Модернизация платформы

Один из самых простых и очевидных способов повысить ценность унаследованной системы — обновить ее до более новой версии (или обновить платформу, от которой она зависит).

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

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

Миграция в облако

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

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

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

Контейнеры и микросервисы

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

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

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

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

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

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

Методологии DevOps

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

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

Внедрение DevOps требует изменения образа мышления вашей организации в отношении доставки и управления ПО; это может потребовать и внедрения некоторых новых инструментов. Но усилия почти всегда оправдывают себя.

Искусственный интеллект/машинное обучение

Благодаря революции в области ИИ, предвестником которой стали инструменты генеративного ИИ, такие как ChatGPT, ИИ и МО преобразуют все сектора технологической отрасли.

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

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

Дорожная карта

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

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

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

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

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

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