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
Podczas planowania musimy wyznaczyć nasze cele oraz opracować wstępne założenia. Jakie w takim razie mogą być nasze cele?
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”
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.
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:
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”.
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
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.