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!

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.