3 pryncypia projektowania aplikacji w chmurze
Używanie chmury pokazywane przez marketing, sprzedawców czy na konferencjach wydaje się proste. Dodatkowo zazwyczaj zapominamy o tym, że usługi w chmurze nie dają 100% czy 99,99999% dostępności, a tak często jest to odbierane.
Rzadko jednak mówi się o trzech najważniejszych dogmatach przy architekturze rozwiązań, które mają trafić do chmury. Projektując aplikację oraz podejmując decyzję, że ma być umiejscowiona w chmurze trzeba pamiętać o podstawowych pryncypiach.
Failures can occur
Brak łączności sieciowej, chwilowa niedostępność usługi czy jakiś błąd lub timeout z API jest chlebem powszednim.
Regional failures can occur
Może się zdażyć, że nasza instancja usługi, na przykład storage, przestanie działać w regionie, gdzie jest aplikacja albo cała usługa storage przestanie działać w regionie, albo co gorsza, cały region przestanie działać. Co wtedy? Jak wyglądają Twoje procesy BCP i DR w tym wypadku? Jakiego czasu SLA naprawdę potrzebuje biznes?
Network latencies can occur
Bardzo często w przypadku uruchamiania aplikacji zapominamy skąd użytkownik lub inne systemy będą się łączyć do aplikacji. Czasami może być to problem, bo dla użytkownika będzie to za wolno. Może, jeśli mamy globalną aplikację, to warto zaprojektować ją tak, żeby była rozproszona i każdy na kontynencie miał swoją instancję? Może lokalny cache w aplikacji/integracji?
Jeżeli będziemy świadomi tych zasad to chmura będzie zaskakiwać mniej. Czasem można podjąć świadome decyzje, że pewne rzeczy nas nie interesują, bo przykładowo, aplikacja może nie działać jeden dzień. Ważne, że pomijamy to rozmyślnie.