Читать книгу Wzorce Cloud Native - Cornelia Davies - Страница 22

Adrian Cockcroft, który był głównym architektem w Netfliksie, a teraz jest VP of Cloud Architecture Strategy w AWS, mówi o złożoności prowadzenia samochodu: jako kierowca musisz kontrolować samochód i nawigować po ulicach, w tym samym czasie starając się nie wejść w kontakt z innymi kierowcami, wykonującymi te same, skomplikowane zadania⁷. Jesteś w stanie to robić tylko dlatego, że stworzyłeś model, który pozwala ci zrozumieć świat i kontrolować swoje narzędzie (w tym przypadku samochód) w ciągle zmieniającym się środowisku.

Większość z nas używa swoich stóp, by kontrolować szybkość, i rąk, by ustalić kierunek, efektywnie określając swój wektor prędkości. Podejmując próbę usprawnienia nawigacji, planiści miast wprowadzili przemyślane układy miast (niech Bóg nam wszystkim pomoże w Paryżu). Narzędzia takie jak znaki i sygnalizacje drogowe w połączeniu z zasadami ruchu drogowego dają ci strukturę, w której możesz myśleć o swojej podróży od początku do końca.

Pisanie aplikacji cloud-native także jest złożone. W tej sekcji prezentuję model pozwalający wprowadzić porządek do mnóstwa zmartwień towarzyszących tworzeniu oprogramowania cloud-native. Mam nadzieję, że ten schemat ułatwi zrozumienie głównych konceptów i technik, co pozwoli ci zostać skutecznym architektem i programistą cloud-native.

Zacznę od łatwych rzeczy, rdzennych elementów oprogramowania tworzonego dla chmury, które na pewno znasz, przedstawionych na rysunku 1.6.

Rysunek 1.6. Znajome elementy podstawowej architektury oprogramowania

App (od application – aplikacja) implementuje zasadniczą logikę biznesową. To tutaj będziesz pisał większość kodu. To tutaj na przykład twój kod odbierze zamówienie od klienta, potwierdzi, że towar jest dostępny w zapasach magazynowych, i wyśle notyfikację do działu księgowego.

Aplikacja jest oczywiście zależna od innych komponentów, których używa, aby otrzymać informacje albo podjąć akcję; nazywam je usługami (services). Niektóre z tych usług przechowują stan – na przykład opis stanu magazynu. Inne mogą być aplikacjami implementującymi logikę biznesową dla innej części twojego systemu – na przykład fakturowania klienta.

Z wykorzystaniem tych prostych konceptów zbudujmy teraz topologię reprezentującą oprogramowanie cloud-native, które będziesz tworzyć – rysunek 1.7. Widzimy tutaj rozproszony zestaw modułów, z których większość ma wiele uruchomionych instancji. Można stwierdzić, że większość z tych aplikacji działa także jako usługi, i dalej, że niektóre z usług są wyraźnie stanowe. Strzałki opisują, jak komponenty zależą od innych.

Ten diagram ilustruje kilka interesujących elementów. Po pierwsze, zwróć uwagę, że elementy (prostokąty i ikony bazy danych lub pamięci trwałej) są zawsze opisane przez dwa oznaczenia: aplikacja i usługa dla prostokątów lub usługa i stan – dla ikonki dysku. Zaczęłam myśleć o prostych konceptach ukazanych na rysunku 1.7 jako o rolach, które przyjmują przeróżne komponenty w twoim oprogramowaniu.

Rysunek 1.7. Oprogramowanie cloud-native bierze znajome konwencje i dodaje ekstremalne rozproszenie systemu, z redundancją na każdym etapie i ciągłymi zmianami

Zauważ też, że każdy obiekt, który ma strzałkę kierującą do niego, oznaczającą, że jakiś inny komponent od niego zależy, jest usługą. To prawda – prawie wszystko jest usługą. Nawet aplikacja, która jest początkiem naszej topologii ma skierowaną do siebie strzałkę od konsumenta naszego oprogramowania. Aplikacje, oczywiście, są miejscem, gdzie działa twój kod. Poza tym szczególnie lubię połączenie adnotacji usługa i stan, co jasno podkreśla, że część usług jest pozbawiona stanu (bezstanowe usługi, o których na pewno słyszałeś, opisane tu jako aplikacje), podczas gdy celem istnienia innych jest zarządzanie stanem.

To sprowadza mnie do zdefiniowania trzech części aplikacji cloud-native, przedstawionych na rysunku 1.8:

Rysunek 1.8. Kluczowe obiekty w modelu oprogramowania cloud-native: aplikacje, dane i interakcje

 Aplikacja cloud-native – jeszcze raz: to jest miejsce, gdzie znajduje się twój kod, to logika biznesowa twojego oprogramowania. Implementacja odpowiednich wzorców w tym miejscu pozwala tym aplikacjom zachowywać się jak dobry obywatel społeczności stworzonej przez twoje oprogramowanie. Pojedyncza aplikacja rzadko jest kompletnym cyfrowym produktem. Aplikacja jest na jednym lub drugim końcu strzałki (lub obu), a zatem musi implementować pewne zachowanie, by mogła być częścią tej relacji. Musi także być skonstruowana w sposób, który umożliwi stosowanie odpowiednich praktyk operacyjnych, zgodnych z cloud-native, takich jak skalowanie i sposób aktualizacji do nowej wersji.

 Dane cloud-native – to tutaj żyje stan twojego oprogramowania cloud-native. Nawet ten prosty rysunek pokazuje wyraźne odchylenie od architektur z przeszłości, które często używały scentralizowanej bazy danych do przechowywania stanu dla znacznych części aplikacji. Na przykład: możliwe, że przechowywałeś profile użytkowników, informacje o kontach, opinie, historię zamówień, informacje o płatnościach i inne w tej samej bazie danych. Oprogramowanie cloud-native dzieli kod na wiele mniejszych modułów (aplikacji) i podobnie jest rozdzielona i rozproszona baza danych.

 Interakcje cloud-native – oprogramowanie cloud-native jest zatem połączeniem aplikacji i danych cloud-native, a sposób, w jaki te części współdziałają ze sobą, ostatecznie determinuje funkcjonowanie i cechy cyfrowego systemu. Z powodu ekstremalnego rozproszenia i ciągłych zmian, które charakteryzują nasz system, te interakcje w wielu sytuacjach znacząco wyewoluowały względem tych klasycznych architektur oprogramowania, a niektóre z wzorców zachowań są całkowicie nowe.