Облака, сервисы и utility computing

Сложность — одна из важных характеристик современных информационных систем, отличающая их от других творений человека. По уровню сложности компьютерные системы приближаются к природным экосистемам, которые возникли в результате сочетания глобальных геологических и биологических процессов, но предстают перед наблюдателем настолько тонко организованными и сбалансированными, что невольно возникает ощущение «руки творца». Аналогичное впечатление вызывают современные компьютерные системы, сочетающие в себе облачные и сервисные начала, возникшие в результате эволюции коммунальной (мультиарендной, мультитенантной) организации ИТ, облаков и связующего их слоя в виде сервисов различных видов. И первое, и второе, и третье возникло и развивалось изначально независимо — у каждого из этих технологических направлений есть своя история, однако случилось так, что в какой-то момент времени они «нашли» друг друга и возникло единое целое, которое хочется назвать «трехликим Янусом». Связка между тремя началами настолько прочна, что практически невозможно ее разорвать и «разложить все по полочкам», последовательно показав, что из чего следует. Поэтому пока удается лишь нарисовать достаточно мозаичную картину, состоящую из отрывочных наблюдений, из которых, надеюсь, можно будет сложить целостную картину.

Utility computing

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

Первым свое видение utility computing изложил в 1955 году Херб Грош, более известный как создатель одноименного закона, постулирующего рост производительности компьютера как функцию квадрата стоимости. Грош считал, что вполне естественно для того времени и для сотрудника IBM, что проблему создания utility computing решает всеобщее подключение к мэйнфреймам через простые терминалы. Такой подход имеет право на существование — например, во Франции была успешно реализована построенная на подобных принципах национальная информационная система Minitel, созданная France Telecom и предоставляющая абонентам разную информацию — от прогноза погоды и расписания поездов до котировок акций. Дальнейшее развитие идея мультиарендности получила в трудах создателя термина «искусственный интеллект», соавтора языков Lisp и Algol Джона Маккарти. Однако какими бы мощными ни были мэйнфреймы, они не могли стать основой для utility computing по следующим причинам:

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

Все эти перечисленные черты utility computing предвосхитил канадский ученый Дуглас Паркхил в своей книге «The challenge of the computer utility», опубликованной еще в 1966 году. Удивительная книга, удивительный автор и удивительные предвидения, настолько актуальные сегодня, что складывается впечатление, будто книга написана вчера. Паркхил раньше других осознал, что, помимо собственно вычислительной мощности, utility computing — это еще и функции по хранению, сбору и распределению информации, а также обеспечение следующих возможностей: одновременная поддержка большого числа пользователей; параллельное выполнение множества программ; представление ресурсов в таком виде, чтобы у пользователя создавалось впечатление, будто он работает на собственном компьютере; оплата услуг по мере их потребления; отсутствие ограничений по потребляемым ресурсам. Кроме наиболее общих форм представления коммунальных ИТ-услуг, могут быть частные системы общего назначения, публичные системы специального назначения и целая иерархия систем от частных до общенациональных. Сегодня эти тезисы звучат банально, но какой силой предвидения нужно было обладать, чтобы прийти к этим выводам более сорока лет назад?

В 90-е годы центр разработки utility computing сместился в Бристольскую лабораторию HP, где появилась идея UDC (Utility Data Center), реализовать которую решили на Unix-машинах, творчески переработав наследие мэйнфреймов, чтобы понять, как можно изолировать приложения, работающие в одной среде. Еще в 2004 году Джон Мэнли, руководивший направлением UDC, отмечал, что информационные системы представляют собой плохо упорядоченный набор разнообразных ресурсов, и взамен их, в идеале, должна быть создана инфраструктура потребления ИТ-сервисов, обеспечивающая доступ к виртуализованному пулу ресурсов. Для этого в HP на первом этапе были созданы виртуализуемые системы на базе серверов Superdome, затем развернуты ЦОД, а потом планировалось предложить некие глобальные виртуальные структуры. Уже тогда в компании понимали, что utility computing чаще всего сравнивали с системами снабжения, относящимися к категории непрерывных услуг, однако на самом деле услуги, с которыми мы имеем дело в обыденной жизни, по большей части имеют разовый характер. Действительно, чаще потребитель обращается куда-то, где по его требованию выполняется определенный набор действий, и он получает конкретный, часто уникальный результат. Мэнли назвал такие услуги словом batch (объем продукции, выдаваемый в один раз), что, кстати, тоже напоминает мэйнфреймы с их работой в пакетном режиме.

Свою нынешнюю популярность идея коммунальности обрела прежде всего благодаря усилиям популяризатора Николаса Карра с его книгой «The Big Switch», в которой он утверждает, что вместе с облаками ИТ превращаются в «технологию общего назначения» (General-Purpose Technology, GPT). Действительно, появление очередной GPT приводит к инновационному росту, так было, например, с паром и электричеством, и если по степени освоенности сравнивать utility computing с электричеством, то, скорее всего, мы находимся где-то на уровне начала прошлого века и пока еще не можем оценить те последствия, к которым приведет массовое распространение облачных технологий.

Однако есть ряд черт, качественно отличающих ИТ от других GPT, — прежде всего то, что Мэнли назвал batch, и то, чем batch-ресурсы отличаются от непрерывных. Кроме того, темпы инноваций сегодня намного выше, чем тридцать лет назад, когда компьютер с производительностью современного планшета стоил миллион долларов; ничего похожего в других областях до сих пор не наблюдалось. Однако в ИТ гораздо сложнее решаются проблемы масштабирования, где действуют ограничения, устанавливаемые, например, известным законом Амдала, не позволяющим линейно наращивать компьютерные мощности, как в электричестве. Либо ограничения, следующие из теоремы CAP и требующие иных, чем реляционные, подходов при работе с большими объемами данных.

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

Итак, облака с их разнообразными технологиями виртуализации преобразуют ИТ в форму, доступную для распределения ресурсов между пользователями, а сервисы служат основным инструментом для распределения. К сожалению, термин «сервис» и в английском, и в русском заметно перегружен, он используется и как «услуга», и как «служба», и как «эксплуатация», и еще во многих смыслах в зависимости от контекста.

Облака

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

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

Сегодня все это уже звучит почти банально, однако видные эксперты, собравшиеся на конференции Cloud Interop для обсуждения предмета cloud computing, пришли к неутешительному выводу: «Мы не вполне понимаем, о чем приходится говорить». Облака приобретают разные формы, они построены из разных компонентов, и, чтобы понять происходящее, требуются систематизация и классификация, или, как сегодня говорят, таксономия.

Попытка облачной таксономии показана на рис. 1 где выделены пять признаков: физическая модель (Deployment Model), используемые стандарты (Standard), технологии (Technology), философия (Philosphy) и модель предоставления сервисов (Model). С учетом слабости такой классификации, она все-таки дает общее представление, хотя и не учитывает, что само облако является сложной системой, а предоставляемые им сервисы служат для создания сложных систем.

Рис. 1. Таксономия облаков

Сервисы

Существование сервисов поддерживается системой стандартов и, что не менее важно, системой контактов — кроме формальных правил, по которым происходит взаимодействие, требуется еще и знание того, с кем и каким образом следует производить взаимодействие, своего рода адресная книга. Хорошо известные стандарты SOAP, WSDL, Atom и REST необходимы, но недостаточны — бизнес-сервисы, помимо стандартов, предполагают знание контактов, но обычно это обстоятельство упускают. Под контактами понимают следующие свойства сервисов: когда сервис доступен, какова его производительность, как часто и какое количество раз можно его использовать, кто несет ответственность за возможные сбои, как сервисы изменяются, кто отвечает за модернизацию и т. п. Использование контактов является важной частью управления — собственно говоря, с использованием контактов и строится слабосвязанная системная архитектура. Стандарты служат средством, обеспечивающим согласованность компонентов, а из контактов складывается желаемая связанность. Сочетание стандартов и контактов позволяет автоматически вызывать для исполнения тот функционал, который нужен в данном местe и в данное время.

Есть еще один источник для ошибочной трактовки сервисов SOA — именование их веб-сервисами, хотя прямой связи с WWW может и не быть, а связывает их, пожалуй, лишь то, что стандартизацией занимается консорциум W3C. И напротив, облачные сервисы, или, как их еще называют, облачные архитектурные образы (Cloud Architecture Pattern, CAP), непосредственно связаны с Интернетом, они передаются по сети.

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

Другое отличие в ориентации — в том, что первично. По замыслу, SOA подчинена приложениям, то есть при делении системы на составляющие главным обстоятельством, влияющим на то, «как разрезать», является функция, которую назначают тому или иному компоненту. Иначе говоря, при проектировании сначала выделяют задачи, а потом делят систему на части таким образом, чтобы компоненты можно было в дальнейшем повторно использовать. В случае же CAP функциональность не рассматривается, сервисы делятся по той роли, которую они играют в общем стеке, — проектирование облака не связывается с решаемыми на нем задачами.

Рис. 2. Шестиуровневая модель облака

Говоря о любых облачных сервисах (*aaS), следует иметь в виду, что облака есть способ потребления технологий в привязке к бизнес-процессам, но не собственно технологии. Облака позволяют избавиться от забот об инфраструктуре и сосредоточиться на количестве и качестве потребляемых ресурсов. С пользовательской точки зрения *aaS описывает услуги, оказываемые тем или иным многократно используемым (reusable), тонко гранулированным (fine-grained) программным или аппаратным компонентом, размещенным в облаке. Из всего множества различных *aaS чаще всего встречаются SaaS, IaaS и PaaS, однако в облаках могут предоставляться в сервисной форме системы хранения (Storage as a Service, SaaS), безопасности (Security as a Service, SECaaS), СУБД (Database as a service, DaaS), средства мониторинга и управления (Monitoring/Management as a Service, MaaS), коммуникации, контент и вычисления (Communications, Content & Computing as a Service, CaaS), контроль идентификации (Identity as a Service, IDaaS), резервное копирование (Backup as a Service, BaaS) и десктопы (Desktop as a Service, DaaS). Каждый из перечисленных сервисов можно соотнести с шестиуровневой моделью облака (рис. 2).

На уровне IaaS и SaaS клиент получает в пользование нужный ему объем оборудования, поддерживаемого и обслуживаемого провайдером; PaaS обычно предоставляет в пользование ресурсы серверов приложений; SaaS позволяет использовать уже готовые приложения типа CRM, ERP и т. п. Мониторинг с применением MaaS пока еще новинка, но, по оценкам экспертов, весьма перспективная, поскольку позволяет упрощать процессы миграции приложений между частными и глобальными облаками.

Пока нет каких-либо международных структур, координирующих процессы формирования облаков, а предпринимаются лишь отдельные попытки различных некоммерческих организаций урегулировать ситуацию. В конце октября 2010 года был объявлен альянс Open Data Center Alliance из 50 крупнейших компаний, призванный найти приемлемую для всех модель облаков. Компания Rackspace совместно с NASA выступила с инициативой открытия кодов OpenStack, ведь в идеале стандарты должны распространяться на все уровни стека облачных сервисов, причем чем выше уровень, тем сложнее задача стандартизации. Структуру этого стека, ставшего стандартом де-факто, приняли сейчас все производители, но это вовсе не значит, что между продуктами разных поставщиков есть хоть какая-то совместимость. Нижние уровни (DaaS и IaaS) можно унифицировать уже сейчас, а вот как быть с верхними, пока сказать сложно.

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

Что же касается SaaS, то здесь дела обстоят плохо — стандартизация приводит тут к ограничению творческой составляющей и, следовательно, качества решения, но в то же время отсутствие совместимости может обернуться большими убытками. Известно пока немного попыток разработки стандартов для SaaS: создание в 2010 году организации CloudAudit, или A6 (Automated Audit Assertion Assessment and Assurance API), и vCloud — как попытка насильственной установки стандарта де-факто на базе наиболее распространенных решений.

Альтернативный подход предпринят организацией OGF (Open Grid Forum), отражающей желание некоторых производителей и академической среды, сформировавшейся вокруг грид, выработать единый взгляд на облака. Результатом деятельности такой организации стало создание рабочей группы и инициативы OCCI (Open Cloud Computing Interface), направленной на согласование всех API, в том числе и Amazon AWS, GoGrid и Flexiscale. Здесь же надо упомянуть работу по стандартизации доступа к данным — создание интерфейса SNIA Cloud Data Management Interface (CDMI), который стал первым промышленным открытым стандартом на управление хранением данных в облаке. В разработке документа приняли участие более 180 экспертов, входящих в SNIA Cloud Storage Technical Work Group (TWG). Стандарт CDMI распространяется на публичные, частные и гибридные облачные решения, и ожидается, что он будет использован сервис-провайдерами и производителями инфраструктурных облачных решений. Основанный на протоколе REST, CDMI призван обеспечить единый формат хранимых метаданных в публичных, частных и гибридных облачных средах, охватывая все аспекты хранения данных в облаке, начиная от обмена и миграции данных до управления уровнем сервиса и шифрованием. Использование этого стандарта в облачных решениях позволит заказчикам, за счет единого формата хранения метаданных, безболезненно перемещать основные данные между различными облачными средами и разными поставщиками сервисов. Стандарты OCCI и CDMI взаимодополняют друг друга, построены по общим принципам и ориентированы на близкие технологии, но пока их можно рассматривать лишь как стартовые точки для будущего более широкого процесса стандартизации. В идеале стандарты должны распространяться на все уровни стека облачных сервисов (рис. 2), причем чем выше уровень, тем сложнее задача стандартизации.

Очевидно, что инфраструктура поддержки облачных сервисов должна быть совершенно иной, чем классическая монолитная, и, скорее всего, под влиянием облаков более востребованы будут методы управления ИТ-сервисами. Некоторые эксперты считают, что поскольку приложения, инфраструктуры и целые бизнес-процессы предоставляются в виде сервисов, то сегодня нет другого инструмента для управления ими, кроме ITSM. Потребностям облаков отвечает версия библиотеки ITIL v3, в которой постулируется концепция сервиса как ценности для бизнеса, которую формируют ИТ на базе своих активов: оборудования, программных решений и человеческих компетенций. С ростом востребованности публичных облаков будут созданы стандартные механизмы внешнего регулирования рынка облачных сервисов и появятся метрики качества их предоставления, которые позволят выстроить нормальные финансовые взаимоотношения между провайдерами и потребителями облачных сервисов.

***

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