Rambler's Top100
Статьи
Александр БАРСКОВ  14 июня 2018

Куда плывут облака

От простого выноса имеющихся приложений в облака компании переходят к их переработке с учетом облачной специфики. Набирают популярность гибридные решения и услуги, предоставляемые по модели «платформа как сервис», появляются услуги «контейнеры как сервис».

Казалось бы, облака уже распространились повсеместно и не осталось ни одной современной компании или организации, которая не использовала бы облачные сервисы. Но, по данным ABC Data, 82% текущих ИТ-бюджетов организаций все еще направляется на локальную инфраструктуру и приложения. Однако уже к 2020 году как минимум 50% ИТ-расходов будет связано с облачными решениями. Так что тенденция к переводу в облака все большего числа ИТ-сервисов очевидна. Эта тенденция стала одной из основных тем обсуждения на проведенной «ИКС-Медиа» конференции Cloud & Digital Transformation 2018.

Первый этап: снижение затрат

Изначально облака применялись главным образом для оптимизации стоимости получения ИТ-сервисов – читай, для сокращения затрат. На этом этапе спросом в основном пользовались базовые модели «ПО как сервис» (SaaS) и «инфраструктура как сервис» (IaaS), которые и сегодня доминируют на рынке. Так, по данным iKS-Consulting, в 2017 г. 69% доходов на рынке облачных услуг России пришлось на сервисы SaaS, а еще 27% – на IaaS (рис. 1).
В большинстве случаев использование моделей SaaS и IaaS на начальном этапе не требовало сколько-нибудь существенного изменения ИТ-менталитета заказчиков. В случае покупки самой популярной в IaaS-портфеле услуги «виртуальный сервер» заказчик получал возможности, к которым привык при работе с обычными серверами. Он так же мог устанавливать операционную систему и приложения, работать с файлами, – но со всеми преимуществами облачной модели, включая гибкое масштабирование и оплату только задействованных ресурсов.


Источник: iKS-Consulting, 2017 г.
Рис. 1. Доли основных типов облачных сервисов на рынке России

Второй этап: учет специфики

Новые возможности, включая гибкое масштабирование ресурсов и реализацию новых бизнес-моделей, стали следующими катализаторами роста интереса к облачной модели. Если на первом этапе эволюции облаков корпоративные приложения, по сути, не менялись, то на втором этапе заказчики начали перерабатывать свои приложения с учетом облачной специфики. Как отмечает Константин Юров, руководитель технической экспертизы гибридных облачных решений IBM, на этом этапе становятся все более популярными гибридные решения, а также услуги, предоставляемые по модели «платформа как сервис» (PaaS). Появляются и новые услуги, такие как «контейнеры как сервис» (CaaS).

 
Источник: Gartner
Рис. 2. Рост мирового рынка услуг xaaS, $ млрд

Если в 2017 г. в России услуги PaaS занимали скромные 4%, то в мире – около 10%. В 2020 г. объем этого сегмента, по прогнозу Gartner, увеличится до $14,7 млрд (рис. 2). В числе драйверов роста Илья Летунов, руководитель b2b-облаков Mail.Ru Group, называет достигаемое благодаря использованию этих сервисов существенное сокращение стоимости разработки и вывода новых продуктов и услуг на рынок. Для сервис-провайдеров развитие услуг PaaS важно, потому что позволит им выделиться на фоне конкурентов в сегменте публичных облаков.

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

«Контейнеры как услуга»

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

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

Но вернемся к вопросу классификации CaaS. Ресурсным элементом в данном случае служит не виртуальный или физический сервер, а контейнер, который может работать как внутри виртуальной машины, так и на «голом железе». Хотя большинство экспертов склонны рассматривать CaaS как подмножество IaaS, некоторые считают, что эти услуги находятся между IaaS и PaaS (рис. 3).

 

Источник: Atlex
Рис. 3. Варианты классификации PaaS, CaaS и IaaS

Пользователям услуги CaaS предоставляется возможность производить различные операции с контейнерами (загружать, организовывать, запускать, останавливать), оплачивая только используемые объемы ресурсов. Эти услуги могут оказаться чрезвычайно привлекательными для оптимизации процессов разработки и вывода новых решений на рынок. При этом контейнеризация позволяет осуществлять собственно разработку и тестирование, например, в публичном облаке, а потом, при необходимости, легко переносить приложения в частное облако. В целом контейнерные технологии помогают мигрировать между различными вариантами размещения: on-premise, частное облако, публичное облако.

Третий этап: переосмысление

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

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

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

Произошедшие в апреле 2018 г. события, связанные с попытками блокировки сервиса Telegram в России, также показали риск использования популярных западных облаков. В условиях, когда этот сервис начал «скакать» с одной подсети на другую, российскому регулятору ничего не оставалось, как заставлять операторов блокировать все новые и новые миллионы IP-адресов, в том числе популярных облачных сервисов Google Cloud, AWS, Digital Ocean, Azure. Из-за этого пострадали ни в чем не повинные сервисы – от мессенджера Viber до электронных касс одной из крупнейших ритейловых сетей.

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

Курс на гиперконвергенцию

Наряду с самими облачными сервисами, развиваются и технологические платформы, на которых они предоставляются. Здесь тоже можно выделить три этапа. На первом для предоставления облачных сервисов использовалась традиционная (распределенная) мультивендорная ИТ-инфраструктура, в состав которой, помимо объединенного локальной сетью (Ethernet) серверного комплекса, как правило, входила сеть средств хранения (SAN на базе Fibre Channel).

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

Источник: Orange Business Services
Рис. 4. Традиционная и гиперконвергентная ИТ-инфраструктура

Третий шаг – выпуск гиперконвергентных решений как ответ на желание заказчиков сэкономить за счет отказа от дорогостоящих выделенных систем хранения данных и сетей SAN. Такие решения состоят из универсальных узлов, реализующих как вычислительные функции, так и функции хранения данных. Кроме того, внутри такого узла имеются все необходимые средства сетевого взаимодействия (рис. 4). Часто за основу гиперконвергентного узла берется обычный сервер x86, который оснащается необходимым числом накопителей. Но это не есть возврат в 90-е годы прошлого столетия, когда активно использовались напрямую подключаемые системы хранения (Directed Attached Storage, DAS). В отличие от архитектуры DAS, которая приводит к образованию изолированных островков хранения, в гиперконвергентных системах каждый сервер может воспользоваться ресурсами хранения на других серверах. Фактически в них реализуется виртуальная сеть хранения (VSAN).

Например, об использовании систем, в которых вычислительные ресурсы и СХД были бы реализованы в одном блоке, в Cloud4Y задумывались еще девять лет назад. Но, по словам Евгения Бессонова, директора по маркетингу этой компании, удовлетворительных (по технико-экономическим показателям) решений тогда не оказалось. Этот провайдер изначально пробовал использовать сеть SAN на базе протокола Fibre Channel, но выявленные недостатки (отсутствие необходимой гибкости, невозможность построить metro-инфраструктуру между двумя ЦОДами) заставили отказаться от этого решения и сделать выбор в пользу iSCSI. «iSCSI экономически выгоднее, не надо отдельных карт и коммутаторов FC», – объясняет специалист Cloud4Y.
Но, похоже, время гиперконвергенции наступает. Все больше сервис-провайдеров устанавливают такие решения и рапортуют об их многочисленных преимуществах.

Одним из пионеров этой тенденции стала компания Linxdatacenter, которая первой среди поставщиков услуг коммерческих ЦОДов в России развернула для предоставления сервисов IaaS гиперконвергентное решение, а именно Cisco HyperFlex. Это решение построено на основе серверов Cisco UCS, к которым добавлена платформа HX Data, объединяющая твердотельные и дисковые накопители в единое распределенное многоуровневое объектное хранилище данных. Облачные платформы, установленные в других ЦОДах Linxdatacenter – в Варшаве (2012 г.) и Санкт-Петербурге (2013 г.), – построены на основе конвергентного решения FlexPod. В 2017-м, когда было запущено облако в Москве, выбор был сделан уже в пользу гиперконвергентной платформы.

Главным результатом развертывания гиперконвергентного решения, по словам Константина Андреенко, технического консультанта Linxdatacenter, стало увеличение прибыли, получаемой с 1 кв. м площади ЦОДа, что особенно важно для объекта, расположенного в центральной части Москвы. Среди преимуществ развернутой системы он отметил простоту (и низкую стоимость) масштабирования и тот факт, что все решение поставляется одним производителем. Для Linxdatacenter оказались также важными совместимость с имеющимся сетевым и вычислительным оборудованием, поддержка широкого спектра целевых задач, включая SAP HANA, встроенная репликация между площадками (возможность создавать катастрофоустойчивые решения) и глубокая интеграция с системой резервного копирования Veeam Backup на уровне СХД.

Еще один сервис-провайдер, Orange Business Services, решил отказаться от классической архитектуры (отдельно серверы, отдельно СХД) и тоже строит свое «облако 2.0» на базе гиперконверентных решений. В России компания использует для этого серверы Huawei и программное хранилище VMware vSAN. Как рассказал на конференции Cloud & Digital Transformation 2018 Алексей Кречетов, менеджер по развитию бизнеса Orange Business Services, в Москве будет реализовано metro-облако, «растянутое» на две площадки. «Классических СХД в нем не будет – только рэк-серверы, набитые дисками, виртуальная СХД. Это решение дешевле, надежнее и гибче. Его очень просто расширять, – рассказывает А. Кречетов. – Задержка между площадками меньше 2 мс, поэтому репликация будет синхронной».

Облака становятся распределенными

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

Тема децентрализации облаков и пограничных вычислений неразрывно связана с так называемыми туманными вычислениями – fog computing. Игорь Лебедев, технический директор компании SONM, представил на конференции Cloud & Digital Transformation 2018 проект по созданию платформы, которая позволит использовать узлы fog computing для предоставления облачных сервисов. Этими узлами могут служить бытовые компьютеры обычных пользователей, незадействованные ресурсы которых можно направить на обработку задач внешних заказчиков. Такой подход обещает существенное снижение стоимости облачных сервисов. К осени 2018 г. SONM планирует вывести на рынок решение для предоставления услуг IaaS и CaaS, а к концу года – PaaS.

Что ж, облачные модели становятся все интереснее для специалистов и привлекательнее для заказчиков. Вопрос в обеспечении SLA и безопасности – но это уже тема для отельного разговора.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!