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