Cele architektury oprogramowania

Cześć! Miło mi Cię gościć w moim kolejnym wpisie na Medium. Tym razem poruszę temat architektury oprogramowania, a dokładniej celów, które są z nią ściśle związane.

“Cokolwiek by to nie było, to widzę to jako sieć mikroserwisów! Koniecznie z Kafką i MongoDB!” — Sebastian, senior developer w firmie Iks

Dobrze, możemy stworzyć nasze nowe funkcjonalności w postaci mikroserwisów, ba — możemy zrobić to samo z tymi starymi, które kłują nam tyłek faktem, że utrzymanie ich kosztuje stukrotnie więcej niż napisanie nowych linijek kodu. Postawmy sobie teraz jednak jedno, zajebiście, ale to zajebiście ważne pytanie: jaki mamy cel wdrożenia naszej nowej architektury?

Czym jest cel architektury w kontekście naszego systemu?

Podczas podejmowania decyzji projektowych stajemy przed bardzo poważnymi problemami, które są związane z doborem rozwiązań architektonicznych. Wybór ich powinien być kierowany przede wszystkim celem, czyli czymś, co jesteśmy w stanie uzyskać poprzez wdrożenie nowego rozwiązania.

Nie możemy wymyślać sposobów rozwiązywania problemów w momencie, gdy jeszcze nie wiemy co jest naszym celem i w jaki sposób możemy go osiągnąć.

1. Architektura skalowalna — to cel, który możemy sobie postawić widząc, że aktualne rozwiązania nie wyrabiają, cholernie potrzebują skalowania, a nie jest to możliwe. Często tutaj spore znaczenie ma samo podejście do infrastruktury czyli architektury wdrożeniowej. Odpowiednia budowa specyficznych części systemu w oparciu o małe, niezależne serwisy umożliwi nam skalowanie horyzontalne.
2. Architektura łatwa w zrozumieniu — to coś, co wybieramy w momencie, gdy wiemy, że konkretny projekt nie będzie rozwiązywał naszych core-owych funkcjonalności, a jedynie stanie się czymś, przez co chcielibyśmy szybko przedrzeć się i później móc łatwo wdrażać nowych developerów, którzy mogliby rozwiązywać zadania po krótkim wprowadzeniu.
3. Architektura testowalna — czyli architektura, która umożliwia sprawdzenie jednostkowymi/akceptacyjnymi/funkcjonalnymi testami każdego jej elementu. Dopisywanie testów powinno być szybkie i łatwe, przez co mamy pewność stabilności takiego rozwiązania.
4. Architektura stabilna — aka. 100% uptime, czyli marzenie każdego SysAdmina. Tutaj chyba nie trzeba tłumaczyć; za cel obieramy sobie na przykład stworzenie systemu odpornego na jakiekolwiek czynniki zewnętrzne. Ciekawostka dotycząca budowania i projektowania takiej architektury, to z pewnością Chaos Monkey by Netflix.
5. Architektura łatwa w usuwaniu - tak, mam na myśli rozwiązania, których nie będzie nam szkoda wyrzucić do kosza. Taka architektura umożliwia bardzo łatwe wymienianie jej elementów niczym klocków, a także usuwanie poszczególnych modułów w sposób bezpieczny, który nie wiąże się z większymi konsekwencjami rozwalania połowy systemu. Po prostu bierzemy dłuto i wydłubujemy konkretne części aplikacji, jedna po drugiej.
6. Architektura mierzalna — dotyczy rozwiązań, które możemy w prosty sposób obserwować i reagować na wszelkie anomalie. Cel bardzo fajny w momencie, gdy chcemy stworzyć system, który będzie rozwijany przez długie lata — dzięki odpowiednim metrykom będziemy w stanie sprawdzać czy development idzie w poprawną stronę.
7. Architektura ewolucyjna — na ten cel składają się także inne wymienione w tym wpisie. Ale po krótce: chcemy by nasz system mógł ewoluować wraz z biznesem, szczególnie ważne, gdy tworzymy aplikację dla startupu, który cały czas poszukuje swojego “wewnętrznego ja” i najlepszego sposobu na rozwiązywanie postawionego mu problemu. Naszym zadaniem jest umożliwienie developerom szybkiej, wygodnej rozbudowy oprogramowania bez popadania w blockery, które hamują większość powstających systemów.
8. Architektura łatwa do monitorowania — monitoring-driven-architecture, czyli pojęcie popularne w ostatnim czasie. Odpowiednie śledzenie zachowań systemu daje nam świetny pogląd na zbliżające się problemy, a dzięki temu będziemy w stanie reagować na wszystko, gdy tylko pojawi się coś niepokojącego na naszym kolorowym dashboardzie.
9. Architektura hype-driven — cel, którym kierujemy się, gdy tylko pojawi nam się nowa zajawka na punkcie nowego języka, nowego frameworka i innych. Super, wow — mamy GraphQL spięty z najnowszymi rozwiązaniami w Scali, które domykamy najbardziej widowiskową bazą danych! Taki cel jest często co najmniej śmieszny, ale z pewnością jego plusem jest fakt, że ktoś będzie mógł zaspokoić swoje ego i wypróbować nowych rzeczy, o których później opowie na kolejnej konferencji dla ludzi z czarnymi plecakami. ;) Szkoda tylko, że często takie rozwiązania bazujące na nowych technologiach, nowych podejściach są ciężkie w utrzymaniu. Później okaże się, że odczujecie na sobie spojrzenia napotkanych losowo osób w parku, które to na codzień odziedziczyły ten kod po Was i dowiedziały się jak wyglądacie.

Cel na początku!

Celów jest jeszcze dużo więcej, a tak naprawdę dopiero zebranie tych, które odpowiadają naszemu projektowi, oraz jego potrzebom jest w stanie pomóc nam z doborem konkretnych rozwiązań i podejmowaniem decyzji związanych z architekturą wdrożeniową, architekturą aplikacyjną czy systemową. Tak, istnieje wiele poziomów architektury, ale o tym napiszę osobny wpis. Buzzword na dziś: C4Model.

Ponadto zebrane zadania, które ma zrealizować nasze rozwiązanie, to świetna podstawka na wytłumaczenie naszym przełożonym i kolegom/koleżankom z zespołu dlaczego aplikacja potrzebuje zmian i/lub na czym powinniśmy się skupić podczas projektowania nowych modułów, serwisów i innych.

Miłego popołudnia!