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

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

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

Если разработчик переносит свое приложение, используя концепцию "Программное обеспечение как сервис" (Software as a Service - SaaS), пользователь может управлять только доступом к приложению с настольного компьютера или мобильного устройства для выполнения бизнес-задач (например, биллинг и выписка счетов); в этой схеме пользователь не может управлять операционной системой, аппаратным обеспечением или сетевой инфраструктурой, на которой выполняется SaaS-приложение. Только разработчик может создавать, развертывать, выполнять и осуществлять управление обновлениями и пакетами исправления ошибок для всех функциональных возможностей приложения.

Если разработчик осуществляет перенос приложения, используя концепцию "Платформа как сервис" (Platform as a Service - PaaS), пользователь может управлять приложением в течение всего цикла жизни платформы, например, управлять обработкой электронных таблиц и платежных ведомостей. Пользователь определяет, какие изменения выполнить в приложении (например, добавление новых пунктов в ниспадающий список). Он по-прежнему не может управлять операционной системой, аппаратным обеспечением или сетевой инфраструктурой.

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

В отчаянном поиске быстрых решений разработчик ведет себя реактивно.

Кошмар реактивности

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

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

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

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

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

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

• Не разбил приложение на модули.
• Не включил в приложение окно порогового значения ресурса для отслеживания использования экземпляров ресурса.

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

Упреждающие изменения поведения

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

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

Ниже приведены два примера модулей, которые разработчик может включить в приложение:

• Элемент управления "ниспадающий список".
• Окно пиктограмм пороговых значений.

Модуль элемента управления "ниспадающий список"

Этот модуль позволяет пользователям сделать выбор из списка взаимоисключающих значений. Одним нажатием кнопки мыши пользователь может выбрать один и только один вариант. Удерживая клавишу Ctrl, пользователь может выбрать несколько вариантов в списке. В стандартном ниспадающем списке пользователь ограничен вариантами, указанными в списке, но в элементе управления "комбинированный список" (combo box), пользователь может ввести значение, отсутствующее в списке.

Один из примеров - ниспадающий список бизнес-задач, которые необходимо активизировать:

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

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

При выборе варианта Выписка счетов отображается список счетов. Затем можно выбрать счет для просмотра и распечатки. Можно вызвать пустой бланк для заполнения и отправки адресату по электронной почте. При выборе варианта Биллинг выбирается счет для просмотра и осуществления платежа.

Если значение отсутствует в списке, а пользователь знает о том, что в приложение была добавлена новая задач, он может ввести в комбинированный список, скажем, пункт invoicing2.

Вот еще один ниспадающий список, отображающий четыре варианта пороговых значений:

• Ресурс.
• Пользователь.
• Запрос данных.
• Инструментальная панель.

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

Например, при выборе варианта Ресурс на экране появляется окно с пиктограммой использования ресурсов. Если затем выбрать только вариант Пользователь, появится окно с пиктограммой статуса пользователя. При выборе первых двух вариантов удерживайте клавишу CTRL для отображения расположенных рядом окон для обоих вариантов. Для отображения первых трех вариантов в одном окне (каждый на отдельном уровне) выберите вариант Инструментальная панель.

Модуль окна пиктограмм пороговых значений

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

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

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

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

Следующий вопрос: как сохранить упреждающий подход?

Как можно сохранить упреждающий подход

После успешных изменений приложения для работы в облачной среде сохраняйте упреждающий подход. Задайте себе вопросы о:

• политиках пороговых значений;
• ограничениях, присущих браузерам;
• сохранении текущего состояния приложения;
• механизмах восстановления после сбоев;
• проблемах безопасности.

Политики пороговых значений

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

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

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

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

Ограничения, присущие браузерам

Знаете ли вы, что Mozilla Firefox загружает страницы быстрее и использует меньше памяти, чем Internet Explorer? Основное ограничение Firefox состоит в том, что он может завершить свою работу или начать медленно реагировать, если недоступны:

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

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

Если окно пиктограмм показывает, что потребление ресурсов превысило граничный уровень, должны отобразиться:

• Предупреждение о чрезмерности потребления.
• Предложение закрыть браузер или выполнить автоматическое удаление системой процессов firefox.exe и повторно запустить браузер.

Сохранение текущего состояния функций приложения

Знаете ли вы, насколько хорошо выполняется сохранение текущего состояния функций приложения? Сохранение текущего состояния (statefulness) говорит о том, насколько хорошо ведет себя одно состояние функции приложения при переходе к следующим состояниям других функций в облаке.

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

Если переход из одного состояния в другое приводит к замедлению работы приложения в облаке по сравнению с внутренним приложением, рассмотрите следующие причины:

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

Механизмы восстановления после сбоев

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

Вот некоторые примеры механизмов восстановления после сбоев:

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

Проблемы безопасности

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

Внутреннее закрытое облако позволяет сохранять данные и извлекать их из известных мест в конкретной юрисдикции (например, США или Канаде). Это удобно при сохранении важных, нормативных, секретных и тестовых данных.

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

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

До предоставления полномочий в контракте должны быть озвучены обязанности администратора: что он может и чего не может делать с вашими данными, каких правил экспорта данных должен придерживаться, какие политики должен реализовать для снижения рисков создания хакерами центров управления и контроля (Command and Control - CnC) в облаке.

Хакеры обладают инструментами обнаружения обмена данными между вашим настольным компьютером и неизвестным месторасположением и наоборот. Платформы PaaS использовались как центры CnC для прямых операций ботнетов, выполняющих распределенные атаки типа "отказ в обслуживании" и для установки в облаке вредоносных (malware) приложений. Хакеры могут разработать и развернуть вредоносные приложения в целях:

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

Заключение

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