Тренд по переводу унаследованных ИТ-инфраструктур в облако находится в самом разгаре, поэтому как крупные, так и небольшие компании стараются ему следовать, полагая, что перенос вычислительных ресурсов и хранилищ данных на публичные платформы, такие как Amazon Web Services (AWS), Microsoft Azure и Google Cloud Platform, приведет к существенному снижению расходов на техподдержку и администрирование собственных ЦОДов и избавит от необходимости постоянного обновления оборудования.

Однако проблема заключается в том, пишет на портале InformationWeek директор по взаимодействию с клиентами консалтинговой компании Elicit Марк Гонсалес, что в погоне за модой многие компании не понимают, как пользоваться преимуществами публичного облака, не допуская перерасхода средств. По его словам, ИТ-команды нередко неверно подсчитывают затраты по переносу инфраструктуры, применяя при этом методику «lift-and-shift» (миграция в новую среду всего оборудования ЦОДов), которая более характерна при подсчете расходов для IaaS, а не для PaaS.

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

Скорость

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

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

При подключении облачной платформы к сетям предприятия не нужно проводить никаких наладочных работ, тестировать оборудование и софт, подключая одно к другому — подготовка к запуску инфраструктуры в облаке требует всего нескольких кликов. Составители проекта фактически избавлены от поиска стороннего ПО, его покупки, лицензирование и установка на локальные машины — все это уже имеется в облаке в виде SaaS. Так же быстро можно задействовать Azure SQL Data Warehouse, Hadoop-кластеры, кластеры баз данных Amazon Redshift, базы данных SMP, хранилища данных, отдельные виртуальные машины, то есть почти все, что работает в современном ЦОДе.

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

Гибкость

Какие действия предпринять предприятию после того, как выяснилось, что ему явно не достает мощности 10-узлового кластера MPP SQL, который связывает локальную архитектуру приложений с облаком, и что вместо 10 узлов ему нужно было подключить 20? Этот вопрос не требует долгих раздумий, потому что в облаке размер кластера можно видоизменить за несколько минут, затем нужно подождать, пока он подключится к локальному ЦОДу (это займет еще несколько минут), перезапустить процесс инициализации узлов и после этого эти 10 узлов можно задействовать в кластере.

Для сравнения. Во избежание в будущем недостатка вычислительной мощности предприятие приобрело серверный кластер на 20 узлов, но позже выяснилось, что эта мощность избыточна и достаточно 10 узлов. Учитывая, что было приобретено физическое оборудование, а не виртуальное как в первом случае, это означает, что предприятие допустило ненужный перерасход средств. Физическое оборудование определенно уступает в гибкости облачному, поскольку в облаке легко избавиться от ненужных узлов, арендуя вычислительные ресурсы в том объеме, который требуется.

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

Точечное управление вычислительными ресурсами и прозрачность затрат

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

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

Гонсалес приводит имевшийся в его практике случай, когда клиенту требовалось развернуть в облаке аналитическую БД с клиентской информацией с нуля, но в связке с локальными системами. Общее время, которое потребовалось клиенту для введения в строй хранилища (тестирование, пусконаладочные работы, стресс-тесты), не превысило полугода. Годичная стоимость обслуживания нового хранилища обошлась клиенту менее чем в 300 тыс. долл. Капитальные расходы на подобные онпремис-решения обходятся в миллионы долларов, тогда как время, требуемое на закупку, введение в эксплуатацию оборудования, подключение к нему связующего ПО для резервирования и архивации данных, как правило, составляет год и больше.