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

Lokalna kopia chmury na przykładzie Office365

Lokalna kopia chmury na przykładzie Office365

Pewnie już zauważyliście nawoływania firmy Veeam, by zapewnić sobie kopię lokalną danych przechowywanych w chmurze Microsoft. Jeśli zastanawiacie się po co to robić, wyjaśnię w kilku zdaniach, kiedy taka kopia może stać się absolutnie niezbędna. Bonusowo, ten wpis zawiera instruktażowe nagranie wideo, jak skopiować nasze dane z usługi Office365 na dysk lokalny, krok po kroku.

Zacznę od tego, że jak zwykle chodzi o właściwe zrozumienie usług, które nabywamy i uważne czytanie regulaminów. Finalnie przecież, odpowiedzialność za właściwie funkcjonowanie naszych systemów zawsze spada na nas. Ktoś powie, ale przecież mamy SLA (Service Level Agreement) z Microsoftu. Zerknijmy zatem, co obiecuje nam dostawca, gdy mowa o Office365 i usłudze Exchange, SharePoint czy OneDrive, tutaj wersja pełna SLA, a poniżej esencja skażona nieco moim spojrzeniem.

  1. Po pierwsze uptime na poziomie 99,9%, czyli czas nieprzerwanej pracy, a więc, co podkreślam – poziom dostępności usługi. Łatwo policzyć, że usługa może być niedostępna około 9h rocznie i nikt nas za to nie będzie przepraszał. Microsoft pozwala liczyć przestój na użytkownika, a więc uwzględnia także iloczyn.
  2. Rekompensaty finansowe, które stanowią procent wartości opłaty za usługę, a więc nigdy nie przewyższą miesięcznego kosztu użytkowania Office365. Zazwyczaj w gradacji:
    • < 99,9% – 25%
    • < 99,0% – 50%
    • < 95,0% – 100%

Jeśli w tym miejscu liczyliście na więcej, to niestety tak to przeważnie wygląda u usługodawców chmurowych i w branży telekomunikacyjnej.

SLA firmy Microsoft jest rozbudowane i zawiera także gwarancje jakości w zakresie dostarczania poczty czy też efektywności antywirusa i filtrów antyspamowych. Spróbujcie jednak znaleźć zadośćuczynienie za utratę danych! O dane zadbaj sam!

Kiedy więc przyda się kopia? Gdy usuniecie, zaszyfrujecie, nadpiszecie swoje dane lub „pomoże” Wam w tym jakiś złośliwy robak. Gdy Wasz administrator usunie niewłaściwe konto. Jeśli zechcecie zmienić dostawcę. A może zrobicie sobie roczne wakacje, także od płacenia. Może się zdarzyć i to wcale nie jest takie rzadkie, że dostawca wypowie Wam umowę, bo naruszycie jakiś punkt regulaminu. Jak widać, kilka powodów robienia lokalnej kopii chmury się znalazło 🙂

Poniżej wideo – jak to zrobić.

Darmowa konsultacja - anty.expert

Planowanie odtwarzania po awarii – 7 grzechów głównych

Planowanie odtwarzania po awarii – 7 grzechów głównych

Jako samozwańczy „ewangelista” z zakresu ciągłości działania – czuję się usprawiedliwiony sięgając po katechizm 😉 Nie będę jednak prawił kazań. Opowiem tylko o typowych błędach jakie towarzyszą planowaniu odtwarzania po awarii, pamiętając przy tym o lekkostrawnej formie.

    1. Pycha. Nam się nic nie przytrafi. Zadziwiająco często spotykam menadżerów którzy jak mantrę powtarzają: „Przecież nigdy się to nie zdarzyło, po co więc chronić się przed takim ryzykiem?” Wtedy zalecam BIA (Analiza wpływu na biznes), która wprost odpowiada na pytanie czy warto czy też nie.
    2. Chciwość. Ta inwestycja nie przyniesie pieniędzy. Biznes nie lubi inwestować gdy nie widzi policzalnych zwrotów. Ciągłość działania porównać można do polisy ubezpieczeniowej, gdzie nakłady to koszt. Niestety, nie wiadomo, czy zaangażowane środki się zwrócą – czyli czy na przykład dzięki nim uratujemy organizację od przestoju. Pozostaje chłodna analizy ryzyk i ich wpływu na biznes oraz kosztów przestoju.
    3. Nieczystość. Nadmiarowość to nie odtwarzanie po awarii. Posiadanie klastra wysokiej dostępności, wyeliminowanie pojedynczych punktów awarii infrastruktury czy świetnie zabezpieczone centrum danych to solidny fundament ciągłości działania. Nie jest to jednak ochrona przed każdym ryzykiem. Przeciętny informatyk wyrwany ze snu bez wahania wskaże kilka scenariuszy, które zatrzymają IT Twojego przedsiębiorstwa.
    4. Zazdrość. Pomijanie właścicieli procesów. Zapominamy, lub co gorsza nie chcemy włączyć do planowania wszystkich interesariuszy. To strzał w kolano. Bez ich wiedzy nie będzie skutecznego odtworzenia po awarii.
    5. Nieumiarkowanie. Wszystko jest krytyczne. Klasyka. Zwykle, gdy zespół IT arbitralnie decyduje o tym, jakie zasoby mają być zabezpieczone na wypadek awarii, mamy sytuację, w której zasoby centrum zapasowego równe są zasobom centrum podstawowego.
    6. Gniew. Dlaczego działa tak wolno? Aspekt wydajności środowiska zapasowego jest częstym zarzewiem konfliktów wewnętrznych i zewnętrznych. Pamiętajmy, że to proteza, niezbędna do czasu powrotu stanu normalnego. Mamy podtrzymać procesy krytyczne. Poza tym testujmy praktycznie nasz plan odzyskiwania po awarii.
    7. Lenistwo. Zbytnie zaufanie do dostawcy DRaaS. Odtwarzanie po awarii jako usługa wymaga zaangażowania każdej strony umowy. Dostawca odpowiada za technologię i zasoby po swojej stronie. My natomiast, zadbajmy o uruchomienia testowe czy też cykliczne aktualizujmy plan odtwarzania po awarii. Przy okazji, zmianie może ulec zapotrzebowanie na zasoby dostawcy.

Darmowa konsultacja - anty.expert

Kopia zapasowa jako usługa (BaaS)

Kopia zapasowa jako usługa (BaaS)

Czym w istocie jest kopia zapasowa? Ile w niej usługi, a ile technologii? Jakie są najlepsze praktyki w tym zakresie? Jaka jest odpowiedzialność dostawcy usługi? Napiszę o tym ile jest „cukru w cukrze” z perspektywy naszego polskiego rynku.

Jakie jest Twoje pierwsze skojarzenie gdy słyszysz „kopia zapasowa jako usługa” (BaaS – Backup as a service)? Ja najczęściej słyszę, że to przestrzeń na dane uruchomiona gdzieś w chmurze. Tymczasem sama definicja mówi o czymś więcej. Jakie są zatem składowe usługi? Standardowo dostawcy kształtują BaaS na bazie trzech lub czterech komponentów. Chodzi o wykorzystywaną przestrzeń nośnika, licencje aplikacji i pracę ludzi. Gdy mamy do czynienia z chmurą (np. AWS, Azure) dochodzi jeszcze transfer danych. Co ciekawe, dla polskich dostawców najwyższy koszt to zajętość nośników danych, który stanowi czasami nawet 60% usługi. Boleśnie odczują to klienci posiadający duże wolumeny danych.

Kopia zapasowa to kolejne „wystąpienie” określonego zbioru danych. Zgodnie z najlepszymi praktykami, w tym regułą 3-2-1, dobrze jest mieć trzy kopie danych na dwóch różnych nośnikach, z czego awaryjnie jedno wystąpienie najlepiej trzymać poza siedzibą (w domyśle jak najdalej od pozostałych). Chodzi przecież o to by minimalizować prawdopodobieństwo utraty danych, które z każdą kolejną kopią, nośnikiem i miejscem składowania, maleje wykładniczo. Obecnie chroni się nie tylko dane, ale i całe systemy. Większość dostępnych aplikacji dedykowana do zastosowań biznesowych potrafi robić „obrazy” systemów i danych „w locie”, a więc podczas pracy aplikacji. W razie zniszczenia urządzenia z kopii odzyskiwane są wówczas nie tylko dane, ale i wszelkie ustawienia, dzięki czemu komputer czy serwer gotowy jest do użytku w ciągu kilkunastu minut.

Pamiętajmy jednak o tym, że kopia zapasowa jako usługa to nie ubezpieczenie od wszelkich nieszczęść. Dostawca usługi umownie ogranicza swoją odpowiedzialność, a górną granicę kar umownych stanowi zazwyczaj wartość abonamentu miesięcznego. Czytanie umowy i regulaminu usługi pozbawia złudzeń. BaaS to nie ubezpieczenie typu Business Interruption. Poza tym kopia (z definicji) to nie pierwowzór, lecz jego klon. Czy to powinno zniechęcać do usługi? Absolutnie nie. Rekomenduję wykonywanie lokalnych kopii bezpieczeństwa i korzystanie z polskich dostawców BaaS dla spełnienia reguły 3-2-1.

Darmowa konsultacja - anty.expert

Chmura publiczna czy własne zasoby IT? A może to i to, czyli hybryda?

Chmura publiczna czy własne zasoby IT? A może to i to, czyli hybryda?

Prędzej czy później każdy stanie w obliczu wyboru – wynajmować czy kupować. Ciekawe, że decyzje zwykle zapadają w oparciu o różne obliczenia. Pytanie tylko, czy całkowity koszt posiadania (TCO) powinien być jedynym kryterium wyboru? Poza tym, czy aby na pewno dobrze porównujemy koszty, a więc czy porównujemy „jabłka do jabłek”? Na koniec, czym jest właściwie hybryda w przypadku chmury?

Decyzja o tym co wybrać, zawsze zależna powinna być od kontekstu, czyli od zadań jakie stawiamy przed systemami IT. Przykładowo, jeśli priorytetem jest szybki dostęp do bazy danych lub aplikacji dla potrzeb dużego zespołu lokalnego, a architektura rozwiązania jest sprzed kilku lat (najczęściej klient-serwer), wówczas trzymanie serwerów w siedzibie firmy ma uzasadnienie. Inaczej jest w przypadku zastosowań Internetowych. Jeśli do naszych systemów mają sięgać rozproszeni terytorialnie pracownicy, klienci albo partnerzy. Jeśli metodą dostępu będzie przeglądarka internetowa lub aplikacja na smartfona, wówczas umiejscowienie serwerów czy też wirtualnych maszyn w centrum danych operatora, jest lepszym rozwiązaniem.

Porównanie TCO, to następny krok. Dlaczego chmura publiczna w arkuszu kalkulacyjnym kosztuje więcej niż własne zasoby IT? W tym miejscu zazwyczaj umyka nam, że chmura publiczna to cały szereg składowych. Nie pamiętamy o nich, bo nie przypisujemy ich do operacji IT. Porównując TCO, uwzględnijmy zatem następujące koszty:

  1. zaangażowanego kapitału (inwestycja);
  2. utrzymania, konserwacji i napraw sprzętu sieciowego i serwerowego;
  3. licencji oraz opłat utrzymaniowych;
  4. pracy własnego zespołu lub usług obcych związanych z utrzymaniem sprzętu oraz administracji warstwą wirtualizacji czy systemów operacyjnych;
  5. utrzymania serwerowni, w tym:
  • utrzymanie, konserwacje i naprawy systemu zasilania awaryjnego,
  • konserwacje i naprawy klimatyzacji,
  • zużycie energii elektrycznej przez sprzęt IT oraz urządzenia infrastruktury serwerowni,
  • ubezpieczenie majątku.

A co z gdyby połączyć jedno z drugim? Czyli, nadal utrzymywać trochę zasobów informatycznych u siebie lokalnie, szczególnie tych do których dostęp musi być bardzo szybki. Równolegle korzystać z wybranych usług chmury publicznej, np.: w zakresie ciągłości działania (DRaaS, BaaS), czy kolokacji albo najmu wirtualnych serwerów (IaaS)? Jak się okazuje, to częsta praktyka, która być może stanie się standardem. Zgodnie z definicją, to chmura hybrydowa, czyli połączenie własnego środowiska informatycznego (serwerów) z chmurą publiczną usługodawcy.

Darmowa konsultacja - anty.expert