Песочная эволюция: взгляд из-за угла ИТ-здания

Кажется, сейчас проще сказать, что не отдается на аутсорсинг. Порой стали отдавать такое, о чем раньше и не думалось, — вплоть до шины обмена данными и информационной системы. А что? Если это стоит дешевле, чем покупка лицензий или самостоятельная разработка, то почему бы и нет? Ну а потом придумали для этого название — «облако»...

ИТ вообще превращается в некую виртуальную область. За короткое время облака и облачные вычисления превратились из прорыва в модный тренд. Хотя, если разобраться, облачные услуги (только под другим названием) существовали на рынке достаточно давно. Попробуем отследить, как с течением времени менялось смысловое наполнение понятия  облако (именно понятия, термин появился и сформировался значительно позже).

Самое первое облако появилось достаточно давно. Не знаю, все ли видели (нам, студентам начала 90-х годов прошлого века, уже демонстрировали как рудимент) классические советские ЭВМ — терминалы и мейнфрейм. Собственно, все вычисления проводились «в облаке» — на стороне мейнфрейма, терминал (как и положено терминалу) решал задачу ввода-вывода информации. Тем не менее до полноценного облака (в современном понимании) такой конструкции не хватало одного — географической независимости: и терминалы, и мейнфрейм были сконцентрированы в одной географической точке.

А потом пришел Интернет. То есть появилась универсальная, унифицированная среда передачи информации, которая нивелировала понятие «географическое положение», так как сервер мог находиться где угодно и возможность его использования никак не зависела от положения терминала. Собственно, именно с этого момента и началось «облачное шествие», постепенно переходящее в «облачное безумие». Но обо всем по порядку.

В ногу с пользователем

Первые, самые заметные примеры облака, шагнувшего в массы, — иначе говоря облачного сервиса — это, наверное, бесплатные почтовые системы с веб-интерфейсом. Почту можно было «забирать» — то есть загружать в почтовую программу на локальном компьютере, или «не забирать» — то есть работать с ней посредством веб-браузера (кто помнит самый первый интерфейс mail.ru? Я вот помню). Объем ящика был небольшой, но при экономии и регулярных чистках его вполне хватало «на поработать». Дальше (или раньше, тут я не отследил) тенденция перешла и в корпоративный сектор: у Microsoft Exchange появлился веб-клиент. Видимо, при его проектировании стояла задача «чтобы было не хуже» — в смысле, чтобы было не хуже, чем в настольном клиенте. В итоге получилось «очень даже», по крайней мере работать в командировках с этим было можно, и даже вполне комфортно (сейчас, по субъективным ощущениям, веб-интерфейс MS Exchange повторяет примерно 80% функциональности настольного клиента — правда, только в браузере Internet Explorer). Следующий этап развития почты — «Гуглопочта», она же GMail. Про Google и его продукты, вероятно, стоит сказать отдельно, тут же просто отметим, что интерфейс и подход GMail оказался не только революционным, но и весьма удобным. Причем настолько, что большинство пользователей и думать забыли про «забор» почты на локальную машину, предпочитая держать ее там, в облаке, и оставаться независимым от конкретного компьютера. (Собственно, интерфейс GMail и проектировался так, чтобы пользователь работал в первую очередь с веб-приложением; функции же передачи почты в клиентские приложения были вторичны).

Следующий пример — порталы. Самый известный, наверное, SharePoint; для полноты картины можно также упомянуть IBM WebSphere, из бесплатных — Alfresco и множество других, менее раскрученных, но позволяющих организовать работу через сеть. Обычную работу среднестатистического офисного сотрудника: создание, редактирование, категоризация, согласование документов; организация заявок и их движение, «Документооборот light», оповещения, обмен сообщениями...

==================================
Из опыта

У меня есть довольно любопытный опыт работы в проекте, который выполнялся силами распределенной команды. Что такое проект? Это план работ, ресурсы для их реализации и учет фактов исполнения (это на верхнем уровне; ну а спускаясь вниз, добавляем критерии качества, особенности конкретных специалистов и т. д.). Так вот, проект, который я курировал, осуществлялся в Москве. Притом что физически я находился в Санкт-Петербурге. Процесс коммуникаций шел преимущественно через Интернет: скайп в качестве основного средства обсуждений и Share Point как место хранения документов. Фактически выезжать приходилось только на совещания — остальные мероприятия проводились удаленно. Планы, факты, отчеты — все выкладывалось на портал, а кое-что там и формировалось.
Получилось, что мы (проектная команда) использовали портал как частное облако, то есть публичный сервис, предназначенный для ограниченного количества лиц в рамках одной организации.
========================
Следующими на свет появились различного рода веб-накопители — сервисы, позволяющие удобно хранить и организовывать личные файлы. Следом — то же, но для корпоративного применения. Кстати, в России такого рода сервисы не прижились, а на Западе очень быстро канули в Лету.
То есть пока никаких революций: рынок достаточно степенно шел за потребностями пользователя. А он (пользователь) живет, как и жил: лень — двигатель прогресса. Разве что чуть избаловался, в смысле того, что «предложите мне что-нибудь этакое, чтобы было еще чуть поудобнее».

Про революции

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

Дальше — больше. С легкой руки того же Google в Интернете появилось множество вспомогательных сервисов: например, сервисы для хранения закладок (интегрированные со всеми популярными браузерами), записок, записной книжки телефона (предусмотренной в контактах GMail), фотографий, новостных подборок...
При этом важно, что каждый из участников схемы «облако — пользователь» концентрируется на решении своей задачи: провайдер облачных услуг обеспечивает поддержку и функционирование облака с заданными параметрами, пользователь решает свои, частные задачи.
==============================
Про риски

Риски облачных сервисов известны давным-давно, они были обозначены в момент появления первых облаков. В частности, основной риск — это вероятность потери конфиденциальных данных. Фактически любое облако приложений хранит данные у себя, а не на серверах пользователя, что автоматически вызывает подобный риск. Вторым риском является риск обеспечения работоспособности системы: для пользователя облачный сервис — «черный ящик», на который он, как правило, не оказывает никакого влияния (с точки зрения администрирования и поддержания работоспособности системы).
Для частного пользователя эти риски в большинстве случаев пренебрежимо малы: ну и что с того, что кто-то увидит мою адресную книгу или почту, где в основном письма частного характера и рассылки? Да если кто-то и прочитает мои статьи, которые я готовлю для IT Manager в Google Docs, тоже беды большой не будет...
Для корпоративного пользователя те же риски оказываются существенно выше: перлюстрация почты или даже списка контактов менеджера может дать конкурентам обширную информацию, воспользовавшись которой, злоумышленники способны нанести существенный урон. Чтобы разрешить этот конфликт, провайдеры подобных услуг предлагают заключать довольно жесткие соглашения о конфиденциальности. В конкретных же случаях проблема решается концепцией (и, естественно, ее реализацией) частных облаков, когда конечному пользователю предлагается определенный сервис — то же «приложение-как-сервис», с той только разницей, что его провайдером выступает та же организация. Точнее ИТ отдел, который в данном случае выступает как сервисного подразделение... но об этом чуть позже.
=================================

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

В связи с этим на ниве всеобщей стандартизации и унификации появились в прайсах сервис-провайдеров забавные строчки типа «стойкоместо — аренда в месяц». (Звучит почти как «койкоместо», с моей точки зрения правильнее писать: «Аренда места в стойке» или «Аренда стойки».) Ценник, кстати, «в среднем по больнице» довольно гуманный, особенно если брать начальный вариант, с невысокими требованиями по безотказности.

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

«Взрослое облако» и управление рисками

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

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

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

Сервис как стиль жизни

В итоге, при переходе к облачной модели работы с приложениями, вольно или невольно ИТ-подразделение превращается в сервисное подразделение, поскольку акцент от «компьютеров и принтеров» начинает смещаться в область параметров сервиса. Важным становится не то, что приложение действует, а то, как именно оно это делает. Недостаточно, чтобы принтер «просто печатал» — он должен выводить на печать заданное количество документов в минуту и иметь определенные гарантии по безотказной работе. То же и с приложениями: мало, чтобы приложение просто функционировало. Важно то, как быстро оно реагирует на запросы, насколько соответствует не только требованиям, но и ожиданиям пользователя. В этом смысле, особенно при использовании арендованных приложений, ИТ становится сервисным подразделением. А значит, на этапе внедрения оно согласует с заказчиками параметры будущего сервиса, заключает соглашение на аренду сервиса с параметрами, которые не хуже, чем запрошенные клиентами, поддерживает сервис, обеспечивая канал до провайдера сервиса, мониторя метрики сервиса и реагируя на тенденции. Причем ИТ-подразделение тем больше будет сервисным, чем больше сервисов оно будет предоставлять. И не обязательно внешних. Как показывает опыт, бывает достаточно сделать один шаг в сторону сервисной модели, чтобы не расставаться с ней уже никогда. Да, да — тут и перестройка в стиле ITIL, и внедрение ITSM, и длительные споры неофитов, и глобальное просветление, обязательно снисходящее на всех адептов сервисной модели...

Ирония тут вполне уместна. Часто, к сожалению, сервисная модель ИТ становится самоцелью, не имеющей под собой самого главного — ответа на вопрос «зачем»? Но это, как говорится, немного другая история, и совсем не про облака.