Tym razem z innej beczki. Nie należy to typowo do serii “Z dziennika architekta”. To można bardziej przyjąć, że jest rozszerzenie wpisu w Changelogu: Pika Note v1.3.66 - Changelog. Zdecydowałem, że ostatecznie nie jest mi potrzebne utrzymywanie systemu używając Azure. Było kilka kwestii, które przemyślałem przed podjęciem decyzji o migracji, ale ostatecznie zmigrowanie backendu na lokalne maszyny.

Tylko czemu w ogóle Azure?

Dosłownie odpowiedź to: bo mogłem. Wykorzystałem Azure jeszcze w czasach studenckich, aby tylko się poduczyć, to pokrywało się z podstawami do AZ-900, a jeszcze wtedy zamierzałem ew. taki egzamin zdawać. Stąd podjąłem decyzję, że wykorzystam CosmosDB, App Service, a potem do tego dorzuciłem bardziej rozwiniętą konfigurację dotyczącą Networkingu, podpięcie pod własną domenę itd. Od pewnego czasu, jednak nie skalowałem tego, nie korzystałem z żadnych nowych funkcjonalności, nie uczyłem się tego dalej. A jednocześnie moje lokalne serwery też działają nadal, więc zacząłem zastanawiać się na ile jest mi nadal ten deployment na Azure potrzebny. Wniosek prosty: no nie jest.

Co rozważałem?

Rozważałem m.in. czy dorzucenie kolejnego, zreplikowanego backendu nie podniesie zużycia procesora i RAM na tyle, że i prąd skoczy jakoś wybitnie. Ale oczywiście nie ma to takie znaczenia, bo wszystkie komponenty, których potrzebowałem na Azure, a były płatne łącznie kosztowały od 90 do 100zł (Zależnie od kursu Euro) na miesiąc. Dorzucenie małego backendu przy moim ruchu nie spowoduje dołożenia tak dużego obciążenia, by skok kosztu za prąd wyniósł więcej jak 100zł. Dodatkowo, łączenie systemów przez WAN jest również mniej wydajne niż po LAN, a więc też kwestia wydajności i UX były tu dla mnie istotne. No i ostatnia kwestia - zawsze to lepiej mieć u siebie niż u kogoś. Fakt, faktem, że notatek (treści) Azure nie przechowywało, ale nadal lepiej mieć jak najwięcej u siebie skoro i tak mam już swoją “infrastrukturę”.

To co zostało zmigrowane?

W zasadzie całość. Na Azure były:

• API (App Service),
• Azure Container Registry,
• Azure DNS,
• Azure Private Endpoint
• Azure CosmosDB

W zasadzie każde z powyższych poza CosmosDB jest płatne. Oczywiście, wszystkie są płatne, po prostu CosmosDB jest darmowy do pewnego poziomu “throughput”. I jest to jedyny komponent, który nie został przeniesiony. Faktycznie w tym momencie baza danych jest dostępna poprzez zewnętrzny endpoint, ale jest to rozwiązanie tymczasowe. Sama usługa CosmosDB jest dopasowana do bycia wystawianą do WAN (posiada szyfrowanie, wymuszenie logowania po clientId i secretcie). Dodatkowo, sama baza, jak wpsomniałem, zawiera tylko deskryptory notatek, żadnych danych osobowych, a nawet ścieżki obiektów notatek są zaszyfrowane. To też nie trzeba nawet dodawać (również) płatnego CosmosDB Gateway’a, aby dodatkowo zabezpieczyć połączenie do tej bazy, bo docelowo ta baza zostanie zastąpiona MongoDB (lub ew. inną baza dokumentową, ale o tym wpis też będzie). Zanim jednak przepiszę cały backend na użytkowanie nowego silnika bazodanowego uznałem, że można “zaryzykować” taką migrację, dlatego, że jest to i tak tylko moje prywatne rozwiązanie, które posiada na tyle dobre zabezpieczenia po stronie Azure’a, by przetrzymało okres przejściowy. Oczywiście, rozważałem zabezpieczenie tego dodatkowo przepuszczając ruch przez network z wykluczeniem z zawężeniem źródła i dodatkowy filtr z cache’em, ale to generowało by dodatkowy koszt, a chciałem usunąć koszty z Azure’a. Stąd taka, a nie inna decyzja. Rozważania dot. wyboru silnika bazy danych NoSQL do użytku wewnątrz mojego systemu (czyli jako cel mgiracji z CosmosDB) przygotuję w odrębnym wpisie “Z dziennika architekta”.