Рубрикатор |
Статьи | ИКС № 2 2018 |
Александр БАРСКОВ | 05 сентября 2018 |
Куда плывут облака
От простого выноса имеющихся приложений в облака компании переходят к их переработке с учетом облачной специфики. Набирают популярность гибридные решения и услуги, предоставляемые по модели «платформа как сервис», появляются услуги «контейнеры как сервис».
Казалось бы, облака уже распространились повсеместно и не осталось ни одной современной компании или организации, которая не использовала бы облачные сервисы. Но, по данным ABC Data, 82% текущих ИТ-бюджетов организаций все еще направляется на локальную инфраструктуру и приложения. Однако уже к 2020 г. как минимум 50% ИТ-расходов будет связано с облачными решениями. Так что тенденция к переводу в облака все большего числа ИТ-сервисов очевидна. Эта тенденция стала, в частности, одной из основных тем обсуждения на проведенной «ИКС-Медиа» конференции Cloud & Digital Transformation 2018.
Первый этап: снижение затрат
Изначально облака применялись главным образом для оптимизации стоимости получения ИТ-сервисов – читай, для сокращения затрат. На этом этапе спросом в основном пользовались базовые модели «ПО как сервис» (SaaS) и «инфраструктура как сервис» (IaaS), которые и сегодня доминируют на рынке. Так, по данным iKS-Consulting, в 2017 г. 69% доходов на рынке облачных услуг России пришлось на сервисы SaaS, а еще 27% – на IaaS (рис. 1).
В большинстве случаев использование моделей SaaS и IaaS на начальном этапе не требовало сколько-нибудь существенного изменения ИТ-менталитета заказчиков. В случае покупки самой популярной в IaaS-портфеле услуги «виртуальный сервер» заказчик получал возможности, к которым привык при работе с обычными серверами. Он так же мог устанавливать операционную систему и приложения, работать с файлами – но со всеми преимуществами облачной модели, включая гибкое масштабирование и оплату только задействованных ресурсов.
Рис. 1. Доли основных типов облачных сервисов на рынке России |
Рис. 2. Рост мирового рынка услуг xaaS, $ млрд |
Второй этап: учет специфики
Новые возможности, включая гибкое масштабирование ресурсов и реализацию новых бизнес-моделей, стали катализаторами роста интереса к облачной модели. Если на первом этапе эволюции облаков корпоративные приложения, по сути, не менялись, то на втором этапе заказчики начали перерабатывать свои приложения с учетом облачной специфики. Как отмечает Константин Юров, руководитель технической экспертизы гибридных облачных решений IBM, на этом этапе растет популярность гибридных решений, а также услуг, предоставляемых по модели «платформа как сервис» (PaaS). Появляются и новые услуги, такие как «контейнеры как сервис» (CaaS).
Если в 2017 г. в России услуги PaaS занимали скромные 4%, то в мире – около 10%. В 2020 г. объем этого сегмента, по прогнозу Gartner, увеличится до $14,7 млрд (рис. 2). В числе драйверов роста Илья Летунов, руководитель b2b-облаков Mail.Ru Group, называет достигаемое благодаря использованию этих сервисов существенное сокращение стоимости разработки и вывода новых продуктов и услуг на рынок.
Почему Россия по уровню проникновения PaaS серьезно отстает? Одна из причин – общее отставание в части использования облачных моделей. Как уже говорилось, в нашей стране до сих пор доминируют концептуально более простые сервисы SaaS и IaaS. Однако, возможно, здесь сказываются и различия в методике классификации. Некоторые услуги однозначно классифицируются как PaaS. Это, скажем, доступ к платформам баз данных, средства визуализации, инструменты для разработчиков, сервисы мониторинга, безопасности и пр. Но есть сервисы, с классификацией которых пока не все ясно. Это, например, CaaS.
«Контейнеры как услуга»
Как известно, контейнер представляет собой изолированную и переносимую среду выполнения приложений или процессов, которые поставляются вместе со всеми необходимыми компонентами и файлами конфигурации. Все нужные для работы приложения находятся внутри контейнера, поэтому его можно легко переносить в разные операционные среды. Он может функционировать как поверх виртуальной машины, так и на физическом сервере.
Помимо отличной переносимости, другим важным преимуществом программных контейнеров является экономное использование ИТ-ресурсов. Контейнеры позволяют уместить на одном физическом сервере гораздо больше приложений, чем виртуальные машины. Дело в том, что виртуальные машины требуют много системных ресурсов (оперативной памяти и процессорных циклов), поскольку каждая такая машина содержит не только операционную систему, но и необходимое для работы виртуальное оборудование. Контейнерам «своя» ОС не нужна.
Рис. 3. Варианты классификации PaaS, CaaS и IaaS |
Но вернемся к вопросу классификации CaaS. Ресурсным элементом в данном случае служит не виртуальный или физический сервер, а контейнер. Хотя большинство экспертов склонны рассматривать CaaS как подмножество IaaS, некоторые считают, что эти услуги находятся между IaaS и PaaS (рис. 3).
Пользователям услуги CaaS предоставляется возможность производить различные операции с контейнерами (загружать, организовывать, запускать, останавливать), оплачивая только используемые объемы ресурсов. Эти услуги могут оказаться чрезвычайно привлекательными для оптимизации процессов разработки и вывода новых решений на рынок. При этом контейнеризация позволяет осуществлять собственно разработку и тестирование, например, в публичном облаке, а потом, при необходимости, легко переносить приложения в частное облако. В целом контейнерные технологии помогают мигрировать между различными вариантами размещения: on-premise, частное облако, публичное облако.
Третий этап: переосмысление
Следующий шаг связан с переосмыслением компаниями всей своей ИТ-инфраструктуры и бизнес-процессов с учетом применения облачных, а фактически мультиоблачных сред. На этом этапе все больше решений создается для облаков с нуля – они становятся cloud native.
Мультиоблачный подход дает новые возможности, в том числе в части дальнейшей оптимизации ИТ. Но здесь не все однозначно. Дело в том, что при реализации мультиоблачной модели могут существенно вырасти расходы на интеграцию и управление, что сведет на нет экономические выгоды. Многие поставщики облачных сервисов рассматривают друг друга в качестве конкурентов, а потому не стремятся помогать заказчикам в вопросах интеграции.
Важен и вопрос безопасности. Чем больше облаков вы используете, тем больше существует потенциальных угроз безопасности, для ликвидации которых опять-таки потребуются дополнительные средства. Следует учитывать, что большинство облачных приложений и сервисов не обеспечивают выполнения требований корпоративной безопасности по умолчанию.
Произошедшие в апреле 2018 г. события, связанные с попытками блокировки сервиса Telegram в России, также показали риск использования популярных западных облаков. В условиях, когда этот сервис начал «скакать» с одной подсети на другую, российскому регулятору ничего не оставалось, как заставлять операторов блокировать все новые и новые миллионы IP-адресов, в том числе популярных облачных сервисов Google Cloud, AWS, Digital Ocean, Azure. Из-за этого пострадали ни в чем не повинные сервисы – от мессенджера Viber до электронных касс одной из ритейловых сетей.
Тем не менее при всех сложностях мультиклауд – будущее облачной модели. Но для ее успешной реализации необходима безопасная интеграция приложений и данных, задействованных в разных облачных средах. Заказчикам следует требовать обеспечения такой интеграции непосредственно от сервис-провайдеров, которым в условиях все более острой конкуренции неизбежно придется осваивать новые для многих компетенции.
Курс на гиперконвергенцию
Наряду с самими облачными сервисами развиваются и технологические платформы, на которых они предоставляются. Здесь тоже можно выделить три этапа. На первом для предоставления облачных сервисов использовалась традиционная (распределенная) мультивендорная ИТ-инфраструктура, в состав которой, помимо объединенного локальной сетью (Ethernet) серверного комплекса, как правило, входила сеть средств хранения (SAN на базе Fibre Channel).
В качестве следующего шага некоторые ведущие производители предложили интегрированные (конвергентные) комплексы, укомплектованные проверенными на совместимость компонентами, которые реализуют комплексное решение. В состав конвергентных решений входят продукты двух-трех производителей, скажем, сетевые компоненты и серверы одной компании, а СХД – другой. Но в таких решениях, пусть и упакованных в одну стойку, серверы и СХД остаются отдельными элементами.
Рис. 4. Традиционная и гиперконвергентная ИТ-инфраструктура |
Третий шаг – выпуск гиперконвергентных решений как ответ на желание заказчиков сэкономить за счет отказа от дорогостоящих выделенных систем хранения данных и сетей SAN. Такие решения состоят из универсальных узлов, реализующих как вычислительные функции, так и функции хранения данных. Кроме того, внутри такого узла имеются все необходимые средства сетевого взаимодействия (рис. 4). Часто за основу гиперконвергентного узла берется обычный сервер x86, который оснащается необходимым числом накопителей. Но это не есть возврат в 90-е годы прошлого столетия, когда активно использовались напрямую подключаемые системы хранения (Direct-Attached Storage, DAS). В отличие от архитектуры DAS, которая приводит к образованию изолированных островков хранения, в гиперконвергентных системах каждый сервер может воспользоваться ресурсами хранения на других серверах. Фактически в них реализуется виртуальная сеть хранения (VSAN).
Например, об использовании систем, в которых вычислительные ресурсы и СХД были бы реализованы в одном блоке, в Cloud4Y задумывались еще девять лет назад. Но, по словам Евгения Бессонова, директора по маркетингу этой компании, удовлетворительных (по технико-экономическим показателям) решений тогда не оказалось. Этот провайдер изначально пробовал использовать сеть SAN на базе протокола Fibre Channel, но выявленные недостатки (отсутствие необходимой гибкости, невозможность построить metro-инфраструктуру между двумя ЦОДами) заставили отказаться от этого решения и сделать выбор в пользу iSCSI. Но, похоже, время гиперконвергенции наступает. Все больше сервис-провайдеров устанавливают такие решения и рапортуют об их многочисленных преимуществах.
Одним из пионеров этой тенденции стала компания Linxdatacenter, которая первой среди поставщиков услуг коммерческих ЦОДов в России развернула для предоставления сервисов IaaS гиперконвергентное решение, а именно Cisco HyperFlex. Это решение построено на основе серверов Cisco UCS, к которым добавлена платформа HX Data, объединяющая твердотельные и дисковые накопители в единое распределенное многоуровневое объектное хранилище данных. Облачные платформы, установленные в других ЦОДах Linxdatacenter – в Варшаве (2012 г.) и Санкт-Петербурге (2013 г.), – построены на основе конвергентного решения FlexPod. В 2017-м, когда было запущено облако в Москве, выбор был сделан уже в пользу гиперконвергентной платформы. Главным результатом развертывания гиперконвергентного решения, по словам Константина Андреенко, технического консультанта Linxdatacenter, стало увеличение прибыли, получаемой с 1 кв. м площади ЦОДа, что особенно важно для объекта, расположенного в центральной части Москвы.
Еще один сервис-провайдер, Orange Business Services, решил отказаться от классической архитектуры (отдельно серверы, отдельно СХД) и тоже строит свое «облако 2.0» на базе гиперконвергентных решений. В России компания использует для этого серверы Huawei и программное хранилище VMware vSAN. Как сообщил Алексей Кречетов, менеджер по развитию бизнеса Orange Business Services, в Москве будет реализовано metro-облако, «растянутое» на две площадки. «Классических СХД в нем не будет – только рэк-серверы, «набитые» дисками, виртуальная СХД. Это решение дешевле, надежнее и гибче. Его очень просто расширять, – рассказывает А. Кречетов. – Задержка между площадками меньше 2 мс, поэтому репликация будет синхронной».
Облака становятся распределенными
Ввиду большой протяженности производственных мощностей и офисов многих компаний в России и их удаленности друг от друга сетевые задержки зачастую критически влияют на бизнес вплоть до того, что не все приложения можно развернуть в облаке и надо делать локальное решение. Поэтому, например, Orange Business Services в рамках описанного выше проекта планирует разворачивать региональные облака-сателлиты с резервированием в центральных хабах. К таким хабам – первый из них создается в Москве – предъявляются особые требования по отказоустойчивости и гибкости.
Тема децентрализации облаков и пограничных вычислений неразрывно связана с так называемыми туманными вычислениями – fog computing. Компания SONM, по словам ее технического директора Игоря Лебедева, собирается создать платформу, которая позволит использовать узлы fog computing для предоставления облачных сервисов. Этими узлами могут служить бытовые компьютеры обычных пользователей, незадействованные ресурсы которых можно направить на обработку задач внешних заказчиков. Такой подход обещает существенное снижение стоимости облачных сервисов. К осени 2018 г. SONM планирует вывести на рынок решение для предоставления услуг IaaS и CaaS, а к концу года – PaaS.
Что ж, облачные модели становятся все интереснее для специалистов и привлекательнее для заказчиков. Вопрос в обеспечении SLA и безопасности – но это уже тема для отдельного разговора.