В теории предполагается отсутствие недостатков сервиса IaaS в таких вопросах как масштабируемость, производительность, гибкость, и проч. А на практике дело обстоит несколько иначе.
Масштабируемость. IaaS улучшает масштабируемые вычисления, позволяя приложениям использовать сотни и даже тысячи серверов одновременно. К сожалению, большинство существующих приложений, которые заказчик хочет разместить в масштабируемой IaaS архитектуре провайдера, требуют изменения в дизайне и кодировании. Традиционные приложения в целом опираются на масштабируемю архитектуру, но первые поколения облаков еще не поддерживают динамическое масштабирование ресурсов, на которых эти приложения выполняются. Зачастую приложение приходится останавливать и запускать заново, добавив оперативную память и процессорную мощность. Вынужденная остановка сервиса неудобна (если вообще возможна) для клиента, особенно в период роста нагрузки и достижения пика потребления сервиса. Выходом из положения может стать покупка у провайдера избыточного потребления ресурсов, достаточного для того чтобы справиться с пиками нагрузки. Но утилизация в таком случае будет низкой, а стоимость высокой.
Первое поколение облаков отличается тем, что улучшение производительности достигается через масштабируемую архитектуру, в основном за счет масшабирования реляционных баз данных
С масштабируемостью напрямую связана и производительность сервиса. Первое поколение облаков отличается тем, что улучшение производительности достигается через масштабируемую архитектуру, в основном за счет масшабирования реляционных баз данных. Но это ведет, опять же, к проблемам, которые решаются путем избыточного выделения ресурсов со всеми вытекающими последствиями. Первое поколение облаков также имеет свойство конфликтовать в борьбе за уровень совместно используемых ресурсов в многопользовательском режиме, а ведет к тому, что приемлемый уровень производительности не может быть обеспечен. Сообщество cloud-пользователей не только совместно использует одну сеть, но и процессорные ядра, и оперативную память. Как досадные соседи, некоторые из пользователей в облаке неожиданно начинают потреблять слишком большой объем общих ресурсов, что непосредственно влияет на производительность, которая нужна остальным.
Гибкость. Хотя первое поколение IaaS - это шаг вперед в плане автоматизации инфраструктуры и скорости выделения ресурсов, но в отношении гибкости - это откат назад. Большинство IaaS провайдеров испытывает недостаток поддержки по части быстрой, практически немедленной кастомизации услуги, и предлагает фиксированный набор конфигураций, ограничивающий выбор заказчика. Первое поколение облачных сетевых ресурсов даже еще менее гибкое, поскольку предлагает весьма слабый контроль над топологией, подсетями, правилами продвижения данных к месту использования и IP адресами.
Первые шаги IaaS
Компания DHL одно из своих приложений - сервис "ПТС", - поместила в облако российского провайдера (речь идет о паспорте транспортного средства). Суть в следующем. Каждый автомобиль имеет паспорт. Но в России автопроизводители наотрез отказываются перемещать эти документы вместе с автомобилем, так как в случае исчезновения того и другого одновременно преступнику будет проще легализовать автомобиль. Поэтому, когда автомобили сходят с конвейера, изготавливаемые для них документы не передаются вместе с машиной в салон продаж, а хранятся отдельно от транспортного средства. Подобная практика характерна для России и некоторых других стран с аналогичной криминальной ситуацией (для европейских дистрибьюторов она неактуальна).
Видя потребность автопрома в специальном решении по доставке клиентам документации на транспортное средство, DHL Express стала предлагать производителям автомобилей передать этот процесс на аутсорсинг. А автопроизводители разумно рассудили, что для доставки документов в региональные офисы проще использовать инфраструктуру DHL Express. Передача громадного количества ПТС у них получается с задержкой, в то время как у DHL в России давно создана развитая сеть.
"Поскольку приложение ПТС и его инсталляции стали быстро расти, мы решили поместить его в облако, - поясняет Геннадий Столяров, руководитель ИТ-департамента DHL в России. - Дело в том, что с приходом облаков появилась (по крайней мере была анонсирована) хорошая возможность очень плавно масштабировать любые инфраструктурные элементы, наращивать или уменьшать - и платить фактически только за то, что используется, И для нас, и для клиентов это важно: не имеет смысла оплачивать запас инфраструктуры и ИТ-специалистов в регионах. Тем более что сегодня, к примеру, нужно два сервера, а завтра - уже десять. Спрос на ИТ-ресурсы может очень сильно меняться, причем в короткие промежутки времени. В решении таких проблем как раз и заключается преимущество облаков, если говорить о самой концепции. Вот мы и попробовали для этого проекта переместить наше приложение в облако и использовать его именно как облачный сервис".
В целом DHL как заказчик облачного сервиса получил желаемое. Но есть и нюансы. "По факту оказалось, что мы получили скорее обычную виртуальную среду, лишь немного усовершенствованную. Удобство есть, но только с точки зрения администрирования, потому что нам не надо обращаться непосредственно к поставщику, чтобы добавить, например, оперативной памяти. Для этого достаточно нажать пару кнопок. Проблема в том, что полученный сервис IaaS, хотя и облегчает наше положение, все-таки далек от ожиданий, поскольку при каждом изменении конфигурации (например, наращивании мощностей) сервис "ПТС" приходится приостанавливать. А в силу специфики бизнес-процесса останавливать его можно, например, лишь по ночам и в выходные, что неудобно".
Столяров поясняет, что периодически представители DHL общаются с компаниями, которые предлагают облачные сервисы, и пытаются оценить их предложения. "Все обещают примерно одно и то же, но по факту возможности провайдеров не одинаковы", - говорит Геннадий. - Например, на это рынок уже пришел T-Systems, мы с ними сейчас ведем переговоры. Пока конкретных результатов нет, но эта компания показывает хорошую заинтересованность".