Рост вычислительных мощностей и развитие технологий виртуализации платформы x86 с одной стороны, и распространение ИТ-аутсорсинга с другой стороны привели к концепции utility computing (ИТ как коммунальная услуга). Почему бы не платить за ИТ так же, как за воду или электричество – ровно столько и ровно тогда, когда это нужно, и не более.
В этот момент и появилась концепция облачных вычислений – потребление ИТ услуг из «облака», т.е. из некоего внешнего пула ресурсов, не заботясь о том, как и откуда берутся эти ресурсы. Так же, как мы не заботимся об инфраструктуре насосных станций водоканала. К этому моменту была проработана и другая сторона концепции – а именно понятие ИТ-услуг и как ими управлять в рамках ITIL / ITSM.
Был разработан целый ряд определений облаков (облачных вычислений), но при этом не следует относиться к ним как к истине в последней инстанции – это лишь способ формализовать способы предоставления utility computing.
- «Облачные вычисления – это технология распределенной обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как Интернет-сервис» Википедия
- «Облачные вычисления представляют собой модель для обеспечения удобного сетевого доступа к общему пулу настраиваемых вычислительных ресурсов (например, сетей, серверов, систем хранения данных, приложений и услуг) по требованию, которые можно быстро выделить и предоставить с минимальными управленческими усилиями или минимальным вмешательством со стороны поставщика услуг» NIST
- «Облачные вычисления – это парадигма обеспечения сетевого доступа к масштабируемому и гибкому пулу распределяемых физических или виртуальных ресурсов, предоставляемых в режиме самообслуживания и администрируемых по требованию» ISO/IEC 17788:2014. Information technology — Cloud computing — Overview and vocabulary.
Согласно NIST существует три основных типа облаков:
- IaaS – Infrastructure as a Service — Инфраструктура как сервис
- PaaS – Platform as a Service — Платформа как сервис
- SaaS — Software as a Service Программное обеспечение как сервис
Для совсем упрощенного понимания разницы давайте рассмотрим модель Pizza-as-a-Service:
NIST определяет следующие необходимые черты ИТ услуги, позволяющие считаться облачной.
- Универсальный сетевой доступ (broad network access) – услуга должна иметь универсальный сетевой интерфейс, дающий возможность подключения и использования услуги практически кому угодно с минимальными требованиями. Пример – чтобы использовать электрическую сеть 220В достаточно подключиться к любой розетке со стандартным универсальным интерфейсом (вилка), который не меняется от того, чайник это будет, пылесос или ноутбук.
- Измеримость сервиса (measured service) – ключевой характеристикой облачной услуги является измеримость сервиса. Возвращаясь к аналогии с электричеством – вы оплатите ровно столько, сколько потребили с минимальной гранулярностью, вплоть до затрат на один раз вскипятить чайник, если за весь месяц вы были в доме один раз и выпили чашку чая.
- Самостоятельное конфигурирование сервисов по требованию (on demand self service) – облачный провайдер предоставляет заказчику возможность разумного конфигурирования сервиса, без необходимости взаимодействия с сотрудниками провайдера. Для того, чтобы вскипятить чайник совершенно необязательно заранее связываться с Энергосбытом и заранее их предупреждать и получать разрешение. С момента как дом подключен (заключен договор) все потребители могут самостоятельно распоряжаться предоставленной мощностью.
- Мгновенная эластичность (rapid elasticity) – облачный провайдер предоставляет ресурсы с возможностью мгновенного наращивания / снижения мощности (в определенных разумных рамках). Как только чайник включен – провайдер немедленно выдает в сеть 3 кВт мощности, и как только выключен – снижает выдачу до нуля.
- Объединение ресурсов в пул (resource pooling) – внутренние механизмы провайдера услуг позволяют объединять отдельные генерирующие мощности в общий пул (бассейн) ресурсов с дальнейшим предоставлением ресурсов как услуги различным потребителям. Включая чайник, нас менее всего волнует с какой конкретно электростанции поступает мощность. И все остальные потребители потребляют эту мощность вместе с нами.
Важно понимать, что описанные выше характеристики облака взяты не с потолка, а являются логическим выводом из концепции utility computing. И публичная услуга должна обладать этими характеристиками в рамках концепции. При несоответствии той или иной характеристике услуга не становится хуже и не становится «ядовитой», она всего лишь перестает быть облачной. Ну а кто сказал, что все услуги должны?
Почему я об этом отдельно говорю? За прошедшие 10 лет с момента появления определения NIST было много споров об «настоящей облачности» согласно определения. В США до сих пор иногда применяется в судебной сфере формулировка «соответствует букве закона, но не духу» — и в случае с облачными вычислениями главное именно дух, ресурсы в аренду в два клика мышью.
Необходимо отметить, что вышеперечисленные 5 характеристик применимы к публичному облаку, но при переходе к частному большинство из них становятся опциональными.
- Универсальный сетевой доступ (broad network access) – в рамках частного облака организация полностью контролирует как генерирующие мощности, так и клиентов-потребителей. Таким образом, данную характеристику можно считать автоматически выполняемой.
- Измеримость сервиса (measured service) – это ключевая характеристика концепции utility computing, оплата по факту потребления. Но как же оплачивать организации самой себе? В данном случае идет деление генерации и потребления внутри компании, ИТ становится провайдером, а бизнес-подразделения потребителями услуг. И взаиморасчет происходит между подразделениями. Возможно два режима работы: chargeback (при реальных взаиморасчетах и движении финансов) и showback (в виде отчетности в потреблении ресурсов в руб, но без движения финансов).
- Самостоятельное конфигурирование сервисов по требованию (on demand self service) – внутри организации может быть общая ИТ служба, и в этом случае характеристика теряет смысл. Однако при наличии собственных ИТ-специалистов или администраторов приложений в бизнес-подразделениях необходимо организовывать портал самообслуживания. Вывод – характеристика опциональна и зависит от структуры бизнеса.
- Мгновенная эластичность (rapid elasticity) – в рамках организации теряет смысл ввиду фиксированности набора оборудования для организации частного облака. Может ограниченно применяться в рамках внутренних взаиморасчетов. Вывод – для частного облака неприменимо.
- Объединение ресурсов в пул (resource pooling) – на сегодня уже практически не существует организаций, не применяющих серверную виртуализацию. Соответственно можно считать данную характеристику автоматически выполняемой.
Вопрос: Так что же такое все таки это ваше частное облако? Что компании нужно купить и внедрить, чтобы его построить?
Ответ: частное облако – это переход к новой административной модели взаимодействия ИТ-Бизнес, который на 80% состоит из административных мер и только на 20 из технологий.
Оплата только за потребленные ресурсы и легкий вход, без необходимости закопать несколько сотен миллионов нефти в капитальных затратах, обусловили новый технологический ландшафт и появление компаний-миллиардеров. Например современные гиганты Dropbox и Instagram появились как стартапы на AWS с нулевой собственной инфраструктурой.
Необходимо отдельно подчеркнуть, что инструменты управления облачными услугами становятся значительно более опосредованными, а ключевой обязанностью ИТ директора становится подбор поставщиков и контроль качества. Давайте рассмотрим проблематику этих двух новых обязанностей.
Появившись как альтернатива классической тяжелой инфраструктуре с собственными ЦОДами и железом, облака обманчиво легки. В облако легко войти, но вот вопрос выхода обычно обходится стороной. Как и в любой другой отрасли облачные провайдеры стремятся к защите бизнеса и усложнении конкуренции. Единственный серьезный конкурентный момент возникает лишь при первичном выборе поставщика облачных услуг, а далее поставщик приложит максимум усилий, чтобы заказчик от него не ушел. Причем далеко не все усилия будут направлены на качество услуг или их ассортимент. Прежде всего, это поставка уникальных услуг и использование нестандартного системного ПО, затрудняющего переход к другому провайдеру. Соответственно, при выборе поставщика услуг необходимо одновременно формировать план перехода от этого поставщика (по сути полноценный DRP – disaster recovery plan) и продумывать архитектуру хранения данных и резервных копий.
Второй важный аспект новых обязанностей ИТ директора – контроль качества услуг от поставщика. Практически все облачные провайдеры соблюдают SLA по собственным внутренним метрикам, что можем иметь крайне опосредованное значение к бизнес-процессам заказчика. И соответственно внедрение собственной системы мониторинга и контроля становится одним из ключевых проектов при переносе значимых ИТ систем к облачному провайдеру. Продолжая тему SLA необходимо подчеркнуть, что абсолютное большинство облачных провайдеров ограничивают ответственность за неисполнение SLA в месячный абонентский платеж или в долю от платежа. Например, AWS и Azure при превышении порога в доступности в 95% (36 часов в месяц) сделают 100% скидки к абонентской плате, а Яндекс.Облако – 30%.
Ну и конечно же, не надо забывать, что облака бывают не только в исполнении мастодонтов класса Amazon и слонов класса Яндекса. Облака бывают и поменьше — размером с кошку, или даже мышь. Как показал пример CloudMouse, иногда облако просто берет и заканчивается. Вы не получите ни компенсации, ни скидки — вы не получите ничего, кроме тотальной потери данных.
Ввиду указанных выше проблем с реализацией ИТ систем высокого класса бизнес критичности в облачных инфраструктурах в последние годы наблюдается явление «облачной репатриации».
К 2020 году для облачных вычислений пройден пик раздутых ожиданий и концепция находится на пути к канаве разочарований (согласно хайп циклу Гартнер). Согласно исследованиям и до 80% корпоративных заказчиков возвращают и планируют возвращать нагрузки из облаков в собственные ЦОДы по причинам:
- Повысить доступность / производительность;
- Сократить расходы;
- Для соответствия требованиям ИБ.
Что же делать и как все «на самом деле»?
Нет никаких сомнений, что облака пришли всерьез и надолго. И с каждым годом их роль будет возрастать. Однако мы живем не в далеком будущем, а в 2020 году во вполне определенной ситуации. Что же делать с облаками, если вы не стартап, а классический корпоративный заказчик?
- Облака – это прежде всего место для сервисов с непредсказуемой или ярко выраженной сезонной нагрузкой.
- В большинстве случаев сервисы с предсказуемой стабильной нагрузкой дешевле содержать в собственном ЦОД.
- Начинать работу с облаками необходимо с тестовых сред и низкоприоритетных сервисов.
- Рассмотрение размещения информационных систем в облаке начинается с разработки методики выхода из облака в другое облако (или назад в собственный ЦОД).
- Размещение информационной системы в облаке начинается с разработки схемы резервного копирования в контролируемую вами инфраструктуру.
Источник: habr.com