Hallo, Habr! Ik presenteer onder uw aandacht vertaling van het artikel door de auteur .
In een tijd waarin de IT-wereld geleidelijk richting microservices en tools als Kubernetes beweegt, wordt slechts één probleem steeds duidelijker zichtbaar. Dit probleem - microservice-versies. Toch is de IT-gemeenschap van mening dat de huidige situatie veel beter is dan de huidige situatie vorige generatie technologieën. Versiebeheer van microservices is echter een zeer complex probleem. Een bewijs hiervan kunnen artikelen zijn zoals .
Als je het probleem nog steeds niet begrijpt door deze tekst te lezen, laat het me dan uitleggen. Stel dat uw product uit 10 microservices bestaat. Laten we nu aannemen dat er voor elk van deze microservices 1 nieuwe versie wordt uitgebracht. Slechts 1 versie - ik hoop dat we het er allemaal over eens zijn dat dit een heel triviaal en onbeduidend feit is. Laten we nu echter nog eens naar ons product kijken. Met slechts één nieuwe versie van elk onderdeel hebben we nu 2^10 - of 1024 permutaties van hoe ons product kan worden samengesteld.
Als er nog steeds sprake is van een misverstand, laat me dan de wiskunde opsplitsen. We hebben dus 10 microservices, die elk één update ontvangen. Dat wil zeggen dat we voor elke microservice twee mogelijke versies krijgen (oud of nieuw). Nu kunnen we voor elk van de productcomponenten een van deze twee versies gebruiken. Wiskundig gezien is het hetzelfde alsof we een binair getal van 2 cijfers zouden hebben. Laten we bijvoorbeeld zeggen dat 10 de nieuwe versie is, en 1 de oude versie - dan kan een mogelijke permutatie worden aangeduid als 0 - waarbij de eerste en vierde component worden bijgewerkt, en alle andere niet. Uit de wiskunde weten we dat een binair getal van 1001000000 cijfers 1^4 of 10 waarden kan hebben. Dat wil zeggen, we hebben de omvang van het aantal waarmee we te maken hebben bevestigd.
Laten we onze redenering verder voortzetten: wat zal er gebeuren als we 100 microservices hebben en elk 10 mogelijke versies heeft? De hele situatie wordt behoorlijk onaangenaam - we hebben nu 10^100 permutaties - wat een enorm aantal is. Ik geef er echter de voorkeur aan om deze situatie op deze manier te bestempelen, omdat we ons nu niet langer verschuilen achter woorden als ‘kubernetes’, maar het probleem onder ogen zien zoals het is.
Waarom ben ik zo gefascineerd door dit probleem? Gedeeltelijk omdat we, nadat we eerder in de wereld van NLP en AI hadden gewerkt, ongeveer 5-6 jaar geleden veel spraken over het probleem van combinatorische explosie. Alleen in plaats van versies hadden we individuele woorden, en in plaats van producten hadden we zinnen en paragrafen. En hoewel de problemen van NLP en AI grotendeels onopgelost blijven, moet worden toegegeven dat er de afgelopen jaren aanzienlijke vooruitgang is geboekt (naar mijn mening kan er vooruitgang worden geboektоHet zou beter zijn als mensen in de industrie wat minder aandacht zouden besteden aan machinaal leren en wat meer aan andere technieken (maar dit is al off-topic).
Laten we terugkeren naar de wereld van DevOps en microservices. We worden geconfronteerd met een enorm probleem, vermomd als olifant in de Kunstkamera - want wat ik vaak hoor is: "Neem gewoon de kubernetes en het roer, en alles komt goed!" Maar nee, alles komt niet goed als alles blijft zoals het is. Bovendien lijkt een analytische oplossing voor dit probleem vanwege de complexiteit ervan niet aanvaardbaar. Net als bij NLP moeten we dit probleem eerst aanpakken door de zoekreikwijdte te verkleinen – in dit geval door verouderde permutaties te elimineren.
Een van de dingen die kunnen helpen, is iets dat ik vorig jaar heb geschreven . Het is ook belangrijk op te merken dat een goed ontworpen CI/CD-proces enorm helpt bij het verminderen van variaties. De huidige stand van zaken met CI/CD is echter niet goed genoeg om het probleem van permutaties op te lossen zonder aanvullende hulpmiddelen voor boekhoud- en trackingcomponenten.
Wat we nodig hebben is een experimenteersysteem in de integratiefase, waarin we de risicofactor voor elk onderdeel kunnen bepalen, en ook kunnen beschikken over een geautomatiseerd proces voor het bijwerken van verschillende onderdelen en testen zonder tussenkomst van een operator - om te zien wat werkt en wat niet.
Een dergelijk systeem van experimenten zou er als volgt uit kunnen zien:
- Ontwikkelaars schrijven tests (dit is een cruciale fase - omdat we anders geen evaluatiecriterium hebben - het is net zoiets als het labelen van gegevens bij machinaal leren).
- Elk onderdeel (project) krijgt zijn eigen CI-systeem - dit proces is nu goed ontwikkeld en het probleem van het creëren van een CI-systeem voor een enkel onderdeel is grotendeels opgelost
- Het ‘slimme integratiesysteem’ verzamelt de resultaten van verschillende CI-systemen en voegt componentprojecten samen tot het eindproduct, voert tests uit en berekent uiteindelijk de kortste weg naar het verkrijgen van de gewenste productfunctionaliteit op basis van bestaande componenten en risicofactoren. Als een update niet mogelijk is, informeert dit systeem ontwikkelaars over de bestaande componenten en welke daarvan de fout veroorzaakt. Opnieuw is het testsysteem hier van cruciaal belang, aangezien het integratiesysteem tests als evaluatiecriterium gebruikt.
- CD-systeem, dat vervolgens gegevens ontvangt van het Smart Integration System en de update direct uitvoert. Deze fase beëindigt de cyclus.
Samenvattend: een van de grootste problemen op dit moment is voor mij het ontbreken van zo’n “Slim Integratiesysteem” dat de verschillende componenten tot een product zou verbinden en je zo in staat zou stellen te volgen hoe het product als geheel in elkaar zit. Ik ben geïnteresseerd in de gedachten van de gemeenschap hierover (spoiler - ik werk momenteel aan een project , wat zo’n slim integratiesysteem kan worden).
Een laatste ding dat ik wil vermelden is dat een monoliet voor mij niet acceptabel is voor welk project dan ook, zelfs niet van gemiddelde omvang. Voor mij veroorzaken pogingen om de implementatietijd en de kwaliteit van de ontwikkeling te versnellen door terug te keren naar een monoliet grote scepsis. Ten eerste heeft een monoliet een soortgelijk probleem bij het beheren van componenten - onder de verschillende bibliotheken waaruit het bestaat, valt dit alles echter niet zo op en manifesteert het zich vooral in de tijd die ontwikkelaars besteden. Het gevolg van het monolietprobleem is de vrijwel onmogelijkheid om wijzigingen in de code aan te brengen - en een extreem lage ontwikkelingssnelheid.
Microservices verbeteren de situatie, maar dan wordt de microservicearchitectuur geconfronteerd met het probleem van combinatorische explosie in de integratiefase. Ja, over het algemeen hebben we hetzelfde probleem van de ontwikkelingsfase naar de integratiefase verplaatst. Naar mijn mening leidt de microservices-aanpak echter nog steeds tot betere resultaten, en bereiken teams sneller resultaten (waarschijnlijk vooral als gevolg van de verkleining van de omvang van de ontwikkelingseenheid – of seriegrootte). De overstap van monoliet naar microservices heeft het proces echter nog niet voldoende verbeterd: de combinatorische explosie van microserviceversies is een enorm probleem, en we hebben veel potentieel om de situatie te verbeteren terwijl we deze oplossen.
Bron: www.habr.com