Condividi tramite

10 porad jak oszczędzać kasę w Microsoft Azure – do bólu i bez ściemy. Epizod 4

  • Articolo

Mam nadzieję, że dotarłeś tutaj, bo czytałeś 3 poprzednie nasze wpisy na temat oszczędzania i już wiesz, że chcesz poznać więcej trików. Jeśli nie czytałeś, wróć na początek serii. Zapraszam Cię do kolejnych 3 porad ale ostrzegam :), dziś będzie nieco bardziej technicznie. Dlaczego? Bo na koniec dnia koszty Twojego środowiska w chmurze w dużej mierze zależą od tego, jak wydajnie zbudowana jest Twoja aplikacja i z jakich rozwiązań korzysta. Paradygmat o tym, że lepiej optymalizować rozwiązanie niż "dorzucać więcej mocy przetwarzania" i w chmurze jest prawdziwy.

Zanim jednak wejdziemy w porady. Czy wiedziałeś, że ponad 16 usług w Azure możesz mieć zupełnie za darmo? https://azure.microsoft.com/en-us/free/pricing-offers/ Do pewnego poziomu użycia wiele usług nic nie kosztuje. Czy te darmowe oferty zawsze wystarczą by uruchomić coś produkcyjnego? Pewnie nie zawsze, ale aby poznać usługę, rozpocząć pierwsze konfiguracje czy nauczyć się choćby interfejsu, już tak.

Jeśli nie masz telemetrii w swojej aplikacji to popełniasz grupy błąd

Nie narzekaj też wtedy, że aplikacja działa wolno bo nawet nie będziesz umiał tego dobrze zdiagnozować. Zdecydowanie musisz poznać Application Insights. Nie tylko dowiesz się jakie są średnie czasy odpowiedzi Twojej strony, jak długo się ładuje, ilu ma unikalnych użytkowników ect… Najważniejszą cechą AppInsights jest to, że wykrywa sytuacji odbiegające od normy i pokazuje zależności zdarzenia od np. czasu odpowiedzi bazy czy innego serwisu z którego korzystasz. Daje to potężne wsparcie przy analizie zachowania aplikacji, rzuć okiem na przykłady App Insights Dependency. Polecam Ci też zobaczyć takie raporty jak 10 najdłużej ładujących się stron czy 10 najdłużej wykonujących się zapytań. Usługa poza zapisywaniem danych i prezentowaniem, pozwala Ci je szybko przeglądać i analizować. Narzędzie Analytics (tu masz demo https://analytics.applicationinsights.io/demo) pozwoli Ci zrobić własne analizy ale też pokaże miejsca, gdzie masz potencjalny problem (tzw. Smart Diagnostics). To nie koniec... Smart Detection samo wyśle Ci maila, jeśli zauważy, że wzrósł np. średni czas odpowiedzi. Poza tym, że dostaniesz maila, to na portalu zobaczysz na jakiej podstawie telemetria dokonała takiej analizy i pokaże Ci requesty, które za taki stan rzeczy odpowiadają.

Aha, mega ważne dla tych, którzy uważają, że Azure wspiera tylko technologie z Redmond. AppInsight nie działa tylko z .Net, lista wspieranych platform jest tutaj: /en-us/azure/application-insights/app-insights-platforms i co ciekawe, rozwija ją też community.   

Pogadajmy wreszcie o kasie. Jeden z moich klientów ma… ponad 90 usług AppInsight. Płaci tylko za 6 z nich, pozostałe 84 są nieodpłatne. Te 6 usług monitoruje serwisy produkcyjne, gdzie zbierany jest duży wolumen danych (po ok. 5GB danych telemetrycznych per serwis). Łączny koszt miesięczny jest zawrotny, mniej niż 100$ .

Jeśli jeszcze nie masz AppInsight a chcesz zmniejszyć swój rachunek, zobacz jak działa Twoja aplikacja i pomóż jej działać wydajniej.

Architektura Twojej aplikacji powinna umiejętnie korzystać z chmury

Ta porada powinna, tak naprawdę. być pierwsza. Architektura aplikacji to będzie przecież to, od czego zaczniesz budowę swojej aplikacji.

Warto przy tej okazji zadać sobie kilka pytań:

  1. Czy Twoja aplikacja musi korzystać z dysków SSD w maszynie wirtualnej by uzyskać odpowiednią wydajność przy odczycie danych? Warto pamiętać, że zwykły Storage Account ma wydajność nawet do 20 000 IOPS i kosztuje Cię ok. 0.02$ za GB za miesiąc z naliczaniem dziennym.
  2. Może zamiast VM'ki możesz skorzystać z usług PaaS dla dostarczania Twojej aplikacji? Wydajność będzie podobna ale koszt utrzymania PaaS (vs. IaaS) jest niższy. Pamiętaj, że nie jest istotne ile usługa kosztuje ale jakie jest jej Total Cost of Ownership. Dla usług Web, API czy Backend usługi PaaS są dla mnie naturalnym wyborem.
  3. A co powiesz o koncepcji Serverless? Jeśli nie wiesz czym są funkcje to błąd. I to duży. Nie twierdzę, że od razu cała Twoja aplikacja zostanie przepisana na funkcje ale zobaczy czym one są i jaki jest ich model kosztowy. Po przykłady wyliczeń zapraszam Cię tutaj: https://azure.microsoft.com/pl-pl/pricing/details/functions/. Jeśli nie wiesz jak zacząć z Functions, polecam Ci blog Gutka. Oczywiście, niektórzy powiedzą, że Serverless jako koncepcja jest młoda, świeża i jeszcze ma wiele "niewygód". Dyskusje pewnie można toczyć długo ale nikt nie odbierze funkcjom tego, że są tanie. Bardzo tanie i bardzo przejrzyste w swoich kosztach.
  4. Boisz się, że Twoją aplikację zabije duża liczba requestów? Zobacz Azure API Managemenet. Serwis jest mało popularny w Polsce a pozwala Ci wystawić bramkę przed Twoim API, która za Ciebie wykona autoryzację zapytań, ograniczy limit zapytań czy wreszcie pozwoli Ci wystawić to samo API w różnych wersjach na świat. Narzędzie o potężnych, a mało znanych możliwościach.

Chcesz więcej? Czy sprawdzałeś kiedyś jak działa Azure Tables? Co ty na to, by była to twoja prosta baza dla parametrów konfiguracji? Szybkie, tanie i łatwe w kodowaniu. Potrzebujesz kopiować dane po wielu kontach danych czy kopiować dane z DocumentDB? Azure Data Factory - znowu niezwykle tanie i bardzo pomocne przy wielu scenariuszach, a rzadko wykorzystywane. Robisz replikację Azure SQL do innego ośrodka? A czy wiesz, że baza w drugim ośrodku może być mniejsza (np. S0 zamiast S3)?

Takich pytań możemy postawić sobie wiele. Zanim zbudujesz aplikację w chmurze, zbuduj architekturę swojej aplikacji i sprawdź czy Twoje architektoniczne decyzje mają sens ekonomiczny. Warto zainwestować w kogoś, kto Ci pomoże w tym procesie. ROI dla takiej inwestycji jest nie policzalne, szczególnie na początku.

A środowisko zapasowe? Nie wycierajmy sobie twarzy koncepcją "Infrastructure As a Code"jeśli z niej nie korzystamy.

Środowisko zapasowe w tradycyjnym jego rozumieniu nie pasuje nieco do modelu chmurowego. Pytanie… czy naprawdę musisz mieć cały czas dostępne środowisko działające w drugim regionie? Nie wystarczy Ci np. replika danych do tego regionu czy kopie zapasowe? Jeśli boisz się, że całe DC wyleci w powietrze poza Backupem użyj DataFactory i kopiuj dane w inne miejsce. Pomyśl tak... być może możesz:) "oskryptować" tworzenie tego środowiska i stworzyć je, gdy będzie taka biznesowa potrzeba. "Infrastructure As a Code" to potężna koncepcja i trzeba nauczyć się z niej korzystać. Serio. Rzuć okiem na krótki a potężny wpis. Wraz z jednym zespołem przygotowaliśmy skrypt do postawienia środowiska w drugim ośrodku, ustawiliśmy "deployment" paczek z kodem, przygotowaliśmy skrypty do migracji parametrów, skrypty do rozgrzania aplikacji, ect. Efekt jest taki, że od momentu podjęcia decyzji o migracji do czasu postawienia drugiego, pełnego rozwiązania mija mniej niż 2 godziny a ciągle kilka zadań możemy zoptymalizować. Fajnie prawda? Najlepsze jest to, że za to drugie środowisko nie płacę dopóki nie muszę go postawić.  

To była już 12 porada, przed nami jeszcze kilka. Epizod 5 już się pisze i to nie jest nasze ostatnie słowo! Miłego oszczędzania.

Comments