Облачные решения: возможности, преимущества, риски

Особенности проектирования облачных решений

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

Таким образом, при проектировании "облачных" решений необходимо учитывать следующее (на примере платформы Windows Azure ):

• Любое приложение, являющееся частью "облака" - удаленный сервис. На этапе планирования решения необходимо учитывать временные задержки, между отправкой запроса и получением результата, а также необходимость контроля статуса соединения и его возобновления.
• Динамичная инфраструктура облака обеспечивает горизонтальную масштабируемость, таким образом, количество единовременно работающих экземпляров приложения может меняться. В связи с этим состояние приложения необходимо хранить в долговременном хранилище (не на локальных дисках).
• Ряд сценариев, стоимость которых велика , в случае их реализации на основе локальной инфраструктуры (к примеру обработка больших объемов данных), могут быть реализованы в "облачном" решении в виде платформенных сервисов.
• Управление выделением вычислительных ресурсов для приложения, их сопровождение осуществляется платформой.
• Стоимость облачного решения. Данное понятие стало актуальным при появлении "облачных решений". Рассмотрим его более детально.

Стоимость "облачного" решения

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

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

Стоимость второй компоненты - вычислительных ресурсов - начинает измеряться с момента начала развертывания приложения и зависит от мощности предоставленных виртуальных машин.

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

Мультитенантная архитектура

Мы рассмотрели, из чего складывается стоимость "облачного" решения. Так каким же образом стоит выстраивать архитектуру приложения, чтобы минимизировать затраты не снижая качества предоставляемых услуг?

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

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

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

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

Рассмотрим этапы перехода к мультитенантной архитектуре:

1. Выделенная архитектура. Каждая группа пользователей использует свою копию приложения (сервиса). Каждая копия ориентирована только на свою группу пользователей, таким образом, каждая копия содержит персональное расширение, в котором хранятся пользовательские настройки. Вся неэффективность данной модели станет наглядна при увеличении числа пользователей. Также становится невозможным повышения эффективности за счет роста масштабов, поскольку фактически пользователи пользуются разными экземплярами приложения.
2. Настраиваемая архитектура. В данном случае приложение, либо сервис настраивается для каждого конкретного пользователя через конфигурацию. Т.е. каждый пользователь работает со своей копией приложения, не смотря на то, что копии идентичны. Вычислительные мощности не разделяются между различными экземплярами приложения, что также не позволяет добиться повышения эффективности за счет увеличения масштабов.. Разделения же самого приложения может быть как виртуальным, так и физическим.
3. Мультитенантная архитектура. Настройка для каждого пользователя выполняется исключительно через конфигурацию, при использовании инструментов для самостоятельной настройки. При этом отсутствует возможность горизонтального масштабирования, т.е. повышение производительности может быть достигнуто только через вертикальное масштабирование.
4. Масштабируемая архитектура. Данная модель поддерживает мультитенатный подход, а также возможность горизонтального масштабирования. При этом новые экземпляры приложений добавляются в общий пул. Общая нагрузка распределяется по всей инфраструктуре. Архитектура настраивается через конфигурацию.

Модели организации мультитенантного хранилища данных

1. Отдельные базы данных. Каждая группа пользователей имеет собственную базу данных, с собственной схемой данных. Может быть эффективной при небольшом числе пользователей в расчете на базу данных. Кроме того, данный вариант предпочтителен, в случае предъявляемых пользователями строгих требований к изоляции и безопасности данных.
2. Совместно используемые базы данных с разными схемами. Все пользователи работают с одной БД, но имеют различные наборы предопределенных полей. Наиболее полезен данный вариант в случае, если хранение данных разных пользователей в одной таблице допустимо, а также заранее известно какие поля потребуются. Может привести к ситуации разряженного наполнения таблиц.
3. Совместно используемые базы данных с совместной схемой. Для хранения расширений данных используются специальные подходы и техники, пользователи работают с одной и той же базой данных. При этом, можно предложить пользователям практически неограниченное количество полей, однако, возникают проблемы при организации индексации и поиска информации. Данный вариант применим, если хранение данных различных групп пользователей в одних и тех же таблицах удовлетворяет требованиям безопасности и изоляции данных.

Прежде, чем перейти к рассмотрению преимуществ и рисков для бизнеса, вкратце рассмотрим подход SOA (Service-oriented architecture).

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

Главными целями, к достижению которых стремится SOA, являются:

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

В основе данного подхода лежат:

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

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

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

Принципы SOA:

• архитектура не должна быть привязана к какой - либо технологии;
• система не должна зависеть от используемой платформы;
• система не должна зависеть от применяемых языков программирования;
• используемые сервисы должны быть независимы от конкретных приложений и обладать стандартизованными интерфейсами доступа к ним;
• сервисы должны быть "слабосвязанными" между собой.

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

Преимущества SOA, SaaS и облачных решений

Рассмотрим более детально, какие именно преимущества способен извлечь бизнес из применения SOA, SaaS и облачных решений:

• Повышение эффективности предоставления услуг. Достигается более глубокое понимание, что же именно необходимо для бизнеса, за счет разработки измеримых компонентов (SOA). Компаниям, реализующим "облачный" подход с использованием SOA и SaaS нет нужны расходовать финансовые, человеческие и ИТ - ресурсы на поддержание собственной инфраструктуры.
• Гибкость. Сформированные службы обладают высокой совместимостью. Новые решения образуются за счет объединения служб ранее созданных решений, что повышает скорость реакции ИТ - служб на постоянно возникающие изменения в потребностях целевой аудитории.
• Масштабирование. Возможность быстро получить необходимое количество ресурсов обеспечивает гибкое масштабирование без внесения ощутимых организационных изменений.
• Доступность. Для доступа к "облачной" платформе необходимо лишь Интернет - соединение.
• Производительность. Территориально распределенные центры данных, ресурсы и платформы достигают величин производительности недоступных для инфраструктуры отдельной компании.
• Контроль. Возможность сочетания различных вариантов размещения приложений: на собственных серверах, на серверах "облака" или их сочетание, позволяет получить необходимую степень контроля за приложением и объединять имеющиеся ресурсы (локальные и "облачные") для решений текущих задач.

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

Риски SOA и SaaS

• Существенная прибыль и экономия возможна в случае, если производительность ранее используемого приложения была низка. В ином случае, переход на SaaS - решение может оказаться даже убыточным. Таким образом, не стоит направлять усилия на изменение решения, от которого не зависит прибыль.
• Сложности проектирования. Всегда есть риск, что спроектированные и реализованные решения не будет приносить заявленных преимуществ. Это может случиться по разным причинам: от ошибок проектирования, до несоответствия решения предъявляемым к нему требованиям (к примеру, конфиденциальность данных).
• Риски, связанные с реализацией решения. Для построения SOA - архитектуры и работы с "облачными" решениями коллектив должен обладать соответствующими компетенциями и опытом, не только в разработке, но и в проектировании решений. Влияние данного риска можно минимизировать, путем прохождения обучения и заключения партнерских соглашений с фирмой - поставщиком.
• Риски использования. Переход на новую модель управления и работы требует начальных инвестиций, для реорганизации технологических процессов и методов работы.

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

1. провести анализ бизнес - функций, возможно сначала необходимо перевести на новую основу сравнительно небольшую и автономную часть бизнеса, сравнения эффективности "до" и "после";
2. сформировать план технологического развития - применение "облачных" решений должно соответствовать нуждам компании и ее клиентов, первоначально имеет смысл только дополнять уже существующие решения там, где это имеет смысл;
3. поддерживать план технологического развития - риски и проблемы будут возникать всегда, только по мере внедрения станет понятно, где и каким образом SOA, SaaS и "облака" могут быть наиболее полезны, необходимо всегда четкое понимание того, что происходит с бизнесом, какие есть проблемные места и как их можно устранить, либо степень их влияния.

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

SOA

1. http://www.ccc.ru/magazine/depot/06_02/read.html?0104.htm
2. http://www.osp.ru/cio/2008/12/5572736/
3. http://citforum.ru/internet/webservice/soa/
4. http://www.information-management.com/news/7992-1.html
5. http://www.information-management.com/news/8262-1.html

SaaS

1. http://www.ibs.ru/content/rus/608/6083-article.asp?archive=1
2. http://www.itpractice.ru/component/content/article/28-interview/221-saasinrussia.html
3. http://www.samag.ru/art/10.2010/10.2010_06.html
4. http://www.interface.ru/home.asp?artId=20217

"Облачные" решения и бизнес

1. http://www.zdnet.com/blog/hinchcliffe/eight-ways-that-cloud-computing-will-change-business/488
2. http://www.intel.com/cd/corporate/pressroom/emea/rus/414904.htm