Часто предприятия и в государственные учреждения хотят, чтобы их традиционные клиентские или клиент-серверные приложения, прекрасно работающие внутри организации, так же хорошо вели себя и в облачной среде. Для этого необходимо упреждающим образом изменить поведение приложений до их миграции в облако. В этой статье автор рассказывает о кошмаре реактивного поведения, дает примеры упреждающих изменений приложений и предлагает способы сохранения упреждающего подхода при миграции приложений.
В хорошо спроектированном приложении одно состояние функции приложения плавно и быстро переходит в состояние другой функции. Приложение доступно всегда, без перерывов, за исключением запланированных остановов на обслуживание.
Рано или поздно разработчик приходит к решению перенести приложение в облачную среду. Рассмотрим сценарий, когда разработчик не действует упреждающим образом. При подготовке к миграции он делает некоторые изменения в приложении, такие как добавление диалогового окна для ввода пользователями своих учетных данных; учетные данные, среди прочего, определяют степень контроля над приложением в зависимости от арендуемого облачного сервиса.
Если разработчик переносит свое приложение, используя концепцию "Программное обеспечение как сервис" (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) приложений. Хакеры могут разработать и развернуть вредоносные приложения в целях:
- размещения экземпляров вредоносных ресурсов;
- переустановки пороговых уровней в нереально высокие значения;
- изменения состояния функций приложения в следующие состояния вредоносных функций.
Изменение поведения внутренних приложений для работы в облаке требует предварительного планирования решения проблем сохранения упреждающего подхода при выполнении изменений в поведении после миграции приложений. Разработчики, пользователи и бизнес-аналитики должны совместно работать над установкой политик пороговых значений, преодолением присущих браузерам ограничений, настройкой механизмов восстановления после сбоев и решением проблем безопасности в облаке. Решение этих проблем намного упрощает задачу сохранения упреждающего подхода при выполнении изменений в поведении приложения.