Microservicios - explosión combinatoria de versiones

Hola Habr! Les presento la traducción del autor del artículo Microservicios - Explosión combinatoria de versiones .

En un momento en que el mundo de TI se está moviendo gradualmente a microservicios y herramientas como Kubernetes, solo un problema es cada vez más notable. Este problema es una explosión combinatoria de versiones de microservicio. Sin embargo, la comunidad de TI cree que la situación actual es mucho mejor que el infierno de la dependencia de la generación anterior de tecnologías. Sin embargo, el control de versiones de microservicios es un problema muy complejo. Una de las pruebas de esto se puede encontrar en artículos como "Devuélvame mi monolito" .

Si está leyendo este texto y aún no comprende el problema, déjeme explicarlo. Supongamos que su producto consta de 10 microservicios. Ahora suponga que para cada uno de estos microservicios se lanza una nueva versión. Solo la versión 1 - Espero que todos podamos estar de acuerdo en que este es un hecho muy trivial e insignificante. Ahora, sin embargo, eche un vistazo a nuestro producto nuevamente. Con solo una nueva versión de cada componente, ahora tenemos 2 ^ 10 - o 1024 permutaciones de cómo se puede componer nuestro producto.

Si todavía hay algún malentendido, permítanme expandir las matemáticas. Entonces, tenemos 10 microservicios, cada uno recibe una actualización. Es decir, obtenemos 2 versiones posibles para cada microservicio (antiguo o nuevo). Ahora, para cada uno de los componentes del producto, podemos usar cualquiera de estas dos versiones. Matemáticamente, esto es lo mismo que si tuviéramos un número binario de 10 caracteres. Por ejemplo, supongamos que 1 es la nueva versión y 0 es la versión anterior; luego, una posible permutación puede designarse como 1001000000, donde los componentes primero y cuarto se actualizan, pero el resto no. Por matemática, sabemos que un número binario de 10 caracteres puede tener 2 ^ 10 o 1024 valores. Es decir, hemos confirmado la escala del número con el que está tratando.

Continuamos la discusión más allá, ¿y qué sucede si tenemos 100 microservicios y cada uno tiene 10 versiones posibles? Toda la situación se está volviendo muy desagradable, ahora tenemos 10 ^ 100 permutaciones, y este es un número enorme. Sin embargo, prefiero describir esta situación así, porque ahora no nos estamos escondiendo detrás de palabras como "kubernetes", sino que estamos encontrando el problema tal como es.

¿Por qué es este problema tan fascinante para mí? En parte porque trabajando antes en el mundo de la PNL y la IA, discutimos mucho sobre el problema de la explosión combinatoria hace unos 5-6 años. Solo en lugar de versiones teníamos palabras separadas, y en lugar de productos teníamos oraciones y párrafos. Aunque los problemas de la PNL y la IA siguen sin resolverse, debemos admitir que se han logrado avances significativos en los últimos años.(desde mi punto de vista, el progreso podría usarse para mejorar si la gente de la industria prestara un poco menos atención al aprendizaje automático y otras técnicas un poco más, pero esto está fuera de tema).

Regresaré al mundo de DevOps y microservicios. Nos enfrentamos a un gran problema, disfrazado de elefante en la Kunstkamera, porque lo que a menudo escucho es "¡solo toma kubernetes y timón, y todo estará bien!" Pero no, no todo estará bien si todo se deja como está. Además, una solución analítica a este problema no parece aceptable en vista de la complejidad. Al igual que en PNL, primero debemos abordar este problema reduciendo el alcance de la búsqueda, en este caso, eliminando permutaciones obsoletas.

Una de las cosas que pueden ayudar: escribí el año pasadosobre la necesidad de mantener una distribución mínima entre las versiones diseñadas para los clientes . También es importante tener en cuenta que un proceso CI / CD bien desarrollado es muy útil para reducir las variaciones. Sin embargo, el estado actual de las cosas con CI / CD no es lo suficientemente bueno como para resolver el problema de permutación sin herramientas adicionales para grabar y rastrear componentes.

Lo que necesitamos es un sistema de experimentos en la etapa de integración, donde podamos determinar el factor de riesgo para cada componente, y también tener un proceso automatizado para actualizar varios componentes y pruebas sin intervención del operador, para ver qué funciona y qué no.

Tal sistema de experimentos podría verse así:

1. ( — — ).
2. () CI — , CI
3. « » CI - , . , . , — .
4. CD , « » . .

En resumen, para mí uno de los mayores problemas ahora es la falta de un "Sistema de integración inteligente" que vincule los diversos componentes al producto y, por lo tanto, le permita realizar un seguimiento de la composición del producto en su conjunto. Me interesarán los pensamientos de la comunidad sobre esto (spoiler: actualmente estoy trabajando en el proyecto Reliza , que podría convertirse en un sistema de integración tan inteligente).

Una última cosa que quiero mencionar es que para mí un monolito no es aceptable para ningún proyecto de al menos mediano tamaño. Para mí, existe un gran escepticismo sobre los intentos de acelerar el tiempo de implementación y la calidad del desarrollo al regresar al monolito. En primer lugar, el monolito tiene un problema similar de gestión de componentes, entre las diversas bibliotecas en las que consiste, pero todo esto no es tan notable y se manifiesta principalmente en el tiempo que pasan los desarrolladores. La consecuencia del problema del monolito es el hecho de que es imposible realizar cambios en el código, y la velocidad de desarrollo es extremadamente lenta.

Los microservicios mejoran la situación, pero la arquitectura del microservicio enfrenta el problema de una explosión combinatoria en la etapa de integración. Sí, en general, hemos trasladado el mismo problema: de la etapa de desarrollo a la etapa de integración. Sin embargo, en mi opinión, el enfoque de microservicios aún conduce a mejores resultados, y los equipos logran resultados más rápidos (probablemente principalmente debido a la reducción en el tamaño de la unidad de desarrollo, o tamaño de lote ). Sin embargo, la transición del monolito a los microservicios aún no ha proporcionado una mejora suficiente del proceso: la explosión combinatoria de versiones de microservicios es un gran problema, y ​​tenemos un gran potencial para mejorar la situación a medida que se resuelve.