Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo manejar la entrega continua de microservicios

 

Cómo manejar la entrega continua de microservicios

El mundo de la arquitectura y el desarrollo de API es complicado en muchos sentidos. Desafortunadamente, no existe una solución "perfecta", y con cada nueva implementación o solución, es probable que surjan nuevos problemas.

Es importante recordar, entonces, que incluso las decisiones más positivas y poderosas en la arquitectura de API podrían tener problemas importantes a largo plazo que, si no se reconocen en el brumoso brillo de la euforia posterior a la adopción, podrían interferir fácilmente con el éxito de una API o colección de API.

Caso en cuestión: entrega continua de microservicios . ¿Cómo maneja un proveedor las actualizaciones consistentes en un conjunto de microservicios? ¿Cómo se optimiza y gestiona la comunicación? Más concretamente, ¿cómo se maneja la compatibilidad cruzada y hacia atrás entre diferentes versiones del mismo cliente?

Estas preguntas tienen serias implicaciones para la gestión de datos, la comerciabilidad, la adopción por parte del usuario y más. Hoy, analizaremos este problema y todos los problemas que genera, mientras ofrecemos algunas soluciones básicas que ayudarán a mitigar problemas más importantes y agilizar la entrega.

¿Qué es realmente un microservicio?

Una forma de conceptualizar los microservicios es pensar en una API como un libro. Un libro no es más que una metodología adoptada por un autor, usando su propio estilo y lenguaje, para traducir sus pensamientos en forma escrita, transfiriéndolos a través de la lectura a su propia mente como pensamientos traducidos. Si bien la comparación no es perfecta, funcionará para nuestros propósitos.

Considere el caso de Artamène , del autor Georges y Madeleine de Scudéry. La novela, publicada por primera vez en formato de serie y luego combinada en una sola novela como se pretendía inicialmente, es posiblemente el libro más largo de la historia, con 1.954.300 palabras en 13.095 páginas.

Si bien el contenido y la historia son interesantes, aquí nos centramos en las propiedades físicas: con un libro tan grande, actividades como la verificación de errores, la traducción e incluso la lectura pueden ser una tarea ardua. El contenido en sí no es el problema, sino el método de entrega .

De hecho, podría ser una de las mejores publicaciones de su tiempo, pero para muchos lectores, el simple hecho de la extensión y el peso resultante del formato previsto de una sola publicación elimina su utilidad en gran medida; intente leer esto en un público abarrotado. entrene en formato de publicación única y verá los negativos de primera mano.

Por otro lado, considere la serie de libros de Harry Potter de JK Rowling. Significativamente más corto y con menos contenido en general que Artamène , sin embargo, ha sido un éxito de ventas en todo el mundo. Olvidando por un momento lo grandiosa y asombrosa que es la historia, el diálogo y el universo, Harry Potter debe su éxito en gran parte a su digestibilidad .

Cada libro de Harry Potter se divide en un arco de la historia que está ligado al tema de la historia que se cuenta, y cada libro es lo suficientemente único como para participar en sus propias propiedades y funcionar de alguna manera como un trabajo independiente. Es fácil de digerir de forma singular, pero se vuelve más potente con el resto de la serie.

Esto es fundamentalmente un microservicio . Si bien podríamos usar una API singular y megalítica, trae consigo una falta de portabilidad, una ausencia de digestibilidad y una dificultad en la verificación y traducción de errores. Al dividir un servicio en funciones separadas y crear "mini API" para cada una que sean lo suficientemente fuertes por sí mismas, pero más poderosas juntas, creamos un conjunto de API que son portátiles, fáciles de verificar en busca de errores, fáciles de implementar y en la mayoría de los casos simplemente mejor.

Todo esto viene con la advertencia de que los microservicios necesitan un backend único en forma de arquitecturas de microservicios . Esto puede ser un costo de tiempo y esfuerzo en sí mismo, pero en muchos casos, es un costo perfectamente aceptable para los beneficios finales.

Más sobre la arquitectura de microservicios: API asíncronas en microservicios coreografiados

Los desafíos ocultos del formato de microservicio

Sin embargo, no todo son margaritas y sol, hay algunos problemas importantes con este tipo de entrega de contenido que no se pueden explicar con una metáfora literaria sorprendente. Siempre que segmenta la funcionalidad de una propiedad en la funcionalidad de muchas propiedades, el error más significativo con el que se encuentra es el tema que generó esta pieza: la comunicación entre cada pieza individual y los problemas que surgen en tal situación.

En pocas palabras, ¿cómo nos aseguramos de que cada aplicación de microservicio sea compatible con el resto de los servicios? ¿Cómo hacemos compatibles los datos entre servicios? ¿ Implementamos todas las funciones de microservicios al mismo tiempo o esto anularía los beneficios de la arquitectura segmentada? ¿Cómo manejamos la entrega continua de microservicios?

Escalado de datos

Cuando se trata de transferir datos de una versión de una aplicación de microservicio a otra, quizás el método más fácil (aunque menos eficiente) sea el escalado de datos . Cuando hablamos de escalado de datos, en realidad estamos hablando de conversión de datos y de escalar o reducir estos datos dinámicamente entre servicios incompatibles.

Tomemos, por ejemplo, una API de geolocalizador que llama a los datos geográficos de su teléfono y los relaciona con un lugar aproximado en una aplicación de mapas. Luego , se llama a otra API, la API CheckIn , desde la colección de microservicios para notificarle qué restaurantes, hoteles y puntos de referencia se encuentran en el área utilizando geodatos de otros usuarios que se han registrado en estos lugares.

Desafortunadamente, la versión de la API Geolocator usa un formato de flujo de datos diferente para entregar su ubicación que la API CheckIn, ya que la API CheckIn requiere una combinación y codificación de datos más eficiente para proteger la privacidad que una simple aplicación de localización.

En este caso, los datos podrían simplemente convertirse dinámicamente . Los datos de CheckIn se pueden anonimizar y desinfectar, eliminando cualquier información de identificación personal privada antes de codificar y luego decodificar este contenido en la aplicación de usuario nativa.

El problema aquí es, por supuesto, los gastos generales. No es justo dejar el peso de la decodificación sobre los hombros del usuario y consume recursos de la aplicación nativa. Esto se podría hacer "en la nube", pero esto plantea más cuestiones de seguridad. Los usuarios podrían ser notificados de esta limitación, y aunque esto es lo ético y legal , podría resultar en una base de usuarios más baja.

Dicho esto, la traducción dinámica de contenido de un servicio a otro es una solución y la utilizan muchas suites de aplicaciones (como la suite de Google de Drive, Gmail, Calendar, etc.).

Asegurar la compatibilidad

Incluso ignorando el problema de los problemas de datos en tiempo real, existe el problema obvio de la compatibilidad entre las versiones de la API. Al actualizar un microservicio, ¿cómo se asegura de que las versiones anteriores sean compatibles?

Una forma sencilla es simplemente agregar soporte para tipos de datos antiguos según las necesidades del consumidor. Con métricas simples , puede rastrear en gran medida qué versión de una API están utilizando sus usuarios y rastrear los tipos de datos como tales. Por lo tanto, si sabe que el 0% de los usuarios usa el tipo de datos antiguo de una versión de API arcaica, puede eliminar el soporte para ese tipo de datos en una revisión de API posterior, mientras mantiene el soporte básico para el 1.5% usando la última actualización de su servicio.

Si bien esto ciertamente agrega algo de hinchazón, es una solución de desarrollo mucho más elegante que la alternativa. Su base de usuarios es su alma, y ​​sin ellos, una API es fundamentalmente inútil. Asegurarse de que los datos sigan siendo compatibles independientemente de la revisión puede agregar algo de hinchazón, pero el seguimiento inteligente de los tipos de datos que se utilizan puede llevar a una reducción del tamaño de la API a largo plazo.

Por supuesto, hay un argumento para descentralizar estos datos. Si una API tiene problemas con el tipo de datos de una revisión a otra, la creación de una API de "enrutamiento" central también es posiblemente una gran solución. Si bien esto agrega otro servicio a la combinación y posiblemente podría crear un punto de estrangulamiento en el flujo de datos, descargar el manejo de datos a una aplicación central que puede enrutar y convertir datos independientemente del origen es una gran solución.

Al eliminar puntos finales, tenga en cuenta estas prácticas recomendadas y defectos de retiro de API

Apoyar una función, no una red

Sin embargo, muchos de estos errores surgen de una falla en el punto de vista más que de una falla en la arquitectura. Demasiados desarrolladores segmentan innecesariamente su API en una colección de microservicios cuando su funcionalidad realmente no lo justifica. Esto termina creando una red de aplicaciones que exigen atención para garantizar que múltiples productos puedan usar cada API, y que cada API esté actualizada y sea compatible.

Sin embargo, no todas las API necesitan esto. Imagina una API de bloc de notas, donde puedes apuntar algunas ideas básicas. ¿Realmente necesitamos una API para cambiar el color del lápiz, una API para revisar la ortografía, una API para guardar el archivo y una API para compartir el archivo? Parte de esa funcionalidad es un puñado de líneas de código, entonces, ¿por qué necesitamos segmentar innecesariamente la funcionalidad en una red?

Esto también se convierte en una pesadilla durante un desarrollo significativo. ¿Desea enviar revisiones beta a cada variación del usuario, a cada función como API? Donde te detienes

Dejemos esto muy claro: debe admitir una función, no una red . Todo lo que haga en el espacio, el formato, la organización y la arquitectura de su API debe ser para mejorar la función que su API está diseñada para realizar. Si esto toma el formato de una red, entonces que así sea, pero simplificar a una función en lugar de una red puede eliminar muchos de esos problemas.

Relacionado: Cómo controlar la identidad del usuario dentro de microservicios

Cuando tiene que admitir una red

Sin embargo, no todas las situaciones pueden simplificarse tanto. A veces hay que admitir una red y no una función. En estos casos, la gestión simple de la planificación y el desarrollo contribuye en gran medida a eliminar estos problemas.

Suponga que tiene varios productos que comparten algunos servicios y luego algunos productos específicos que utilizan solo uno o dos de estos servicios y no tocan los compartidos. La implementación de una versión beta de estos productos o servicios puede ser una tarea ardua, dados los problemas de compatibilidad, la reutilización de servicios anteriores mientras se lanzan nuevos y el manejo de esta comunicación de alto nivel.

¿Cómo lo hace un proveedor de manera eficaz? Como casi todo, la organización te hará libre. Planifique sus revisiones y garantice la compatibilidad en un entorno interno. Integre el soporte heredado donde sea necesario y cree una "capa de compatibilidad" dentro de aplicaciones específicas en las que sepa que las llamadas a las funciones básicas del usuario son muy diferentes de las nuevas funciones y llamadas.

El problema del control de versiones no es alterar drásticamente su base de usuarios desde el principio, sino llevarlos lentamente a nuevas versiones. Querer cambiar todo de una vez es una búsqueda noble, pero que rompe y segmenta a su comunidad.

Si bien puede centralizar el manejo de datos para eliminar las limitaciones beta del usuario, el hecho es que la mayoría de los problemas que surgen en la entrega de microservicios son de enfoque, más que de limitaciones técnicas.

Otra solución: envoltorios y contenedores

Existe otra solución, y una que este autor considera la “mejor” de las aquí presentadas. Adoptar envoltorios y contenedores en lugar de simplificar la funcionalidad a través de la segmentación es quizás la solución más clara, si no la más fácil, posible.

El concepto general detrás de un contenedor es envolver la base del código con un contenedor simple que establece una interfaz constante e invariable para el usuario y la convierte al formato necesario. Un ejemplo de esto es GraphQL , un contenedor REST que recopila varios puntos finales en un punto final de entrada singular.

Funcionalmente, esto significa que la aplicación en cuestión solo necesita comunicarse con el servidor para conocer las limitaciones en el tipo, formato y estructura de los datos. El manejo de datos está completamente fuera de las manos de la aplicación local y, en cambio, es manejado y dictado por el servidor que maneja los datos.

Asimismo, el concepto del método contenedor es contener servicios similares y sus activos requeridos en un paquete singular. Un sistema como la solución de contenedor de Docker puede empaquetar dependencias y funcionalidades en un solo servicio; esto es increíblemente importante para garantizar la compatibilidad, ya que el servicio de compatibilidad o la capa se pueden empaquetar con las nuevas versiones de la aplicación para garantizar la compatibilidad cruzada con facilidad. .

Conclusión

Los problemas de compatibilidad cruzada, funcionalidad de revisión y entrega continua no son una limitación técnica, sino una limitación de enfoque. Al garantizar el soporte heredado entre versiones de la misma aplicación y descargar gran parte del manejo de datos lejos del usuario, puede garantizar la compatibilidad con poco impacto en el usuario.

Cualquiera de las soluciones aquí podría funcionar, aunque el formato de envoltorio y contenedor es probablemente el más efectivo para la mayoría de las situaciones. Una vez que un proveedor de API decide brindar este soporte a largo plazo, las soluciones simples como estas contribuirán en gran medida a garantizar que el manejo de la entrega continua de microservicios sea lo más simple e indoloro posible.

Publicar un comentario

0 Comentarios