Эклов Мохан, старший директор-аналитик компании Gartner приводит советы по переводу существующих корпоративных приложений на нативно-облачную архитектуру. Материал основан на отчете Gartner «How to modernise your application to use cloud-native architecture».

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

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

Типичное унаследованное приложение, перенесенное на инфраструктуру как сервис (IaaS) по принципу «lift and shift» (перенос без модификации), не может в полной мере использовать все возможности облака. Организации, использующие такой подход, часто обнаруживают, что команда миграции «срезала углы» и придумывала обходные пути, чтобы обеспечить работу приложений.

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

Одним из моментов, на которые следует обратить внимание, является то, что типичное унаследованное приложение опирается на традиционные реляционные системы управления базами данных (РСУБД) и ACID-транзакции (атомарность, согласованность, изоляция и долговечность) для обеспечения надежной целостности данных.

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

Однако в современном дизайне приложений используются преимущества многовариантного хранения (polyglot persistence) для оптимизации поведения базы данных для конкретных сценариев использования. Эта концепция позволяет разработчикам выбирать хранилище данных, которое наилучшим образом соответствует данным и их подходу к программированию, а не заставлять данные вписываться в традиционную SQL-модель. Использование РСУБД для хранения всех данных может привести к негибкости дизайна и значительным затратам на масштабирование базы данных.

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

Определение целей

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

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

Построение карты оценки усилий

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

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

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

Ингибиторы модернизации

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

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

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

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

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

Другие проблемы

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

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

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

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