Architektura IT: od monolitu do mikroserwisów i myślenie systemowe
Przejście do architektury często nie jest planowane, ale wynika z rozwoju projektu. Gdy jedna drużyna już nie radzi sobie z obciążeniem, a rozwiązania trzeba pamiętać przez lata, programista staje się architektem. Delgado rozpoczął w latach 90., od obsługi technicznej, a po pół roku przejął cały projekt. To zmusiło go do myślenia nie o żądaniach, ale o długoterminowym rozwoju.
Wykształcenie wyższe zapewnia podstawy pracy ze skomplikowanymi problemami: matematyka uczy przejść między abstrakcjami – od idei do implementacji. Uniwersytet rzadko uczy architektury bezpośrednio, ale rozwija myślenie systemowe. Książki takie jak prace McConnella, wzorce GoF czy Fowlera tworzą fundament poprzez refaktoryzację i strukturę kodu.
Konferencje typu Highload++ od 2007 roku pozwalają sprawdzić teorię na praktyce: dyskusje z deweloperami różnych technologii oddzielają idealne modele od rzeczywistości.
Rola architekta w drużynie
Architekt to rola koordynacyjna, a nie tylko stanowisko. W latach 90. istniały główni architekci odpowiedzialni za globalną koordynację. Dziś to poziom principal/staff engineer: odpowiedzialność za cały system, a nie tylko za moduł.
W skomplikowanych projektach, takich jak przetwarzanie kart lub wczesne wersje Yandex.Deneg, architekt przewiduje scenariusze, biorąc pod uwagę wydajność i dziedzinę tematyczną. Duma pochodzi z systemów produkcyjnych, które przetrwały próbę rzeczywistości. Start-upy uczą elastyczności, ale często nie docierają do wersji produkcyjnej.
Kluczowe wyzwania:
- Rozbieżność między 'książkową' architekturą a rzeczywistymi wymaganiami.
- Dostosowywanie do zmian bez konieczności rekonstrukcji.
- Balans między szybkością a skalowalnością.
Rutyna architekta to ciąg podobnych zadań, nie zawsze delegowanych. Koncentracja jest niezbędna: 2 godziny na kontekst, 3 godziny na analizę, czasem dni na rozwiązanie.
Monolit vs mikroserwisy: kontekst decyduje
Wybór między monolitem a mikroserwisami zależy od etapu projektu i zespołu. Monolit pasuje do początkowego etapu, gdy działa jedna, ścisła drużyna. Mikroserwisy są uzasadnione przy konflikcie wymagań i potrzebie niezależnego wdrożenia. Nie ma uniwersalnej odpowiedzi: decyzja ewoluuje wraz ze wzrostem złożoności.
Architekt musi rozumieć implementację: bez znajomości technologii 'ładna' schemat na diagramie zawiedzie. Architekt rozwiązania może obejść się bez kodu, ale architekt oprogramowania potrzebuje doświadczenia z frameworkami – by przewidywać koszt realizacji i ryzyko błędów.
Umiejętności i narzędzia architekta
Myślenie systemowe rozwija się przez praktykę: utrzymywanie systemu 'z góry' i z różnych perspektyw. Podoba się odpowiedzialność i niezależność: wybór rozwiązań, odpowiadając za jakość przez lata.
Nie podoba się rotacja: mniej kodu, więcej rutyny. Zmiana projektów jest trudna – zależy od dziedziny.
Top umiejętności dla middle/senior:
- Przejścia między abstrakcjami.
- Przewidywanie ewolucii systemu.
- Uwzględnianie kosztów realizacji.
- Radzenie sobie z sprzecznymi wymaganiami.
- Skupienie się na skomplikowanych zadaniach.
Książki są preferowane przed filmami: tekst pozwala powtarzać, budować logiczny tok. Filmy służą do prezentacji kodu, ale nie do głębokiego zrozumienia.
Rekomendacje literackie
Do rozwijania myślenia architektonicznego:
- 'Harry Potter i metody racjonalnego myślenia' (Yudkowsky) – racjonalność i prawdopodobieństwo.
- Książki z TRIZ, np. 'Miesiąc pod gwiazdami fantazji'.
- 'Tajemnica Prometeusza' (Mesterházi) – krytyczna analiza.
- Prace Lotmana z semiotyki.
- 'Sun Tzu' z komentarzami Conrad.
Te teksty trenują analizę niezależnie od technologii.
Co ważne
- Architektura to zarządzanie złożonością, a nie rysowanie schematów.
- Przejście od kodu do architektury poprzez wzrost odpowiedzialności.
- Obowiązkowe doświadczenie technologiczne dla architekta oprogramowania.
- Myślenie systemowe rozwija się przez praktykę i książki.
- Monolit/mikroserwisy: wybór zależy od kontekstu projektu.
— Editorial Team
Brak komentarzy.