Ola, Habr! Presento á súa atención tradución do artigo do autor .
Nun momento no que o mundo das TI se está movendo aos poucos cara a microservizos e ferramentas como Kubernetes, só un problema é cada vez máis perceptible. Este problema - versións de microservizos. Aínda así, a comunidade informática cre que a situación actual é moito mellor que tecnoloxía anterior da xeración. Non obstante, a versión de microservizos é un problema moi complexo. Unha proba diso poden ser artigos como .
Se aínda non entendes o problema ao ler este texto, déixame explicar. Digamos que o teu produto consta de 10 microservizos. Agora supoñamos que se publica 1 nova versión para cada un destes microservizos. Só 1 versión: espero que todos esteamos de acordo en que este é un feito moi trivial e insignificante. Agora, con todo, imos dar outra ollada ao noso produto. Con só unha nova versión de cada compoñente, agora temos 2^10 - ou 1024 permutacións de como se pode composto o noso produto.
Se aínda hai algún malentendido, déixeme desglosar as matemáticas. Polo tanto, temos 10 microservizos, cada un dos que recibe unha actualización. É dicir, obtemos 2 versións posibles para cada microservizo (antigo ou novo). Agora, para cada un dos compoñentes do produto, podemos usar calquera destas dúas versións. Matemáticamente, é o mesmo que se tivésemos un número binario de 10 díxitos. Por exemplo, digamos que 1 é a nova versión e 0 é a versión antiga, entón unha posible permutación pódese indicar como 1001000000, onde se actualizan os compoñentes 1 e 4 e non todos os demais. Polas matemáticas sabemos que un número binario de 10 díxitos pode ter 2^10 ou 1024 valores. É dicir, confirmamos a escala do número que estamos a tratar.
Continuemos co noso razoamento: que pasará se temos 100 microservizos e cada un ten 10 versións posibles? Toda a situación vólvese bastante desagradable - agora temos 10 ^ 100 permutacións - que é un número enorme. Porén, prefiro etiquetar esta situación así, porque agora xa non nos agochamos detrás de palabras como “kubernetes”, senón que nos enfrontamos ao problema tal e como está.
Por que estou tan fascinado con este problema? En parte porque, despois de traballar anteriormente no mundo da PNL e da IA, discutimos moito o problema da explosión combinatoria hai uns 5-6 anos. Só en lugar de versións tiñamos palabras individuais, e en lugar de produtos tiñamos frases e parágrafos. E aínda que os problemas da PNL e da intelixencia artificial seguen en gran parte sen resolver, hai que admitir que se produciron importantes avances nos últimos anos. (Na miña opinión, poderíase avanzarоSería mellor que a xente do sector prestase un pouco menos de atención á aprendizaxe automática e un pouco máis a outras técnicas, pero isto xa está fóra do tema.
Volvemos ao mundo de DevOps e microservizos. Enfrontámonos a un problema enorme, disfrazarnos de elefante na Kunstkamera, porque o que escoito a miúdo é "simplemente toma kubernetes e timón, e todo estará ben!" Pero non, non todo estará ben se todo se deixa como está. Ademais, unha solución analítica a este problema non parece aceptable pola súa complexidade. Do mesmo xeito que na PNL, primeiro debemos abordar este problema reducindo o alcance da busca, neste caso, eliminando as permutacións obsoletas.
Unha das cousas que pode axudar é algo que escribín o ano pasado . Tamén é importante ter en conta que un proceso CI/CD ben deseñado axuda moito a reducir a variación. Non obstante, o estado actual de cousas con CI/CD non é o suficientemente bo para resolver o problema das permutacións sen ferramentas adicionais para os compoñentes de contabilidade e seguimento.
O que necesitamos é un sistema de experimentación na fase de integración, onde poidamos determinar o factor de risco para cada compoñente, e tamén dispor dun proceso automatizado de actualización de varios compoñentes e probas sen intervención do operador, para ver o que funciona e o que non.
Tal sistema de experimentos podería verse así:
- Os desenvolvedores escriben probas (esta é unha etapa crítica, porque se non, non temos un criterio de avaliación, é como etiquetar os datos na aprendizaxe automática).
- Cada compoñente (proxecto) recibe o seu propio sistema de CI - este proceso agora está ben desenvolvido e o problema de crear un sistema de CI para un só compoñente resolveuse en gran medida.
- O "sistema de integración intelixente" recolle os resultados de varios sistemas de CI e ensambla proxectos de compoñentes no produto final, realiza probas e, finalmente, calcula o camiño máis curto para obter a funcionalidade do produto desexada en función dos compoñentes existentes e dos factores de risco. Se unha actualización non é posible, este sistema notifica aos desenvolvedores sobre os compoñentes existentes e cal deles está a provocar o erro. Unha vez máis, o sistema de probas ten unha importancia crítica aquí, xa que o sistema de integración utiliza probas como criterio de avaliación.
- sistema de CD, que despois recibe datos do Smart Integration System e realiza a actualización directamente. Esta etapa remata o ciclo.
En resumo, para min un dos maiores problemas agora é a falta de tal "Sistema de integración intelixente" que vincule os distintos compoñentes nun produto e permita, así, facer un seguimento de como se ensambla o produto no seu conxunto. Estarei interesado nos pensamentos da comunidade sobre isto (spoiler: estou traballando nun proxecto , que pode converterse nun sistema de integración tan intelixente).
Unha última cousa que quero mencionar é que, para min, un monólito non é aceptable para ningún proxecto de tamaño medio. Para min, os intentos de acelerar o tempo de implementación e a calidade do desenvolvemento volvendo a un monólito provocan un gran escepticismo. En primeiro lugar, un monólito ten un problema similar de xestión de compoñentes: entre as diversas bibliotecas que está formada, todo isto non se nota tanto e maniféstase principalmente no tempo que pasan os desenvolvedores. A consecuencia do problema do monólito é a virtual imposibilidade de facer cambios no código e unha velocidade de desenvolvemento extremadamente lenta.
Os microservizos melloran a situación, pero entón a arquitectura de microservizos enfróntase ao problema da explosión combinatoria na fase de integración. Si, en xeral, trasladamos o mesmo problema da fase de desenvolvemento á fase de integración. Non obstante, na miña opinión, o enfoque dos microservizos aínda leva a mellores resultados e os equipos conseguen resultados máis rápido (probablemente debido principalmente á redución do tamaño da unidade de desenvolvemento, ou tamaño do lote). Non obstante, o paso do monolito aos microservizos aínda non mellorou o proceso o suficiente: a explosión combinatoria de versións de microservizos é un gran problema e temos moito potencial para mellorar a situación mentres a solucionamos.
Fonte: www.habr.com