Игроки: Облако должно быть безопасным

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

В компании DHL, помимо прочего, я отвечаю как за разработку перспективных IT-сервисов, повышающих привлекательность наших услуг, так и за поиск новых технологических решений, позволяющих повысить эффективность внутри самой компании.

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

Провайдеры обещали, что мы сможем без взаимодействия с ними изменять параметры нашей [IT] архитектуры, масштабировать наши приложения (причем как горизонтально, так и вертикально), используя при этом только автоматические системы управления либо программные интерфейсы – чтобы платить им только за электричество, когда сервисом никто не пользуется. Утверждалось, что облако в принципе не может «упасть», а учет потребления ресурсов можно вести в абсолютно разных абстракциях, начиная от пропускной способности и заканчивая объемом баз данных, количеством транзакций, количеством пользователей и т.д. И это в конечном итоге даст нам значительную экономию наших затрат.

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

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

Понятно, что, когда мы подключаем новых клиентов, у нас всегда встает вопрос: а какой у них объем продаж, какие прогнозы, сколько нам надо мощностей, сколько пользователей будет?

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

Еще один кейс. У нас есть довольно много небольших локальных приложений. То есть мы не знаем, в какой момент времени произойдет пиковая нагрузка. Поэтому есть несколько серверов, например, баз данных, на которых расположено очень много компонентов различных приложений. Провайдеры облачных вычислений обещали предоставить программные интерфейсы или даже систему по автоматическому масштабированию, которые позволят обеспечить нормальное функционирование этих систем. Однако когда мы стали глубже копать эту тему, оказалось, что у нас используется очень много приложений. А фреймворк работает таким образом, что кэширует объекты в памяти для ускорения работы самого приложения, сжирает практически всю доступную ему мощность сервера и освобождает, если на него претендует другое приложение. Поэтому не очень понятно, каким образом будут работать облака в этом случае. Единственный способ это выяснить – методом проб и ошибок на каких-то конкретных реализованных проектах. Но в России мы пока этого не видели.

Есть у нас и еще один сервис, хорошо ложащийся под концепцию облака. Он называется meilroom и по сути представляет из себя управление внутренней логистикой на территории клиента. Это набор компонентов, которые мы можем настроить в зависимости от конкретного клиента – в этом особенность системы. Сложность в том, что на это уходит очень много времени. От момента продажи услуги до момента внедрения проходит обычно несколько месяцев. А концепция облака позволяет сделать некий snapshot (снимок файловой системы) конфигурации и предоставлять всю систему, условно говоря, одним нажатием кнопки. Выяснилось, что здесь не так много технических проблем – гораздо больше сложностей лежит в области лицензирования. Ведь вендор, предоставляющий нам этот софт, дает нам и ключ, используя который, мы могли бы предлагать эти конфигурации в совершенно неограниченном количестве, и вендор об этом практически ничего бы не знал, а мы, таким образом, фактически нарушили бы политику лицензирования. Разумеется, путем переговоров нам удалось добиться соглашения, однако понятно, что это достаточно серьезный барьер на пути массового распространения облачных технологий.

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

Кратко обозначу основные причины, по которым, на наш взгляд, трудно говорить об облачных технологиях, как о чем-то очень распространенном. Это отсутствие полноценного эластичного масштабирования. Но без этого свойства облачных средств получается, что мы устанавливаем кондиционер в комнату, а этот кондиционер не умет определять температуру. То есть экспертизы практически ни у кого нет, проектов реализовано очень мало, а наработать собственный опыт можно только путем проб и ошибок, что является достаточно серьезным препятствием.

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

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

На наш взгляд, сегодня нет ни одной компании, предоставляющей достоверные данные, чтобы можно было сделать вывод о безопасности в облачных средах. Именно по этой причине наша компания самостоятельно формулирует требования к провайдерам, с тем чтобы страны (например, Россия) могли свободно применять эту технологию для своих нужд. И я скажу откровенно, на данный момент этот пункт для нас – самое главное препятствие. Все наши попытки, переговоры и проекты сейчас противоречат нашим региональным указаниям, и мы не можем массово использовать облачные технологии, пока не будет решен этот вопрос.

Отсутствие универсальных средств разработки облачных приложений – это, мне кажется, самый интересный вопрос. Потому что говорить о том, что в целом меняет принципы разработки программного обеспечения, сейчас довольно тяжело. У многих компаний целый багаж софта, который разрабатывался 5–10 лет назад, и никто тогда об облачной технологии вообще не знал. Поэтому совершенно непонятно, как встраивать все это добро в облако, реализовав при этом свойство эластичности. Решения на данный момент нет.

И напоследок скажу о формировании компетенции в этой области. В принципе слово «компетенция» можно заменить на слово «рынок». Я бы хотел подчеркнуть, что рынок – это в конечном итоге совокупность покупателей, а не продавцов, как нам иногда пытаются преподнести. Есть часть экспертов, которые критикуют облачную концепцию, приводя в качестве аргументов несостоятельность технических решений. Другая часть экспертов говорит о том, какие у нас классные проекты реализованы, сколько мы денег сэкономили. На наш взгляд, наиболее правильное отношение к этой теме – нейтральное. Что я имею в виду? Очевидно, что в будущем уровень зрелости этой технологии достигнет такого уровня, что она станет повсеместной. Соответственно, задача вендоров, наверное, уже не решение каких-то технических проблем. Их задача, скорее, выстраивание экономических моделей, сервис-ориентированных структур, которые были бы выгодны не только большим компаниям, желающим переместить в облака свой ЦОД, состоящий из 1000 серверов, но были бы также выгодны малому и среднему бизнесу, да и физическим лицам.