chmura

Chmura na przykładzie Microsoft Azure

Byłem wczoraj na wykładzie o Microsoft Azure. Prowadzący opowiadał tam ogólnie o tym jak skaluje się aplikacje w chmurach i szczegółowo o tym co ma do zaoferowania ta konkretna. Pokazał też bardzo fajne wzorce projektowe, których wcześniej nie znałem.

Na początku mowa była o tym że używanie chmury jest dobrym rozwiązaniem przy przyrostowym wytwarzaniu oprogramowania. Przy każdej iteracji można zwiększyć wydajność serwera jeśli to tylko potrzebne i  o tym, że można to zrobić w kilku kliknięciach. Prowadzący wychwalał przy tym prostotę interfejsu, w którym zmienia się parametry serwerów. Ja wiem, że takie klikane interfejsy dostarczane są przez wszystkich dostawców rozwiązań chmurowych. Wszystkie te interfejsy są łatwe w obsłudze.

Muszę tu wspomnieć o tym jak zwiększa się zasoby w chmurach. Można to zrobić na dwa sposoby:

  1. W pionie – dokładamy więcej pamięci i rdzeni procesora do maszyny.
  2. W poziomie – dokładamy więcej maszyn.

Lektor w celu zobrazowania tego, co chce przekazać, posługiwał się głównie przykładami opartymi o domniemaną infrastrukturę Netflix. Domniemaną z tego powodu, że firma nie udostępniła informacji o tym jak wygląda jej zaplecze. Wiadomo jedynie o tym, że oparta jest o mikroserwisy.

Podzielenie aplikacji na mikroserwisy daje tę przewagę, że kiedy jeden z nich przestanie działać, to użytkownik traci tylko jedną z funkcjonalności a nie dostęp do całego serwisu. Padł tutaj przykład predykcji filmów, które mogą się nam spodobać na podstawie tych, które już oglądnęliśmy. Główną funkcjonalnością serwisu Netflix jest strumieniowanie wideo i to ta usługa jest kluczowa. Kiedy wydzielimy przewidywanie do oddzielnego serwisu i to właśnie ta funkcjonalność przestanie działać, to nie wyrządzi to tyle szkody biznesowi jak kiedy padłby serwer ze wszystkim.

Mowa była także o serwerach bazodanowych. Relacyjne bazy danych są niepodzielne. Maszyny, na których pracują można skalować w pionie. Co jednak kiedy, cytując prelegenta, „uderzymy o sufit”? Tutaj padł przykład sieci salonów fryzjerskich. Wiemy o tym, że użytkownik szukając salonu fryzjerskiego, szuka tego, który jest najbliżej. Nie będzie potrzeby łączenia danych z wielu salonów na raz. Można więc wydzielić bazy poszczególnych salonów do różnych serwerów. Jeśli zajdzie potrzeba przeszukania wszystkich serwerów będzie to nadal możliwe ale wolne bo trzeba przeszukać wszystkie serwery bazodanowe.

Ktoś z sali zapytał o to, czy utrzymywanie serwisu internetowego w chmurze to dobry pomysł kiedy najbliższe data center Microsoftu znajduje się w Holandii a Polscy dostawcy mają swoje maszyny w kraju. Co z opóźnieniami? Mówca przyznał rację że opóźnienia będą większe ale różnice są tak niewielkie że nie są zauważalne dla użytkowników. Wyjaśnił także różnicę między standardową serwerownią a tą w chmurze. Wyobraźmy sobie sytuację kiedy utrzymujemy kilka serwerów dla gry, którą napisaliśmy. Jako twórca organizujemy turniej i wiemy że teraz zamiast kilku maszyn będziemy potrzebować ich kilkadziesiąt. Zapotrzebowanie to będziemy mieli tylko na czas trwania turnieju czyli kilka dni. W chmurze wystarczy pare kliknięć a u standardowego dostawcy, o ile w ogóle byłoby to możliwe, to zajęło by to o wiele więcej czasu. Dodać tu także trzeba że chmury mają uptime na poziomie 99% co jest niespotykane w Polskich firmach hostingowych.

Prowadzący pod koniec przyznał że wszyscy dostawcy rozwiązań chmurowych są równie dobrzy do utrzymywania aplikacji internetowych. Powiedział że to, co wyróżnia Azure na tle konkurencji to usługi dodatkowe niespotykane u innych. Za przykład posłużyła tu usługa sieci neuronowej. Poprzez kilka kliknięć uruchamia się taką sieć, która może na przykład posłużyć za mikroserwis do przewidywania filmów, które mogą się spodobać użytkownikom.

Prelekcja mówiła również o wzorcach projektowych w chmurze. Jeden z nich zaciekawił mnie bardziej niż inne. Wzorzec Repeat polega na tym że komunikat o błędzie z połączeniem wyświetla się użytkownikowi dopiero kiedy żądanie o zasób nie powiedzie się kilkukrotnie. Na przykład kiedy mamy na stronie przycisk zapisz, którego naciśnięcie powoduje wysłanie asynchronicznego zapytania. Komunikat o niepowodzeniu zapisu wyświetlamy użytkownikowi dopiero kiedy zapytanie zwróci kod 500 kilkukrotnie. Azure udostępnia usługę, która działa jak proxy dla zapytań i sama realizuje ten wzorzec. Przeglądarka użytkownika wysyła tylko jedno żądanie do proxy a ono zwraca do użytkownika kod 500 dopiero po kilku nieudanych próbach. Więcej wzorców można znaleźć na stronie https://msdn.microsoft.com/en-us/library/dn568099.aspx.

Tak jak pisałem wcześniej chmura ma sens także do utrzymywania stron internetowych. Warto zapoznać się  z usługami dodatkowymi żeby wybrać odpowiednią dla siebie.

Obrazek z vecteezy

2 myśli na temat “Chmura na przykładzie Microsoft Azure

  1. Ja generalnie nie przepadam za Azure – żeby debugować tworzoną apkę musimy mieć Visual Studio 2010 Ultimate, który jest cholernie drogi i cholernie wolny. Microsoft potrafi doskonale strzelać sobie w stopę.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *