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

Hiperkonwergencja – zrób to sam (DIY)

Hiperkonwergencja – zrób to sam (DIY)

Czy da się zbudować rozwiązanie serwerowe klasy korporacyjnej w oparciu o sprzęt dla małego i średniego biznesu? Zdecydowanie tak! Z pomocą przychodzi hiperkonwergencja, która coraz częściej zastępuje silosową architekturę konwergentną. Paliwem do zmiany podejścia jest nie tylko cena, ale coraz powszechniejsza konteneryzacja i architektura mikroserwisów. Dodatkowym bodźcem są zmiany pokoleniowe. Chodzi mi o słabą dostępność inżynierów, którzy potrafią zarządzać złożonymi środowiskami.

Zwyczajowo zacznę od definicji. Co to jest architektura konwergentna? Otóż, jest to ekosystem sprzętowo-aplikacyjny, składający się z serwerów, macierzy oraz sieci i zwykle też silnika wirtualizacji, ale nie jest on niezbędny. W takim podejściu, mamy do czynienia z siecią lokalną (LAN) i siecią dla pamięci masowej (SAN). Ta druga służy dedykowanej komunikacji serwerów z macierzą dyskową. Czym zatem jest hiperkonwergencja (HCI)? Jest uproszczeniem polegającym na połączeniu w jednym urządzeniu: mocy obliczeniowej oraz pamięci masowej. W tym przypadku konieczny jest silnik wirtualizacyjny (hiperwisor), stąd pochodzi pierwszy człon nazwy własnej tej architektury.  W rozwiązaniach hiperkonwergentnych często eliminuje się sieć SAN, jako zbędną. Nadmienię, że w rozwiązaniach wysoko wydajnych HCI, szczególnie gdy zastosujemy najszybsze dyski półprzewodnikowe (NVMe), nadal separuje się sieć IP od sieci pamięci masowej. Warto podkreślić, że hiperkonwergencję jest możliwa dzięki pamięci definiowanej programowo (Software Definied Storage). SDS to metoda na zarządzanie rozproszonymi zasobami dyskowymi i sposób na nadmiarowość. Tyle teorii.

HCI można kupić od kilku znanych dostawców, jak: Nutanix, Dell, HPE, itd. Ja jednak, idąc „pod prąd” namawiam do metody – zrób to sam (DIY). Wówczas inwestycja wyjdzie, nawet połowę taniej! Można też zaplanować migrację z częściowym alokowaniem dla HCI swoich obecnych zasobów serwerowych. Wówczas najprościej (ale nie najtaniej), użyć technologii vSAN od VMware. Gdy wpadniesz na pomysł: „zrobię to na OpenSource”, rozważ krótką listę akronimów, które niechybnie poznasz i to zaraz na starcie: SDS, SAN, DRBD, RDMA, IPoIB, RoCE, IBoE, Ceph, NFS, SR-IOV, NFMeoF, itd. Jeśli masz mocny zespół, to wspaniale, na pewno dacie radę. W innym razie rekomenduję wybór dostawcy, który dostarczy know-how w postaci skonfigurowanego sprzętu i aplikacji. Dużo drożej nie będzie, ale na pewno szybciej i bez huśtawki nastrojów.

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

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

Ile wytrzyma biznes bez Internetu?

Ile wytrzyma biznes bez Internetu?

Zapewniam, że bardzo krótko. Firmy badawcze podają, że już godzinne odcięcie to dla 50% firm w Europie straty zauważalne. Czy u nas jest inaczej? Raczej nie, to dlaczego tak mało przedsiębiorstw posiada łącze zapasowe? Polaku, tnij koszty, ale we właściwych miejscach! Dostęp do Internetu ma obecnie wyższy priorytet niż telefon. Nie ma się co dziwić, aplikacje mnożą się jak bakterie, a każda z nich do życia potrzebuje sieci.

Przypowieść z życia wzięta, niestety typowa. Firma usługowa, dla której komunikacja z otoczeniem to podstawa. Koparka rozkopuje kanalizację wtórną (to ta rura w ziemi, w którą wkłada się kable) i przecina światłowody oraz przyłącza miedziane. W efekcie wiele firm traci wszelką łączność i biznes zostaje bez Internetu. Czy da się zapobiec takiemu zdarzeniu? Wątpię. Za to, da się zabezpieczyć organizację przed całkowitą utratą łączności. Ruch telefoniczny i tak migruje na komórki, ale czy z komórek mamy wchodzić do sieci, gdy biznes zostaje bez Internetu? Oczywiście, to byłaby solidna dziura w bezpieczeństwie.

Jeśli dublujesz łącze, rób to z głową. Jaki sens mają dwa łącza od tego samego operatora? Albo, po co dwóch operatorów, z których każdy wchodzi do budynku tym samym światłowodem. Redundancja łącza, aby była rzeczywistą, winna zostać zrealizowana przez dwóch niezależnych dostawców w oparciu o różne media transmisji, czyli na przykład radio i światłowód. Jednocześnie, usługi nie mogą być obsługiwane przez pojedyncze urządzenie. Z tego powstaje wzór łatwy do zapamiętania: 2-2-2, czyli dwóch dostawców, dwa media i dwa urządzenia. Trzymajcie się tego a Internetu Wam nie zabraknie 😉

Oferty w zakresie łącza zapasowego są od zawsze, a teraz w dodatku operatorzy radiowi, zdywersyfikowali usługi. Bez problemu możemy mieć radiówkę przy której rozliczamy się wielkość portu (przepustowość) i za ruch. Gdy łącze jest bezczynne mamy niewielką stałą opłatę abonamentową. Prawda, że pięknie!? Niektórzy operatorzy tworzą też oferty od razu uwzględniające zapas, np. w oparciu o LTE/3G. Uważajcie jednak aby na końcu były dwa a nie jedno urządzenie (reguła 2-2-2), dostawca zwykle chce zaoszczędzić. Poza tym jeśli macie zespół większy niż 10 osób, to współdzielenie dostępu komórkowego będzie bardzo mało komfortowe.

Darmowa konsultacja - anty.expert