Hei, Habr! Esitän huomionne kirjoittajan käännös artikkelista .
Aikana, jolloin IT-maailma on vähitellen siirtymässä kohti mikropalveluita ja Kubernetesin kaltaisia työkaluja, vain yksi ongelma on tulossa yhä selvemmäksi. Tämä ongelma - mikropalveluversiot. Silti IT-yhteisö uskoo, että nykyinen tilanne on paljon parempi kuin edellisen sukupolven teknologioita. Mikropalvelujen versiointi on kuitenkin hyvin monimutkainen ongelma. Yksi todiste tästä voivat olla esimerkiksi artikkelit .
Jos et vieläkään ymmärrä ongelmaa lukemalla tämän tekstin, anna minun selittää. Oletetaan, että tuotteesi koostuu 10 mikropalvelusta. Oletetaan nyt, että jokaiselle näistä mikropalveluista on julkaistu yksi uusi versio. Vain yksi versio - toivottavasti voimme kaikki olla yhtä mieltä siitä, että tämä on hyvin triviaali ja merkityksetön tosiasia. Katsotaanpa nyt kuitenkin tuotettamme uudelleen. Vain yhdellä uudella versiolla kustakin komponentista meillä on nyt 1^1 - tai 2 permutaatiota siitä, miten tuotteemme voidaan muodostaa.
Jos on vielä väärinkäsityksiä, anna minun purkaa matematiikka. Meillä on siis 10 mikropalvelua, joista jokainen saa yhden päivityksen. Eli saamme 2 mahdollista versiota jokaiselle mikropalvelulle (joko vanhalle tai uudelle). Nyt voimme käyttää jokaiselle tuotteen komponentille jompaa kumpaa näistä kahdesta versiosta. Matemaattisesti se on sama kuin jos meillä olisi 10 numeron binääriluku. Oletetaan esimerkiksi, että 1 on uusi versio ja 0 on vanha versio - silloin yksi mahdollinen permutaatio voidaan merkitä 1001000000 - jossa 1. ja 4. komponentit päivitetään, mutta kaikki muut eivät. Matematiikasta tiedämme, että 10-numeroisella binääriluvulla voi olla 2^10 tai 1024 arvoa. Toisin sanoen olemme vahvistaneet käsittelemämme numeron laajuuden.
Jatketaan pohdintaa edelleen - mitä tapahtuu, jos meillä on 100 mikropalvelua ja jokaisessa on 10 mahdollista versiota? Koko tilanteesta tulee melko epämiellyttävä - meillä on nyt 10^100 permutaatiota - mikä on valtava määrä. Haluan kuitenkin leimata tämän tilanteen mieluummin tällä tavalla, koska nyt emme enää piiloudu sanojen "kubernetes" taakse, vaan kohtaamme ongelman sellaisena kuin se on.
Miksi tämä ongelma kiehtoo minua niin paljon? Osittain siksi, että olemme aiemmin työskennelleet NLP:n ja tekoälyn maailmassa, ja keskustelimme kombinatorisen räjähdyksen ongelmasta paljon noin 5-6 vuotta sitten. Vain versioiden sijasta meillä oli yksittäisiä sanoja ja tuotteiden sijaan lauseita ja kappaleita. Ja vaikka NLP:n ja tekoälyn ongelmat ovat suurelta osin ratkaisematta, on myönnettävä, että viime vuosina on tapahtunut merkittävää edistystä. (Mielestäni edistystä voisi tapahtuaоOlisi parempi, jos alan ihmiset kiinnittäisivät vähän vähemmän huomiota koneoppimiseen ja vähän enemmän muihin tekniikoihin - mutta tämä on jo off-topic).
Palataan DevOpsin ja mikropalvelujen maailmaan. Edessämme on valtava ongelma, naamioituessamme elefantiksi Taidekamerassa - koska kuulen usein olevan "ota vain kubernetes ja ruori, niin kaikki on hyvin!" Mutta ei, kaikki ei ole hyvin, jos kaikki jätetään ennalleen. Lisäksi analyyttinen ratkaisu tähän ongelmaan ei vaikuta hyväksyttävältä sen monimutkaisuuden vuoksi. Kuten NLP:ssä, meidän pitäisi ensin lähestyä tätä ongelmaa kaventämällä hakualuetta – tässä tapauksessa poistamalla vanhentuneet permutaatiot.
Yksi asia, joka saattaa auttaa, on viime vuonna kirjoittamani asia . On myös tärkeää huomata, että hyvin suunniteltu CI/CD-prosessi auttaa suuresti vähentämään vaihteluita. CI/CD:n nykyinen tilanne ei kuitenkaan ole riittävän hyvä ratkaisemaan permutaatioongelmaa ilman lisätyökaluja laskenta- ja seurantakomponenteille.
Tarvitsemme integraatiovaiheessa kokeilujärjestelmän, jossa voimme määrittää kunkin komponentin riskitekijän, ja lisäksi meillä on automatisoitu prosessi eri komponenttien päivittämiseen ja testaamiseen ilman käyttäjän väliintuloa - nähdäksemme mikä toimii ja mikä ei.
Tällainen koejärjestelmä voisi näyttää tältä:
- Kehittäjät kirjoittavat testejä (tämä on kriittinen vaihe - koska muuten meillä ei ole arviointikriteeriä - se on kuin tietojen merkitsemistä koneoppimisessa).
- Jokainen komponentti (projekti) saa oman CI-järjestelmänsä - tämä prosessi on nyt hyvin kehittynyt, ja ongelma CI-järjestelmän luomisesta yhdelle komponentille on suurelta osin ratkaistu
- "Älykäs integraatiojärjestelmä" kerää erilaisten CI-järjestelmien tulokset ja kokoaa komponenttiprojektit lopputuotteeksi, suorittaa testauksen ja laskee lopuksi lyhimmän reitin halutun tuotteen toiminnallisuuden saavuttamiseen olemassa olevien komponenttien ja riskitekijöiden perusteella. Jos päivitys ei ole mahdollista, tämä järjestelmä ilmoittaa kehittäjille olemassa olevista komponenteista ja siitä, mikä niistä aiheuttaa virheen. Tässäkin testijärjestelmällä on kriittinen merkitys - koska integraatiojärjestelmä käyttää testejä arviointikriteerinä.
- CD-järjestelmä, joka vastaanottaa tiedot Smart Integration System -järjestelmästä ja suorittaa päivityksen suoraan. Tämä vaihe päättää syklin.
Yhteenvetona voidaan todeta, että yksi suurimmista ongelmista minulle nyt on sellaisen "Älykkään integraatiojärjestelmän" puute, joka yhdistäisi eri komponentit tuotteeksi ja mahdollistaisi siten tuotteen kokonaisuuden koottamisen seuraamisen. Olen kiinnostunut yhteisön ajatuksista tästä (spoileri - työskentelen parhaillaan projektin parissa , josta voi tulla niin älykäs integrointijärjestelmä).
Viimeinen asia, jonka haluan mainita, on se, että minun mielestäni monoliitti ei ole hyväksyttävä missään edes keskikokoisessa projektissa. Minussa yritykset nopeuttaa toteutusaikaa ja kehityksen laatua palaamalla monoliittiin herättävät suurta skeptisyyttä. Ensinnäkin monoliitilla on samanlainen ongelma komponenttien hallinnassa - eri kirjastojen joukossa, joista se koostuu, kaikki tämä ei kuitenkaan ole niin havaittavissa ja ilmenee ensisijaisesti kehittäjien käyttämässä ajassa. Monoliittiongelman seurauksena on virtuaalinen mahdottomuus tehdä muutoksia koodiin - ja erittäin hidas kehitysnopeus.
Mikropalvelut parantavat tilannetta, mutta sitten mikropalveluarkkitehtuuri kohtaa integraatiovaiheessa kombinatorisen räjähdyksen ongelman. Kyllä, yleisesti ottaen olemme siirtäneet saman ongelman kehitysvaiheesta integraatiovaiheeseen. Kuitenkin mielestäni mikropalvelulähestymistapa johtaa silti parempiin tuloksiin ja tiimit saavuttavat tuloksia nopeammin (luultavasti lähinnä kehitysyksikön koon pienentymisen vuoksi - tai erän koko). Siirtyminen monoliitista mikropalveluihin ei kuitenkaan ole vielä tuonut tarpeeksi parannusta prosessiin - mikropalveluversioiden kombinatorinen räjähdys on valtava ongelma, ja meillä on paljon potentiaalia parantaa tilannetta sitä ratkaisemalla.
Lähde: will.com
