Tydzień z Azure – odcinek 25 (EN)

This week a special guest all they from Australia – Troy Hunt, who is a well known Pluralsight author, Microsoft MVP and the creator of a very popular web sites – http://www.haveibeenpwnd.com. Besides the weekly portion of news Troy does a great overview of “Have I Been Pwnd” site and how it’s hosted on Azure!

Enjoy the show! 🙂

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 17

Do 17 odcinka udało mi się zaprosić super gościa, wprost z Redmond – Jakub Jędryszek – Software Engineer pracujący dla Microsoft nad nowym portalem Azure. Ponadto Jakub prowadzi bloga jj09.net oraz jest współorganizatorem wirtualnej konferencji dla .NET Developerów dotNetConfPL. W tym odcinku bardzo dużo nowości ogłoszonych przy okazji konferencji //BUILD/.

Zapraszamy do oglądania! 🙂

Tydzień z Azure – czwarty odcinek

Czwarty odcinek “Tydzień z Azure” prowadzę razem z Bartkiem Zassem, a nowości w zeszłym tygodniu pojawiło się bardzo dużo, no to i odcinek wyszedł nam trochę dłuższy niż “przeciętnie”, ale myślę, że warto oglądać! 🙂 Zapraszam!

Microsoft Azure SQL Database Server – kasowanie pustych serwerów z poziomu PowerShell-a

Jak pisałem już kiedyś, Azure’a wykorzystuję m.in. bardzo mocno w scenariuszu developersko/testowo/prezentacyjnym. Często tworzę jakieś bazy danych, czy to przy prezentacjach, albo testując różne rzeczy. Zazwyczaj przy okazji tworzenia nie tworzę ich na istniejących serwerach tylko tworze nowy serwer. Później kasuję np. Web Site’a i on kasuje samą bazę danych, ale serwera już nie. Pojawia się wtedy problem, że w mojej subskrypcji jest dużo serwerów, które nie mają żadnych baz. Nie jest to jakiś wielki problem, ponieważ taki pusty serwer bez bazy nie generuje żadnych kosztów i na nic nie wpływa, oprócz mojego poczucia estetyki 😉

W portalu bezpośrednio nie ma informacji o tym czy dany serwer ma jakieś bazy danych. Trzeba by się przeklikać po każdym serwerze i zobaczyć czy ma jakieś bazy. Lepszym natomiast rozwiązaniem jest na pewno skorzystanie ze skryptów PowerShella, które ułatwiają wiele czynności, jak m.in. ta, dlatego napisałem mega prosty skrypt, który taką czynność wykonuje.

# Get the list of server from a subscription
$myServers = Get-AzureSqlDatabaseServer | ForEach-Object {$_.ServerName}
# Iterate through the list of server
foreach ($server in $myServers)
{
    # Get the list of databases for the given server
    $databases = Get-AzureSqlDatabase -ServerName $server
    # Check the count od DBs on a given server. One DB means that there is only the master DB on the server
    if ($databases.count -eq 1)
    {
        # Extra check to make sure that the single DB is the master db, so no user DBs are deleted
        $checkArray = $databases | ForEach-Object {$_.Name, $_.Edition}
        if ($checkArray[0] -eq "master" -and $checkArray[1] -eq "System")
        {
            # Deleting the DB
            Remove-AzureSqlDatabaseServer -ServerName $server -Force
            Write-Host "Server: " -NoNewline; Write-Host $server -NoNewline; Write-Host " has been deleted."
        }
    }
}

Działanie jest bardzo proste. Najpierw pobierana jest lista serwerów z subskrypcji. Następnie dla każdego serwera pobierana jest lista baz danych. Jeśli zwracana jest tylko jedna baza danych to jest to kandydat do skasowania. Jedna baza danych oznacza, ze jest to baza master, a nie baza użytkownika. Dodatkowo dodałem sprawdzanie czy faktycznie ta baza to baza master, gdyby nagle w jakiejś wersji cmdletów przestała taka baza być zawracana to wolałbym nie skasować sobie serwera z bazami danych 🙂

Skrypt jest mega prymitywny, można by go pewnie ulepszyć na kilka sposobów, dodać jako workflow itp., ale na moje potrzeby wystarcza. Można go dodatkowo wykorzystać w Azure Automation i dzięki temu np. ustawić, że skrypt ma się uruchomić codziennie o 17 kiedy kończymy pracę, albo raz w tygodniu, dzięki czemu nasza subskrypcja będzie czysta 🙂

Jeśli ktoś nie wie jak skorzystać z cmdletów PowerShell-a do Azure zapraszam do odwiedzenia tej strony.