Переход от эксплуатации приложений в облаке к решениям в облакеИсточник: CIO
Два года назад основным возражением против перехода в облако были соображения безопасности. Поставщики облачных сервисов быстро наработали убедительные ответы на подобные вопросы. Сегодня вопрос безопасности облаков всем уже поднадоел и ушёл на второй план. Тем более что массовых случаев утечек данных клиентов из облачных сервисов пока не наблюдается, а вот скандалы вокруг традиционных систем возникают с пугающей регулярностью. Пока нет доказательств того, что Мэннинг и Сноуден могли бы повторить свои подвиги, если бы секретные документы хранились в "облаке". Впрочем, сегодня к облачным провайдерам возникает множество других вопросов. Особенно к провайдерам PaaS- и IaaS-решений. Всё дело в том, что большинство пользователей уже получили позитивный опыт эксплуатации облаков, хотя бы на примере почты, документов Google или файловых сервисов. Они убедились, что это хорошо, удобно и действительно работает, и даже попробовали различные SaaS-сервисы. Чем большинство SaaS-решений отличается от традиционных систем on premise? Огромное количество таких сервисов требует минимальных усилий для того, чтобы начать ими пользоваться. Обычно в таких сервисах не предполагается миграции огромных массивов данных, сложных процедур внедрения, адаптации экранных форм под параметры, принятые в компании, и прочих элементов обычного внедрения. Поэтому чаще всего первый опыт использования SaaS связан с теми функциями, которые в компании не были автоматизированы вообще или были автоматизированы неудовлетворительно либо недостаточно с точки зрения пользователей. Какой вывод делают пользователи? Облака - это дёшево, просто и удобно - а значит, следующий шаг - готовность перенести в облако более тяжёлые бизнес-решения. Однако опыт эксплуатации облачных приложений по модели SaaS в случае PaaS- и IaaS-решений не работает. PaaS- и IaaS-продукты предполагают традиционный процесс внедрения, с построением архитектуры, развертыванием, миграцией, сопровождением и прочими атрибутами ИТ-сервисов. Более того, в таком облаке, в общем-то, будут работать все те же продукты и на тех же платформах, что и в обычных дата-центрах компаний, разве что оборудование будет принадлежать провайдеру, а не самой компании. А значит, и облака в итоге предлагают не что-то новое, прорыв, принципиально отличный от всего, чем ИТ-инфраструктура была ранее, а вполне привычные CIO ИТ-сервисы. Раз уж CIO всю свою профессиональную деятельность занимались переговорами с вендорами и поставщиками ИТ-решений, то зачем делать исключение для облаков? То, что крупные облачные провайдеры не идут на переговоры и предлагают очень ограниченные варианты SLA, не совсем верно. Как и с традиционными вендорами, всё дело в стоимости контракта. Финансовая модельМодель pay-as-you-go, предлагаемая многими облачными сервисами, совершенно справедливо считается одним из важнейших преимуществ облачного подхода. Изначально цена облачных сервисов выглядит очень привлекательной. Правда, без пробной эксплуатации или большого опыта дать правильные оценки потребностей компании в ресурсах облачного провайдера может быть довольно сложно. Тут как с алкоголем. Можно взять стаканчик в баре, можно купить бутылку в гипермаркете, а можно приехать на оптовый склад и там закупить десяток ящиков. Стоимость одного и того же продукта будет очень сильно разниться. Никто не ждёт, что оптовый покупатель станет платить по цене стаканчика. На самом деле многие облачные сервисы имеют довольно гибкие возможности для оптовых заказчиков услуг - крупных предприятий, промышленных приложений. В итоге стоимость самого сервиса отступает на второй план по сравнению с более привычным фокусом на процессах и архитектуре. Необходимо, правда, учитывать, что у каждого вендора свои собственные представления о биллинге. Одни считают операции, загрузку процессоров, скачанные/залитые данные и т. п. Такой биллинг в итоге может быть довольно замысловатым и малопрозрачным. Другие вендоры считают пользователей, поштучно и оптом: от нуля до 20 пользователей - X долларов за штуку, 21-50 - Y и так далее. Нужно учесть: в первой модели возможны нестандартные нагрузки на сервис, вызванные как внутренними, так и внешними причинами, что в итоге может привести к неожиданному значительному увеличению месячной оплаты. Управление изменениямиВ публичных облаках вендор берёт на себя все обязательства по поддержанию работоспособности сервиса. К сожалению, иногда провайдеры на безальтернативной основе и без каких-бы то ни было извещений вносят исправления в работу сервиса. Причем изменения могут как относиться к собственному ПО провайдера, так и применяться к виртуальным машинам клиентов. При переносе приложений в облако стоит убедиться, что ваше приложение не использует специфических функций, которые не будут работать в другой версии той же среды. Подобной требовательностью к среде отличаются, например, некоторые Java-разработчики, продукция которых привязана к строго определенным версиями приложения. Убедитесь, что поставщик облачных услуг будет вас по крайней мере заранее уведомлять о подобных изменениях. Еще лучше, если вы получите возможность отказаться от нежелательного обновления. ПрозрачностьВ облачной среде у вас нет физического доступа к серверам, на которых работают ваши приложения. Тем более для вас важно знать и понимать, что происходит с вашей облачной средой. Теоретически облачные провайдеры представляют довольно много разнообразной информации о вашем сервисе. На практике полезно иметь возможность отслеживать такие параметры, как активность различных пользователей в вашей облачной среде, производитель, доступность сервиса (прежде всего из вашего офиса), выполнение SLA и т. п. О чем стоит поговорить с провайдером облачных услуг, планируя перенос приложений в облако?
|