Autogenerowana dokumentacja do aplikacji mikroserwisowej

Autogenerowana dokumentacja do aplikacji mikroserwisowej - spotkał się ktoś?

Marzy mi się programik/skrypt który przejdzie się po repo i mi wygeneruje obrazek/graf wszystkich kilkudziesięciu mikroserwisów które mam w mojej korporacyjnej apce. Wraz ze wszystkimi połączeniami do zewnętrznych systemów, baz danych, remisów, rabbitów, kafek, SOA etc.

Zacząłem to robić ręcznie ale wiadomo, że zajmie mi to pewnie z miesiąc. A po miesiącu od razu będzie pewnie nieaktualny, stąd pytam o autogenerowanie.

Ktoś się spotkal z takim pomysłem albo nie daj boże z realizacją?

Nie spotkałem się z czymś, co statycznie analizuje kod, ale narzędzia typu AppDynamics fajnie rysują (z tym że na żywo) połączenia między serwisami. Wiadomo, rysuje tylko to, co aktualnie się dzieje w systemie.

marian pazdzioch napisał(a):

Zacząłem to robić ręcznie ale wiadomo, że zajmie mi to pewnie z miesiąc. A po miesiącu od razu będzie pewnie nieaktualny, stąd pytam o autogenerowanie.

Czemu miałby być nieaktualny?
Wrzucacie najpierw serwis, a potem się zastanawiacie, do czego ma służyć?

Nie wyobrażam sobie automatu, który wygeneruje połączenia pomiędzy mikroserwisami.
Do robienia z ręki polecam https://structurizr.com/

Kwestionowałbym zasadność takiego rozwiązania

Rozumiem że taka dokumentacja miałby pełnić rolę informacyjną - żeby czytając ją, byłbyś w stanie stwierdzić jakie są relacje pomiędzy usługami. Ta dokumentacja miałaby być generowana rozumiem na podstawie czegoś - jakiegoś kodu zapewne. Pytanie za milion punktów - czemu ten kod nie mógłby być napisany w taki sposób żeby był na tyle czytelny że dałoby się go rozczytać i z niego wywnioskować relacji usług?

To ja bym jeszcze odbił piłeczkę:

Zacząłem to robić ręcznie

Czyli jak? Bo może to, co robisz ręcznie, da się zautomatyzować. Szukasz wszystkich odwołań do klienta HTTP czy publishera Kafki? Albo może masz to owrapowane w jakiś osobny komponent, który da się znaleźć statycznie?

Dodam tylko jeszcze, że nawet jeśli uda ci się stworzyć statycznie takie coś, to jest jeden poważny problem - skąd wiesz, czy dane połączenie jest używane? :) Dlatego jestem raczej za observability na prodzie, tracingi powiedzą ci, gdzie faktycznie są połączenia.

Na podstawie analizy kodu to raczej trudno będzie. Może w oparciu o magię użytego frameworka, ale teoretycznie każdy mikroserwis to może być inny stack.
Spotkałem się natomiast z generowaniem na podstawie serwisów zdefiniowanych w Dockerze: https://github.com/pmsipilot/docker-compose-viz#image-renderer

Takie obrazki to sztuka dla sztuki żeby zaprezentować infre do biznesu a nie dla devów. Ja osobiście wole wyczytać wszystko z jakichś helmchartów, dockerfilów czy jakie tam akurat configi są akurat w projekcie. Takie obrazki raczej nie pomagają w pracy.

Płyniecie z tym dogmatycznym podejściem "dokumentacja jest zła, bo trzeba ją utrzymywać". Kiedyś mieliśmy poplątany kod, teraz mamy mikroserwisy, czyli kod sam w sobie jest c.a. ok, bo ciężko zrobić duży burdel w małym, izolowanym kawałku. Tylko złożoność, która powodowała to poplątanie kodu nie zniknęła, zwyczajnie przeniosła się wyżej.
Klient składa w banku wniosek o kredyt, kiedyś leciało to przez kilkanaście niby-modułów w "modularnym monolicie", a teraz leci przez kilkanaście mikroswerwisów. Co z tego, że są one proste, skoro sam proces się nie zmienił. Dokumentacja jest nawet bardziej potrzebna, bo przez kod można było się przy sporej dozie cierpliwości przeklikać, a przez poplątane mikroserwisy jest już dużo trudniej.

@kelog

Dlatego jestem raczej za observability na prodzie, tracingi powiedzą ci, gdzie faktycznie są połączenia

No i to jest jeden ze sposobów do których doszedłem. Być może nawet łatwiej jest zdjąć odcisk z tracingu i wygenerować graf kto z kim.

Jedyne czego tam nie będzie widać to rury które istnieją ale nie są używane. I powinny zostać zdemontowane.

Wrzuć jakieś Istio, czy podobne zarządzanie ruchem, zdefiniuj explicit dozwolone połączenia, sprawdź co nie działa. Jak już wszystko zacznie działać masz definicję wszystkich połączeń, które są faktycznie potrzebne, a wszystkie nadmiarowe powycinane.