Одна из самых популярных и навязчивых идей или, если угодно, концепций в ИТ последнего времени — это открытость. Мы то и дело слышим об открытых сетях, открытых облаках, открытой инфраструктуре. Открытое программное обеспечение уже давно никакая не новость. Но если Open Source является концепцией довольно-таки чётко обозначенной и описанной всевозможными стандартами, то в сетевом пространстве гуляет ветер неопределённости. Что такое пресловутая «открытость» применительно к сетям?
Новые возможности виртуализации сетей, свалившиеся на голову совсем недавно, внесли ещё больше сумятицы. Программно-определяемые сети (SDN) и функциональная виртуализация сети (NFV) наконец-то смогли софтверно абстрагировать сеть от её физического воплощения, однако как нам теперь понять, насколько такие сети соответствуют критериям открытости?
«Одна из самых популярных концепций на рынке сетевого оборудования сегодня — это SDN, или программно-определяемые сети. Практически все вендоры сетевого оборудования так или иначе освоили эту концепцию, превратив её во вполне реальную технологию, без которой невозможно представить современный ЦОД. Внедряя эту технологию, вендоры расписывают её как способ оперативного выделения ресурсов и эффективного контроля состояния сетевой инфраструктуры.
SDN, как и любая технология, относящаяся к виртуализации, предполагает логичное разделение уровней управления и данных. Первые два слова в этой аббревиатуре, ставшей уже весьма привычной, описывают подход, который в дальнейшем будет применяться не только к сетевой инфраструктуре, но и к другим компонентам дата-центра. Я говорю о концепции software-defined, то есть о программной или централизованной определяемости» (источник).
Итак, усложнение технологий и появление все новых и новых софтверно-определяемых слоёв ЦОДа совсем не упрощает стандартизацию и поиск критериев сетевой «открытости». Однако, собрав достаточно информации, можно выявить ряд требований к той концепции, которую западные коллеги склонны называть «openness». Индустрия ещё не вербализовала эти критерии, но кому, как не нам, заниматься их утверждением? Руководствуясь общими требованиями ИТ-отрасли, вашему покорному слуге удалось выявить пять столпов «открытости», на которую нынче принято уповать в технологическом мире, а если конкретнее, то в сетевой и облачной его частях.
Стандарты
Разговоры вокруг открытости так или иначе сводятся к технологическим стандартам и сообществам, которые их создают и поддерживают. Как правило, стандарты устанавливаются для того, чтобы сделать возможным межотраслевое сотрудничество в рамках одних и тех же технологий, которые по-разному характеризуется и воспринимаются вендорами. Например, когда какой-то конкретный протокол стандартизирован, вендор уже не может видоизменять его, чтобы защитить свою технологию от использования другими компаниями. Таким образом, стандарты устанавливают общие для всех правила игры. Однако стандарты не то чтобы защищают технологии. Конечно, они определяют аспекты технологии, которые должны быть общими для всех, но это не останавливает компании от того, чтобы развивать стандартизированные технологии по-своему. И пока это, к сожалению, общее место: так делают практически все. Тем более что вышеупомянутые сообщества и компании, создающие и поддерживающие стандарты, зачастую не устанавливают строгих критериев. Поэтому на ранних этапах развития технологии её преимущества почти всегда вытесняют стандарты.
Способность к взаимодействию
Какими бы ни были стандарты, на практике оказывается, что открытость — это способность к взаимодействию. Для большинства компаний на рынке конечной целью является ИТ-решение, которое может быть развёрнуто и эффективно применено в нише, где работает множество вендоров. С точки зрения сетевых или облачных технологий наиболее мощным препятствием к взаимодействию оказывается понимание границ той или иной инфраструктуры.
Как правило, администраторы и пользователи облаков и сетей по-разному воспринимают границы применения технологии. Несмотря на это, клиенты предъявляют вендорам вполне конкретные требования к способности технологий и сетей взаимодействовать. Поэтому способность к взаимодействию и её чёткое определение оказывается ключевым критерием открытости.
Open Source
Открытость также часто оказывается условным сокращением от Open Source. Сторонники открытого ПО, как правило, заинтересованы в том, чтобы дать сообществу разработчиков возможность строить свои проекты на продуктах, созданных коллективно. Тем более что «открытые» разработки весьма эффективно выращивают сообщества разработчиков, что ускоряет инновации, постоянно повышая планку, расширяя границы.
Однако Open Source как концепция не предназначается для того, чтобы развивать идеи взаимодействия и взаимозаменяемости софтверных продуктов. Тем не менее опенсорсные продукты представляют большую ценность для сообществ, которые они обслуживают. Открытые продукты освобождены от необходимости быть прибыльными — а значит, они могут быть, условно говоря, лабораторией для больших экспериментов.
Взаимозаменяемость
Если мы говорим о взаимодействии устройств, то следует определиться и со степенью заменяемости их друг другом. Иными словами, если устройство A функционально эквивалентно устройству B, то они взаимозаменяемы.
Открытость зиждется в том числе и на данном критерии, поскольку это позволяет использовать решения различных вендоров, тем самым избегая участи попасть в ловушку к одному вендору, а заодно — создавать конкуренцию между вендорами, что влияет на их ценовую политику.
Основной барьер для взаимозаменяемости технологий — это кастомизация. Едва-едва поддерживаемые функции тех или иных продуктов создают заметный барьер для заменимости компонентов систем. Вендоры стремятся наплодить как можно больше таких «уникальных» технологий и продать их. А ответственность потом несут клиенты, которые не в состоянии распространить узконаправленные особенности технологий на массовый рынок.
Доступность
Это, пожалуй, наименее важный критерий открытости облачных и сетевых решений, однако оставлять его без внимания никак нельзя. Как правило, открытость в данном случае обозначает наличие свободного доступа к информации. Это особенно важно при разработке решений, которые подразумевают наличие API или слоёв интеграции. Например, недавно все SDN-сообщество обсуждало, следует ли встраивать северный интерфейс (так называемый northbound interface, позволяющий приложению предоставлять низкоуровневые детали вышестоящему в архитектуре приложению) в сетевые контроллеры — или оставить его на уровне API. Такие API могут быть весьма специфичными, поэтому их стандартизация не всегда обязательна. Однако если какая-либо компания захочет работать с таким программным интерфейсом, то ей понадобится полный доступ к самому интерфейсу и информации о нем. Доступность как критерий предполагает именно это.
В конце замечу, что концепция открытости и приведённые критерии важны не только как идеологическая установка, а и как необходимое условие активного развития софтверного и «железного» рынков. Открытость порождает разнообразие и конкуренцию, а это позволяет избежать монополизации, к которой так склонны крупные вендоры, даже если речь идёт о монополии в рамках отдельной технологии.