Czym się różni PaaS od hostingu?

Czym się różni PaaS od hostingu?

PaaS (Platform as a Service) i współdzielony hosting są usługami dla zupełnie innych odbiorców, dlatego istotnie się różnią, pomimo pozornego podobieństwa. Platforma jako usługa ma konsolę z ilością ustawień przypominającą kokpit samolotu. Hosting z kolei bardziej przypomina pilota od Apple TV 😊 Kto korzystał z obu tych usług, nigdy ich nie pomyli. Nadmienię jednak, że ostatnio, szczególnie u największych usługodawców, oblicze hostingu trochę się zmienia.

Mniej więcej 20 lat temu zbudowałem biznes „hostingowy” B2B (nie podejmuje się tłumaczenia tej nazwy), i byłem wówczas w Polsce jednym z nielicznych dostawców. Sam od lat jestem użytkownikiem współdzielonego hostingu od GoDaddy (cPanel) i Zenbox. Jakieś 3 lata temu odkryłem alternatywę w postaci Platformy jako Usługi (PaaS). A w ubiegłym roku postanowiłem włączyć się do gry jako usługodawca PaaS. Poznałem zatem blaski i cienie każdego rozwiązania, w dodatku z obu perspektyw – dostawcy i klienta.

Zacznę od tego, że hosting nie spełnia kryteriów chmury. Otóż, według National Institute of Standards and Technology, chmurę definiuje kilka charakterystycznych elementów (str 2). O ile przy hostingu możemy mówić w jakimś stopniu o samoobsłudze, o tyle już o rozliczeniu za użycie, czy automatycznej skalowalności możemy zapomnieć. Hosting ma być prosty i ładnie opakowany. Zwykle klient dostaje do wyboru 3 sztywne pakiety, bo większy wybór wywołuje niepotrzebny ból głowy. Niekiedy usługodawca umożliwia klientowi przełączanie się między pakietami, trzeba to jednak zrobić ręcznie. Tyle w kwestii skalowalności, a teraz przejdźmy do kwestii rozliczeń.

Cechą podstawową hostingu jest ryczałt. Zapewne ten fakt, jak i agresywna polityka cenowa dostawców sprawia, że hosting jest tak atrakcyjny dla klientów. Ale uwaga, bo tu jest haczyk. Jak wiemy z lekcji ekonomii, zasoby są zwykle ograniczone. Bardzo to uwydatnia się przy hostingu, gdzie współdzielenie mocy obliczeniowej, pamięci i przestrzeni dyskowej nie zawsze odbywa się w sposób uczciwy. Każdy dostawca zakłada jakąś nadsubskrypcję usług. Przyjmuje zatem, że kupujący nie wykorzysta 100% zasobów przypisanych mu w ramach pakietu. Mało tego, często przyjmuje się, że klient sięgnie po nie więcej niż 10-20%. Przy kilkuset klientach to już spora oszczędność. I tu jest właśnie największa słabość tej oferty.

No dobrze, a co z odpornością na awarie? Wybierając ofertę dostawców hostingu nie mamy zupełnie kontroli nad poziomem niezawodności usługi. Owszem, możemy robić backup bazy danych, czy kopię zapasową plików, jednak na tym kończy się nasza lista możliwości.

Takie opcje jak balansowanie ruchu, klastry wysokiej dostępności, regiony geograficzne, replikacja czy autoskalowalność to domena rozwiązań klasy PaaS lub IaaS, a więc chmury publicznej. W rezultacie, niezawodność usług hostingowych zależy od decyzji biznesowych dostawcy. Te decyzje są zwykle pokłosiem poziomu świadomości technicznej, nakładów oraz wynikającej z nich architektury rozwiązania.

Jak wygląda odtwarzanie awaryjne naszego e-commerce w sytuacji jakiegoś incydentu po stronie dostawcy hostingu? Oznacza najczęściej oczekiwanie aż usługa znowu zacznie działać. Można oczywiście podjąć próbę uruchomienia wszystkiego u innego usługodawcy, a potem zrobić przekierowanie domeny w serwerze nazw, ale będzie to proces żmudny i, może się okazać, że niepotrzebny. Tutaj trzeba oddać sprawiedliwość hostingodawcom, bo choć wpadki zaliczają, to zwykle przerwy w dostępności są krótkotrwałe. Gorzej, gdy wydarzy się coś katastrofalnego w skutkach. Wówczas, RTO może wynieść nawet kilka dni (wspomniana odbudowa w innym miejscu), a RPO może oznaczać zgubienie transakcji z 24 godzin, pod warunkiem, że kopie zapasowe bazy trzymamy w innym miejscu.

Spójrzmy na zagadnienie z perspektywy Platformy jako Usługi. Możliwości konfiguracyjne są bardzo rozbudowane, co sprawia, że nieobeznany użytkownik poczuje się zagubiony.

PaaS nie jest dla kogoś kto nie wie, co to jest Apache, NGINX, Varnish, PHP, Memcached, albo czym różni się baza SQL od NoSQL, czy skalowanie stanowe od bezstanowego. Nagrodą za tę wiedzę jest kontrolowana skalowalność, nadmiarowość i bezpieczeństwo usługi oraz spore możliwości.

Przyjmijmy, że aplikacja, którą mamy używać wymaga różnych, precyzyjnie skonfigurowanych bibliotek oprogramowania, aby działać optymalnie. W hostingu jest to właściwie niemożliwe, a w PaaS to podstawowa funkcjonalność. Podobnie jest z dynamicznym przydzielaniem większej ilości zasobów obliczeniowych. Gdy uruchomicie kampanię i nagle do Waszego sklepu „zajrzy” 1000x więcej klientów niż dotychczas, co wtedy? W 99% przypadków wasz dostawca hostingu wyświetli im komunikat błędu kategorii pięćset – np. limit zasobów, wewnętrzny błąd serwera, itp. Coś takiego nie wydarzy się jednak w przypadku PaaS. Chmura załatwia to w locie, dodając pamięć, moc, a jak trzeba także kolejne serwery. Dostaniecie też powiadomienie, że obciążenie wzrosło, aby ewentualnie samemu zdecydować jak ma się dalej zachować wasze środowisko.

Sceptyk od razu przyczepi się, że to pewnie sporo kosztuje. I tak i nie. Owszem, nie ma ryczałtu, więc jest trochę niepewności dotyczącej tego, jaki będzie ostateczny koszt. Dużo zależy od sposobu korzystania z usługi. Moje analizy wykazały, że dla podobnych usług ceny są prawie takie same. W GoDaddy na przykład ryczałt roczny za 1 publiczny adres IP to koszt 287 zł netto. Na platformie PaaS Cloudlets.Zone to 3 gr za godzinę, a więc 262 zł brutto za rok. W dodatku nie trzeba przedpłacać. Jeśli uwzględnić możliwość usypiania środowisk w chmurze to już naprawdę hosting staje się mało opłacalny. Po co na przykład system do wideokonferencji ma działać całą dobę? Można go przecież automatycznie zagasić, powiedzmy o 22:00, by potem kalendarzowo włączyć o 7:00.

Mam nadzieję, że lektura tego artykułu dała odpowiedzi na postawione w tytule pytanie. Choć hosting pojawił się o wiele wcześniej, niż moda na chmurę, wciąż jeszcze ma się dziś dobrze, z resztą nie tylko w Polsce. Tym niemniej, wraz z rosnącymi potrzebami i świadomością klientów, PaaS może okazać się potencjalnym, bardzo ciekawym następcą rozwiązań hostingowych.

Wypróbuj PaaS

Nadmiarowość, czy odtwarzanie po awarii?

Nadmiarowość, czy odtwarzanie po awarii?

Czym jest uptime i jak się to ma do czasu przestoju?  Ile dziewiątek po przecinku gwarantuje względny spokój, gdy mowa jest o wysokiej dostępności infrastruktury informatycznej? I na koniec, na co postawić: na nadmiarowość czy może na błyskawiczne odtwarzanie po awarii?

Czy wiesz jaki poziom dostępności mają Twoje systemy?  Najlepsze centra danych w Polsce (np.: Atman, Beyond, Exea, Polcom, T-mobile), mogą pochwalić się niezawodnością na poziomie 99,99%. Oznacza to, że ich przestój w skali roku nie przekroczy godziny. Zwracam jednak uwagę, że procenty dotyczą określonych usług. Już tłumaczę. Powiedzmy, że zdecydujemy się na usługę kolokacji, czyli wynajmujemy miejsce w szafach teletechnicznych w centrum danych. Usługodawca deklaruje cztery dziewiątki. Czy w związku z tym nasze środowisko także będzie miało dostępność na poziomie 99,99%? Najprawdopodobniej nie. Wysoka dostępność dotyczy systemów zbudowanych w centrum danych, w tym zasilania, łączności, klimatyzacji, itp. Wystarczy, że architektura naszego rozwiązania została zaprojektowana bez nadmiarowości. Czyli do szaf wynajętych w centrum danych włożymy pojedyncze urządzenia. Wówczas niestety, poziom dostępności naszego środowiska IT będzie równy poziomowi dostępności najsłabszego elementu.

Czas nieprzerwanej pracy systemów określany jako uptime, dotyczy każdego elementu infrastruktury IT. Projektując wysokodostępne środowisko IT należy eliminować pojedyncze punkty awarii. Robimy to dublując urządzenia z najniższym przeciętnym uptime. Właściwie, to robimy to dublując wszystko co się da 🙂 Jedyne odstępstwa dotyczą usług, których niedostępność nie zatrzymuje procesów krytycznych dla działalności operacyjnej. W ten sposób istotnie zmniejszamy ryzyko wystąpienia przestojów. Naturalnie, poszczególne systemy nie muszą mieć jednakowego poziomu dostępności. Ustalanie precyzyjnych wskaźników dla każdej usługi wpływa wprost na poziom nakładów na środowisko IT i na rodzaj i koszt Disaster recovery.

Wysoka dostępność (HA) jest pochodną nadmiarowości. Odtwarzanie awaryjne uznać powinniśmy za uzupełnienie HA, bo odpowiada na problemy, których nie rozwiąże nawet rozproszony geograficznie klaster wysokiej dostępności. Disaster recovery (np. DRaaS) to ostatnia deska ratunku, gdy nasze systemy padną ofiarą cyberataku lub co bardziej prawdopodobne, staną się niedostępne przez jakiegoś wirusa szyfrującego. Moje doświadczenia pokazują, że nadmiarowość i odtwarzanie po awarii, które według najlepszych praktyk ITIL powinny być komplementarne, bardzo często rozdziela tytułowe „czy”.

Darmowa konsultacja - anty.expert

IT Disaster Recovery Plan w wersji mini

IT Disaster Recovery Plan w wersji mini

Krótko i konkretnie o tym, co powinno się znaleźć w Planie Odtwarzania po awarii dla obszaru IT. Kto zmierzył się z tym tematem ten wie, że są atrakcyjniejsze formy spędzania czasu. Mimo wszystko, gdy się już go popełni, satysfakcja gwarantowana 😉 Jeśli zabieracie się za samodzielne opracowanie planu, być może ten artykuł pomoże Wam uporządkować myśli.

Dla porządku, IT Disaster Recovery Plan jest częścią Zarządzania Ciągłością Działania (Business Continuity Management – BCM), a dokładnie jest jednym z dokumentów Planu Ciągłości Działania. Celem BCM jest zapewnienie dostępności krytycznych procesów i zasobów nawet w sytuacji kryzysowej, a więc na przykład w trakcie awarii. BCM obejmuje wszelkie procesy i zasoby występujące w organizacji. Tymczasem Plan Odtwarzania po awarii skupia się na obszarze teleinformatycznym.

Jak każdy plan, wymaga formy pisemnej. Warto go mieć pod ręką. Co powinien zawierać IT Disaster Recovery Plan, wymieniam w kolejności:

  1. Analiza Ryzyk, czyli przed czym mamy się chronić. Podczas analizy proponuję skupić się na procesach krytycznych. Biznes musi wiedzieć też o pozostałych operacjach, które nie zostaną obsłużone w razie awarii. Pamiętajmy, że to zarząd ostatecznie zdecyduje, które procesy mamy podtrzymać.
  2. Analiza Wpływu na Biznes (BIA) skoro mamy już opisane zagrożenia, to teraz przypisujemy im oddziaływanie. Przyczyna – skutek – konsekwencje. Polecam tutaj proste tabelki i matrycę, która „wyostrza optykę”. Bardzo ważne to wyliczenia, np. koszty przestoju, utraconych korzyści, itd.
  3. Katalog usług i map zależności – to zadanie może być przykre, bo pisanie katalogu usług dla klienta wewnętrznego, gdy służyć ma tylko jednemu celowi, słabo się broni. Jak dla mnie, wystarczy przyłożyć każdy proces krytyczny do odpowiedniego systemu czy aplikacji i tak powstanie nam lista zasobów, które musimy podtrzymać podczas awarii.
  4. Parametryzacja RTO & RPO, czyli określamy dla każdego procesu oczekiwany czas odtworzenia oraz akceptowalny przez organizację poziom utraty danych. Namawiam, by „odczarować” akronimy.

Koniecznie trzeba zrobić przymiarkę, ile będzie kosztował przyjęty zakres ochrony. Jeśli poza podstawowymi procesami mamy chronić także coś więcej, koniecznie sprawdźmy czy to ekonomicznie uzasadnione. Znowu, niech zdecyduje biznes.

Według mnie to najważniejsze punkty IT Disaster Recovery Planu. Mniej znaczy więcej. Zawsze można coś dopisać 🙂

Darmowa konsultacja - anty.expert