Header Ads Widget

Ticker

6/recent/ticker-posts

Uso de Canary Release para facilitar el control de versiones de API


 Una de las mayores dificultades que puede enfrentar un proveedor de API es cómo administrar versiones y compilaciones de una instancia a otra. La necesidad constante de iterar junto con la necesidad constante de organizar ha hecho que el control de versiones sea una faceta controvertida y a menudo discutida del desarrollo moderno de API. Sin embargo, existen algunas alternativas al control de versiones tradicional que otorgan algunos beneficios importantes.

Hoy, vamos a discutir una de estas soluciones: Canary Release . El lanzamiento de Canary se ha convertido rápidamente en un gran componente del desarrollo de API transparentes, y para la banca abierta , es quizás una de las mejores herramientas que las instituciones financieras modernas pueden aprovechar para un control de versiones transparente y efectivo sin romper la interoperabilidad fundamental.

Esta pieza se inspiró en la charla de Patrice Krakow A Journey from API Versioning to Canary Release de la Nordic APIs 2017 Summit. Mírelo a continuación y vea las diapositivas aquí .

¿Por qué son tan importantes el control de versiones de API y la versión Canary?

A veces, puede haber cierta tensión entre los proveedores de API y los consumidores de API. Es posible que el proveedor de la API desee cambiar la API a medida que obtenga nuevas ideas más importantes. Estas ideas son prometedoras y muestran nuevas características, nuevas metodologías y posibles nuevas direcciones para la API.

Sin embargo, el consumidor de API a menudo solo quiere algo estable. A menos que el consumidor esté interesado en esa nueva gran idea, los consumidores quieren que la API funcione de manera predecible .

Esto crea una lucha clara y obvia, y es principalmente la razón por la que el control de versiones es tan difícil para muchos usuarios. Sin embargo, quizás el mejor argumento en contra de las versiones es de Roy Fielding, el padre del diseño REST. ¿Su opinión sobre la implementación de versiones? No ".

Más información sobre los tipos de control de versiones: Introducción a las mejores prácticas de control de versiones de API

¿Qué es el control de versiones?

¿Por qué, específicamente? ¿Por qué no deberíamos hacer el control de versiones como algo natural? Echemos un vistazo a las repercusiones del control de versiones de las API.

El control de versiones es la idea de que a medida que se agregan características a un servicio, esto crea fundamentalmente una nueva versión de los objetos existentes. Estas versiones son claramente diferentes y, a menudo, funcionan completamente por separado con un propósito diferente y, como tales, se tratan como desarrollos claramente separados .

En el desarrollo de versiones tradicionales , estas nuevas versiones se marcarían en pequeños movimientos como lanzamientos beta para pruebas y como lanzamientos de referencia para mejoras completas. Una vez que las pruebas están en marcha, generalmente de forma opcional, estas versiones beta se moverán lentamente hacia versiones candidatas y luego versiones reales.

Este tipo de control de versiones tiene algunos beneficios importantes , el principal de los cuales es el hecho de que las principales mejoras en la forma y la función están claramente delimitadas . Esta capacidad de demarcación es muy importante, especialmente cuando se trabaja con diferentes versiones de hardware, pero en última instancia, esto en sí mismo es la ruina del enfoque versionado. Muchos usuarios conocerán el dolor de intentar usar un dispositivo solo para descubrir que su firmware, software u otro elemento es incompatible y requiere actualización. Por lo tanto, no usan el sistema y regresan en una fecha posterior para encontrar que la situación es aún peor.

En última instancia, esto conduce a una división masiva en la base de usuarios de actualizado y no actualizado, y le da demasiada importancia a instancias singulares en lugar del sistema holístico en sí.

Relacionado: Estrategia de control de versiones continua para API internas

¿Qué es Canary Release?

La liberación canaria es una técnica que busca paliar muchos de estos negativos. El lanzamiento de Canary se posiciona a menudo como una alternativa al versionado, como el versionado lite .

En la versión canary, el riesgo de introducir nuevo software se mitiga implementando primero lentamente estos cambios en pequeños subconjuntos de usuarios , en lugar de implementarlos a través de la suscripción voluntaria y luego la liberación forzada como en el control de versiones clásico. Estos pequeños subconjuntos de usuarios prueban la nueva versión a través del balance de carga dinámico , y una vez que se verifica que el control de versiones funcione como se desea, la nueva versión se convierte en la predeterminada.

Llamamos a este lanzamiento canario porque funciona de manera similar a un canario en un pozo de mina. Los mineros usaron una vez un canario para probar el aire en una mina. Si el aire era venenoso, el canario moriría, indicándole al minero que tenía que irse inmediatamente. De la misma manera que el canario muere en la mina, si la instancia de API que se está probando lentamente es mala, se detectará debido a fallas en el subconjunto pequeño en lugar de fallas masivas para la audiencia general.

La aplicación está llamando a una instancia de un servicio vinculado a una API y, a medida que estas solicitudes se exponen gradualmente a la nueva versión, se pueden probar aplicaciones, hardware, métodos y más específicos de forma dinámica y granular con la nueva versión. Eventualmente, si todo va bien, todo irá a la nueva versión , la versión anterior quedará obsoleta y los usuarios no se darán cuenta.

Un gran beneficio aquí es el hecho de que retroceder es fácil; en última instancia, simplemente deja de enviar solicitudes a la nueva instancia de Canary y simplemente la envía a la anterior.

Lea también: Cómo implementar la sincronicidad de API a SDK

Control de versiones de ING

Este enfoque es más fácil de entender una vez que lo ve en acción. Patrice Krakow dio una charla sobre la liberación canaria en la Cumbre de la Plataforma de APIs nórdicas de 2017, en la que proporcionó el siguiente flujo de trabajo como un ejemplo de cómo ING Bank maneja la liberación canaria.

Construyendo el sistema

En el sistema ING, gran parte de la interacción API es impulsada por una puerta de enlace API . Consideran que su red está separada en dos capas : la red externa y la red interna , con una tercera división de la red interna que representa la red de la oficina . Patrice señala que las puertas de enlace API funcionan en un borde externo y en un borde interno, aunque señala que en realidad no existe un "Gateway interno" como podría sugerir el diseño.

En términos de su API , todo, incluido el equilibrio de carga y el direccionamiento lógico, se maneja principalmente mediante el descubrimiento de servicios de API . Cuando se crea una instancia de un servicio, ese servicio se entrega al API Server Discovery como una instancia, un grupo de puntos finales y una dirección al cliente a través de un enrutador . Por un momento, debemos tomar un pequeño desvío para discutir ese enrutador. En ING, manejan su enrutador no como un componente externo, sino como parte del cliente ; de esta manera, el código del cliente maneja su propio equilibrio de carga.

En el sistema ING, el servicio y los puntos finales son dos cosas separadas, pero están vinculados y controlados por algo llamado manifiesto . Este manifiesto es esencialmente un vínculo explícito y bien definido entre el servicio y una lista de puntos finales de API , y funciona como una especie de guía sobre cómo funciona la instancia en sí.

Cuando un paquete de software desea llamar a un punto final de API, primero declara su intención de hacerlo. En ING, esto se denomina suscripción , que funciona como una relación entre el paquete de software (también conocido como la aplicación) y el punto final API específico. Cuando el peer-token se genera internamente, la versión de la especificación de la API se almacena desde el momento en que se crea esta suscripción, teniendo en cuenta la versión de la instancia como parte del gran sistema canario.

Hemos cubierto las aventuras de API de ING Bank en el pasado: de  API Doing a API Thinking en un banco importante

Utilizando el sistema

Con todas estas partes constituyentes en su lugar, ING finalmente implementa el lanzamiento canario a través de su enrutador. El flujo comienza con la API y los puntos finales que se indican en un archivo Swagger que existe en el Registro de API . Se adjunta un servicio a los puntos finales de la API y luego se agrega el manifiesto al servicio con su versión de especificación específica. Cuando se inicia una instancia de un servicio, le da al módulo API Service Discovery su dirección física, así como un manifiesto de todos sus puntos finales.

Tomado de la charla de Patrice Krakow. Desliza aquí .

Cuando la aplicación quiere llamar a un punto final, se suscribe con una lista de puntos finales a los que puede llamar, así como la versión específica con la que pretende hablar. El enrutador, ya sea dentro del código o fuera de él, luego entrega la información y el token del par de registro, y llama a la API Service Discovery con la dirección física de los puntos finales. Si la versión específica de la especificación de API coincide, el código puede dirigirse a la instancia básica oa una versión compatible con versiones anteriores que funcione con esa versión.

De esta manera, el sistema puede comenzar a descargar a una nueva instancia que es compatible con la anterior y, una vez que se prueba todo el subconjunto, puede aumentar dinámicamente esta cantidad de base de usuarios . Al final, cuando el 100% de la base de usuarios se ha migrado de forma transparente, los identificadores de instancias anteriores están obsoletos y la nueva instancia se convierte en la predeterminada en el manifiesto.

Conclusión: muchas industrias pueden beneficiarse de un lanzamiento de Canary

En última instancia, el hecho de que un proveedor de API elija incorporar la versión canary o adherirse al control de versiones tradicional depende completamente del caso de uso específico del propio desarrollador de API. Si bien la versión canary de hecho hace que el control de versiones sea mucho más fácil, a veces puede ser mucho más esfuerzo de lo que vale si una API solo tiene una o dos versiones principales cada pocos años. Sin embargo, si una API está cambiando continuamente , iterando constantemente, el lanzamiento de canary es posiblemente uno de los métodos más poderosos y efectivos para gestionar este movimiento.

Este concepto tiene muchas aplicaciones en una variedad de industrias . Podemos mirar solo uno para ver cuán poderoso es este concepto potencial. El   movimiento de banca abierta , por ejemplo, está alentando a las instituciones financieras a alejarse de los enfoques estándar más antiguos. Como tal, la idea de la liberación canaria no es solo un enfoque técnico, es un nuevo espíritu que ofrece un cambio de paradigma en cómo funciona un banco tanto en términos de transacciones financieras como en términos de construcción arquitectónica.

Si bien esta es una aplicación muy específica, el uso del control de versiones canary es aplicable a una amplia gama de funciones y propósitos. Por esa razón, sigue siendo atractivo para muchos desarrolladores. ¿Qué opinas sobre la liberación de canarios? ¿Crees que es más complicado de lo que vale, o crees que es una solución tan prometedora como algunos parecen afirmar que es? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios