Hybrid multi-cloud – jak budować aplikacje

Data: 2021-03-17
Autor: Sebastian Konkol
Hybrid multi-cloud – jak budować aplikacje

Kiedy słucham o złożoności budowy aplikacji działających w środowisku hybrydowym lub multi-cloud, odnoszę wrażenie, że aby cokolwiek zrobić w takim scenariuszy trzeba łączyć zdolność inżynieryjną Mr Spocka ze szczęściem Arsena Lupin. Większość takich opowieści wygląda jak film Alfreda Hitchcocka – zaczyna się od trzęsienia ziemi, a potem napięcie zaczyna narastać. Czy naprawdę tak musi być?

Skoro tu jesteśmy razem, to przypomnę jedynie, że aplikacja, która ma działać w chmurze – jednej, dwóch, hybrydowej, wielochmurze – musi być zbudowana w odpowiedni sposób, aby móc działać w takim środowisku. Zdecydowana większość posiadanych na dziś aplikacji takimi nie jest, jak dobrze wiemy. Aplikacja chmurowa musi być zaprojektowana jako cloud native, respektując pryncypia budowy aplikacji dla chmur obliczeniowych – jeśli nie wprost według tych zasad, to opierając się o nie. Jeśli jednak już przeskoczymy ten próg, to czy będzie to jedna chmura, czy wiele, nie ma już aż takiego znaczenia – architektura oprogramowania cloud native jest u samych podstaw „wielochmurowa”.

Naturalnie, w tym miejscu mógłbym się zagłębić w tajniki infrastruktury wielochmury hybrydowej. Ale nie zrobię tego, bo w praktycznym użyciu nie ma to istotnego znaczenia. Ważniejsze jest to, aby ustalić tę cechę środowiska chmurowego, która daje nam wymagany poziom elastyczności i możliwości zmian. Próbowałem takich eksperymentów u kilku moich klientów. Część z nich działa na AWS, część na Azure, zawsze hybrydowo. Pomimo różnic technicznych, ścieżki rozwoju i wnioski z wycieczek po nich są dosyć podobne.

Co buduje konieczność takich działań? Ja przedreptałem kilka ścieżek i kilka wzorców architektury. Przebrnąłem przez architekturę rozwiązań, w której części aplikacji działały „po jednej ze stron” (bo PaaSy są takie superanckie), minimalizując komunikację pomiędzy środowiskami. Przeszedłem pole minowe chmura jako offload do własnego data centre (to najbardziej podstawowe marketingowo uzasadnienie), skutkujące zwykle dwoma stosami technologii dla jednej aplikacji. Opracowałem nawet architekturę dla usług świadczonych „i tu, i tu” (bo jeśli SLA wymaga 400 ms czasu odpowiedzi, oprogramowanie jest wyżyłowane i nie pozwolisz sobie na stratę 100-200 ms na RTT między on-premises a chmurą). Tak, czy inaczej, działanie aplikacji w chmurze hybrydowej oznacza albo dualność aplikacji, albo unifikację „infrastruktury” on-premises i chmury. Dualność aplikacji odpada.

Próbowałem przenieść chmurę do on-premises, żeby korzystać z PaaSów, ale to ciężka sprawa. Data centre on-premises to nie chmura i doskonałej skalowalności się nie uzyska, a koszty są wysokie. Do tego jeszcze stos technologiczny z chmury (Azure Stack, AWS Outpost, być może Google Anthos), a to nie są tanie rzeczy, trzeba przenieść do data centre. Więc „się nie kalkuluje”. Trochę nie rozumiem tej polityki cenowej, bo „za darmo” silniej uzależniłoby klientów od danej chmury. Pomijając jednak nawet tę wątpliwość, import (najazd?) określonej chmury do własnego data centre nie rozwiązuje zagadnienia wielochmury.

Są na szczęście inne możliwości. Ostatnio fascynuję się działaniami rozwojowymi VMware, które dogadało się ze wszystkim głównymi dostawcami chmur i już dziś można rozciągnąć swoje, w pełni zarządzalne środowisko VMware do innych chmur, gdzie ten VMware działa na fizycznym sprzęcie. Wszak to rozwiązuje w pełni zagadnienie tworzenia aplikacji dla hybrydowych multichmur. Inne, oczywiste rozwiązanie, to środowiska konteneryzowane (Docker rządzi) i orkiestracji kontenerów (Kubernetes jest wszędzie, także w wersji zarządzanej). Jeśli dodać do tego, że każda chmura oferuje PaaS relacyjnej bazy danych kompatybilny z MySQL, cloud native w wersji multichmury hybrydowej staje się zagadnieniem niemalże trywialnym. Na marginesie, okiestracja kontenerów to chmura sama w sobie – jeśli można skorzystać z zarządzanej wersji Kubernetes, to polecam. Czasami myślę, że rozwój chmury i kontenerów napędzają się wzajemnie koncepcyjnie. Morał z tego jest prosty. Jeśli potrzebujesz hybrydy lub multicloud i nie chcesz być zależny od dostawcy chmury, to się nie uzależniaj, bowiem wcale nie musisz.

Na koniec kilka ostrzeżeń. PaaS w każdej chmurze to pułapka „lojalizacji”, bo oprócz kodu jest bogactwo konfiguracji i ustawień specyficznych dla chmury. Jeśli w kodzie aplikacji jest odwołanie do KeyVault to do KeyVault, a nie do Secrets Managera. Transfer danych z chmury także ma „lojalizować” i jest kosztowny. Kalkulacja finansowa weryfikuje więc wykorzystanie fajnych ficzerów i czasami wymusza użycie słabszych, ale „z tej samej chmury”. O ile można wierzyć, że w jednej chmurze ucieknie się od sieci (znów cudowne PaaSy?), o tyle w wielochmurze sieć to absolutny fundament, a sieć w multicloud to sieć na sterydach (ostatnio przechodziłem eksperyment myślowy zabezpieczeń regionalnych połączenia Azure i OCI, polecam). Szukaj nie tyle rozwiązań prostszych, co architektur upraszczających. Brzytwa Ockhama prawdę Ci powie.

Pozostaw komentarz