Привет! Меня зовут Тимур Юсипов, я занимаюсь развитием сетевого продукта в Oxygen. Меня, как и многих коллег в ИТ и наших клиентов, волнуют вопросы, озвученные до ката. Каждый отвечает на них по-своему, я буду опираться на тренды, опыт моей команды и свой собственный. Ну что ж, приступим!

Теория. О том, как дошли до жизни такой

Если вас интересует практическая часть, рекомендую сразу переходить к разделу ПРАКТИКА.

Рост сегмента приватных облаков

На сегодня это один из ключевых трендов. Только в нашей компании рост запросов на приватные решения вырос в 3 раза за последние 2 года.

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

Этот тренд характерен не только для рынка РФ, но и для мира в целом. Так, большой прогноз Global Private Cloud Services Market 2023-2027 обещает совокупный среднегодовой темп роста общемирового рынка на уровне 26.7%. Причин этому несколько:

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

Гарантированная производительность. В приватном облаке по определению отсутствует конкуренция за ресурсы между тенантами. Это особенно важно для приложений, которые имеют высокие требования к производительности. Например, базы данных, которые постоянно выполняют большое количество операций чтении/записи комфортнее чувствуют себя в приватном облаке или on-prem инсталляции.

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

Санкции. Наконец, фактор, который больше присущ именно Российскому рынку - санкционные риски. Зарубежные вендоры, на которых опирались как корпоративные клиенты в своих инсталляциях, так и облачные операторы, не доступны в полной мере. Тренд на импортозамещение диктует необходимость внедрять российские или «российские» решения, которые попросту не готовы для использования в публичных облаках. Решения, которые предлагают облачные операторы на базе OpenStack или собственных разработок не всегда соответствуют ожиданиям заказчиков, привыкших к условному VMware. Приватная инсталляция же позволяет не реализовывать полноценный функционал облачной платформы, а ограничится возможностями различных платформ виртуализации для создания и управления ВМ.

А как насчет on-premise?

Если дальше анализировать тренд перехода всего и вся в облако, то интересно посмотреть на соотношение объема рынка colocation и cloud. И тут динамика российского рынка не показывает драматических изменений в пользу перехода клиентов из on-prem в облако.

Рынок ЦОДов: рост на фоне спада

Да, рынок постепенно перераспределяется, но по-прежнему очень многие заказчики рассматривают только on-prem решения. Другие заказчики используют on-prem инсталляции для критичных приложений или данных. 

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

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

Решения класса SaaS

Не стоит забывать также про SaaS решения. Несмотря на то, что рынок SaaS растет на уровне 16% в год, а SaaS-решения - одни из самых простых для внедрения и развертывания, область их применения ограничена определенным набором кейсов. Классические решения для SaaS – почта, мессенджеры, CRM. Тем не менее, SaaS сервисы являются частью множества корпоративных ИТ инфраструктур и должны быть включены в них с учетом требований к качеству и ИБ.

SaaS – это приложения и данные, размещенные на удалённых серверах, доступ к которым пользователи получают с помощью сети интернет.

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

Связность как тенденция

Современная корпоративная ИТ инфраструктура состоит из множества различных, порой разрозненных элементов. Есть публичные облака, рынок которых находится в зрелом состоянии, когда заказчики хорошо осознают преимущества и недостатки решения и готовы делать осознанный выбор. Там размещаются ресурсы, которые требуют прежде всего быстрого масштабирования и не имеют специфических требований по производительности, предсказуемости и безопасности. Есть приватные облака, где размещаются ресурсы, не удовлетворяющие ограничением публичного облака. По-прежнему велика часть инфраструктуры, размещенная на базе on-premise/HaaS сервисов. В этом же контуре SaaS и PaaS продукты. И все это необходимо связать в единую цельную инфраструктуру.

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

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

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

Практика. Строим связность

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

Как решить задачу?

Для реализации такого сервиса рынок предлагает две стратегии.

• Стратегия маркетплейса. Один поставщик на весь комплекс услуг, в том числе отвечающий за сервис построения сетевой связанности.

• Стратегия облачного интегратора. Облачный оператор предоставляет требуемые сервисы заказчику и выступает в роли интегратора для консалтинга ИТ департаментов заказчика с целью построения сетевой и/или общей архитектуры, отвечающей имеющимся требованиям.

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

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

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

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

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

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

Модель “облачного интегратора” позволяет реализовать такое решение и сохранить преимущество «одного окна» для заказчика, что особенно важно при тендерных закупках. В таком случае облачный интегратор предлагает услуги других поставщиков по партнерской схеме продаж. При этом финансовая и административная часть вопроса полностью обеспечивается через компанию – интегратора решения. Техническая поддержка реализуется совместно с партнером для привлечения его экспертизы в вопросах, требующих детальной проработки или оперативного решения.

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

А сейчас у меня вопрос к читателям. Как вы оцениваете модель “облачного интегратора”? Согласны, что у нее больше плюсов, чем минусов? Или вам больше нравится модель маркетплейса? Поделитесь своим мнением в комментариях.