Witaj, Habro! Zwracam uwagę autorskie tłumaczenie artykułu .
W czasach, gdy świat IT stopniowo zmierza w stronę mikroserwisów i narzędzi typu Kubernetes, coraz bardziej zauważalny staje się tylko jeden problem. Ten problem - wersje mikroserwisów. Mimo to społeczność IT uważa, że obecna sytuacja jest znacznie lepsza niż poprzedniej generacji technologii. Jednak wersjonowanie mikrousług jest problemem bardzo złożonym. Dowodem na to mogą być artykuły takie jak .
Jeśli po przeczytaniu tego tekstu nadal nie rozumiesz problemu, pozwól, że wyjaśnię. Załóżmy, że Twój produkt składa się z 10 mikrousług. Załóżmy teraz, że dla każdej z tych mikrousług została wydana 1 nowa wersja. Tylko 1 wersja – mam nadzieję, że wszyscy się zgodzimy, że jest to fakt bardzo trywialny i nieistotny. Teraz jednak przyjrzyjmy się jeszcze raz naszemu produktowi. Dzięki tylko jednej nowej wersji każdego komponentu mamy teraz 2^10 – czyli 1024 permutacji tego, jak można skomponować nasz produkt.
Jeśli nadal są jakieś nieporozumienia, pozwólcie, że wyjaśnię matematykę. Mamy więc 10 mikroserwisów, każdy otrzymujący jedną aktualizację. Oznacza to, że dla każdego mikrousługi otrzymujemy 2 możliwe wersje (stare lub nowe). Teraz dla każdego ze składników produktu możemy zastosować jedną z tych dwóch wersji. Matematycznie jest to to samo, co gdybyśmy mieli liczbę binarną składającą się z 10 cyfr. Załóżmy na przykład, że 1 to nowa wersja, a 0 to stara wersja - wówczas jedną z możliwych permutacji można oznaczyć jako 1001000000 - gdzie pierwszy i czwarty komponent są aktualizowane, a wszystkie pozostałe nie. Z matematyki wiemy, że 1-cyfrowa liczba binarna może mieć 4^10 lub 2 wartości. Czyli potwierdziliśmy skalę liczby, z którą mamy do czynienia.
Kontynuujmy nasze rozumowanie dalej – co się stanie, jeśli będziemy mieli 100 mikroserwisów i każdy będzie miał 10 możliwych wersji? Cała sytuacja staje się dość nieprzyjemna – mamy teraz 10^100 permutacji – co jest ogromną liczbą. Wolę jednak tak określić tę sytuację, ponieważ teraz nie kryjemy się już za słowami takimi jak „kubernetes”, ale raczej stawiamy czoła problemowi takim, jaki jest.
Dlaczego tak bardzo fascynuje mnie ten problem? Częściowo dlatego, że pracując wcześniej w świecie NLP i sztucznej inteligencji, około 5-6 lat temu dużo omawialiśmy problem eksplozji kombinatorycznej. Tylko zamiast wersji mieliśmy pojedyncze słowa, a zamiast produktów zdania i akapity. I choć problemy NLP i AI pozostają w dużej mierze nierozwiązane, to trzeba przyznać, że w ciągu ostatnich kilku lat poczyniono znaczne postępy (moim zdaniem można osiągnąć postępоByłoby lepiej, gdyby ludzie z branży poświęcali nieco mniej uwagi uczeniu maszynowemu, a trochę więcej innym technikom – ale to już nie na temat).
Wróćmy do świata DevOps i mikroserwisów. Stoimy przed ogromnym problemem, przebieraniem się za słonia w Kunstkamerze – bo często słyszę: „wystarczy wziąć kubernetesa i ster, a wszystko będzie dobrze!” Ale nie, nie wszystko będzie dobrze, jeśli wszystko pozostanie tak, jak jest. Ponadto analityczne rozwiązanie tego problemu nie wydaje się akceptowalne ze względu na jego złożoność. Podobnie jak w NLP, powinniśmy najpierw podejść do tego problemu, zawężając zakres poszukiwań – w tym przypadku eliminując przestarzałe permutacje.
Jedną z rzeczy, która może pomóc, jest coś, co napisałem w zeszłym roku . Należy również zauważyć, że dobrze zaprojektowany proces CI/CD znacznie pomaga w ograniczaniu zmienności. Jednakże obecny stan rzeczy w zakresie CI/CD nie jest na tyle dobry, aby rozwiązać problem permutacji bez dodatkowych narzędzi do elementów rozliczania i śledzenia.
To, czego potrzebujemy, to system eksperymentowania na etapie integracji, w którym możemy 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 zobaczyć, co działa, a co nie.
Taki system eksperymentów mógłby wyglądać następująco:
- Programiści piszą testy (jest to etap krytyczny – bo inaczej nie mamy kryterium oceny – to tak, jakby etykietować dane w uczeniu maszynowym).
- Każdy komponent (projekt) otrzymuje swój własny system CI – proces ten jest obecnie dobrze rozwinięty, a kwestia tworzenia systemu CI dla pojedynczego komponentu została w dużej mierze rozwiązana
- „Inteligentny system integracji” zbiera wyniki różnych systemów CI i składa projekty składowe w produkt końcowy, przeprowadza testy i na koniec oblicza najkrótszą ścieżkę do uzyskania pożądanej funkcjonalności produktu w oparciu o istniejące komponenty i czynniki ryzyka. Jeśli aktualizacja nie jest możliwa, system powiadamia programistów o istniejących komponentach i tym, który z nich powoduje błąd. Po raz kolejny system testowy ma tu kluczowe znaczenie - ponieważ system integracyjny wykorzystuje testy jako kryterium oceny.
- System CD, który następnie odbiera dane z Inteligentnego Systemu Integracji i bezpośrednio dokonuje aktualizacji. Ten etap kończy cykl.
Podsumowując, dla mnie jednym z największych problemów jest obecnie brak takiego „Inteligentnego Systemu Integracji”, który łączyłby różne komponenty w produkt i dzięki temu pozwalał śledzić, jak produkt jako całość jest składany. Będę zainteresowany przemyśleniami społeczności na ten temat (spoiler – obecnie pracuję nad projektem , który może stać się takim inteligentnym systemem integracji).
Ostatnią rzeczą, o której chcę wspomnieć, jest to, że moim zdaniem monolit nie jest akceptowalny w przypadku żadnego projektu, nawet średniej wielkości. Dla mnie próby przyspieszenia czasu wdrożenia i jakości rozwoju poprzez powrót do monolitu budzą duży sceptycyzm. Po pierwsze, monolit ma podobny problem z zarządzaniem komponentami - wśród różnych bibliotek, z których się składa, wszystko to jednak nie jest tak zauważalne i objawia się przede wszystkim czasem spędzonym przez programistów. Konsekwencją problemu monolitu jest praktycznie niemożność wprowadzenia zmian w kodzie - i niezwykle powolne tempo rozwoju.
Mikrousługi poprawiają sytuację, ale wtedy architektura mikroserwisów staje przed problemem eksplozji kombinatorycznej na etapie integracji. Tak, ogólnie rzecz biorąc, przenieśliśmy ten sam problem z etapu rozwoju do etapu integracji. Jednak moim zdaniem podejście mikroserwisowe w dalszym ciągu prowadzi do lepszych wyników, a zespoły osiągają rezultaty szybciej (prawdopodobnie głównie ze względu na zmniejszenie rozmiaru jednostki deweloperskiej – czyli wielkość partii). Jednak przejście z monolitu do mikroserwisów nie usprawniło jeszcze tego procesu w wystarczającym stopniu – kombinatoryczna eksplozja wersji mikroserwisów to ogromny problem i mamy duży potencjał, aby poprawić sytuację, gdy ją rozwiążemy.
Źródło: www.habr.com