Опубликован: 30.05.2011 | Доступ: свободный | Студентов: 2238 / 142 | Оценка: 4.12 / 4.41 | Длительность: 12:00:00
Лекция 3:

Стратегия развертывания облака

< Лекция 2 || Лекция 3 || Лекция 4 >
Аннотация: В рамках данной лекции будут рассмотрены следующие вопросы: SaaS - мифы. Какие приложения организации следует переводить на "облачную" основу и когда. Развертывание "облака":сценарии, стратегия

Мифы о SaaS

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

Миф №1. Хранить информацию на сервере сторонней компании небезопасно (или "Организация не может отказаться от услуг SaaS - поставщика, не потеряв данные").

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

Миф №2. Невозможно принять оперативные меры, в случае некорректной работы арендуемого программного обеспечения.

SaaS -приложение, в настоящий момент, функционально не отличается от аналогичного desktop - приложения. Функции оперативного управления и контроля приложения, как правило, осуществляются самим клиентом, в то время как, сопровождение, обновление и т.п. - функции поставщика услуг.

Миф №3. Организация, оплатившая длительную аренду, переплачивает (или "Экономия при использовании SaaS неочевидна").

Зачастую, при расчете затрат упускают из вида, что в стоимость SaaS включены: ПО, оборудование, плата за электроэнергию, каналы связи, доступ, архивирование, оплата труда персонала.

Миф №4. SaaS подходит только для малого и среднего бизнеса.

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

Что и когда нужно переводить в облако

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

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

Согласно статистике наиболее востребованы следующие SaaS - приложения (см п. 4 списка дополнительных источников):

  • Почта и коммуникации;
  • Антивирусные системы;
  • Службы технической поддержки;
  • Проектный менеджмент;
  • Дистанционное обучение.

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

  1. Необходимость быстро разворачивать новые версии сред разработки и тестирования.
  2. Необходимость отсутствия ограничений на число экземпляров различных вариантов пользовательских сред.
  3. Необходимость оперативного учета количества и стоимости потребляемых IT - ресурсов.

Сценарии использования облака

Существует два способа использования "облачных" технологий:

1. Размещение приложения в "облаке"

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

2. Использование сервисов "облака"

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

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

Стратегия развертывания облака

Во - первых, перед началом процесса формирования "облака" необходимо убедиться в том, что это именно то, необходимое вам решение. Необходимо четко осознавать стоящие перед вами задачи и перспективы.

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

  1. Пробный этап. Переход на облако, это прежде всего смена стратегии, переосмысление роли информационных технологий в организации, в целом. Таким образом, прежде чем менять IT - подход в организации, необходимо сменить "стиль" мышления соответствующим образом. Имеет смысл, предоставить своим сотрудникам возможность работы с публичными "облаками", следует перевести ряд задач на "облачную" основу. Для конечных пользователей "облаков" важно обладание четким пониманием, что такое "облако", какие задачи с помощью него можно решать. Данный этап поможет оценить степень готовности организации в целом к реорганизации IT - инфраструктуры, а также привить основные навыки работы с "облаками".
  2. Формирование требований. После того, как в организации сформируются определенные правила и нормы, по началу скорее неформальные, использования облачных платформ, необходимо задуматься о формировании общеорганизационных требований к предоставляемым внешним поставщиком услугам. К примеру, необходимо определиться с тем, какие именно сервисы и платформы нужны для работы, сколько необходимо систем хранения данных. На данном этапе следует определиться с поставщиками "облачных" услуг, сформировать требования к архитектуре и функционалу используемых решений. Результатом данного этапа должен быть набор формализованных требований к "облакам" организации.
  3. Построение частного облака. Данный этап актуален для крупных компаний. Началом данного этапа можно считать момент, когда большая часть сотрудников активно пользуется "облачными" сервисами в своей работе. При наличии экономической целесообразности, можно начать формирование своего корпоративного вычислительного облака, на базе имеющегося центра обработки данных. В конечном счете, эволюционным развитием подобного центра и является корпоративное "облако". При этом, формирование своего центра облачных вычисление не обязательно означает отказ от услуг внешних поставщиков подобных решений. Вполне может использоваться гибридная схема работы, когда для решения поставленных задач используется как частное, так и внешнее "облако".

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

Мифы о SaaS в России

http://www.e-xecutive.ru/knowledge/announcement/1341745/

Мифы об облачных вычислениях

http://www.ibm.com/ru/cloud/pdf/Dispelling_the_vapor.pdf

Критерии оценки на соответствие требованиям "облака"

http://www.bureausolomatina.ru/node/99

Облачные вычисления

http://www.devbusiness.ru/mkozloff/2010/10/26/будущее-облаков-россии

http://www.osp.ru/nets/2010/07/13004617/

http://www.itsec.ru/articles2/Oborandteh/oblako-ili-korobka

http://materials.it-event.ru/470/SaaS.pdf

http://www.mobiset.ru/articles/text/?id=5186

< Лекция 2 || Лекция 3 || Лекция 4 >
Роза Мальцева
Роза Мальцева
Игнат Гринько
Игнат Гринько

Примерно месяц назад получил на сайте код Дримспарк, сегодня вводил его на сайте Дримспарк, пишет: Недействительный код проверки. Проверьте правильность введенного кода. Код вводил методом: скопировать-вставить.

Дмитрий Дряничкин
Дмитрий Дряничкин
Россия, Казань
Атанас Маринов
Атанас Маринов
Болгария