Czym Jest Chmura Hybrydowa? (i jak ją zaprojektować, aby zostać bohaterem w swojej firmie)

Zdradzę Ci sekret.
Nie ma jednej definicji chmury hybrydowej.
Nie wszyscy jednak zdają sobie z tego sprawę.

Czym jest chmura publiczna wyjaśniliśmy w ostatnim wpisie. Ale czym jest chmura hybrydowa (hybrid cloud computing)?

No właśnie.

Słyszy się, że chmura hybrydowa to przyszłość, chmura hybrydowa to teraźniejszość, kup Pan wagon serwerów i oprogramowania i będziesz miał chmurę hybrydową, musisz mieć chmurę prywatną, aby mieć chmurę hybrydową… i tak dalej i tak dalej.

Podróż w czasie

Aby zrozumieć to pojęcie musimy cofnąć się w czasie do roku 1961.

Czy wiesz, że w roku 1961 powstał pierwszy hybrydowy komputer?

Nazywał się Hycomp 250 i został wyprodukowany przez Packard Bell. Część analogowa był szybka, ale niezbyt precyzyjna. Część cyfrowa miała niemalże nieskończoną precyzję, jednak nie były tak szybkie jak części analogowe. Razem jednak działały cudnie. W tej chwili już niespotykane, ale kilkadziesiąt lat temu były doskonałymi narzędziami. Były czymś przejściowym. Elementem historii prowadzącym do teraźniejszości.

Jak możemy odnieść tą analogię do chmury hybrydowej w 2017 roku?

Co raz częściej firmy budując usługi wykorzystują chmurę hybrydową. Część rozwiązania umieszczają w lokalnym Data Center lub kolokacji. Kolejne części uruchamiają w chmurze publicznej (są też kombinacje chmura – chmura). Usługa zbudowana w ten sposób działa cudnie. Wykorzystuje część lokalną i część publiczną, aby rozwiązać pewien problem biznesowy.

Ale hola, hola….

Dlaczego hybryda, a nie 100% chmura publiczna?

W 2017 chmura publiczna nie jest idealna.
W 2017 nasze umysły wierzą w bajki, które usłyszały od “wrogów” chmury publicznej.
W 2017 ciągle posiadamy dług technologiczny, który nie pozwala nam na All-IN!

Jakie są jednak prawdziwe zalety i wady chmury hybrydowej?

No właśnie. Dlaczego nie używać w 100% chmury publicznej?
Dlaczego nie zostać do końca dni swoich w naszym lokalnym Data Center?

Zalety chmury hybrydowej

Zalety

• Amortyzacja (płacimy hajs za obecne zasoby, czasami już jest za darmo)
• Korzystamy z skalowalności (płacimy per użyte zasoby w chmurze)
• Aktualne aplikacje (nie damy rady ich przenieść w opłacalny sposób)
• Mniejsze uzależnienie od danego dostawcy (przy dobrej architekturze)
• Możliwość negocjacji (dobre warunku więcej używamy)

Wady chmury hybrydowej

• Utrzymanie x2
• Ludzie nie chcą migrować umiejętności (wymaga nowych osób)
• Utrudnia architekturę i sposoby wdrażania aplikacji
• Dostosowywanie się do „gorszej” części układanki
• Innowacja na minusie (przy modelu bursting)

Aby to skrócić do jednego zdania:

Chmura hybrydowa pozwala nam cieszyć się z naszych lokalnych zasobów i przy okazji korzystać z zalet chmury publicznej na poziomie jaki akceptujemy.

Model wdrażania chmury hybrydowej

No właśnie Mirku. W końcu mięso. Piszesz czym jest, jakie ma zalety, ale jak taką chmurę zbudować. Przecież dostawca X mówi, że…

Dostawca X mówi to, co pozwoli mu zarobić więcej pieniędzy.

Jeżeli chmura hybrydowa pozwoli mu sprzedać więcej serwerów, to na pewno w definicji chmury hybrydowej będzie więcej serwerów. Jeżeli chmura hybrydowa pozwoli mu sprzedać więcej chmury publicznej, to na pewno w definicji chmury hybrydowej będzie więcej chmury publicznej.

Więc jak wybrać?
Komu wierzyć?
Jak żyć?

Jak wybrać – tak, aby daną technologią rozwiązać pewien problem biznesowy.
Komu wierzyć – nikomu.
Jak żyć – szybko.

Problem biznesowy i chmura hybrydowa

1. Nasz biznes rośnie tak szybko, że nie możemy dostarczać serwerów na czas.

Czasem też znany jest jako problem sezonowości. Np. w grudniu mamy zapotrzebowanie na DUŻO więcej mocy serwerów i innych urządzeń w naszym Data Center niż mamy.

Jak to rozwiązać?

Budujemy usługę, która w chwili zapotrzebowania na większą moc obliczeniową przerzuca ruch do chmury. Chmura (najczęściej publiczna w tym modelu) ma to do siebie, że płacimy za wykorzystane zasoby i skaluje się (prawie) bez końca. Jest więc idealna na ten przypadek. Piękne wykorzystanie hybrydy.

2. Mam klientów w Sydney i usługi, które im świadczę z PL ssą.

Świadczymy usługi w jednym miejscu, a bardzo byśmy chcieli świadczyć usługi w innym miejscu. Nie zawsze jednak jakość usługi świadczonej z naszego lokalnego Data Center daje dobre wyniki w innym zakątku świata.

Budujemy usługę, która wystawiona jest w kilku miejscach. Jednym z nich jest nasze Data Center, kolokacja lub chmura (przypadek multi-cloud), a drugim miejsce jest chmura. Synchronizujemy dane i używamy głównie usług DNS do określenia, gdzie dany użytkownik powinien trafić.

3. Przygotowanie środowisk test/dev zajmuje za dużo czasu.

Boimy się lub nie możemy uruchamiać usług produkcyjnych w chmurze, ale znamy zalety chmury dla rozwiązań test/dev.

Budujemy nasze środowisko w ten sposób, aby kod i dane produkcyjne uruchamiane były w naszym lokalnym systemie, a środowiska testowe i developerskie uruchamiają się w chmurze. Tutaj pomagają narzędzia do procesów wdrażania kodu, jak np. Visual Studio Team Services lub narzędzia, która budują warstwę abstrakcji dla naszej aplikacji, jak np. Red Hat OpenShift.

4. Buduję nową aplikację, która idealnie pasuje na chmurę publiczną, ale korzysta z systemów lokalnych.

Część systemów, które mamy lokalnie, są “nie do ruszenia” jednak nowa aplikacja może skorzystać z chmury.

Budujemy usługę w chmurze korzystając z platformy (np. Google BigQuery, Amazon EMR, Azure App Service). Ciągle jednak wykorzystujemy usługi z lokalnego Data Center, do których usługi z chmury czerpią dane i vice versa.

5. Buduję rozwiązanie Disaster Recovery i nie chcę płacić za kolejne Data Center.

Aplikacja jest uruchomiona w lokalnym środowisku, ale w momencie awarii chcemy ją uruchomić w innym miejscu.

Usługa działa w lokalnym środowisku. Określamy czas RPO i RTO. W zależności od tych czasów projektujemy rozwiązanie, które w chwili awarii usługi w miejscu źródłowym, zacznie działać w chmurze. Najczęściej do tego typu wdrożeń używamy rozwiązań, które ułatwiają nam wdrożenie takiego systemu, np. Azure Site Recovery.

6. Kończy mi się miejsce na macierzach i archiwach. W sumie, to chyba przeżytek.

Posiadamy skończoną przestrzeń na dyskach i taśmach, a ponoć w chmurce jest dużo i tanio.

W tym modelu korzystamy z zasobów w chmurze publicznej i tam umieszczamy nasze dane. Można do tego używać rozwiązań, które znamy w lokalnym Data Center lub użyć rozwiązań ala AWS Storage Gateway lub Azure StorSimple.

7. I tak dalej i tak dalej.

Nie ma jednej definicji. Sama idea związana jest z wykorzystywaniem zasobów w chmurze, gdy dana sytuacja biznesowa tego wymaga. Tyle.

A czy jest tu miejsce na Chmurę Prywatną?

Przecież, aby była chmura prywatna, to muszę zainstalować OpenStack, VMware vCloud Suite, Azure Stack, Pivotal Cloud Foundry, Red Hat OpenShift, itd.

To muszę mieć chmurę prywatną, aby mój zarząd zaakceptował wydatki na chmurę hybrydową w mojej organizacji?

TAK i NIE.

Często pojęcie chmury prywatnej (private cloud computing) jest mylone z oprogramowaniem, które umożliwia zbudowanie chmury prywatnej.

Wymienione wyżej rozwiązania są używane na wiele sposobów. Czasami są niezależnym systemem (np. gdy lokalnie uruchamiamy OpenStack). Czasami uruchamiamy to samo rozwiązanie w lokalnym Data Center, ale też w chmurze publicznej (np. OpenShift na AWS). Opcji jest wiele. Nie skupiajmy się tutaj, czy mowa o chmurze prywatnej lokalnie, ale bardziej o wykorzystywaniu zasobów lokalnych + usłudze cloud computing.

Co jest ważne przy projektowaniu rozwiązań hybrydowych

Wiele rzeczy:

• Bezpieczeństwo
• Zarządzanie
• Rozliczanie
• Automatyzacja
• Monitorowanie
• SLA
• Narzędzia
• Połączenia Sieciowe
• Zarządzanie Dostępem Użytkowników
• … i dużo więcej

Ale o tym porozmawiamy… JUŻ NIEDŁUGO.

ZOSTAŃ EKSPERTEM CHMURY HYBRYDOWEJ

Uwielbiam firmy, które ciągle ulepszają swoje usługi. Zawsze pamiętałem 3S jako dostawcę usług sieciowych. Jednak jakie było moje zdziwienie, gdy pewnego dnia na spotkaniu MeetIT w Warszawie, usłyszałem o tym, że 3S buduje rozwiązania hybrydowe.

Jakże moje zdziwienie przerodziło się w ekscytację, gdy zobaczyłem jak inżynierowie 3S budują rozwiązanie hybrydowe, które skaluje się z usług 3S Data Center do Amazon Web Services. Ekscytacja przerodziła się w podziw, gdy usłyszałem, że robią to już od dawna i mają zadowolonych klientów.

Uznałem, że musimy zrobić coś razem. Odczarować chmurę hybrydową i wyjaśnić wszystko.

Zmienić każdego Polaka w eksperta chmury hybrydowej

Tak więc razem z firmą 3S Data Center uruchomiliśmy projekt:

HybrIT: Jak ugryźć chmurę hybrydową, czyli zjeść ciastko i mieć ciastko

Przez najbliższe tygodnie dostarczymy Ci masę PRAKTYCZNEJ WIEDZY o budowaniu usług w modelu hybrydowym.

W najbliższych tygodniach weźmiesz udział w szkoleniach online:

• [03.10. wtorek] Jak skutecznie zaprojektować rozwiązania hybrydowe
• [10.10. wtorek] 8 modeli chmury hybrydowej, które musisz znać w 2017 roku
• [16.10. poniedziałek] Sieć w modelu hybrydowym
• [20.10. piątek] 5 narzędzi, które pozwolą synchronizować Twoje dane w modelu hybrydowym

Podczas czterech sesji szkoleniowych zagłębimy się w architektoniczne bolączki, praktyczne wyzwania i w to czego NIE ROBIĆ. Wszystko na żywo i z możliwością zadawania pytań.

Ale to nie koniec.

Na każdym ze szkoleń będziemy losowali 5 kuponów o wartości 1000 PLN każdy na usługi 3S Data Center, takie jak:

• Wdrożenie usług hybrydowych
• Distaster Recovery
• Migracja środowisk
• 3S Cloud2B
• i dużo więcej

Ale to nie koniec.

26.10 zobaczymy się na całodniowym wydarzeniu w Katowicach, gdzie w formule MeetIT porozmawiamy z praktykami polskiej sceny chmurowej o wdrożeniach chmury hybrydowej!

ABY ZACZĄĆ, ZAPISZ SIĘ NA PIERWSZE SZKOLENIE! LICZBA MIEJSC OGRANICZONA!