Dobrý den, Habr! předkládám vaší pozornosti autorský překlad článku .
V době, kdy se IT svět postupně posouvá směrem k mikroslužbám a nástrojům jako Kubernetes, je stále více patrný pouze jeden problém. Tento problém - mikroservisní verze. Přesto se IT komunita domnívá, že současná situace je mnohem lepší než předchozí generace technologie. Verze mikroslužeb je však velmi složitý problém. Jedním z důkazů toho mohou být články jako .
Pokud při čtení tohoto textu stále nerozumíte problému, dovolte mi to vysvětlit. Řekněme, že váš produkt se skládá z 10 mikroslužeb. Nyní předpokládejme, že pro každou z těchto mikroslužeb je vydána 1 nová verze. Pouze 1 verze – doufám, že se všichni shodneme, že jde o velmi triviální a nepodstatnou skutečnost. Nyní se však na náš produkt podíváme ještě jednou. Pouze s jednou novou verzí každé komponenty máme nyní 2^10 – neboli 1024 permutací toho, jak lze náš produkt skládat.
Pokud stále dochází k nějakému nedorozumění, dovolte mi rozebrat matematiku. Máme tedy 10 mikroslužeb, z nichž každá dostává jednu aktualizaci. To znamená, že pro každou mikroslužbu (starou nebo novou) získáme 2 možné verze. Nyní pro každou komponentu produktu můžeme použít kteroukoli z těchto dvou verzí. Matematicky je to stejné, jako bychom měli binární číslo o 10 číslicích. Řekněme například, že 1 je nová verze a 0 je stará verze - pak lze jednu možnou permutaci označit jako 1001000000 - kde 1. a 4. komponenta je aktualizována a všechny ostatní ne. Z matematiky víme, že 10místné binární číslo může mít 2^10 nebo 1024 hodnot. To znamená, že jsme potvrdili měřítko čísla, se kterým se zabýváme.
Pokračujme v úvahách dále – co se stane, když budeme mít 100 mikroslužeb a každá bude mít 10 možných verzí? Celá situace se stává značně nepříjemnou – nyní máme 10^100 permutací – což je obrovské číslo. Raději však tuto situaci takto označuji, protože nyní se již neschováváme za slova jako „kubernetes“, ale spíše čelíme problému tak, jak je.
Proč mě tento problém tak fascinuje? Částečně proto, že když jsme předtím pracovali ve světě NLP a AI, asi před 5-6 lety jsme hodně diskutovali o problému kombinatorické exploze. Jen místo verzí jsme měli jednotlivá slova a místo produktů věty a odstavce. A přestože problémy NLP a AI zůstávají z velké části nevyřešeny, je třeba přiznat, že za posledních několik let bylo dosaženo významného pokroku. (podle mého názoru by se dalo dosáhnout pokrokuоBylo by lepší, kdyby lidé z branže věnovali trochu méně pozornosti strojovému učení a trochu více jiným technikám – ale to už je mimo téma).
Vraťme se do světa DevOps a mikroslužeb. Potýkáme se s obrovským problémem, maskujeme se v Kunstkameře za slona – protože často slýchávám „jen vezmi kubernetes a kormidlo a všechno bude v pořádku!“ Ale ne, všechno nebude v pořádku, pokud vše zůstane tak, jak je. Analytické řešení tohoto problému se navíc nezdá přijatelné kvůli jeho složitosti. Stejně jako v NLP bychom k tomuto problému měli nejprve přistoupit zúžením rozsahu vyhledávání – v tomto případě odstraněním zastaralých permutací.
Jedna z věcí, která by mohla pomoci, je něco, co jsem napsal minulý rok . Je také důležité poznamenat, že dobře navržený proces CI/CD výrazně pomáhá při snižování variací. Současný stav věcí s CI/CD však není dost dobrý na to, aby vyřešil problém permutací bez dalších nástrojů pro účtování a sledování komponent.
Potřebujeme systém experimentování ve fázi integrace, kde můžeme určit rizikový faktor pro každou komponentu, a také mít automatizovaný proces aktualizace různých komponent a testování bez zásahu operátora – abychom viděli, co funguje a co ne.
Takový systém experimentů by mohl vypadat takto:
- Vývojáři píší testy (toto je kritická fáze – protože jinak nemáme žádné hodnotící kritérium – je to jako označování dat ve strojovém učení).
- Každá komponenta (projekt) dostává svůj vlastní CI systém – tento proces je nyní dobře rozvinutý a otázka vytvoření CI systému pro jednu komponentu je z velké části vyřešena
- „Inteligentní integrační systém“ shromažďuje výsledky různých systémů CI a sestavuje projekty komponent do konečného produktu, provádí testování a nakonec vypočítává nejkratší cestu k získání požadované funkčnosti produktu na základě existujících komponent a rizikových faktorů. Pokud aktualizace není možná, tento systém informuje vývojáře o existujících komponentách a o tom, která z nich způsobuje chybu. Opět je zde rozhodující testovací systém, protože integrační systém používá testy jako hodnotící kritérium.
- CD systém, který následně přijímá data ze Smart Integration System a přímo provádí aktualizaci. Tato fáze ukončuje cyklus.
Abych to shrnul, jedním z největších problémů je nyní pro mě nedostatek takového „Smart Integration System“, který by propojoval různé komponenty do produktu a umožňoval tak sledovat, jak je produkt jako celek sestaven. Bude mě zajímat názor komunity na toto (spoiler - právě pracuji na projektu , který se může stát takovým chytrým integračním systémem).
Poslední věc, kterou chci zmínit, je, že pro mě není monolit přijatelný pro žádný projekt, byť střední velikosti. Pokusy zrychlit dobu implementace a kvalitu vývoje návratem k monolitu u mě vyvolávají velkou skepsi. Za prvé, monolit má podobný problém se správou komponent - mezi různými knihovnami, ze kterých se skládá, však toto vše není tak nápadné a projevuje se především časem stráveným vývojáři. Důsledkem problému monolitu je virtuální nemožnost provádět změny v kódu - a extrémně pomalá rychlost vývoje.
Mikroslužby situaci zlepšují, ale pak architektura mikroslužeb čelí problému kombinatorické exploze ve fázi integrace. Ano, obecně jsme stejný problém přesunuli z fáze vývoje do fáze integrace. Přístup mikroslužeb však dle mého názoru stále vede k lepším výsledkům a týmy dosahují výsledků rychleji (zřejmě především díky zmenšení velikosti vývojové jednotky - popř. objem várky). Přechod od monolitu k mikroslužbám však ještě proces dostatečně nezlepšil – kombinatorická exploze verzí mikroslužeb je obrovský problém a my máme velký potenciál situaci zlepšit, když ji vyřešíme.
Zdroj: www.habr.com