Создание открытых сетей в реальном мире. Часть 4. Взаимодействие: проблемы с API
В нашем предыдущем посте мы рассмотрели различные общие схемы соответствия стандартам в открытых сетевых решениях. В этом посте мы рассмотрим еще один уровень взаимодействия на уровне интерфейса прикладных программ (API), который создает проблемы, выходящие за рамки стандартов.
Справочная информация
Как мы упоминали ранее, сетевое оборудование уже много десятилетий фокусируется на совместимости интерфейсов и интероперабельности и имеет историю реальных испытаний. успешная совместимость. Традиционные сети предоставляют доступ к коммуникационным интерфейсам, и большинство стандартов для сетевого оборудования ориентированы на эти интерфейсы.
Но с появлением сетевых программных эквивалентов аппаратных устройств мы открываем новые области для решения проблем.Программные компоненты могут реализовывать те же типы коммуникационных интерфейсов, но также предоставлять интерфейсы прикладных программ (API) для взаимодействия между собой и другими программными компонентами. Эти API могут быть предметом стандартов, и, таким образом, могут применяться вопросы, поднятые в предыдущей статье. Или это могут быть просто собственные API, уникальные для поставщика.
Итак, нам нужно взглянуть на то, как API могут поддерживать совместимость, а также на проблемы, возникающие при реализации API, которые усложняют взаимодействие.
Совместимость API
Существует ряд уровней, на которых API являются открытыми и потенциально совместимыми, или нет.
- Наличие спецификации и поддержка поставщиком сторонней реализации (стандартной или собственной)
- Уровень соответствия любой документации (стандартизированной или нет)
- Способность базовых компонентов обеспечивать удовлетворять требованиям открытого API
Ранее мы рассказывали о различных степенях соответствия требованиям и препятствиях, которые это создает на пути успешных открытых сетевых решений. В этом посте мы подробно остановимся только на двух других.
Наличие спецификации интерфейса
Спецификации открытых стандартов, как правило, доступны, но часто недоступны в свободном доступе. Некоторые организации ограничивают использование спецификаций различными уровнями членства в своей организации. Иногда доступ к спецификациям могут получить только платные пользователи.
Собственные интерфейсы могут быть доступны при определенных ограниченных условиях или могут быть недоступны вообще. Доступность стандартов де-факто обычно выше, поскольку это позволяет владельцу стандартов оказывать определенное влияние на рынок. Интерфейсы с высокой степенью запатентованности часто имеют более высокие препятствия для получения доступа, как правило, только в том случае, если реальный клиент запрашивает спецификацию для себя или от имени интегратора решений.
Практическая доступность в проекте
Одно дело получить доступ к документу спецификации API, но совсем другое — получить практическую информацию. доступ к информации, необходимой для реализации интерфейса к этому API.
В арсенале компонентов открытого сетевого решения могут быть сотни API, а то и больше. Эти API должны быть доступны для использования разработчиками решений. Типичным решением является публикация этих API в каталоге с возможностью поиска. В некотором смысле это может быть «открытым», но не обязательно совместимым.
Интеграторы решений также должны иметь доступ к ресурсам поддержки, чтобы помочь с проблемами, возникающими при реализации (ошибки и т.д.). Слишком часто документ API содержит мало деталей, неточен и даже устарел. Богатство этого ресурса поддержки и наличие специалистов по оперативной поддержке напрямую влияют на производительность внедрения.
Способность базовых компонентов удовлетворять требованиям API
Программное обеспечение добилось ряда успехов в реализации синтаксической и репрезентативной открытости, но не семантической открытости. Используя стандарт REST в качестве примера, я могу отправить корректно отформатированную и закодированную полезную нагрузку в конечную точку REST, но если принимающее приложение не понимает семантический контент, интерфейс не работает.
И если базовые компоненты не могут обработать запрос в общем (не говоря уже о стандартным) способом теоретическая совместимость становится сложной и/или ограниченной.
Может помочь пример NFV.
Рассмотрим вариант использования NFV Orchestration, который выполняет автоматическое масштабирование экземпляров NFV на основе некоторого соотношения пропускной способности и емкости. Большинство компонентов NFV позволяют легко получать требуемые значения соответствующих показателей с помощью телеметрии.
Но именно диапазон доступных показателей и алгоритмы, используемые для их генерации, создают сложность и потенциально влияют на совместимость.
Один поставщик NFV может обеспечить этот показатель с точки зрения использования ЦП на общем уровне NFV. Другой может обеспечить использование ЦП на уровне виртуальной машины. Или поставщики могут использовать разные алгоритмы для расчета показателя, который они называют “загрузкой процессора”, или могут значительно отличаться в сроках обновления. Другой поставщик может вообще не учитывать загрузку процессора, но может указывать количество пакетов в секунду.
Заключение
API играют важную роль во внедрении открытых сетевых решений и достижении функциональной совместимости. Однако они не являются “серебряной пулей”, и здесь может возникнуть множество проблем. Как и в случае с соблюдением стандартов, нельзя предполагать доступность API и, возможно, соответствие стандарту.
В последних нескольких статьях мы сосредоточились на темах, связанных с программным обеспечением, но пришло время вернуться к сетевой стороне Open Networking в наших последних двух статьях. Если пока оставить в стороне технологии, то как специалист по интеграции решений справляется с различными парадигмами реализации решений, которые могут существовать в рамках открытого сетевого проекта? Мы расскажем об этом в следующем посте.
Следите за обновлениями.
Готовы ли вы перенести свою сеть в будущее, определяемое программным обеспечением?
Автоматизируйте свою сеть с помощью ONAP.
Узнайте, как создать открытую сеть в реальном мире. Часть 4 «Совместимость: проблемы с API» впервые появилась на Aptira.
Другие новости: