В рубрику "Облака" | К списку рубрик | К списку авторов | К списку публикаций
Облачные сервисы считаются одним из самых быстро развивающихся трендов бизнеса. Все больше и больше компаний задумывается о миграции тех или иных систем в облако. Так, рано или поздно перед CIO встает вопрос: как правильно выбрать сервис для достижения максимального эффекта в рамках реализации бизнес-процесса и повышения эффективности бизнеса в целом? Здесь важен основательный и поэтапный подход.
Прежде всего стоит знать и понимать основные характеристики всех разновидностей облачных сервисов. Всего таких разновидностей три: частные, публичные и гибридные.
Частное облако – это сервис, разворачиваемый в IТ-инфраструктуре заказчика, в его локально-вычислительной сети. Если говорить о конкретных примерах, то в данном случае уже стали традиционными сервисы на базе Hyper-V, VMWare и т.д. – систем виртуализации, которые базируются либо на вычислительных мощностях, единых СХД, либо на распределенных системах хранения данных, которые объединяют в дисковое пространство ресурсы с нескольких серверов. Последняя модель сейчас становится довольно популярной, поскольку предполагает большую отказоустойчивость системы. Дело в том, что СХД по тем или иным причинам может "упасть", и в таком случае вместе с ней "упадет" и вся система виртуализации. Последняя концепция – несколько серверов, в которые вставляются несколько жестких дисков, которые, в свою очередь, подсоединяются к вычислительным мощностям, тем самым убирая точку отказа в виде редко дублируемого в силу стоимости СХД. За счет этого достигается надежность процессов – существенно сокращается вероятность простоя бизнеса.
Публичные облака – решения, расположенные в публичном Интернете. Наиболее крупные провайдеры – Microsoft Azure, Amazon и др. Здесь за все отвечает провайдер – за надежность, доступность, масштабируемость, сохранность данных и т.д. Чаще всего за эксплуатацию публичного сервиса отвечает поставщик: необходимо заключить договор об уровне оказываемого сервиса (SLA) и дальше голова у заказчика не болит ни о чем, кроме денег.
При первом рассмотрении затраты при использовании публичного облака выше, но если копнуть глубже, то данные сервисы могут оказаться довольно выгодным приобретением в связи с тем, что у крупных провайдеров есть возможность использовать собственные технологии, иметь специальные цены от поставщиков оборудования, недоступные обычному потребителю.
Третий вид – гибридные облака. Как уже можно понять из названия, данные сервисы представляют собой решение, объединяющее частные и публичные облака.
Перейдем к рассмотрению сценариев использования этих сервисов. Зачастую клиенты, находящиеся на стадии принятия решения об использовании облаков, задаются вопросом "Насколько безопасно переносить наши системы, нашу корпоративную информацию в облачную среду?". Наша позиция в данных вопросах обычно такая – не стоит, руководствуясь современными тенденциями, бездумно выносить в облако все подряд. Безусловно, при всем удобстве использования таких технологий вопределенных ситуациях вынос данных в облачную среду может быть не лишен серьезных рисков для бизнеса. Несмотря на довольно высокий уровень безопасности, которого достигли облака, минимальная вероятность утечки данных все равно присутствует. К каждому сценарию использования нужно подходить очень внимательно – лучше всего разбить IТ-сервисы на компоненты и определить, что стоит, а что не стоит выносить в облако.
Итак, существует несколько сценариев.
Первый сценарий
Подразумевает полный вынос в облачную среду конкретного бизнес-приложения.
Второй сценарий
Перевод конкретной функциональности – например, при локальной работе того или иного приложения функцию архивирования данных мы отправляем в облако. За счет применения такого сценария мы можем повысить отказоустойчивость нашего сервиса, используя частное или гибридное решение.
Например, развертывание резервной ноды SQL-сервера в облаке, при этом основная нода остается размещенной локально. Таким образом, при возникновении неполадок с локальной инфраструктурой рабочая программа будет продолжать работать при использовании SQL, расположенной в облачном сервисе. Возможно, это будет не так быстро, как в случае использования локального сервиса, но главное – не "упадет" рабочий процесс: по-прежнему можно просматривать, редактировать и выгружать данные.
Третий сценарий
Использование полностью нового сервиса. Например, компания начинает пользоваться облачным сервисом BI, который получает информацию из облачной ноды SQL-сервера, из которой выгружается информация для проведения аналитики. Основной плюс в этой схеме – не нагружается рабочая база данных, в которой ведутся оперативные транзакции, не снижается производительность. В то же время сотрудники, которым требуется та или иная отчетность, могут получать требуемую информацию.
Четвертый сценарий
Подразумевает наличие сервисов, развернутых как в локальной, так и в облачной средах, между которыми настроено взаимодействие. Сценарий применяется при использовании гибридных сервисов. Например, учетная система предприятия розничной торговли, работающая с транзакциями "физических" магазинов, находится локально, а аналогичный сервис, находящийся в облаке, обрабатывает заказы из интернет-магазина в облачной среде. Здесь мы можем достигнуть фактора надежности за счет того, что используем две независимые системы. Второй плюс – мы можем загружать данные из облачной системы в локальную за счет видимости данных сервисов. Например, при совершении транзакции в интернет-магазине у нас обновляются данные об остатке на складах локальных точек.
Затрагивая тему плюсов и минусов сервисов, предлагаю для начала рассмотреть публичные и частные облака, поскольку они наиболее противопоставлены друг другу.
Плюсы: быстродействие, надежность за счет хранения информации в локальном контуре.
Минусы: риск доступа к данным третьих лиц – может прийти сторонний человек, и, грубо говоря, взяв сервер под мышку, удалиться в неизвестном направлении. За эксплуатацию сервиса отвечает IТ-отдел – только там есть информация относительно того, насколько плачевна или хороша ситуация с сервисом (например, своевременно ли производится бэкап и есть ли он в принципе).
Плюсы: возможность выбора наиболее качественного и надежного провайдера путем сбора информации по открытым каналам, в частности Интернета (большинство провайдеров публикуют исчерпывающую информацию по использованию предоставляемых ими сервисов). Наличие гарантий – договор о финансовой ответственности за работоспособность сервиса (SLA). В большинстве случаев анонсируемые характеристики всегда соответствуют действительности. Безопасность – крупные вендоры регулярно проходят аудиты по уровню безопасности, предоставляют достаточные средства для использования и приобретению серьезного надежного оборудования по требованию заказчика.
Минусы: в условиях российских реалий Интернет не достиг скоростей, требуемых для комфортной работы, – в данном случае разница с локально развернутой системой очень ощутима. К публичному облаку теряется доступ в случае сбоя сервиса провайдера, что опять-таки в условиях российских реалий случается не так редко. Иначе говоря, если бизнес-процесс отличается высокой критичностью, в случае его переноса в облако возникают серьезные риски. Сравнительно недавно, в связи с обострившейся политической ситуацией, обозначился еще один, "психологический" минус – боязнь появления санкций при использовании сервиса зарубежного провайдера. Однако, как показывает практика, данный риск существует большей частью лишь в головах. Теоретически он имеет место скорее для определенных государственных структур, которые в данном случае могут представлять потенциальный интерес для иностранного правительства. Иначе говоря, если вам еще ни разу не звонили из американского консульства, скорее всего опасаться вам нечего. Но даже если ваш начальник – бывший фээсбэшник, можно подстраховаться и самостоятельно делать бэкап, храня данные и в локальной среде.
Данный сервис прежде всего позволяет обеспечить гибкость: зная плюсы и минусы частных и публичных облаков, мы можем построить нашу потенциальную облачную структуру таким образом, чтобы в ней максимально сочетались плюсы обоих вариантов и по возможности отсутствовали риски. Для сценария, где нас в большей степени интересует производительность и заказчики, использующие сервис, находятся в офисе и используют "толстый" клиент, мы выбираем локальное развертывание; если таких ограничений нет – облако.
Для принятия решения об использовании того или иного сервиса конкретной компании стоит рассмотреть соответствующий алгоритм. Прежде всего речь идет о расчете стоимости компонентов: "железа" (источники бесперебойного питания, сетевое оборудование и т.д.), сопутствующего системного оборудования, требуемых мощностей и пр. Далее вся стоимость делится на пять лет – сейчас такая формула считается общепринятой для расчета длительности эксплуатации оборудования, рекомендованной производителем. Конечно, можно продолжить использовать сервис и по истечении десяти лет, однако в силу динамичного развития данных технологий, этот сервис скорее всего уже устареет, не будет соответствовать требованиям, которые у вас к нему на тот момент появятся. Также не стоит забывать о стоимости расширенной поддержки обслуживания, оказываемой вендором (например, замена вышедшего из строя сервера при наличии сервисного контракта произойдет на следующий же день, а не в течение 45 дней, прописываемых в условиях стандартной гарантии), – не менее 20% общей стоимости сервера. Складываем стоимость оборудования, расширенной гарантии с затратами на техподдержку и делим ее на 60 месяцев. Итог – ежемесячная стоимость.
Далее компании-подрядчику отправляется техническое задание для расчета стоимости размещения данной инфраструктуры в облаке, а затем сравнивается рассчитанная стоимость с полученной ранее. В этой ситуации может возникнуть ряд нюансов. Например, неуверенность, что данный сервис "приживется" в компании: в качестве примера можно привести ситуацию, когда компания запускает интернет-магазин и не имеет гарантий, что бизнес "взлетит". В этом случае стоит рассмотреть самый пессимистичный сценарий и разделить стоимость требуемого "железа" на полгода. Полученная сумма – затраты в условиях закрытия бизнеса. В такой ситуации стоимость объема аренды вычислительных мощностей может оказаться гораздо выгоднее. В частности, на основании этого алгоритма IТ-директор может принять конкретное решение и обосновать его перед конечным бизнес-пользователем.
Опубликовано: Журнал "Технологии и средства связи" #4, 2014
Посещений: 26731
Статьи по теме
Автор
| |||
В рубрику "Облака" | К списку рубрик | К списку авторов | К списку публикаций
