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