[czlowiek_z_lisciem_na_glowie]

Jak wygląda deploy na produkcję w aplikacjach, takich jak Facebook, Twitter, Google, YouTube, Twitch, Instagram, giełdy brokerów, kryptowalut itd.. czyli tam gdzie nawet minuta fakapu przynosi milionowe straty.
Czy są wdrażane jakieś procedury bezpieczeństwa nieznane w "normalnych" aplikacjach, czy siedzi sobie jakiś senior backend developer, widzi, że przeszły testy, robi merga do gałęzi prod i deploy? ( ͡º ͜ʖ͡º)

#programista25k #programista15k #programowanie #technologia

[bb89]

@czlowiek_z_lisciem_na_glowie AB testing na początek

[sawcioo]

Przecież ten system jest rozproszony, nie aktualizują wszystkich serwerów od razu, podejrzewam że jest to rozbite nawet na kilka dni jak wchodzi coś grubszego

[czlowiek_z_lisciem_na_glowie]

@sawcioo
No ale np. core backendu giełdy kryptowalut, gdzie w każdej sekundzie zachodzi setki tysięcy transakcji w czasie rzeczywistym nie może być rozproszony, a jakoś działają bez fakapów. Twitter także działa w czasie rzeczywistym w przeciwieństwie do Facebooka, który ma odczuwalny cache.

[sawcioo]

Jakiś load balance musi być na giełdach typu binance gdzie jest tylu użytkowników, zawsze można odciąć połowę serwerów zaaktualizować wszystkie i następnie przepiąć cały ruch na nowe serwery a stare odciąć

[JanPawelDrugiLechWalesaPierwszy]

@czlowiek_z_lisciem_na_glowie: bardzo często te największe firmy testują na produkcji bo nie są w stanie zrobić tego w inny sposób. Natomiast:
- aktualizują pojedyncze serwisy które są niezależne od innych
- są przygotowani na awaria czyli: aktualizują tylko część serwerów danego serwisu, mogą w łatwy sposób przywrócić starą wersję.

PS kiedyś pracowałem w małej firmie w której właściciel myślał że jak będziemy testować na produkcji to staniemy się najlepsza firma na

[NoName4891]

@czlowiek_z_lisciem_na_glowie: blue green deployments

[janciopan]

@czlowiek_z_lisciem_na_glowie: Strzelam, że używają jakiegoś kubernetesa albo czegoś podobnego.

Masz pierdyliard mikroserwisów, każdy ma ileś tam working nodów a jak dochodzi do aktualizacji mikroserwisu to po prostu working node jest ubijany, reszta starych nodów działa, na nich ruch jest przekierowany a później wstaje z nową wersją, kolejny node jest ubijany, i tak dalej.

Najbardziej skomplikowane moim zdaniem są raczej migracje na bazie i ja nie wiem jak oni to robią.

[janciopan]

@czlowiek_z_lisciem_na_glowie:

[atraac]

@czlowiek_z_lisciem_na_glowie http://softwareengineeringdaily.com/2019/08/27/facebook-release-engineering-with-chuck-rossi/

[szmichal]

@czlowiek_z_lisciem_na_glowie: myślę, ze mają dobry rollout i rollback plan i kazdy zaangazowany wie co robić

[szmichal]

@czlowiek_z_lisciem_na_glowie: Spotify nawet najdrobniejsze zmiany po testach wrzuca od razu na proda, jak bede mial czas to odkopię artykuł. Mysle ze tez jest to jakiś sposob by ograniczyc fuckupy, releasujac kod z malymi zmianami

[janciopan]

@szmichal: jak pracowałem przy bardzo dużym polskim projekcie to robiliśmy mikrowgrywki mikroserwisów nawet kilka razy dziennie, jak coś się wywaliło to właśnie rollback a środowiska testowego nie było bo stały stack był za bardzo skomplikowany. Paradoksalnie jakoś to działało.

[ponton]

@czlowiek_z_lisciem_na_glowie: https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/

[tylko_zerknalem]

@czlowiek_z_lisciem_na_glowie:
1. Każda z tych platform jest pod spodem zbudowana z dziesiątek mniejszych aplikacji.
2. Deployment nowego ficzera to deployment tylko jednej z N aplikacji.
3. Sam deployment robi się etapami. Mogą to być np. canary deployments (gdzie powiedzmy 10% ruchu przepuszcza się przez nowe instancje, a 90% ruchu zostaje na starych instancje) albo green/blue deployments (gdzie mamy na produkcji zarówno starą i nową wersję aplikacji, i na poziomie load balancera decydujemy do której idzie ruch)
4. Sama kwestia tego że zawsze znajdzie się jakaś instancja jest ogrywana na poziomie infrastruktury i load balancera: dopóki nowa wersja aplikacji w pełni nie wstanie, to stara cały czas będzie wpięta do load balancera i będzie serwowała ruch. W momencie kiedy nowa wstanie i zacznie zbierać ruch, to starą wypina się z load balancera (pozwalając jej jednak przetworzyć wszystkie aktualnie przetwarzane requesty).
5. Oprócz samych strategii deploymentu bardzo mocno stosuje się też feature flagi (aka feature toggles). Wtedy odseparowujesz deployment od releasu. Możesz np. wdrożyć na produkcję ficzer który nie jest w pełni przetestowany, ale jest ukryty za feature flagą i użytkownik końcowy go nie widzi (ale widzi go na przykład Twój

[nad__czlowiek]

@czlowiek_z_lisciem_na_glowie: canary deployment

[Mazowia]

@czlowiek_z_lisciem_na_glowie w takim enterprise w którym pracuję to budują nową wersję na innym serwerze i później robią przekierowanie . Nawet jest jeden serwis do synchronizowania sesji.