Кредит доверия к облачным системам подходит к концу?

Исследования и прогнозы в IT
Кредит доверия облачных ресурсов подходит к концу?Это становится тенденцией, причем нехорошей. Каждый раз когда происходит сбой очередного облачного сервиса все сторонники облачных решений — провайдеры, аналитики, поставщики, разработчики и просто евангелисты в один голос заявляют — “Shit happens, разрабатывайте и внедряйте отказоустойчивые системы”, при этом не принимая или неадекватно принимая любую критику, которой подвергается эта небесспорная, прямо скажем, точка зрения. И технические аналитики нередко уподобляются им — по незнанию, по убеждениям или из корыстных мотивов — вопрос другой. Это неправильно и это должно измениться.

Каюсь, я виноват в том же. Я был евангелистом облачных систем и их внедрения и распространения продолжительное время и старался закрывать глаза на некоторые очевидные факты. Но по мере того как облачные решения действительно получают путевку в жизнь от все большего количества заказчиков, становится ясно, что игнорировать этого “слона в посудной лавке” больше никак нельзя.

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

Подозреваемый №1


Главным подозреваемым по нашему делу проходит AWS, что и неудивительно, учитывая сколько различных сервисов работает на его серверах. Отключение даже одного датацентра приводит к отключению и/или перебоям в работе множества сервисов. Так, накануне рождества сбой в выравнивании нагрузки привел к тому, что Netflix на 23 часа стал недоступен. Это было бы абсолютно неприемлемо будь сбой виной внутренних серверов компании, а в случае с Amazon оказывается совершенно житейским делом. Более того, каждый раз когда это происходит клиенты даже не получают сколько-нибудь внятного объяснения, что именно произошло и какие меры приняты для того чтобы не дать ситуации повториться, не говоря уже о компенсации убытков. Более того, некоторые журналисты добывали копии писем Amazon своим клиентам, которые рассылаются после сбоев — похоже что их рассылает автомат, потому что в разных случаях пострадавшие получали совершенно шаблонный ответ с однотипными извинениями. Комментарии аналитиков тоже не отличаются разнообразием — Дэвид Линтикум в интервью GigaOm опять заводит старую песню про слишком низкую отказоустойчивость приложений. То есть волноваться нечего, все идет своим чередом. Это нормальная фаза в развитии любой технологии.

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

Я не говорю, что облачные решения гарантированно имеют худшие показатели надежности чем аппаратные комплексы, работающие на предприятиях. Существует немало случаев, когда на предприятии ИТ-служба поставлена ненадлежащим образом и переход на облачную структуру пойдет только на пользу. Большинство таких предприятий — малого и среднего размера, и активное внедрение таких решений для них действительно оправдано во всех смыслах. Но когда дело доходит до уровня надежности, который требует крупный бизнес, начинаются проблемы. По определению облачные решения еще не имеют достаточной наработки и опыта применения для того чтобы говорить о них как о реальной альтернативе внутренним ИТ-службам корпораций, которые занимались своим делом по 20-30 лет и зачастую имеют уникальный опыт в решении специфических для конкретного предприятия задач.

Сказка о SLA


Типовое соглашение об уровне предоставляемых услуг, заключаемое с Amazon определяет время безотказной работы (SLA) как 99.95%. Это заявление, однако, весьма сомнительно по нескольким причинам.

Во-первых, значение 99.95% относится к SLA целых регионов (Северная Америка, Европа etc), показатели же конкретных датацентров нигде не указываются, что превращает сравнение приведенных цифр с показателями корпоративных датацентров в сравнение яблок с бананами. Использование показателей SLA лучшего датацентра целого региона и экстраполяция на весь регион – абсурд. Если бы показатели корпоративных датацентров рассчитывались аналогичным образом, то в их цифрах SLA было бы куда больше девяток.

Во-вторых, даже если принять цифру в 99.95% за данность, выясняется что она не соответствует истине. Этот показатель у AWS за 2012 год равен 99,5% (и это мы не углубляемся в вопрос о том, как Amazon учитывает рабочее время...), что приблизительно соответствует показателям среднестатистического корпоративного датацентра в 2007 году (тогда он был равен 99.3%), но исследования 2011 года показали что он возрос до 99,9%, что впрочем тоже далеко от обещанных Amazon показателей.

В третьих, время “запланированного обслуживания” не учитывается Amazon как нерабочее, так же как и неучтенное нерабочее время. Если это время составляет всего несколько секунд или минут то как правило пользователи ничего не замечают, и провайдер не учитывает это время, в отличие от корпоративных датацентров, которые обязаны учитывать каждую секунду времени недоступности, независимо от того заметил это кто-то или нет.

Резюмируя, по показателю SLA AWS в лучшем случае равен, а в худшем — значительно уступает среднестатистическому датацентру, не говоря уже о лучших из лучших. Что усугубляет ситуацию, так это то что подразумевается что пользователи должны сами помнить о возможности сбоев, и делать свои приложения более устойчивыми. То есть вина с провайдера ненавязчиво перекладывается на клиента. Цитируя Линтикума: “Я уверен, что в этом году будут новые случаи отказов — это неизбежно. Это просто фактор, который необходимо учитывать при планировании операций и разработке приложений”.

Вредные советы


Внесение элементов отказоустойчивости в приложения — дело, безусловно, правильное и нужное, и следовать этому принципу я рекомендую вне зависимости от того, какой платформой вы пользуетесь и для кого разрабатываете ПО. Особенно это важно при разработке приложений, изначально нацеленных на работу в облаке (“нативно” облачные приложения). У этого подхода есть только один недостаток — он применим не везде.

Начать с того что внедрение избыточной надежности в наследственные, приложения, переезжающие в облако после долгого использования на наследственном оборудовании (т.н. приложения-мигранты), и хостящиеся на сервисах класса IaaS. С сервисами третьих сторон, как SharePoint или SAP клиент попросту ничего не может сделать со своей стороны чтобы повысить их надежность если этим не займется провайдер. В большинстве PaaS-окружений отказоустойчивость тоже недостижима, так как запасной платформы, на которую можно было бы переехать в случае отказа основной нет. Что же касается модели SaaS, то в ней клиент может использовать ПО только в том виде как оно ему предоставлено и не может ничего сделать сам.

Всё это наталкивает на мысль — почему обеспечение отказоустойчивости системы становится проблемой клиента? Почему бы не потребовать от провайдеров услуг более высокого качества (скажем так, корпоративного класса), хотя бы и по более высоким ценам. В конце концов в случае отказа в вашем датацентре для тех, кто его обслуживает не пытаются перевалить вину на разработчиков, приложения которых “недостаточно отказоустойчивы”. Тот же самый принцип должен применяться и к провайдерам облачных услуг. Впрочем, вполне возможно, многие уже занимаются этим вопросом, но судя по всему у них пока не очень получается.

Стоит отметить, что все что я сказал относится отнюдь не только к Amazon. Тот факт что я так часто поминаю AWS объясняется исключительно тем что занимая больше половины рынка он собирает основную долю прибыли и шишек. Едва ли меньшие по размерам и опыту провайдеры могут обеспечить большую степень надежности. Другое дело что AWS по известным уже причинам получает львиную долю внимания публики в том числе и потому что она стал платформой для новых сервисов и бизнес-приложений, которые интересуются отказоустойчивостью гораздо больше чем среднестатистические пользователи.

Резюме


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

Опять-таки, всё вышесказанное также не значит что тем, кто уже использует услуги внешних поставщиков должны от них отказаться. Ситуация будет улучшаться, но насколько быстро это улучшение произойдет, в значительной степени зависит от самих клиентов. Чем скорее они поднимут вопрос об ответственности провайдеров за качество услуг, которое они предоставляют, тем скорее можно ожидать улучшения. Это не означает что им нельзя доверять. В конце концов, все делают бизнес и всех интересует в первую очередь собственная выгода. А для того чтобы бизнес повернулся к вам лицом, ему необходимо намекнуть, что самые плодотворные — стабильные — партнерства получаются тогда, когда интересы обоих партнеров соблюдаются в равной мере.

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn