Firmy coraz częściej przekazują dużą część swojej infrastruktury informatycznej i portfolio aplikacji zewnętrznym dostawcom. Tworzy to interesującą sytuację, gdy organizacja korzysta wyłącznie z jednej platformy w chmurze lub usługi zarządzanej. Właśnie to może okazać się wspomnianym wyżej słabym punktem, który z zasady staramy się eliminować.

 

Bakup w batalii z pojedynczymi punktami awarii

Przyjęte podejście w walce z pojedynczymi punktami podatności zakłada implementację co najmniej jednego z poniższych:

• Więcej niż 1 dostawca Przy połączeniach z Internetem warto skorzystać z dwóch różnych dostawców wchodzących do Twojego centrum danych na dwóch różnych obwodach. Najlepiej przez różne wejścia w lokalizacji. Jeśli dojdzie do przypadkowego lub celowego uszkodzenia jednego z kabli światłowodowych, pozostaje drugi.
• Dodatkowa przepustowość Do zwykle wykorzystywanej przepustowości warto dołożyć dodatkowe X% zabezpieczających możliwość wystąpienia nagłych skoków.
• Drugie łącze Wykorzystując światłowód trzeba uwzględnić dodatkowe połączenie, np. przez satelitę. Alternatywą pozostaje utrzymywanie kompletnej kopii zapasowej (hot spare) na wypadek zniszczenia głównej lokalizacji (na przykład w wyniku naturalnej katastrofy).

Chociaż ww. metody w szczegółach się różniły, jednak były dotąd powszechnie stosowane przez rozwijające się organizacje. Takie sposoby mogą jednak zwiększać złożoność środowisk, wymagają pracowników i są uzależnione od nakładów inwestycyjnych (CapEx).

Ani mniej, ani więcej - tyle zasobów, ile potrzeba

Wspomniany wyżej rodzaj kosztownej złożoności jest powodem, dla którego chmura, oprogramowanie jako usługa (SaaS) — wraz z funkcjami (FaaS), infrastrukturą (IaaS) w tej samej formule oraz powiązane z nimi rozwiązania stały się tak popularne.

Ponieważ zamieniając CapEx na wydatki operacyjne (OpEx) płaci się tylko za to, z czego się korzysta w formie stosunkowo niewielkiej opłaty abonamentowej za usługi według ustalonych wcześniej stawek.

Chmura i SaaS umożliwiają skalowanie w górę lub w dół w zależności od potrzeb. Dają możliwość wykorzystania infrastruktury wielkich dostawców w celu uzyskania szybkich, skalowalnych, niezawodnych, bezpiecznych usług i obniżenia ich kosztów. Niweluje to potrzebę zwiększania zasobów ludzkich oraz kosztownej infrastruktury jak np. serwery i sprzęt sieciowy. Do wdrożenia w krótkim czasie wystarczy wiedza inżynierska z zakresu chmury. Umożliwia to także przekazanie uruchamiania wielu aplikacji zewnętrznym dostawcom — e-mail, telekonferencje, systemy komunikacji, zarządzanie klientami, a nawet zasoby ludzkie.

Na barkach poddostawców spoczywa: masowe dostarczanie, redundancja i utrzymywanie odrębnych systemów. Mają oni większe możliwości niż pojedyncza organizacja, ponieważ wykorzystują ekonomię skali.

Zapewnienie bezpieczeństwa w takiej formule jest realizowane na podstawie umowy dotyczącej poziomu usług i ich zakresu. W przypadku błędów po stronie poddostawców, daje to możliwość odzyskania części lub całości środków finansowych utraconych w wyniku błędu. Przenoszenie ryzyka z rozwiązań będących pod kontrolą wewnętrzną pod kontrolę zewnętrzną ma spory sens, szczególnie w przypadku, gdy jest to core business poddostawców.

Ryzyko vs kompromisy

Rynek rozwiązań oferowanych “jako usługa” jest obecnie zdominowany przez kilku kluczowych graczy. W zależności od czynników, takich jak region, kraj lub branża, niektóre organizacje mogą osiągać niemal 100% udział w rynku. Zjawisko nie jest nowe, jednak może dziś powodować problemy. Polegając na jednym dostawcy, przeczekiwanie problemów może okazać się jedynym wyjściem w przypadku awarii, anomalii i nieoczekiwanych wydarzeń.

Decyzje wymagają kompromisów. Zalety przejścia na OpEx z modelu CapEx są znaczące, a poleganie na jednym dostawcy wyraźnie wiąże się z ryzykiem.

Skuteczne wydaje się więc zrównoważone podejście do liczby dostawców, podobnie jak z utrzymywaniem środowisk on premises dla usług o znaczeniu krytycznym. Uruchamianie zduplikowanych aplikacji w więcej niż jednej chmurze publicznej jest trudne, ale możliwe do osiągnięcia dzięki konteneryzacji i mikrousługom.

Ryzyko dla takiego podejścia stanowi nadmiarowość, a więc i możliwe wyższe koszty. Dla przykładu, dostawcy usług w chmurze zabiegają o uruchamianie kodu klientów w ich strukturach FaaS, wykorzystanie ich magazynów danych i bram API. Modele cenowe to odzwierciedlają, a podejście „natywnego dostawcy” zapewnia wyższą wydajność. Biorąc powyższe pod uwagę w podejściu opartym na wielu chmurach warto ograniczyć się do usług, które bezwzględnie muszą pozostać dostępne.

Zalety podejścia pre-app

W przypadku mniej krytycznych elementów korzystne może być uruchamianie każdej aplikacji z dostawcą chmury, który najbardziej jej odpowiada. Może to ograniczyć wpływ awarii do podzbioru aplikacji niekrytycznych, pod warunkiem, że organizacja całego portfela aplikacji zostanie wykonana bezpiecznie.

Każda przyjęta strategia wiąże się z kosztami. Niemniej nawet strategia jedna aplikacja – jeden dostawca wydaje się generować mniej kosztów niż samodzielne uruchamianie aplikacji. Niemniej branża stale pracuje nad zdejmowaniem pojedynczych punktów podatności – bez względu na to czy potencjalne lokalizacje tych awarii przenosimy poza własne organizacje do zewnętrznych dostawców.

Źródło: F5