Tydzień z Azure – odcinek #28

Czas na kolejny odcinek! Tym razem podczas wyprawy na konferencję Cloudyna razem z Mirkiem i Michałem po całym dniu słuchania, i prowadzenia sesji poczuliśmy potrzebę przekazania Wam najnowszych newsów ze świata Microsoft Azure! Zapraszamy o oglądania!

IaaS czy PaaS? Odwieczne pytanie chmurowców

Ostatnio dostałem prośbę od klienta o wycenę potencjalnego rozwiązania w Azure. Założenia, które zostały mi podane były następujące:

  • Maszyna wirtualna
  • 6-8GB RAM
  • Windows Server
  • Dostęp zdalny 3-5 użytkowników
  • IIS (do 10 użytkowników)
  • SQL Express (baza do 1GB)

Ogólnie patrząc na wymogi sprawa dość prosta. Jednak mając za sobą już trochę doświadczenia od razu w oczy rzuciły mi się dwa punkty zapalne “prostego” podejścia do tematu: dostęp zdalny (czyt. Remote Desktop – będzie tam zainstalowana aplikacji okienkowa oraz SQL Express). Zacznijmy jednak od początku 😉

Dla przypomnienia albo dla osób, które jeszcze nie widzą lub nie czują różnicy pomiędzy IaaS (Infrastructure as a Service) i PaaS (Platform as a Service) mały obrazek ilustrujący te różnice:

iaaspaas

To jest dość uproszczony widok, ale można powiedzieć, że w przypadku IaaS zarządzamy wszystkim od poziomu systemu operacyjnego wzwyż, a w przypadku PaaS tylko aplikacją i danymi. W większości miejsc jest to prawda, ale np. takie funkcjonalności jak Kudu w Azure App Service Web App pozwalają też w pewnym stopniu zarządzić samą maszyna wirtualną w środowisku PaaS.

Mając założenia, które podał partner sprawdźmy jakie byłyby koszty i architektura tego rozwiązania w Azure zarówno nakładając to na IaaS i na PaaS oraz jakie minusy i plusy każdego podejścia możemy znaleźć.

Zastrzeżenie: Podane tutaj ceny są cenami orientacyjnymi, nie są to oficjalne wartości cennikowe więc nie są w żaden sposób wiążące, a dają jedynie pogląd na różnicę w podejściu do wdrażania i tworzenia przykładowego rozwiązania.

IaaS – zacznijmy od architektury z maszyną wirtualną.

Dla podanych wymagań dobieramy sobię maszynę D2, czyli 2 rdzenie i 7GB RAM, która wg. strony kosztuje ~$272 miesięcznie.
Do tego mamy wymaganie IIS i 10 użytkowników – na szczęście w Azure nie ma problemu z licencjonowaniem użytkowników, którzy dostają się poprzez IIS zatem nie ma zaczenia czy będzie ich 2, 3, 10 czy 10000 – dopóki maszyna to uciągnie – be my guest! 🙂
SQL Express – darmowa baza danych więc na koszty nam nie wpłynie.
Zanim przejdziemy do najtrudniejszych rzeczy w tym podejściu zróbmy jeszcze te łatwe. Założyłem z zapasem, że będziemy potrzebowali około 100GB przestrzeni (wliczając w to system operacyjny) co daje nam kwotę miesięcznie ~$5.
Do storage trzeba jeszcze doliczyć transakcję, z dużym zapasem powiedzmy, że będzie ich 100 milionów, a to daje miesięcznie koszt ~$3,6.
Dorzućmy 50GB ruchu wychodzącego z Azure w miesiącu czyli ~$3,92.
Póki co nie jest źle, ale teraz przejdziemy do części najtrudniejszej czyli dostępu zdalnego aka Remote Desktop. Tutaj pojawia się dodatkowy zakup, który musimy policzyć, a mianowicie CAL-e RDS-owe. Zakładając 5 użytkowników i wybierając tańsze CAL-e per urządzenie to wychodzi nam 5 * ~$154 = ~$770.

Cena jak cena, ale to nie jest największy problem, który pojawia się w tym scenariuszu dla IaaS. Zgodnie z zapisami Azure, na dzień dzisiejszy aby maszyna miała SLA na poziomie 99,95% muszą być dwie maszyny tego samego typu w Availability Set, zatem kwotę ~$272 musielibyśmy pomnożyć x 2.

Ale to nadal nie jest najwiekszy problem. Myślę, że dużo większym problemem jest tutaj fakt, że mając dwie maszyny wirtualne, a na nich SQL Express jakoś trzeba synchronizować te bazy co w przypadku wersji Express nie jest zadaniem trywialnym mówiąc lekko 😉

Podsumujmy póki co koszty dla IaaS, a do dalszych wniosków jeszcze dojdziemy (liczę wersję z pojedynczą maszyną wirtualną ze względu na problemu techniczne sycnhronizacji SQL Expressa pomiędzy dwiema instancjami):
~$272 + ~$5 + ~$3,6 + ~$3,92 + ~$770 = ~$1055.

PaaS – poświęćmy chwilę czasu i zastanówmy się jak można wykorzystać komponenty Platform as a Service i być może zbudować architekturę rozwiązania trochę inaczej.

Zaczniemy od potrzeby hostowania strony WWW. Tutaj idealnie nada się Azure Web App. Jeśli wyjściowy serwer miał mieć 6-8GB RAM, a teraz dla WWW odciążamy go z hostowania bazy SQL, aplikacji okienkowych, to możemy wystartować z poziomu S2 (Standard) (trzeba pamiętać, że wariant zawsze na słasbszy/mocniejszy można zmienić), czyli są to 2 rdzenie i 3.5GB RAM, a miesięcznie kosztuje to ~$149. A dodatkowo w przypadku Web App wystarczy nam jedna instancja dla SLA na poziomie 99,9%! 🙂

Kolejny istotny komponent to baza danych. Tutaj żeby skorzystać z technologii PaaS należałoby się zmigrować do Azure SQL Database. Pod tym linkiem  znajduje się opis migracji takiej bazy. Trzeba pamiętać, że SQL Database jeszcze nie obsługuje wszystkiego co “standardowy” SQL Server, ale zgodność w moim odczuciu jest na poziomie ~95%, a dla bazy, która działa na SQL Express myślę, że nawet 99%. Przy tej wielkości rozwiązania, baza S2, która kosztuje miesięcznie ~$75 będzie wystarczająca. Dodatkowo zostaje z nas zdjęta potrzeba zarządzania bazą danych pod wieloma względami.

Takie rzeczy jak storage, transakcje, ruch wyjściowy możemy zostawić bez zmian ze względu na pomijalne koszty, a np taki ruch wyjściowy będzie niższy bo usługa, o której mowa poniżej ma taki ruch wliczony w cenę 🙂

No i dochodzimy do najwazniejszego punktu wyliczenia dla PaaS czyli dostępu zdalnego dla aplikacji okienkowych. W Azure taka usługa oczywiście jest i nazywa się ona RemoteApp. Na dzień dzisiejszy jej wyliczenie jest dość mało intyicyjne, dlatego spieszę z pomocą 🙂 W chwili obecnej jest pewien minimalny limit użytkowników, dla których trzeba wykupić RemoteApp, a jest to 20. Co powoduje, że wykupienie RemoteApp w miesiącu dla naszego scenariusza będzie kosztowało ~$200. Ale to nie całościowa cena RemoteApp. Każdy użytkownik RemoteApp ma wliczone w standardową cenę 40 godzin użytkownia. Powyżej tego czasu każda godzina jest naliczana, ale co bardzo fajne, jest maksymalna kwota per użytkownik i w wawiancie Basic, o którym tu mówimy wynosi ona ~$17. Zatem do tych $200 musimy doliczyć jeszcze przekroczenie 5 użytkowników i dodatkowo załóżmy, że maksymalnie przekroczą swój czas czyli finalnie cena naszego RemoteApp wyniesie ~$200 + 5 * ~$17 = ~$285.

Reasumując nasze koszty dla PaaS wychodzi nam:
~$149 + ~$75 + ~$5 + ~$3,6 + ~$3,92 + ~$285 = ~$522.
Czyli prawie połowę taniej! 🙂

WNIOSKI
Można by na podstawie samej ceny powiedzieć łatwo i szybko, że PaaS bije IaaS na głowę i w ogóle nie ma co się zastanawiać nad wyborem i dlatego też tytuł tego wpisu był nieco przewrotny 😉 . Chcę jednak BARDZO mocno podkreślić, że jestem BARDZO daleki od takiego wniosku. Zarówno scenariusze Infrastructure as a Service jak i Platform as a Service mają swoje miejsce. Różne są potrzeby dla różnych rozwiązań i nie wszystko wszędzie daje się zrobić tak samo łatwo lub w ogóle jest możliwe. Ten powyższy scenariusz, który dostałem do opracowania dobitnie pokazuje to, co chciałbym aby było najważniejszą rzeczą, która zostanie wyniesiona z tego wpisu – patrząc na chmurę, zastanwiając się nad rozwiązaniami, które tam chcemy wdrożyć, nie wolno patrzeć na nią jak na prosty hosting (bez żadnej obrazy oczywiście dla hostingu 😉 ). Warto poświecic parę chwil na zastanowienie się nad możliwościami jakie daje chmura, poświęcić też może trochę czasu na migrację pewnych rzeczy do nowych technologii, a w jakiejś (zazwyczaj dobrze określonej perspektywie czasu) jesteśmy w stanie łatwo zauważyć korzyści, które płyną z naszej pracy, przemyślenia i wdrożenia czegoś np w Microsoft Azure.

Jeśli komuś natomiast brakuje doświadczenia w kwestiach chmurowych, to oczywiście zapraszam do kontaktu ze mną – razem z koleżankami i kolegami z działu Developer Experience (nazwa może i mylącą, ale administratorzy systemów też są mile widziani 🙂 ) na pewno będziemy w stanie porozmawiać i pomóc!

Tydzień z Azure – odcinek 22

W dwudziestym drugim (wow, jak ten czas leci!) odcinku nowości z całego spektrum Azure: SharePoint, DocumentDB, Web App, VM, Linux, Backup, Storage i certyfikacje. Nowe pomieszczenie i lekka modyfikacja w formacie prezentacji – ciekawe czy sie przyjmie.

Zapraszam do oglądania! 🙂

Tydzień z Azure – odcinek 9

Kolejny super tydzień nowości w Microsoft Azure. W dziewiątym odcinku ogarnąć to pomaga mi Michał Smereczyński, który jest związany z Azure od bardzo dawna. W tym odcinku wszystko od nowości w portalu, nowe maszyny wirtualne, a skończywszy na Linuxie i Open Source.

Zapraszam do oglądania! 🙂

Pingowanie maszyn wirtualnych (oraz pingowanie z maszyn wirtualnych)

Dość często pojawia się potrzeba pingowania maszyny wirtualnej w Azure lub pingowanie na zewnątrz z maszyny wirtualnej. Jeśli spróbujemy wykonać prosty test:

PS C:\> ping pingdemotw.cloudapp.net

Pinging pingdemotw.cloudapp.net [191.238.97.93] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 191.238.97.93:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
PS C:\>

To zobaczymy, że nie da się takiej operacji przeprowadzić.

I tak samo stanie się kiedy spróbujemy wysłać pinga z wewnątrz maszyny wirtualnej:

PS C:\> ping www.microsoft.com

Pinging lb1.www.ms.akadns.net [134.170.184.133] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 134.170.184.133:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
PS C:\>

Sytuacja ta wynika z faktu, że na load balancerze, który jest w Azure blokowany jest ruch ICMP.

Najprostszym rozwiązaniem tej sytuacji jest skorzystanie z narzędzia PsPing, które jest częścią pakietu Sysinternals 🙂 Aplikacja ta pozwala wykonywać ping po protokole TCP a nie ICMP więc pozwoli nam wykonać takie testy.

Po jej sciągnięciu i zainstalowaniu można wykonać polecenie jak poniżej, podając dodatkowo otwarty port (za pomocą endpointa) dla naszej maszyny i dzięki temu otrzymamy wyniki:

PS C:\> psping pingdemotw.cloudapp.net:61025

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 191.238.97.93:61025:
5 iterations (warmup 1) connecting test:
Connecting to 191.238.97.93:61025 (warmup): 57.06ms
Connecting to 191.238.97.93:61025: 54.98ms
Connecting to 191.238.97.93:61025: 55.69ms
Connecting to 191.238.97.93:61025: 54.53ms
Connecting to 191.238.97.93:61025: 56.86ms

TCP connect statistics for 191.238.97.93:61025:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 54.53ms, Maximum = 56.86ms, Average = 55.51ms
PS C:\>

No i oczywiście z poziomu samej maszyny wirtualnej też zadziała w drugą stronę:

PS C:\> psping www.microsoft.com:80

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 134.170.184.133:80:
5 iterations (warmup 1) connecting test:
Connecting to 134.170.184.133:80 (warmup): 140.72ms
Connecting to 134.170.184.133:80: 140.81ms
Connecting to 134.170.184.133:80: 140.67ms
Connecting to 134.170.184.133:80: 140.78ms
Connecting to 134.170.184.133:80: 140.81ms

TCP connect statistics for 134.170.184.133:80:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 140.67ms, Maximum = 140.81ms, Average = 140.77ms
PS C:\>