5 kroków do stworzenia bezproblemowego rozwiązania w chmurze

Od pomysłu do wdrożenia na produkcję często mija kilka lat. Niestety, ale projekty często nie nadążają za technologią, praktycznie w każdej firmie jest „legacy kod”, cóż nie ma co się dziwić, ponieważ aby wszystko co zostało już napisane miało zostać przepisane lub non stop kompatybilne z najnowszymi wersjami to pewnie większość firm by musiała zwiększyć budżet na projektu o kilkaset procent. 

Jak w takim razie planować rozwiązania chmurowe w środowisku Azure, abyśmy mogli z nich korzystać jak najdłużej? Sam proces może zostać podzielony na wiele kroków. W artykule postaram się pokazać jeden z tych które najczęściej sam używałem przy swoich projektach. Na początku odwołam się do typowego cyklu od pomysłu do produkcji. Poniżej znajduje się bardzo czytelny proces, który występuje w mniej lub bardziej podobnej postaci w większości firm/projektów IT. Na podstawie tego procesu będziemy go dopasowywać do procesu, który proponuję przestrzegać przy założeniu, że nasze rozwiązanie ma być rozwiązaniem chmurowym.

Business Analysis Role in Mobile Application Development - Velvetech

Krok 1

Podczas planowania musimy wyznaczyć nasze cele oraz opracować wstępne założenia. Jakie w takim razie mogą być nasze cele? 

• Aplikacja powinna być gotowa na wzmożony ruch w trakcie dnia
• Dane użytkowników powinny być bardzo dobrze chronione, ponieważ będą wrażliwe
• Oraz wiele innych wymagań funkcjonalnych oraz nie funkcjonalnych.

Na tym etapie można już wyklarować sobie mniej więcej serwisy w chmurze, które będziemy chcieli zastosować. Warto zajrzeć na stronę Microsoft.

Znajdziemy tam wszystkie informacje na temat zasobów chmurowych. Przede wszystkim ważne dla nas są informacje o „retirements” – czyli zasobach, które nie będą w najbliższym czasie dłużej utrzymywane. Z własnego doświadczenia wiem, że przeważnie informacja o zakończeniu utrzymania pojawia się na minimum rok przed taką sytuacją. Warto również zobaczyć jakie nowości będzie oferował nasz dostawca, czyli „IN PREVIEW”, czasami zdarza się, że coś co planujemy wdrożyć jest dostępne właśnie w takiej wersji – dzięki czemu możemy to przetestować oraz sprawdzić, czy spełni nasze oczekiwania i może akurat okaże się, że będzie dostępne w wersji normalnej przy końcowej fazie rozwoju naszego projektu.

Oczywiście rekomenduję nie stosować zasobów bądź funkcjonalności „IN PREVIEW” w wersjach produkcyjnych. Oczywiście nigdy nic w świecie IT nie jest zgodne z wyznacznikami. Jeśli po odpowiedniej serii testów okaże się, że rozwiązanie spełnia nasze oczekiwania – pewnie można się pokusić o jego użycie, aby znacznie nie utrudniać sobie życia tak zwanymi „workarounds” 

Krok 2

Czyli tak naprawdę wywiad dokonany przez „biznes”, który pomoże nam wyklarować nasze plany. Jest to stosunkowo bardzo ważny proces w trakcie planowania projektu, niestety my jako ludzie techniczni nie mamy na to zbytnio wpływu. Natomiast powinniśmy zawsze zebrać jak najwięcej danych z tej części, ponieważ pozwoli ona nam zaplanować nie tylko dobrą infrastrukturę, ale też dopasować ją do problemu, ponieważ tak naprawdę liczy się stosunek jakości do ceny, o której często zapominamy. Niestety, ale wszystkie zasoby kosztują a tworzenie mikro serwisów dla systemu, z którego korzysta 100 osób dziennie jest faux pas.

Często niedoświadczone osoby kierują się tym, aby zadowolić swoje programistyczne i dla prostych problemów projektują skomplikowane rozwiązania, dla powyższego problemu nie ma lepszej (stosunek łatwości i ceny do problemu) architektury niż aplikacja monolitowa/wykorzystania FaaS. Zawsze trzeba mieć w głowie analizę biznesową i uwzględniać ją podczas projektowania rozwiązania, oczywiście jeśli firma ma nieskończone pokłady pieniężne – warto się pokusić o zrobienie rozwiązania, które będzie „overkillem”, ale my jako programiści/architekci będziemy o wiele bardziej z tego dumni.

Krok3

Tak naprawdę w praktyce wiemy, iż punkty 3 oraz 4 bardzo często się przeplatają, nieważne jak dobrze zostałaby przeprowadzona analiza i tak podczas projektu zachodzą zmiany w trakcie jego powstawania. Natomiast podstawa każdej architektury może być zaplanowana już na tym kroku. Warto więc określić wiele aspektów związanych z chmurą. Najważniejsze rzeczy, o których powinniśmy pamiętać to:

• Odpowiednie zaplanowanie nazw naszych zasobów wg umownie panujących standardów: jako przykład takich standardów odwoływałbym się do tego artykułu. Dzięki zastosowaniu się do tych standardów będziemy bardziej uniwersalni, przykładowa nazwa „Resource Group”, która będzie przeznaczona dla projektu o nazwie „Hades” dla środowiska dev:  rg-dev-hades

• Kolejnym standardem, który pomoże nam wypracować porządek w naszej chmurze jest zasada single responsibility, czyli tworzymy resource groupy do konkretnych projektów czy podprojektów, jeśli jakieś projekty współdzielą zasoby warto pomyśleć o podzieleniu zasobów na 3 RG 
  

• Opracowanie strategii CI/CD, na tym etapie warto przygotować repozytorium schematu zmiennych, zdecydować się z jakich narzędzi będziemy korzystać, czy ARM czy Terraform, tutaj nie będę się rozwodził nad różnymi podejściami, ponieważ to temat na osobny artykuł.
• Przeprowadzenie wstępnych badań/testów/dyskusji na temat zasobów ich plusów minusów oraz kosztów, przykładowo aby wykonać obliczenia w tle w chmurze Azure możemy użyć do tego co najmniej kilka zasobów (How to Run Background Jobs on Azure | Desuvit), tutaj odsyłam do artykuły, który opisuje te zasoby w sposób wystarczający do podjęcia decyzji, natomiast takich problemów będzie o wiele więcej, zawsze warto zagłębić się w dostępne rozwiązania, przeprowadzić wstępne testy i na ich podstawie podjąć decyzję.
  
  

Krok 4

Tak jak wspomniałem wcześniej punkty 3 oraz 4 często się ze sobą zacierają, ponieważ, najpierw planujemy potem wdrażamy, natomiast często pracujemy w SCRUM, także proces ten jest powielany w kółko. W przypadku chmurowym development to stworzenie wszystkiego co zaplanowaliśmy oraz napisane skryptów/pipelines odpowiadających za wdrożenie rozwiązania. W zależności od projektu często za tą część odpowiedzialny jest DevOps, natomiast z doświadczenia wiem, że warto, aby przynajmniej jedna osoba oprócz DevOpsa posiadała doświadczenie w tym zakresie, ponieważ w przypadku braku dostępności, często nasz cały projekt może być zablokowany.

Dobrym podejściem do pisania skryptów jest stworzenie ich manualnie w Azure portalu a następnie pobranie ARM templates oraz ich sparametryzowanie, dzięki temu zaoszczędzimy dużo czasu oraz unikniemy potencjalnych błędów. Możemy podejrzeć wszystkie zasoby w postaci IaC z poziomu portalu, wystarczy z lewej strony wybrać „Export template”.

Krok 5

Tutaj następuje moment, w którym docenimy to, że zastosowaliśmy się do wszystkich wyżej wymienionych porad. Okazuje się, że kwestia wdrożenia naszego rozwiązania na środowisko testowe to wyłącznie zmienienie w najlepszym wypadku „dev” na „test” w najgorszym zrobienie tego w kilku miejscach. Warto pamiętać, aby parametryzacja była we wszystkich potencjalnych miejscach oraz o tym, żeby nie nazywać zasobów bez uwzględniania środowiska, ponieważ część zasobów (ich nazw) musi być unikalna, tak więc nie będziemy mogli wdrożyć naszych zasobów na inne środowiska, jeśli zmienna nie jest parametryzowana.

Przy przeprowadzaniu testów, warto upewnić się, że logujemy wszystkie nas interesujące dane, używając takich zasobów jak Application Insights czy Log Analytics Workspace

Podsumowanie, czyli krok 6

Raz na jakiś czas (optymalnie miesiąc) warto przeglądnąć punkty od 1 do 5 i sprawdzić, czy stosujemy się do nich. Przy każdej iteracji projektu warto tworzyć listę polityk, jeśli w ramach naszej firmy/projektu chcemy tworzyć zasoby zgodne z pewnymi zasadami bardzo polecam przyjrzeć się Azure Blueprints. Dzięki zastosowaniu blueprints możemy rozwiązać wiele problemów np. związanych z dostępami, oczywiście jest to długi i obszerny temat, ale też jeden z często występujących problemów czyli bardzo duży bałagan w AAD, co w późniejszym czasie może skutkować problemami z security.