Dziś porozmawiamy o wdrożeniach i o tym, w jaki sposób można zrobić wdrożenie aplikacji bez przestojów, żeby żaden z naszych klientów tego nie zauważył.

Jak wygląda normalne wdrożenie aplikacji?

Gdy wdrażamy kolejną wersję naszej aplikacji na serwer (mowa tu w szczególności o aplikacjach webowych), musimy wykonać kilka kroków:

1. Wyłączamy usługę. 
2. Wgrywany nowe pliki. 
3. Włączamy usługę. 

Poniższa animacja świetnie to obrazuje. Nie jest moja, ale bardzo mi się spodobała.

Tak więc pomiędzy pierwszym a ostatnim krokiem mamy przestój w działaniu aplikacji. Może on skutkować dla klientów niedostępnością całej naszej aplikacji lub też części jej funkcjonalności (jeżeli wdrażamy tylko serwis odpowiedzialny za pewien obszar np. wysyłkę SMSów). To jednak nie powinny być długie przestoje.

Jednak co w przypadku,  gdy nasze planowane wdrożenie aplikacji bez przestojów się nie uda? Gdy po wgraniu nowej wersji, aplikacja przestaje działać? Mamy dwie opcje:

1. Walczymy z problemem, próbując go mimo wszystko naprawić. 
2. Cofamy wersję aplikacji. 

Jednak w obu przypadkach tylko przedłużamy okres niedostępności naszej usługi. W pierwszym przypadku o cały czas potrzebny na naprawę danej funkcji, w drugim zaś o czas potrzebny na zrobienie backupu bazy i aplikacji, a następnie rollback (przywrócenie poprzednich wersji). W przypadkach jakichkolwiek błędów czas niedostępności drastycznie rośnie.

Możliwe rozwiązania

Co możemy więc zrobić, żeby uniknąć jakiejkolwiek planowanej niedostępności w naszych systemach?Możliwe jest kilka rozwiązań. Jednak każde z nich ma następujące wymagania:

• wdrażana zmiana musi być kompatybilna wstecz – integracje z naszą usługą powinny działać z dowolną wersją (zarówno starszą jak i nowszą)
• usługa powinna działać na wielu serwerach – żeby zminimalizować czas niedostępności, 
• musimy korzystać z load balancera lub proxy przekierowującego ruch – aby sterować kompunikacją pomiędzy klientem a naszą usługą hostowaną na wielu serwerach, 
• bezstanowość serwisu – nie powinno mieć znaczenia, że nasz klient rozpoczął proces na serwerze. 

Blue green

Jest to dość podstawowa strategia wdrażania bez przestoju aplikacji. Polega ona na tym, że utrzymujemy dwa środowiska: 

• niebieskie – aktualnie używane jako produkcja, 
• zielone – używane jako kopia niebieskiego środowiska do wdrożenia nowej wersji. 

Te dwa środowiska mogą być utworzone na różnym poziomie:

• każda instancja na różnych serwerach, 
• instancje blue/green na jednym serwerze i to zwielokrotnione. 

Dzięki temu wdrożenie będzie wyglądało tak:

1. Wdrażamy nową wersję na środowisko green. 
2. Przepinamy load balacer lub proxy dostępowe z instancji blue na green. 

Wtedy starsza wersja aplikacji nie musi zostać wyłączona i wszystkie żądania, które na niej były wykonywane zostaną zakończone, a przepięcie sieciowe zostanie wykonane natychmiastowo.

Zalety:

• testy wersji green przeprowadzane są na produkcji (a mianowicie na instancji, która zaraz stanie się produkcją). Daje to bardzo wiarygodne testy, ale może powodować problemy z danymi na produkcji;
• może być łatwo cofnięte do poprzedniego stanu w przypadku błędów.

Wady:

• wymaga pełnej kompatybilności wstecznej wszystkich zależności np. bazy danych;
• trzeba się upewnić, że procesy rozpoczęte na starszej wersji mogą być dokończone na nowszej wersji. 

Canary Deployment

Kolejna metoda na wdrożenie aplikacji bez przestojów polega na tym, że na początku wdrażamy nową wersję naszej aplikacji tylko w jednej instancji. Dzięki temu tylko część ruchu jest przekierowywana na nowe rozwiązanie. Zyskujemy zatem brak przestoju, bo Load Balancer nie przekieruje ruchu na niedziałającą usługę oraz możliwość wystawienia nowej wersji tylko części użytkownikom.Co więcej, gdy odpowiednio ustawimy reguły Load Balancera, będziemy mogli udostępnić nową wersję określonej grupie odbiorców (np. grupie małego ryzyka).
W tym przypadku wdrożenie aplikacji bez przestojów wygląda następująco:

1. Wdrażamy aplikację na pierwszą instancję. 
2. Czekamy na testy lub feedback. 
3. Wdrażamy aplikację na pozostałe instancje. 

Zalety:

• Możemy testować na produkcji.
• Możemy przeprowadzić “testy” na produkcji z udziałem docelowych użytkowników.
• Zbierając feedback od użytkowników możemy zdecydować o tym, czy wdrażamy dana zmianę, czy nie.
• Świetnie pasuje do podejścia toggle switch – selektywnego włączana określonych funkcjonalności.

Wady:

• Wymaga uważności przy zmianach bazy danych. 

Rolling deployment

Jest to rozszerzenie poprzedniego modelu – canary deployment. W rolling deployment wdrażamy naszą aplikację po kolei na kolejne instancje, jedna po drugiej.
Proces wdrożenia:

1. Najpierw wdrażamy nową wersję na instancję 1. 
2. Następnie wdrażamy nową wersję na instancję 2. 
3. Później kolejno wdrażamy nową wersje na instancję N. 

Dzięki temu nawet, gdy samo wdrożenie pojedynczej instancji generuje przestój, to zawsze utrzymujemy większość instancji w stabilnym stanie.

Zalety:

• Stopniowanie ruchu na nowej wersji. Jest to przydatne, jeżeli na bieżąco monitorujemy stan błędów w nowej wersji.
• Proste cofnięcie wersji w przypadku wykrycia problemów.
• Tańsze niż utrzymywanie pełnej kopii środowiska w blue green. 

Wady:

• wymaga automatyki wdrażania;
• istnieje możliwość problemów z kompatybilnością wersji. W tym przypadku baza danych musi być w stanie równocześnie pracować z nową jak i starą wersją. Tak samo procesy. Każda akcja w procesie może być wykonana na dowolnej instancji. 

Podsumowanie

Jak widać jest wiele technik na unikanie przestojów podczas wdrożeń oprogramowania. Każda z nich ma swoje dobre i złe strony. Jeżeli zależy nam na jak najmniejszym utrudnianiu pracy naszym klientom (lub aplikacjom klienckim), warto świadomie wybrać najlepsze do tego rozwiązanie.