Dlaczego dowozimy wolno?

Istnieje kilka powodów, dla których decydujemy się na architekturę mikroserwisową. Chcemy osiągnąć lepszą wydajność, skalowalność oraz jeszcze jedną rzecz – tę, którą często obiecujemy naszym interesariuszom: szybsze dostarczanie nowych funkcji. Mówimy, że dzięki niezależnemu wdrażaniu z CI/CD, asynchronicznej komunikacji oraz wyraźnym granicom domenowym, zespoły będą mogły pracować autonomicznie. Ale czy to rzeczywiście wystarczy? Z mojego doświadczenia wynika, że nie. Brakuje jednego kluczowego elementu, jest jeszcze jedno wąskie gardło.

Transcript

1. DLACZEGO DOSTARCZAMY WOLNO?
2. GWIDON ➤ Architekt w „rosnącym projekcie” ➤ Monolit ➤ Legacy ➤ Plan na 12 zespołów ➤ Jakiś czas temu dostał zadanie od CTO …
3. OBJECTIVE - MAKE VALUE DELIVERY FASTER KEY RESULT - LEAD TIME FROM 2 MONTHS TO 2 WEEKS (80 PERCENTILE)
4. DESIGN -> DEVELOP -> RELEASE
5. „Wszystko trzeba wdrażać na raz, to chyba trzeba rozproszyć ten system!
6. DESIGN -> DEVELOP -> RELEASE
7. „Mamy za dużo zależności, to chyba trzeba zrobić Event-Driven okraszone DDD!
8. DESIGN -> DEVELOP -> RELEASE
9. „WTF! Teraz to nie wiem o co chodzi. Które książki powinienem przeczytać?
10. „- Najbardziej doświadczone osoby mniej kodują, głównie chodzą po spotkaniach - Nowe osoby mają trudność z wejściem w projekt - HLD mają się nijak do rzeczywistości
11. „ Co jest kolejnym wąskim gardłem?
12. SERVICE AUTONOMY != DEVELOPER AUTONOMY
13. ROZPROSZONA WIEDZA
14. LATENCY, AVAILABILITY, CONSISTENCY Checkout Get user status CRM Buy now User data changed Checkout CRM Buy now
15. LATENCY, AVAILABILITY, CONSISTENCY Team A How it works? Team B Design new feature We did it that way Design new feature Team A Team B Knowledge Base Meeting
16. DATA REPLICATION Service C Create new report Data changed Service B Service D Reporting service Data changed Data changed
17. KNOWLEDGE REPLICATION Team C We did it that way Design new feature Team A Team D Knowledge Base We did it that way Team B We did it that way
18. „ Czego użyć jako bazy wiedzy?
19. PODEJŚCIE 1 - SERVICER CATALOG
25. ZALETY ➤ Łatwe wyszukiwanie ➤ Zależności między komponentami ➤ Wizualna reprezentacja ➤ Dokumentacja API ➤ Wiedza o systemie w jednym miejscu ➤ Integracja dodatkowych narzędzie np. monitoring
26. „ Skąd się biorą informacje, które są widoczne w tych systemach ?
27. MANUAL YAML FILE GENERATION
28. Change frequency Amount of detail Developer Portals C4 tools CZY MANUALNIE GENEROWANA DOKUMENTACJA JEST AKTUALNA ?
29. PODEJŚCIE 2 - LLM
31. „Czy mogę ufać tym informacjom? Czy koszty związane z LLM mnie nie zjedzą? Czy muszę mieć monorepo?
32. PODEJŚCIE 3 - LLM + GROUNDING + ONTOLOGIES Code 
 model Org 
 model Infra 
 model P3
 Knowledge
 Graph + Conventions + Conventions + Conventions AI Agents Static
 Documentation Noesis UI Parser Parser Parser Builder
33. https:/ /noesis.vision
34. I THE END KNOWLEDGE SHARING BECOMES BOTTLENECK AND YOU NEED A SOLUTION TO REMOVE IT
35. Q & A