Zero downtime deployment

Witam,
ogarniam sobie temat zero downtime deployment. Znalazłem metodę blue/green deployment oraz zrobiłem sobie małe demo w Springu (Eurek, Zuul). Teraz pojawiły się nowe pytania.

Po pierwsze: czy jest możliwe coś takiego - w Eurece mamy zrejestrowane dwie instancje serwisu; jak coś "wywali się" to jest możliwość skorzystania/podjęcia próby skorzystania z innej instancji serwisu.

Po drugie: czy to zrealizowania zero downtime deployment potrzebne jest tyle elementów (Eureka, Zuul)? To są dodatkowo dwie rzeczy, które trzeba utrzymać. Czy nie da się tego zrobić prościej?

Będę wdzięczny za wszystkie podpowiedzi i pomoc.

Nie trzeba nic aż tak komplikować. Stawiasz np. http://www.haproxy.org/ i rejestrujesz tam te swoje nody. Kiedy chcesz zrobić deploy to po prostu usuwasz ten node na chwile i dodajesz znów do listy jeśli wstanie i działa. Możesz w ogóle użyć jakiegoś zintegrowanego środowiska w stylu Openshift, gdzie w zasadzie masz to out of the box. Eureka czy Zuul dają ci możliwość dynamicznego skalowania i rekonfiguracji, ale nie wiem czy potrzebujesz coś takiego.

Shalom napisał(a):

Nie trzeba nic aż tak komplikować. Stawiasz np. http://www.haproxy.org/ i rejestrujesz tam te swoje nody. Kiedy chcesz zrobić deploy to po prostu usuwasz ten node na chwile i dodajesz znów do listy jeśli wstanie i działa. Możesz w ogóle użyć jakiegoś zintegrowanego środowiska w stylu Openshift, gdzie w zasadzie masz to out of the box. Eureka czy Zuul dają ci możliwość dynamicznego skalowania i rekonfiguracji, ale nie wiem czy potrzebujesz coś takiego.

Nie jest to takie trywialne. Jak serwujesz bezstanowy web to tak, wystarczy haproxy czy generalnie zautomatyzowany load balancer i masz Blue/Green deployment. Natomiast w praktyce, masz bazy danych, które trzeba często przemigrować, są integracje z ESB przez które przelatują dane, są też komendy, które są asynchroniczne i mogą uniemożliwić od tak przełączenie systemu na nową wersje. Dużo zalezy od samej aplikacji. Pierwszy nietrywialny problem: jak zapenić dostępność usługi kiedy baza jest migrowana na nowszą wersje. Drugi: w przypadku awarii, jak przywrócić poprzednią bazę i powtórzyć transakcje, które poleciały do nowej wersji.

Dużo zalezy od samej aplikacji. Pierwszy nietrywialny problem: jak zapenić dostępność usługi kiedy baza jest migrowana na nowszą wersje

Musisz tak projektować zmiany, żeby były kompatybilne wstecz, nawet jeżeli to zwiększy ilośc wdrożeń, bo wdrażasz nowa wersje kompatybilna wstecz, potem wersje ktora to czysci i migruje dane na nowa, te ktore wpadly do systemu podczas migracji

Jezeli masz jakas mega zmiane to mozesz odstapic od reguly i wprowadzic ja normalnym trybem, gdzie usługa jest niedostepna przez jakis czas, ale nie powinno byc takich zmian duzo.

Drugi: w przypadku awarii, jak przywrócić poprzednią bazę i powtórzyć transakcje, które poleciały do nowej wersji.
To samo co wyzej - wprowadzajac nowa wersje musisz byc komptatybilny wstecz i liczyc sie z tym, ze masz dwa modele danych przez pewien czas, dopiero majac nowy model wdrazasz wersje, ktora pozbywa sie starego

Nie wiem co rozumiesz przez pojęcie bezstanowy web, ale ludzie produkcyjnie tak działają, czyli B/G deployment, bazy danych, migracje, kolejki i się da. To, że jest to trudniejsze i bardziej czasochłonne jest kosztem wprowadzenia zero downtime deployment, cieżko mi wymyśleć realny przykład gdzie nie ma to kosztów, pomijajac zestawienie odpowiedniej infrastruktury, jeżeli takiej nie masz, PoCe nie PoCe, testy

hcubyc napisał(a):

Musisz tak projektować zmiany, żeby były kompatybilne wstecz, nawet jeżeli to zwiększy ilośc wdrożeń, bo wdrażasz nowa wersje kompatybilna wstecz, potem wersje ktora to czysci i migruje dane na nowa, te ktore wpadly do systemu podczas migracji

Jezeli masz jakas mega zmiane to mozesz odstapic od reguly i wprowadzic ja normalnym trybem, gdzie usługa jest niedostepna przez jakis czas, ale nie powinno byc takich zmian duzo.

Masz racje, ale nadal nie eliminuje to drugiego przypadku z awarią, kiedy migracja lub nowa wersja uszkadza dane.

Nie wiem co rozumiesz przez pojęcie bezstanowy web, ale ludzie produkcyjnie tak działają, czyli B/G deployment, bazy danych, migracje, kolejki i się da. To, że jest to trudniejsze i bardziej czasochłonne jest kosztem wprowadzenia zero downtime deployment, cieżko mi wymyśleć realny przykład gdzie nie ma to kosztów, pomijajac zestawienie odpowiedniej infrastruktury, jeżeli takiej nie masz, PoCe nie PoCe, testy

Chodziło mi o sytuacje gdy z punktu widzenia klienta usługa działa natomiast obsługa requestów (o ile to web) jest przejmowana przez nową wersje transparentnie. Trudniej jak system ma long polling czy po prostu serwer aplikacyjny trzyma stan i przy przepinaniu wersji transakcja zakończy się niepowodzeniem. Przeważnie jest to sytuacja do przełknięcia dla biznesu, bo klient powtórzy działanie, ale jeżeli wymaganie niefunkcjonalne to zero downtime to taki system już by go niespełnił.

Masz racje, ale nadal nie eliminuje to drugiego przypadku z awarią, kiedy migracja lub nowa wersja uszkadza dane.

A co jak gdy migracja w zwykłym deploymencie uszkodzi dane? Apka stoi, ale trzeba wgrac backup, a czas przerwy się wydłuza. W przypadku B/G dopiero w tym przypadku (awaria/blad) nastepuje przerwa i sila rzeczy utrata czesci danych. Generalnie nie zdarzyło mi się to jeszcze, może ktoś ma lepszą procedurę, to niech się podzieli, ale tak bym zrobił - system stop, naprawa, start.
Co do przypadku z awarią - jest to dodatkowe ryzyko, co do błędu w nowej wersji - wiadomo, każdemu może się zdarzyć, ale na testowanie trzeba położyc mocny nacisk w takim przypadku i też mieć srodowisko testowe z B/G żeby symulowac produkcyjne wdrożenie