Tydzień z Azure – odcinek 32

Idą święta więc Azure’owy Mikołaj przynosi worek prezentów dla miłośników chmury – wszystko od Azure Automation, przez DocumentDB, StorSimple, Web Apps, Azure Machine Learning i wiele wiele innych świątecznych łakoci dla wszystkich! 🙂

Zapraszamy do 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 12

Kolejny tydzień bogaty w nowości Azure. Nowe, zmienione, ulepszone funkcjonalności zarówno dla programistów jak i administratorów. W tym odcinku moim gościem jest Emil Wasilewski, który pracuje jako architekt systemów IT.

Zapraszam do oglądania!

Kurs MVA – Azure 101: Instalacja WordPress na Microsoft Azure

No i stało się! Kolejny odcinek Azure 101 jest dostępny. Tym razem ja opowiadam o tym, jak zainstalować WordPress na Microsoft Azure, czyli pokazuje jak został zainstalowany np. ten blog. Jest to jeden z kilku sposobów na taką instalację, na pewno najprostszy i najszybszy sposób 🙂

Zapraszam zatem do oglądania!

Wyłączanie ARR Affinity Session (sticky sessions) w Azure Web Sites

Microsoft Azure Web Sites ma zaimplementowany Application Request Routing co oznacza, że wspiera tak zwane sticky sessions. Co to oznacza? Oznacza to w dużym skrócie, że request, który przychodzi od kogoś, dostaje w nagłówku zwrotnym informację z jakiego serwera został obsłużony i przy jego każdym kolejnym requescie load balancer będzie kierował go do tego samego serwera.

Jest to bardzo fajne rozwiązanie kiedy np. chcemy w bardzo prosty i szybki sposób przenieść naszą istniejącą stronę do Azure, a strona ta nigdy nie była przystosowana do bezstanowości, a w szczególności do trzymania sesji użytkownika w jakimś zewnętrznym kontenerze (cache, baza danych etc.). Jednak gdy taką zmianę dodamy lub chcemy wykorzystać takie usługi jak Traffic Manager do rozdysponowania ruchu pomiędzy nasze wdrożenia warto jest wyłączyć sticky sessions i wykorzystać prawdziwą skalowalność chmury.

Na potrzeby wpisu mam wgraną na Azure prostą witrynę z szablonu ASP.NET w Visual Studio i zobaczmy jej ruch sieciowy w narzędziach developerskich IE (klawisz F12):

arrcokie

Widać, że zostało dodane ciasteczko z informacją o ARRAffinity.

Teraz żeby wyłączyć tę funkcjonalność należy do pliku web.config dodać następujący wpis:

  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Arr-Disable-Session-Affinity" value="true"/>
      </customHeaders>
    </httpProtocol>
  </system.webServer>

Teraz po odświeżeniu strony i podejrzeniu ruchu sieciowego zobaczymy, że nie ma już ciasteczka odpowiedzialnego za sticky sessions:

arrnocookie

Project Kudu – tylne wejście do Azure

Nawiązując do porównania, które na swoim blogu umieścił Scott Hanselman Azure Web Sites jest jednym z bardziej odizolowanych od samej platformy Azure środowiskiem. Ma to swoje plusy i minusy. Plusem na pewno jest łatwości wykorzystania, zapewnienie działania etc.. Minusem natomiast może być fakt niemożliwości skonfigurowania wielu rzeczy lub podejrzenia co się dzieje na różnych poziomach samej platformy. Nie wszystko jednak stracone bo mamy Kudu! 🙂

Project Kudu jak można przeczytać na jego oficjalnej stronie githuba jest silnikiem umożliwiającym deployment z poziomu git-a do Azure Web Sites. Jednak to zdanie było chyba napisane bardzo dawno temu bo obecnie Kudu potrafi dużo więcej!

Zacznijmy od zalogowania się do Kudu. Załóżmy, że adres naszej strony to http://mojamegasuperstrona.azurewebsites.net. Musimy go lekko zmodyfikować, aby wyglądał następująco https://mojamegasuperstrona.scm.azurewebsites.net. Po udanym logowaniu pojawi się nam się strona główna Kudu

projectkudumain

Na pierwszej stronie dostaniemy podstawowe informacje o naszym środowisku oraz linki do API REST-owego, dzięki czemu rzeczy, które dostarcza Kudu możemy także sami wywołać z poziomu kodu (sam Kudu tak naprawdę jest tylko nakładką UI na to API).

Druga zakładka Envoirement dostarcza bardziej szczegółowych informacji dotyczących naszego środowiska, w ramach , którego uruchomiona jest witryna. Podzielone są one na kategorię (jak na zdjęciu poniżej) i każda z tych kategorii zawiera szereg informacji. Część z nich jest dostępna z poziomu portalu zarządzania naszą witrynę, ale większość nie

projectkuduenv

Kolejna zakładka to Debug console, gdzie możemy sobie wybrać czy wolimy posługiwać się klasycznym wierszem poleceń czy PowerShellem 🙂 Dodatkowo znajduje się tam prosty explorer plików, z możliwością m.in. edycji, a także funkcją drag&drop więc jeśli szybko potrzebujemy przerzucić jakieś pliki na stronę można to zrobić w ten sposób

projectkududebugconsole

Idąc dalej znajdziemy zakładkę Process explorer, w której jak nie trudno się domyśleć, znajdują się informacje o działających procesach. Można podejrzeć właściwości wybranego procesu, pobrać memory czy GC dumpa, zobaczyć wątki,  moduły i dużo więcej. Przypominam, że to wszystko w przeglądarce! 🙂

projectkuduprocessex

Przedostatnia już zakładka to Tools. Znajdują się tam trzy narzędzia. Pierwsze z nich to Diagnostic dump, który powoduje tak de facto sciągnięcie katalogu Logs z naszej witryny, a tam będą znajdowały się różne logi, w zależności od tego co skonfigurowaliśmy w portalu dla naszej witryny. Log stream, powoduje wyświetlenie konsoli, która pokazuję w czasie rzeczywistym strumień logów, który możemy włączyć w panelu strony, a w kodzie aplikacji korzystać z metod klasy Trace, takich jak TraceError, TraceInformation, TraceWarning. Na samym końcu jest opcja Web hooks, która umożliwia podłączenie poprzez właśnie tę technologię różnych zewnętrznych serwisów. Przykładem może być tu Zapier, który potrafi się zintegrować z Azure Web Sites i ustawić jakąś akcję, która zostanie wykonana po deplymencie nowej wersji naszej wtiryny/aplikacji. Akcją to może być mail, sms, telefon i wiele, wiele innych 🙂

projectkudutools

Na sam koniec została zakładka Site extensions. Jak nazwa wskazuje są to rozszerzenia naszej witryny. O co chodzi. Chodzi o rozszerzenia, które nie są dostępne dla użytkowników, ale raczej dla administratorów. Jako przykład widać, że jest tutaj “Monaco“, czyli on-line’owa wersja Visual Studio, która umożliwia edycję plików witryny bezpośrednio w przeglądarce, czy np. phpMyAdmin, czyli są tu rzeczy, do których dostęp powinni mieć tylko administratorzy, ale działające w kontekście naszej witryny. Istnieje też galeria rozszerzeń, do której można wrzucać swoje rozszerzenia, można ją znaleźć pod adresem http://www.siteextensions.net/.

projectkudusiteexptensions

Ciekawą rzeczą jest też fakt, że Project Kudu można zainstalować u siebie na serwerze i korzystać z jego możliwości 🙂

Mam nadzieję, że dzięki temu narzędziu, oraz innym, które są przez nie dostarczane, łatwiejszy stanie się wgląd w bebechy
Azure Web Sites.

Hello World! from Microsoft Azure

Pierwszy wpis na nowo otwartym blogu! 🙂

Osoby, które mnie znają wiedzą, że mam już jednego bloga, którego można znaleźć pod adresem http://tomaszwisniewski.com. Postanowiłem jednak stworzyć nowego, który skupi się tylko na technologii Microsoft Azure, która jest mi najbliższa obecnie, bo od prawie dwóch lat cały czas z nią pracuję.

Wpisy na tym blogu będą bazowały na czymś co trudno na polski przetłumaczyć, a mowa o “lessons from the field”. Jako że na co dzień pracuję z klientami i partnerami w zakresie Azure często zadają mi różne pytania jak coś zrobić, jakie są możliwości aby osiągnąć zamierzony cel etc.. Na bazie tych pytań (oczywiście anonimowo 😉 ) będę tworzył kolejne wpisy, które dzięki temu staną się praktyczną wiedzą z zakresu wykorzystania Azure w różnych scenariuszach i będą pomocą w wielu sytuacjach.

Można też pokusić się o zadanie pytania, dlaczego tych wpisów nie umieściłem w swoim głównym blogu np. w osobnej kategorii? Powody są myślę dwa: jeden “miękki” drugi “techniczny”.

Miękki jest taki, że chciałem odseparowania treści pomiędzy tymi blogami. Nie wiem czy ten blog się przyjmie, czy będzie zainteresowanie (zakładam, że tak, ale wiadomo – różnie bywa 😉 ).

Techniczny natomiast jest taki, że ze względu, że blog ten jest o Microsoft Azure, to strona jest hostowana na samym Azure! 🙂 Postawienie tej strony zajęło jakieś +/- 60 sekund dzięki technologii Azure Web Sites, gdzie z galerii dostępnych aplikacji wybrałem szablon WordPress-a, wypełniłem podstawowe dane o witrynie, Azure założył dla mnie w tle także bazę MySQL (tak, w Azure TEŻ można wykorzystać bazę MySQL 🙂 ) i tyle. Chwila obserwacji napisu “Creating…” w portalu i strona gotowa do użycia. A gdyby strona się nie przyjęła, to mogę w każdej chwili ją skasować i przestać płacić za usługę, w zależności od ruchu jaki będzie generowany mogę ja dowolnie skalować – same zalety Azure! 🙂

Zachęcam zatem do odwiedzania strony i czytania różnych ciekawostek ze świata Microsoft Azure.