Локально или удаленно, создавать или покупать

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

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

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

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

◦Используйте готовое коробочное приложение, если оно удовлетворяет всем требованиям и приемлемо по цене.

Размещайте приложение у поставщика услуг размещения, если предполагаете оптимизировать свои операции, но желаете сохранить контроль над ПО. Например, можно развертывать настроенный пакет Enterprise Resource Planning (ERP) у

поставщика услуг размещения и передать им ответственность за управление энергопотреблением, оборудованием, сетью и операционной системой. Как правило, поставщик услуг размещения будет обеспечивать очень специфические требования вашей организации, такие как, например, настройка Virtual Private Network (VPN), добавление специализированного оборудования и многое другое. При размещении приложений во внешней компании-поставщике услуг размещения:

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

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

Используйте сервисы в облаке (размещенные у поставщика ПО), если покупаете SaaSприложение у поставщика услуг размещения или ISV; если можете обеспечить спецификацию требуемого приложения; если не имеете ресурсов, времени или навыков для создания приложения; или если существующее стандартное или настроенное приложение необходимо немедленно. Другая причина использования внутренних свойств стандартных блоков сервисов в облаке (таких как эластичность) – создание самого приложения. Приобретая сервисы приложений у поставщика:

◦Выбирайте готовое коробочное приложение, созданное поставщиком ПО, если оно отвечает имеющимся краткосрочным и долгосрочным требованиям. Это SaaS-подход.

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

Производительность

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

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

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

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

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

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

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

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

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

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

Композиция сервисов

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

С появлением сервисов и SOA-приложений отделы ИТ получили возможность предоставлять приложения и данные как сервисы, либо размещенные локально, или приобретенные как SaaS. Портфели сервисов могут по-прежнему предоставлять сочетание традиционных локальных приложений, размещенных локально сервисов и удаленных сервисов через порталы, которые скрывают пользователя от реализаций и позволяют отделам ИТ быстро и без труда переходить на различные сервисы. Однако дизайны и технологии S+S и SaaS обеспечивают отделам ИТ и корпоративным потребителям возможность полной интеграции сервисов. Интеграция сервисов поможет реализовать модель многие-к-одному, при которой все приложения и сервисы доступны пользователю через архитектуру композиции, предоставляющую их как одно приложение (рис. 2). Механизм интеграции сервисов

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

Рис. 2

Механизм интеграции сервисов может объединить множество сервисов в единый интерфейс

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

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

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

◦Компоненты, управляющие доступом, данными, рабочим процессом и правилами.

◦Агенты сервисов, которые согласовывают схемы и обмениваются сообщениями с приложениями, базами данных, Веб-сервисами и другими ресурсами.