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

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 — это еще и функции по хранению, сбору и распределению информации, а также обеспечение следующих возможностей: одновременная поддержка большого числа пользователей; параллельное выполнение множества программ; представление ресурсов в таком виде, чтобы у пользователя создавалось впечатление, будто он работает на собственном компьютере; оплата услуг по мере их потребления; отсутствие ограничений по потребляемым ресурсам. Кроме наиболее общих форм представления коммунальных ИТ-услуг, могут быть частные системы общего назначения, публичные системы специального назначения и целая иерархия систем от частных до общенациональных. Сегодня эти тезисы звучат банально, но какой силой предвидения нужно было обладать, чтобы прийти к этим выводам более сорока лет назад?

Время для utility computing

Бристольскую лабораторию HP можно отнести к числу тех немногих мест, где концепцию 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 — это то, что формой распространения ресурсов являются сервисы.

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

 

Обещания и реальность

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

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

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

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

Виталий Савченко (6110035@veeam.com), руководитель группы системных инженеров Veeam Software, Россия и СНГ (Москва).

 

Облака

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

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

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

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

 

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

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

 

Практика против сложности

Непременными условиями предоставления сервисов из облаков является оплата по факту использования, самообслуживаемость и масштабируемость — такие сервисы, как VMware SlideRocket (SaaS), Socialcast (SaaS), ITBM (SaaS) или CloudFoundry (PaaS), удовлетворяют этим требованиям. Другие сервисы и решения, предлагаемые компанией, дают возможность нашим партнерам предложить решения, удовлетворяющие перечисленным требованиям. Если говорить про IaaS, то с недавнего времени мы предлагаем комплексное решение vCloud Suite, позволяющее создать инфраструктуру частного, публичного или гибридного облака.

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

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

Если говорить об управлении ИТ-активами гибридных облаков, то каких-то новых задач управления здесь нет, однако следует учесть, что известные задачи, относящиеся к Services Portfolio Management, в динамичной и гибкой среде гибридного облака решаются иначе. Вместе с тем управление ИТ-сервисами, возникшее в результате необходимости переноса внимания с технологий и внутренней организации провайдера ИТ-услуг на качество предоставляемых сервисов, в случае облаков должно опираться на конкретную практику и анализ лучшего опыта. Такие хорошо знакомые по ITIL понятия, как Service Strategy, Service Design, Service Transition, Service Operation и Continuous Service Improvement, применимы и для облачных инфраструктур. Даже если представить себе некую облачную инфраструктуру, гарантирующую 100-процентную доступность предоставляемых на ее основе сервисов, то все равно останется множество задач, эффективное решение которых без ITSM не представляется возможным, например управление конфигурациями.

Подход VMware к обеспечению управления облачными сервисами заключается в трансформации роли ИТ предприятия и превращению ее в сервис-брокера, осуществляющего оркестрацию сервисов, предоставляемых как внутренней ИТ-организацией, так и внешними провайдерами. При этом возникает ряд вопросов, связанных с тем, насколько детализированным должно быть управление внешними сервисами. Например, укрупнение сторонних сервисов позволяет использовать уже существующие в организации практики supplier management, однако это может усложнить реализацию управлениями, изменениями и релизами.

В целом реализация управления изменениями, доступностью и производительностью может оказаться неожиданно сложной в случае облачных сервисов. Для того чтобы помочь организациям эффективно решать задачи ITSM в случае облачных сред, VMware предлагает как различные программные решения, оптимизированные для облаков и автоматизирующие различные процессы ITSM, так и набор лучших практик по проектированию (vCAT) и эксплуатации (Cloud Ops) облачных сервисов.

Владимир Ткачев (vtkachev@vmware.com), технический директор VMware в России и СНГ (Москва).

 

Сервисы

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

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

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

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

Рис. 2. Шестиуровневая модель облака
Рис. 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, в которой постулируется концепция сервиса как ценности для бизнеса, которую формируют ИТ на базе своих активов: оборудования, программных решений и человеческих компетенций. С ростом востребованности публичных облаков будут созданы стандартные механизмы внешнего регулирования рынка облачных сервисов и появятся метрики качества их предоставления, которые позволят выстроить нормальные финансовые взаимоотношения между провайдерами и потребителями облачных сервисов.

 

Просто о сложном

Здравый смысл подсказывает, что в любой сфере — от социальной до технической — есть предел сложности монолитных систем управления. Яркий пример — крах плановой системы социалистической экономики. Пагубность гигантизма не понимали не только кибернетики-утописты, мечтавшие о создании в СССР Общегосударственной автоматизированной системы учета и обработки информации (ОГАС), но и более «трезвые» разработчики систем управления для ракетных крейсеров типа «Тикондерога». Это был огромный и дорогостоящий проект — с 1981 по 1992 год для ВМФ США было построено 27 таких суперкораблей, отличавшихся от предшественников высочайшим для того времени уровнем компьютеризации всех возможных функций. В крейсерах вообще не была предусмотрена возможность ручного управления, но проект явно опередил время. Начало восьмидесятых — расцвет мини-ЭВМ и появление микропроцессоров, а крейсер «Тикондерога» был спроектирован как монолит, без возможности обновления программного и аппаратного обеспечения. Постепенно оказалось, что за плановый период эксплуатации таких кораблей, составляющий не менее 30 лет, вооружение успевает безнадежно устареть морально и уже в середине этого срока его нужно менять. При вполне пригодных к эксплуатации корпусах, машинах и механизмах дешевле построить новые корабли, чем пытаться доводить крейсеры этого типа до уровня, соответствующего времени. В итоге, прослужив половину положенного срока, один корабль уплыл в музей, другой стал учебным пособием, три пока в строю, а остальные пустили на плавучие мишени либо подготовили для продажи дружественным странам.

Избежать судьбы проектов «Тикондерога» и ОГАС вполне позволила бы ориентация на сервисные принципы слабой связности (loosely coupling). Данный термин предложил специалист по организационной психологии, профессор Карл Вейк; по его мнению, любая организация, в частном случае информационная система, подчиняется тем же эволюционным законам, что и биологическая система, которая изменяется под влиянием воздействий из внешней среды. Одним из условий успешной эволюции является слабая связанность между компонентами, когда отдельному компоненту нужно обладать ограниченными знаниями об остальных или вообще не знать о них ничего.

 

***

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF