¡Hola Habr! presento a su atención traducción del autor del artículo .
En un momento en que el mundo de las tecnologías de la información avanza gradualmente hacia microservicios y herramientas como Kubernetes, solo hay un problema que se hace cada vez más evidente. Este problema - Versiones de microservicios. Aún así, la comunidad de TI cree que la situación actual es mucho mejor que la generación anterior de tecnologías. Sin embargo, el control de versiones de los microservicios es un problema muy complejo. Una prueba de esto pueden ser artículos como .
Si aún no entiendes el problema al leer este texto, déjame explicarte. Digamos que su producto consta de 10 microservicios. Ahora supongamos que se lanza 1 nueva versión para cada uno de estos microservicios. Sólo 1 versión: espero que todos estemos de acuerdo en que este es un hecho muy trivial e insignificante. Ahora, sin embargo, echemos otro vistazo a nuestro producto. 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 analizar los cálculos. Entonces tenemos 10 microservicios, cada uno de los cuales recibe una actualización. Es decir, obtenemos 2 versiones posibles para cada microservicio (ya sea antigua o nueva). Ahora bien, para cada uno de los componentes del producto, podremos utilizar cualquiera de estas dos versiones. Matemáticamente es lo mismo que si tuviéramos un número binario de 10 dígitos. Por ejemplo, digamos que 1 es la nueva versión y 0 es la versión anterior; entonces una posible permutación se puede indicar como 1001000000, donde los componentes primero y cuarto se actualizan, y todos los demás no. Por las matemáticas sabemos que un número binario de 1 dígitos puede tener 4^10 o 2 valores. Es decir, hemos confirmado la magnitud del número al que nos enfrentamos.
Sigamos con nuestro razonamiento: ¿qué pasará si tenemos 100 microservicios y cada uno tiene 10 versiones posibles? Toda la situación se vuelve bastante desagradable: ahora tenemos 10^100 permutaciones, que es un número enorme. Sin embargo, prefiero etiquetar esta situación de esta manera, porque ahora ya no nos escondemos detrás de palabras como “kubernetes”, sino que enfrentamos el problema tal como es.
¿Por qué estoy tan fascinado por este problema? En parte porque, habiendo trabajado anteriormente en el mundo de la PNL y la IA, discutimos mucho el problema de la explosión combinatoria hace unos 5 o 6 años. Sólo que en lugar de versiones teníamos palabras individuales y en lugar de productos teníamos oraciones y párrafos. Y aunque los problemas de la PNL y la IA siguen en gran medida sin resolver, hay que admitir que se han logrado avances significativos en los últimos años. (en mi opinión, se podría avanzarоSería mejor si la gente de la industria prestara un poco menos de atención al aprendizaje automático y un poco más a otras técnicas, pero esto ya está fuera de tema).
Volvamos al mundo de DevOps y microservicios. Nos enfrentamos a un gran problema, disfrazados de elefante en la Kunstkamera, porque lo que escucho a menudo es "simplemente toma kubernetes y el timón, ¡y todo estará bien!". Pero no, no todo irá bien si todo se deja como está. Además, una solución analítica a este problema no parece aceptable debido a su complejidad. Al igual que en la PNL, primero deberíamos abordar este problema reduciendo el alcance de la búsqueda (en este caso, eliminando permutaciones obsoletas).
Una de las cosas que podría ayudar es algo que escribí el año pasado. . También es importante señalar que un proceso de CI/CD bien diseñado ayuda enormemente a reducir las variaciones. Sin embargo, la situación actual con CI/CD no es lo suficientemente buena para resolver el problema de las permutaciones sin herramientas adicionales para los componentes de contabilidad y seguimiento.
Lo que necesitamos es un sistema de experimentación 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 realizar pruebas sin intervención del operador, para ver qué funciona y qué no.
Un sistema de experimentos de este tipo podría verse así:
- Los desarrolladores escriben pruebas (esta es una etapa crítica, porque de lo contrario no tenemos ningún criterio de evaluación; es como etiquetar datos en el aprendizaje automático).
- Cada componente (proyecto) recibe su propio sistema de CI; este proceso ahora está bien desarrollado y la cuestión de crear un sistema de CI para un solo componente se ha resuelto en gran medida.
- El "sistema de integración inteligente" recopila los resultados de varios sistemas de CI y ensambla proyectos de componentes en el producto final, ejecuta pruebas y finalmente calcula el camino más corto para obtener la funcionalidad deseada del producto en función de los componentes existentes y los factores de riesgo. Si no es posible realizar una actualización, este sistema notifica a los desarrolladores sobre los componentes existentes y cuál de ellos está causando el error. Una vez más, el sistema de pruebas tiene aquí una importancia crítica, ya que el sistema de integración utiliza las pruebas como criterio de evaluación.
- Sistema de CD, que luego recibe datos del Smart Integration System y realiza la actualización directamente. Esta etapa finaliza el ciclo.
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 en un producto y así permita rastrear cómo se ensambla el producto en su conjunto. Me interesará la opinión de la comunidad sobre esto (spoiler: actualmente estoy trabajando en un proyecto , que puede 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, ni siquiera de tamaño mediano. Para mí, los intentos de acelerar el tiempo de implementación y la calidad del desarrollo volviendo a un monolito causan un gran escepticismo. En primer lugar, un monolito tiene un problema similar con la gestión de componentes; sin embargo, entre las diversas bibliotecas que lo componen, todo esto no es tan notable y se manifiesta principalmente en el tiempo dedicado por los desarrolladores. La consecuencia del problema del monolito es la virtual imposibilidad de realizar cambios en el código y una velocidad de desarrollo extremadamente lenta.
Los microservicios mejoran la situación, pero luego la arquitectura de microservicios se enfrenta al problema de la 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ápido (probablemente debido principalmente a la reducción del tamaño de la unidad de desarrollo, o tamaño del lote). Sin embargo, pasar del monolito a los microservicios aún no ha mejorado lo suficiente el proceso: la explosión combinatoria de versiones de microservicios es un problema enorme y tenemos un gran potencial para mejorar la situación a medida que la solucionemos.
Fuente: habr.com