Mikrousługi — eksplozja kombinatoryczna wersji

Cześć, Habr! Przedstawiam wam tłumaczenie artykułu Mikroserwisy – Kombinatoryjny Eksplozja Wersji.

W czasach, gdy świat IT stopniowo przechodzi na mikroserwisy i narzędzia takie jak Kubernetes, coraz bardziej wyraźny staje się jeden problem. Problem ten to eksplozja kombinatoryjna wersji mikroserwisów. Jednak społeczność IT uważa, że obecna sytuacja jest znacznie lepsza niż „Piekło zależności” poprzednich pokoleń technologii. Niemniej jednak zarządzanie wersjami mikroserwisów jest bardzo skomplikowanym problemem. Jednym z dowodów mogą być artykuły takie jak „Oddajcie mi mój monolit”.

Jeśli czytając ten tekst nadal nie rozumiesz problemu, pozwól, że wyjaśnię. Załóżmy, że twój produkt składa się z 10 mikroserwisów. Teraz załóżmy, że dla każdego z tych mikroserwisów wychodzi 1 nowa wersja. Tylko 1 wersja – mam nadzieję, że wszyscy możemy się zgodzić, że to dość trywialny i nieznaczny fakt. Teraz jednak spojrzmy jeszcze raz na nasz produkt. Z jedną nową wersją każdego komponentu mamy teraz 2^10 – czyli 1024 permutacje, jak możemy złożyć nasz produkt.

Jeśli nadal pozostaje niejasność, pozwól, że rozłożę matematykę. Mamy 10 mikroserwisów, każdy otrzymuje jedno uaktualnienie. To znaczy, że mamy 2 możliwe wersje dla każdego mikroserwisu (albo starą, albo nową). Teraz, dla każdego z komponentów produktu możemy używać którejkolwiek z tych dwóch wersji. Matematycznie, jest to to samo, co byśmy mieli liczba binarna z 10 cyfr. Na przykład, powiedzmy, że 1 to nowa wersja, a 0 to stara wersja – wtedy jedna z możliwych permutacji może być oznaczona jako 1001000000 – gdzie 1-szy i 4-ty komponenty są zaktualizowane, a wszystkie pozostałe nie. Z matematyki wiemy, że liczba binarna z 10 cyfr może mieć 2^10 lub 1024 wartości. To potwierdza zakres liczby, z jaką mamy do czynienia.

Kontynuując rozważania — co się stanie, jeśli będziemy mieli 100 mikroserwisów i każdy z 10 możliwych wersji? Sytuacja staje się bardzo nieprzyjemna — teraz mamy 10^100 permutacji — to ogromna liczba. Niemniej jednak, wolę określić tę sytuację w ten sposób, ponieważ teraz nie ukrywamy się za słowami takimi jak „kubernetes”, ale stawiamy czoła problemowi takim, jaki jest.

Dlaczego ta kwestia tak mnie fascynuje? Częściowo dlatego, że pracując wcześniej w świecie NLP i AI, wiele dyskutowaliśmy o problemie eksplozji kombinatorycznej około 5-6 lat temu. Tylko zamiast wersji mieliśmy pojedyncze słowa, a zamiast produktów mieliśmy zdania i akapity. I chociaż problemy NLP i AI w dużej mierze pozostają nierozwiązane, muszę przyznać, że w ciągu ostatnich kilku lat zrobiono znaczący postęp. (moim zdaniem, postęp mógłby być większy,większągdyby ludzie w branży poświęcili nieco mniej uwagi uczeniu maszynowemu i trochę więcej innym technikom — ale to już temat na osobną dyskusję).

Wracam do świata DevOps i mikroserwisów. Stoją przed nami ogromne wyzwania, które przypominają słonia w lunaparku — często słyszę: „po prostu weź kubernetes i helm, a wszystko będzie dobrze!” Ale nie, nic nie będzie dobrze, jeśli pozostawimy wszystko tak, jak jest. Co więcej, analityczne rozwiązanie tego problemu wydaje się niedopuszczalne ze względu na złożoność. Podobnie jak w NLP, powinniśmy najpierw podejść do tego problemu poprzez zawężenie obszaru poszukiwań — w tym przypadku poprzez wyeliminowanie przestarzałych permutacji.

Jedną z rzeczy, która może pomóc — pisałem w zeszłym roku o konieczności utrzymywania minimalnego rozrzutu między wersjami udostępnianymi klientom. Również ważne jest to, że dobrze opracowany proces CI/CD bardzo pomaga w redukcji wariacji. Jednak obecny stan rzeczy w CI/CD nie jest wystarczająco dobry, aby rozwiązać problem permutacji bez dodatkowych narzędzi do śledzenia i monitorowania komponentów.

To, czego potrzebujemy, to system eksperymentów na etapie integracji, w którym moglibyśmy określić czynnik ryzyka dla każdego komponentu, a także mieć zautomatyzowany proces aktualizacji różnych komponentów i testowania bez interwencji operatora — aby widzieć, co działa, a co nie.

Taki system eksperymentów mógłby wyglądać następująco:

1. Deweloperzy piszą testy (to kluczowy etap — ponieważ w przeciwnym razie nie mamy kryteriów oceny — to jak etykietowanie danych w uczeniu maszynowym).
2. Każdy komponent (projekt) otrzymuje swój własny system CI — ten proces jest obecnie dobrze opracowany, a kwestia stworzenia systemu CI dla pojedynczego komponentu w dużej mierze została rozwiązana.
3. „Inteligentny system integracji” zbiera wyniki różnych systemów CI i łączy elementy projektów w gotowy produkt, uruchamia testy, a na końcu oblicza najkrótszą drogę do uzyskania wymaganej funkcjonalności produktu, bazując na istniejących komponentach i czynnikach ryzyka. Jeśli aktualizacja nie jest możliwa, system informuje programistów o dostępnych komponentach i o tym, na którym z nich występuje błąd. Jeszcze raz podkreślam, że system testów ma tu kluczowe znaczenie — ponieważ system integracji używa testów jako kryterium oceny.
4. System CD, który następnie pobiera dane z „Inteligentnego systemu integracji” i bezpośrednio przeprowadza aktualizację. Ten etap kończy cykl.

Podsumowując, jedną z największych obecnie dla mnie problemów jest brak takiego „Inteligentnego systemu integracji”, który łączyłby różne komponenty w produkt, a tym samym pozwalałby śledzić, jak produkt jest zbudowany w całości. Ciekawią mnie myśli społeczności na ten temat (spoilery — pracuję teraz nad projektem Reliza, który może stać się takim inteligentnym systemem integracji).

Ostatnia rzecz, którą chcę wspomnieć, to to, że dla mnie monolit nie jest akceptowalny dla jakiegokolwiek projektu przynajmniej średniej wielkości. Budzi we mnie duży sceptycyzm próby przyspieszenia czasu realizacji i jakości rozwoju przez powrót do monolitu. Po pierwsze, monolit ma podobny problem zarządzania komponentami — wśród różnych bibliotek, z których się składa, jednak wszystko to nie jest tak zauważalne i objawia się przede wszystkim w czasie, który spędzają programiści. Skutkiem problemu monolitu jest faktyczna niemożność wprowadzenia zmian w kodzie — oraz niezwykle wolna prędkość rozwoju.

Mikroserwisy poprawiają sytuację, jednak architektura mikroserwisowa napotyka problem eksplozji kombinatorycznej na etapie integracji. Tak, w zasadzie przenieśliśmy ten sam problem — z etapu rozwoju na etap integracji. Jednak według mnie podejście mikroserwisów wciąż prowadzi do lepszych wyników, a zespoły osiągają wyniki szybciej (prawdopodobnie głównie z powodu zmniejszenia rozmiaru jednostki rozwoju — lub rozmiaru partii). Jednak przejście od monolitu do mikrousług wciąż nie przyniosło wystarczającej poprawy procesu — eksplozja wersji mikrousług to ogromny problem, a my mamy duży potencjał na poprawę sytuacji w miarę jej rozwiązania.

Źródło: habr.com