Изменение поведения приложений: Из ЦОД в облако

Источник: IBM

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

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

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

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

Заключение

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

Работа с данными Active Directory c помощью сценариев: Часть 3. Проблемы, связанные с обработкой данных, загруженных из LDAP-сервера.

Гибкая разработка программного обеспечения с применением уже имеющихся инструментов CCM.

Решение IBM Rational для разработки технических систем
и встраиваемого ПО.

Какой ты программист?.

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

Главная » IBM