Облачные приложения не всегда работают так, как хотелось бы, и этому есть множество причин — от нехватки ресурсов до «слепых зон» и плохого планирования, отмечают опрошенные порталом ComputerWeekly эксперты — и дают советы, как решать эти проблемы.

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

Оуэн Роджерс, директор по исследованиям в области облачных технологий компании Uptime Intelligence, утверждает, что архитектура облачных приложений должна быть масштабируемой с точки зрения производительности и эффективности. К сожалению, многие предприятия просто переносят приложения в облако без модификации («lift and shift»). «Для масштабирования большинство приложений придется перепроектировать, что повлечет за собой затраты денег и времени», — поясняет Роджерс.

Джон Лукас, соучредитель и директор компании Hyve Managed Hosting, добавляет, что решающее значение имеют правильное планирование и тщательное тестирование. «Сядьте и проработайте спецификацию и свои требования, а затем воплотите их в среде разработки», — говорит он.

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

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

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

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

Разделяй и властвуй

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

«Такое впечатление, что некоторые заказчики просто не задумываются о том, насколько большим будет размер системы или сколько одновременных пользователей будут на ней работать. Те заказчики, которые добиваются хороших результатов, четко спланировали свою работу, не ограничиваясь тем, что будет хорошо работать в течение одного-двух лет», — говорит Мэддерс.

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

Грант Кейли, главный технолог NetApp по Великобритании и Ирландии, говорит, что разработчики могут не иметь возможности оптимально строить и разрабатывать приложения, которые максимально эффективно используют базовые ресурсы. «У них нет особого выбора, поскольку им предоставляется инструмент — платформа разработки, — который может вызывать проблемы с производительностью», — поясняет он.

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

«Дело не в том, что люди неаккуратны, — добавляет он. — Мы все стараемся разрабатывать приложения как можно скорее, потому что нужно успеть вывести их на рынок, нужно не упустить момент для бизнеса».

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

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

Благодаря развитию платформ low-code/no-code создавать приложения могут менее квалифицированные команды, что также потенциально может вызывать проблемы, добавляет Кейли.

Придерживайтесь своих принципов

Однако Ханс де Виссер, директор по продуктам поставщика платформы разработки приложений low-code Mendix, утверждает, что с этой проблемой часто можно справиться, если более четко следовать нативно-облачным (cloud-native) принципам.

«Примените подход „объекты с сохранением состояния, соединения без сохранения состояния“, чтобы убедиться, что это работает в гипермасштабе, — говорит он. — Вы можете разбить свое приложение на несколько микросервисов или независимых компонентов, независимо выпускаемых и масштабируемых».

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

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

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

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

«Хитрость low-code заключается в максимальном абстрагировании и автоматизации, чтобы менее технически подкованные люди, не имеющие представления об архитектуре и способах ее построения, могли создавать довольно сложные приложения», — отмечает де Виссер.

Маркус Ниспел, технический директор Extreme Networks в регионе EMEA, считает, что необходимо сосредоточиться на разработке для «неограниченного» распределения пользователей, устройств и приложений. «Необходимо учитывать местоположение облачных приложений относительно тех, кто хочет их использовать», — отмечает он.

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

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