Hola, Habr! Us presento a la vostra atenció traducció de l'autor de l'article .
En un moment en què el món de les TI s'està avançant gradualment cap a microserveis i eines com Kubernetes, només un problema es fa cada cop més evident. Aquest problema - versions de microservei. Tot i així, la comunitat informàtica creu que la situació actual és molt millor tecnologia de la generació anterior. Tanmateix, la versió de microserveis és un problema molt complex. Una prova d'això poden ser articles com .
Si encara no entens el problema llegint aquest text, deixa'm explicar-ho. Suposem que el vostre producte consta de 10 microserveis. Ara suposem que s'allibera 1 versió nova per a cadascun d'aquests microserveis. Només 1 versió: espero que tots estiguem d'acord que aquest és un fet molt trivial i insignificant. Ara, però, fem una altra ullada al nostre producte. Amb només una versió nova de cada component, ara tenim 2^10 - o 1024 permutacions de com es pot compondre el nostre producte.
Si encara hi ha algun malentès, deixeu-me desglossar les matemàtiques. Així doncs, tenim 10 microserveis, cadascun rebent una actualització. És a dir, obtenim 2 versions possibles per a cada microservei (antic o nou). Ara, per a cadascun dels components del producte, podem utilitzar qualsevol d'aquestes dues versions. Matemàticament, és el mateix que si tinguéssim un nombre binari de 10 dígits. Per exemple, suposem que 1 és la versió nova i 0 és la versió antiga, llavors una possible permutació es pot indicar com 1001000000, on s'actualitzen els components 1r i 4t, i tots els altres no. Per les matemàtiques sabem que un nombre binari de 10 dígits pot tenir 2^10 o 1024 valors. És a dir, hem confirmat l'escala del nombre que estem tractant.
Continuem amb el nostre raonament: què passarà si tenim 100 microserveis i cadascun té 10 versions possibles? Tota la situació esdevé força desagradable -ara tenim 10^100 permutacions-, que és un nombre enorme. No obstant això, prefereixo titllar aquesta situació d'aquesta manera, perquè ara ja no ens amaguem darrere de paraules com "kubernetes", sinó que enfrontem el problema tal com és.
Per què estic tan fascinat per aquest problema? En part perquè, després d'haver treballat anteriorment al món de la PNL i la IA, vam discutir molt sobre el problema de l'explosió combinatòria fa uns 5-6 anys. Només en lloc de versions teníem paraules individuals, i en lloc de productes teníem frases i paràgrafs. I encara que els problemes de la PNL i la IA segueixen en gran part sense resoldre, cal admetre que s'han fet avenços significatius durant els darrers anys. (al meu entendre, es podria avançarоSeria millor que la gent del sector prestés una mica menys d'atenció a l'aprenentatge automàtic i una mica més a altres tècniques, però això ja està fora del tema).
Tornem al món de DevOps i microserveis. Ens trobem davant d'un problema enorme, disfressar-nos d'elefant a la Kunstkamera, perquè el que escolto sovint és "només agafa kubernetes i timó, i tot anirà bé!" Però no, no tot anirà bé si tot es deixa tal com està. A més, una solució analítica a aquest problema no sembla acceptable per la seva complexitat. Com en la PNL, primer hauríem d'abordar aquest problema reduint l'abast de la cerca, en aquest cas, eliminant les permutacions obsoletes.
Una de les coses que podria ajudar és una cosa que vaig escriure l'any passat . També és important tenir en compte que un procés CI/CD ben dissenyat ajuda molt a reduir les variacions. Tanmateix, l'estat actual de les coses amb CI/CD no és prou bo per resoldre el problema de les permutacions sense eines addicionals per als components de comptabilitat i seguiment.
El que necessitem és un sistema d'experimentació en l'etapa d'integració, on puguem determinar el factor de risc de cada component, i també disposar d'un procés automatitzat d'actualització de diversos components i proves sense intervenció de l'operador -per veure què funciona i què no.
Aquest sistema d'experiments podria semblar així:
- Els desenvolupadors escriuen proves (aquesta és una etapa crítica, perquè en cas contrari no tenim criteri d'avaluació, és com etiquetar dades en l'aprenentatge automàtic).
- Cada component (projecte) rep el seu propi sistema CI; aquest procés ara està ben desenvolupat i el problema de crear un sistema CI per a un sol component s'ha resolt en gran mesura.
- El "sistema d'integració intel·ligent" recull els resultats de diversos sistemes CI i reuneix projectes de components en el producte final, realitza proves i finalment calcula el camí més curt per obtenir la funcionalitat del producte desitjada en funció dels components i factors de risc existents. Si no és possible una actualització, aquest sistema notifica als desenvolupadors els components existents i quin d'ells està causant l'error. Una vegada més, el sistema de proves és d'una importància crítica aquí, ja que el sistema d'integració utilitza proves com a criteri d'avaluació.
- sistema de CD, que després rep dades del sistema d'integració intel·ligent i realitza l'actualització directament. Aquesta etapa acaba el cicle.
En resum, per a mi un dels problemes més grans ara és la manca d'aquest "Sistema d'integració intel·ligent" que vinculés els diferents components en un producte i així us permeti fer un seguiment de com s'ajunta el producte en conjunt. M'interessarà les opinions de la comunitat sobre això (spoiler: actualment estic treballant en un projecte , que pot esdevenir un sistema d'integració tan intel·ligent).
Una darrera cosa que vull esmentar és que, per a mi, un monòlit no és acceptable per a cap projecte de mida mitjana. Per a mi, els intents d'accelerar el temps d'implementació i la qualitat del desenvolupament tornant a un monòlit provoquen un gran escepticisme. En primer lloc, un monòlit té un problema similar a la gestió dels components: entre les diverses biblioteques de les quals es compon, tot això no es nota tant i es manifesta principalment en el temps que dediquen els desenvolupadors. La conseqüència del problema del monòlit és la virtual impossibilitat de fer canvis al codi i una velocitat de desenvolupament extremadament lenta.
Els microserveis milloren la situació, però després l'arquitectura de microserveis s'enfronta al problema de l'explosió combinatòria en l'etapa d'integració. Sí, en general, hem traslladat el mateix problema de l'etapa de desenvolupament a l'etapa d'integració. Tanmateix, al meu entendre, l'enfocament dels microserveis encara condueix a millors resultats i els equips aconsegueixen resultats més ràpidament (probablement principalment a causa de la reducció de la mida de la unitat de desenvolupament, o Mida del lot). Tanmateix, passar del monòlit als microserveis encara no ha millorat prou el procés: l'explosió combinatòria de versions de microserveis és un gran problema i tenim molt de potencial per millorar la situació a mesura que la solucionem.
Font: www.habr.com