Redes abiertas del mundo real. Parte 4 – Interoperabilidad: Problemas con las API

En nuestra última publicación analizamos diferentes modelos generales de cumplimiento de estándares en soluciones de Red Abierta. En esta publicación profundizamos en otra capa para analizar la interoperabilidad en el nivel de la interfaz del programa de aplicación (API), lo que crea problemas a un nivel más allá de los estándares.

Como mencionamos anteriormente, los equipos de red se han centrado en la compatibilidad y la interoperabilidad de las interfaces durante varias décadas y tienen una verdadera historia de éxito en materia de interoperabilidad. Las redes tradicionales exponen interfaces de comunicación y la mayoría de los estándares para equipos de red se centran en estas interfaces.

Pero con la llegada del software de red equivalente a los dispositivos de hardware, abrimos nuevas áreas de problemas.

Los componentes de software pueden implementar los mismos tipos de interfaces de comunicación, pero también proporcionarán interfaces de programa de aplicación (API) para la interacción entre ellos y otros componentes de software. Estas API pueden ser objeto de estándares, por lo que podrán aplicarse las cuestiones planteadas en el artículo anterior. O pueden ser simplemente API propietarias, exclusivas del proveedor.

Por eso queremos analizar cómo las API pueden respaldar la interoperabilidad y también los problemas que ocurren en la implementación de las API que hacen que la interoperabilidad sea más desafiante.

Hay varios niveles en los que las API son abiertas y potencialmente interoperables o no.

Anteriormente, cubrimos los distintos grados de cumplimiento y los obstáculos que obstaculizan el éxito de las soluciones de red abierta. En esta publicación profundizaremos solo en los otros dos.

Las especificaciones de Estándares Abiertos generalmente están disponibles, pero a menudo no están disponibles de forma gratuita. Algunas organizaciones restringen las especificaciones a varios niveles de membresía de su organización. A veces, sólo los miembros pagos pueden acceder a las especificaciones.

Las interfaces propietarias pueden estar disponibles bajo ciertas condiciones limitadas o pueden no estar disponibles en absoluto. La disponibilidad es generalmente mayor para las normas de facto, porque permite al propietario de las normas ejercer cierta influencia en el mercado. Las interfaces propietarias suelen tener barreras más altas para obtener acceso, generalmente solo si un cliente real solicita la especificación para sí mismo o en nombre de un integrador de soluciones.

Una cosa es obtener acceso a un documento de especificación de API, pero otra muy distinta es obtener acceso práctico a la información necesaria para implementar una interfaz para esa API.

Una solución Open Network puede tener cientos de API en su inventario de componentes, o más. Estas API deberían estar disponibles para que las utilicen los diseñadores de soluciones. Una solución típica es publicar estas API en un catálogo con capacidad de búsqueda. Esto puede ser «abierto» en cierto sentido, pero no necesariamente interoperable.

Los integradores de soluciones también deben tener acceso a un recurso de soporte para ayudar con los problemas que surjan de la implementación (errores, etc.). Es muy común que el documento API tenga detalles limitados, sea inexacto e incluso esté desactualizado. La riqueza de este recurso de soporte y la disponibilidad de especialistas en soporte en vivo se traducirán directamente en productividad de implementación.

El software tiene varios éxitos en la implementación de la apertura sintáctica y representacional, pero no de la apertura semántica. Usando el estándar REST como ejemplo, puedo publicar una carga útil codificada y formateada correctamente en un punto final REST, pero a menos que la aplicación receptora comprenda el contenido semántico, la interfaz no funciona.

Y si los componentes subyacentes no pueden atender la solicitud de una manera común (más bien estándar), la interoperabilidad teórica se vuelve difícil y/o restringida.

Un ejemplo de NFV puede ayudar.

Considere un caso de uso de NFV Orchestration que realiza un escalado automático de instancias de NFV en función de alguna medida de rendimiento versus capacidad. La mayoría de los componentes de NFV facilitan la obtención de las medidas necesarias de métricas relevantes a través de la telemetría.

Pero es la gama de métricas disponibles y los algoritmos utilizados para generar las métricas lo que introduce complejidad y potencialmente afecta la interoperabilidad.

Un único proveedor de NFV puede proporcionar esta medida en términos de utilización de CPU a nivel total de NFV. Otro puede proporcionar utilización de CPU a nivel de VM. Cualquiera de los proveedores puede utilizar diferentes algoritmos para calcular la métrica que llaman «utilización de la CPU» o pueden variar considerablemente en el momento de las actualizaciones. Es posible que otro proveedor no proporcione ningún uso de CPU, pero puede proporcionar una métrica de paquetes por segundo.

Las API desempeñan un papel importante en la implementación de soluciones de red abierta y el logro de la interoperabilidad. Sin embargo, no son «soluciones milagrosas» y pueden plantearse muchos desafíos. Al igual que con el cumplimiento de estándares, no se puede asumir la disponibilidad de API y, potencialmente, el cumplimiento de un estándar.

Las últimas publicaciones nos hemos centrado en temas relacionados con el software, pero es hora de recuperar el lado de redes de Open Networking para nuestras dos últimas publicaciones. Dejando de lado la tecnología por el momento, ¿cómo aborda un integrador de soluciones los diferentes paradigmas de implementación de la solución que pueden existir en un proyecto de Open Networking? Cubriremos esto en la próxima publicación.

Manténganse al tanto.