W ostatnim odcinku serii opisałem, co rozumiem przez termin cloud. Opisałem także początki mojego własnego systemu tego typu. W tym odcinku postaram się przybliżyć trochę więcej detali technicznych. Najpierw chciałbym Ci zaproponować kilka pomysłów na własny cloud. A mając w głowie taką główną ideę, spróbuję pomóc Ci dobrać odpowiedni tech stack. Zapraszam do lektury!
Na początek wybierz pomysł na cloud
Jeśli chodzi o pomysły, to tych może być mnóstwo. Naprawdę całe mnóstwo. Może to być własny prywatny OneDrive czy Google Drive. Mam na myśli klona pod względem funkcjonalności. Może to być system zarządzania wewnętrznymi wydatkami Twojego domostwa, własny TODO board albo np. integracja maili, wiadomości z różnych komunikatorów w jeden system. To wszystko co wymieniłem, wydaje się, że jest to kopiowanie już istniejących pomysłów, prawda? Każdy junior przecież ma listę TODO. Oczywiście, że tak! Z tym że to jest tylko lista TODO. A co z autoryzacją i uwierzytelnieniem? Co z backupami? Kwestia skalowania w poziomie? Monitoring zasobów i logów? I oczywiście można tak wymieniać i wymieniać. Cloud na każdą wąsko określoną funkcjonalność ma co najmniej kilka funkcjonalności infrastrukturalnych.
Wynika to z tego, że cloud to system wysokiej dostępności. W tym momencie rozszerzamy sobie poniekąd definicję terminu cloud. Do definicji z ostatniego odcinka serii możemy dodać, że jest to taki system, który zazwyczaj jest zgodny z podejściem HA, jest redundantny i cechuje go wysoki stopień integracji modułów między sobą. Podsumowując, zwykle chodzi tylko o to, aby spróbować zrobić coś, co będzie służyło Tobie. Zawsze wtedy, gdy będziesz tego potrzebował.
Po burzy mózgów ustal stos technologiczny
Skoro zaproponowałem kilka pomysłów na własny system cloud to mogę przejść do zasugerowania stacków technologicznych. Dobór stacku będzie zazwyczaj zależny od tego, jaki język znasz. Wpływ na ten wybór powinien mieć przede wszystkim typ zadań jakie chcesz, aby cloud wykonywał. Wynika to z tego, że każda technologia nadaje się do innych typów zadań. Przykładowo, jeśli wiesz, że chcesz zbudować modularny monolit zgodnie z architekturą Heksagonalną to wybierzesz ASP.NET bądź Spring. Z drugiej strony zakładając, że chcesz zbudować mikroserwisy lub miniserwisy będzie to zazwyczaj nodejs, Symfony czy Flask. Jeszcze innym przykładem jest aplikacja, która z góry wiesz, że nie urośnie poza kilka prostych CRUDów. Wtedy świetnym wyborem będzie Laravel bądź Django albo Ruby on Rails. Każdy z tych przykładów nadaje się do innego typu systemu ze względu na przewidywaną architekturę. Każda z tych technologii ma inny zestaw cech, który powoduje, że mają różne predyspozycje do różnych zastosowań.
Trochę więcej mięska…
Teraz wytłumaczę sens powyższego akapitu na przykładzie różnic między Symfony, a Laravelem. Patrząc na Symfony, można powiedzieć, że jest to microframework z rodziny Spring-like. Laravel jest z kolei z rodziny frameworków podobnych do Django i RoR. Chodzi głównie o warstwę modelowania logiki biznesowej. Symfony używa wzorca bazującego na Entity. Laravel zaś używa wzorca Active Record. Już tutaj rozstrzał między tymi wzorcami powoduje, że Symfony jest bardziej elastyczne, a Laravel tworzy duży narzut na nasz kod. W związku z tym, jeśli potrzebujemy system, złożony np. z mikroserwisów to dobierzemy Symfony.
Wynika to z tego, że mikroserwis jest bezpośrednio zależny od przyjętego konceptu na architekturę całości rozwiązania, nie ma żadnego „blueprintu„. To z kolei powoduje, że wymagasz by technologia, której użyjesz, pozwalała na dowolne manewry. Z przytoczonych dwóch będzie to Symfony. Jednak jeśli potrzebujemy zmontować coś na szybko, modularnie, ale monolitycznie to Laravel sprosta naszym oczekiwaniom.
Z mojego doświadczenia wynika, że technologie dające większą elastyczność lepiej sprawdzą się w dalszym planie. Oczywiście takie rozwiązania są trudniejsze w utrzymaniu, mając niewielkie doświadczenie w programowaniu. Z tego samego powodu czas rozwoju takiego systemu jest często znacznie dłuższy. Jednakże wiąże się to z bardzo dużymi możliwościami rozwoju w razie, jeśli nagle uznasz, że zmienisz skalę systemu. Zmiana skali systemu, tyczy się zarówno skalowania w górę, jak i w dół.
Personalnie mogę powiedzieć, że wybór ASP.NET był dobry w długiej perspektywie. Na start nauki Web nie był to najlepszy wybór, ale sumarycznie było to bardzo dobre posunięcie. W tym momencie, 3 wersja cloudu rozwija się i pozwala się dobrze skalować w pionie i poziomie. Takie możliwości daje ASP.NET. Jednocześnie bez odpowiedniej infrastruktury i organizacji pracy, której nie mogłem mieć. Z początku praca z tym stosem była po prostu uciążliwa i trudna.
Jakie elementy infrastruktury powinien mieć cloud?
Podsumowując poprzedni akapit, istotnym elementem przy budowaniu własnego rozwiązania typu cloud powinna być dla Ciebie towarzysząca infrastruktura. Poprzez termin infrastruktura mam na myśli głównie usługi typu Jenkins, czyli CI&CD, GitLab lub GitHub, jako solucja do wersjonowania, Grafana czy Kibana do wizualizacji logów, Elasticsearch do ich gromadzenia, Zabbix czy Munin do monitorowania, Docker lub Kubernetes do konteneryzacji itd. Tak naprawdę nie ma żadnych, które by definiowały cloud. Każdy z nich robi co innego, więc poniekąd jest wymagany. Zwykle każdy z nich pomaga w automatyzacji działań, a to jedno z założeń cloudu. To od Ciebie będzie zależeć, co jest istotne, a co nie, jednak zalecam zainwestować w każdy z wymienionych pionów: wersjonowania, CI&CD, wizualizacji i agregacji logów oraz monitorowania. W PikaCloud każdy z tych pionów występuje, nie zawsze w tzw. production grade, ale jest obecny.
Podsumowanie – przykładowa architektura cloudu
W tej sekcji podsumuję Ci oba poprzednie podrozdziały tego odcinka. Zrobię to, posługując się przykładem hipotetycznego projektu, którego domeną biznesową będzie system analizy paragonów na podstawie analizy OCR oraz Machine Learning do kategoryzowania paragonów. Z perspektywy tak zwanego biznesu ten system ma służyć do agregacji zdjęć z paragonami, analizy tych zdjęć w celu ekstrakcji danych dot. zakupów. Będą to informacje dot. kategorii produktów oraz ich cen, a następnie budowanie historii wydatków razem ze statystykami.
Draft architektury
Na sam start musisz przemyśleć, jak chcesz powyższą logikę biznesową opisać, używając architektury. Na dobry początek może to być modularny monolit. Chyba wszyscy przywykliśmy, że właśnie w ten sposób zaczyna swoje życie każdy większy system typu Web, a tym bardziej cloud, który ma być wąsko wyspecjalizowany. Jeśli jednak projektując ten system, uznasz, że preferujesz podejście mikroserwisowe, nie wahaj się go zastosować. Na potrzeby uproszczenia opisu zdecydowałem się pójść dalej z modularnym monolitem.
Skoro zdecydowałeś już jaki ogólny „szablon” architektury przyjmiesz, w moim przypadku jest to wspomniany typ monolitu, możemy przesunąć się krok dalej. Teraz dobierz technologie pomocnicze, czyli technologie infrastrukturalne z kategorii wspomnianych wcześniej. Chodzi o technologie z zakresu: CI&CD, wersjonowania kodu, wizualizacji logów i monitorowania zasobów. Do takiego projektu w tym momencie wybrałbym następujące technologie:
- Jenkins/TeamCity,
- Grafana i Loki,
- Zabbix,
- GitLab lub GitHub(zależy czy on-premise czy on-cloud).
Dodatkowo to wszystko bym wsparł Terraformem i Ansible’em. Jeśli zaś chodzi o stack technologiczny, to prawdopodobnie wybrałbym znów ASP.NET albo Symfony. Możliwe, że do wyspecjalizowanych service’ów pomocniczych użyłbym czegoś w rodzaju Golanga lub Elixira. Jeśli zaś chodzi o infrastrukturę, użyłbym swojego serwera. W Twoim wypadku dobrą opcją będzie VPS albo serwer dedykowany. Następny i ostatni krok w tej fazie to rozpisanie sobie listy zadań do zrealizowania w ramach każdego obszaru. Może też to być rozrysowanie sobie w formie diagramów UML.
Implementacja architektury cloudu
Od tego momentu możesz już implementować powoli zarówno swoją aplikację, jak i wdrażać rozwiązania poboczne. Pamiętaj, że to nie będzie ani jeden wieczór, ani nawet tydzień. To będą miesiące żmudnej pracy po godzinach, aby to działało tak, jak tego chcemy. Ten punkt będzie tak naprawdę trwał najdłużej, a możliwe, że nigdy się nie zakończy.
Zakończenie
To już koniec tego wpisu. Więcej detali dotyczących implementacji wspomnianych elementów cloudu rozpocznę omawiać od następnego odcinka. A, skoro to czytasz, to znaczy, że dotarłeś do końca tego odcinka, za co Ci szczerze dziękuję i zachęcam do obserwowania dalej mojej serii. W następnym odcinku opowiem Ci o przykładowej, podstawowej konfiguracji repozytorium oraz przykładowej integracji tego z serwerem JetBrains TeamCity. Cześć i do następnego razu!
