• Akademia
  • Blog
  • O Serverless
  • O stronie

Najpopularniejsze problemy serverless


Najpopularniejsze problemy serverless
Pracuj膮c w IT od lat wiem, 偶e nie ma czego艣 takiego jak silver bullet. Ka偶de rozwi膮zanie ma swoje wady i zalety. Jakby tego by艂o ma艂o, cz臋sto nie ma obiektywnej, z g贸ry przyj臋tej, klasyfikacji, co jest wad膮, a co zalet膮. Przewa偶nie ocena zale偶y od konkretnej sytuacji i wymaga艅 stawianych przed budowanym rozwi膮zaniem. Jak to m贸wi膮: context is a king!

Mimo uderzaj膮cej relatywno艣ci bij膮cej z powy偶szego wst臋pu chc臋 przedstawi膰 Ci list臋 problem贸w z kt贸rymi prawie na pewno si臋 spotkasz korzystaj膮c z architektury i technologii serverless. By przygotowa膰 ten materia艂 jak najbardziej rzetelnie i wielowymiarowo poprosi艂em o wypowiedzi kilku rodzimych specjalist贸w od serverless, tak aby zbilansowa膰 moje subiektywne zdanie z do艣wiadczeniem i wiedz膮 innych os贸b.

Mam nadziej臋, 偶e ta lista umo偶liwi Ci podj臋cie 艣wiadomego wyboru czy serverless to jest co艣 z czym chcesz si臋 zmierzy膰 i czy na pewno zalety przewa偶aj膮 nad wadami w Twojej opinii?

Uwaga: w tym artykule nie b臋d臋 si臋 mierzy艂 z mitami i b艂臋dnymi przekonaniami funkcjonuj膮cymi w 艣wiatku programistycznym. Zatem je艣li czego艣 tu brakuje to albo w istocie nie jest problem albo jest na tyle b艂ahe, 偶e si臋 nie za艂apa艂o na t臋 list臋 馃槈 Przyk艂adem mitu jest rzekomo wy偶sza z艂o偶ono艣膰 rozwi膮za艅 serverless w stosunku do klasycznych architektur - znakomicie z tym rozprawi艂 si臋 Yan Cui w swoim artykule Even simple serverless applications have complex architecture diagrams鈥, so what?

Problemy serverless

1. Z艂udna prostota funkcji Lambda

Ka偶dy programista stawiaj膮c swoje pierwsze kroki w serverless ma ju偶 du偶y baga偶 do艣wiadcze艅 zdobytych na wcze艣niejszych projektach. Najcz臋艣ciej oznacza to, 偶e tworzy艂 aplikacji w architekturze monolit贸w w ci臋偶kich j臋zykach (Java czy C#). Oczywi艣cie, cz臋艣膰 os贸b ma ju偶 du偶e do艣wiadczenie w mikroserwisach, ale to nadal wi臋ksze komponenty ni偶 funkcje.

Przeskakuj膮c na serverless pisany w JavaScript czy Python 艂atwo zach艂ysn膮膰 si臋 wolno艣ci膮 oferowan膮 przez te technologie. Funkcje s膮 na tyle ma艂e i proste, a brak (wymuszania u偶ycia) typ贸w sprawiaj膮 razem, 偶e wydaje si臋 i偶 nie trzeba pami臋ta膰 o dobrych praktykach rzemios艂a programistycznego.

Wojciech D膮browskiNic bardziej mylnego! 艢wietnie t臋 kwesti臋 podsumowa艂 programista oraz Cloud Architect Wojciech D膮browski w swojej wypowiedzi:

Cz臋st膮 pu艂apk膮 i pokus膮 w aplikacjach serverless jest swobodne podej艣cie do jako艣ci kodu i test贸w automatycznych. Tworz膮c jakie艣 rozwi膮zanie, szczeg贸lnie na etapie POC lub MVP, stosunkowo 艂atwo jest przeoczy膰 ten aspekt. Pocz膮tkowy rozmiar kodu mo偶e by膰 znacz膮co mniejszy ni偶 w aplikacjach monolitycznych, czy nawet w mikroserwisach. To z kolei mo偶e podsun膮膰 my艣l, 偶e nie ma sensu pisa膰 do niego test贸w lub dba膰 o jego jako艣膰. Moim zdaniem powinni艣my traktowa膰 kod stworzony w ramach aplikacji serverless z co najmniej tak膮 sam膮 trosk膮. Pracuj膮c z takimi projektami, staram si臋 pami臋ta膰 o testach automatycznych. Warto r贸wnie偶 zastosowa膰 na przyk艂ad architektur臋 heksagonaln膮 - nawet w przypadku funkcji Lambda.

2. Testowanie

Zdecydowanie z testowaniem b臋dziesz mie膰 problemy. Nie spotka艂em si臋 w swojej karierze z nikim kto by na to w serverless nie narzeka艂. Wr臋cz przeciwnie!

Bynajmniej nie oznacza to, 偶e si臋 nie da testowa膰!

Wojciech Gawro艅skiTestowanie to standardowe wyzwanie przy pracy z aplikacjami klasy Serverless - m贸wi Wojciech Gawro艅ski, g艂贸wny architekt i CTO w firmie Pattern Match - wymaga zmiany nastawienia oraz poznania nowych wzorc贸w architektonicznych (np. ports and adapters - znany r贸wnie偶 pod nazw膮 architektury heksagonalnej).

Jednak same wzorce i style architektoniczne nie wystarcz膮. W pierwszej kolejno艣ci nale偶y zrozumie膰 sedno problemu i zidentyfikowa膰, co najbardziej si臋 do niego przyczynia. Moim zdaniem g艂贸wnym winowajc膮 jest fakt, 偶e w architekturze serverless korzystamy z wielu gotowych us艂ug, kt贸re rozdzielaj膮 nasz kod na ma艂e cz臋艣ci. Na przyk艂ad Lambda -> SNS -> Lambda -> DynamoDB -> Lambda -> SES (6 komponent贸w a kod mamy tylko w trzech z nich). Te fragmenty bez us艂ug w chmurze nie maj膮 wi臋kszego sensu i po prostu nie dzia艂aj膮. Prosz臋, nie zrozum mnie 藕le, wykorzystanie gotowych us艂ug to r贸wnocze艣nie najwi臋ksza zaleta serverless, niestety utrudnia testowanie.

Na przestrzeni ostatnich dw贸ch lat mo偶na zauwa偶y膰 intensywne dzia艂ania spo艂eczno艣ci serverless maj膮ce na celu u艂atwienie testowania. Je艣li chodzi o design nale偶y wymieni膰 wykorzystanie wspomnianej ju偶 architektury heksagonalnej oraz na odej艣cie od starej dobrej piramidy test贸w i zast膮pienie jej bardziej nowoczesnym konceptem, kt贸ry diametralnie zwi臋ksza ilo艣膰 zalecanych test贸w integracyjnych.

Zmiany w podej艣ciu do testowania aplikacji

Zmiany w podej艣ciu do testowania aplikacji. Po lewej klasyczna Piramida test贸w. Po prawej Plaster miodu zaproponowany przez Spotify. Opracowanie w艂asne na bazie: https://engineering.atspotify.com/2018/01/11/testing-of-microservices/

Na p艂aszczy藕nie technicznej, pojawi艂o si臋 wiele rozwi膮za艅 z kt贸rych do艣膰 du偶膮 popularno艣膰 zyska艂y wszelkiego typu mocki - maszyny wirtualne uruchamiane w Dockerze na komputerze programisty emuluj膮ce prawdziwe us艂ugi chmury AWS. Najbardziej znany jest tutaj localstack, kt贸rego u偶ycie jest antywzorcem i zdecydowanie go Tobie odradzam!

To mo偶e by膰 zaskakuj膮ca rada dlatego j膮 uzasadni臋. Po pierwsze localstack to projekt open-source, kt贸ry nie jest wspierany przez AWS i nie gwarantuje, 偶e mocki us艂ug b臋d膮 sie zachowywa艂y jak orygina艂y. Po drugie, u偶ywaj膮c tego typu rozwi膮za艅 nie jeste艣 w stanie przetestowa膰 dost臋p贸w opisanych rolami IAM, co w praktyce oznacza, 偶e Twoje testy w 偶aden spos贸b nie gwarantuj膮, 偶e po deploymencie Tw贸j kod b臋dzie dzia艂a膰 w chmurze! I wreszcie po trzecie u偶ycie mock贸w i Dockera komplikuje 艣rodowisko deweloperskie (sam niejednokrotnie s艂ysza艂em jak kto艣 sp臋dzi艂 2 dni na konfiguracji tego typu rozwi膮za艅).

Zatem jak testowa膰?

Nale偶y pisa膰 du偶o test贸w integracyjnych, kt贸re u偶ywaj膮 rzeczywistych zasob贸w w chmurze. Projektuj膮c aplikacj臋 w stylu architektury heksagonalnej jest to wzgl臋dnie proste i dosy膰 艂atwo napisa膰 kod kt贸ry komunikuje si臋 z us艂ugami w AWS (czy dowolnej innej chmury) z komputera programisty. Co wi臋cej, w ten spos贸b mo偶na r贸wnie偶 testowa膰 przywileje funkcji Lambda opisane rolami IAM - tego 偶aden mock, ani Docker nie umo偶liwia.

3. D艂ugi feedback loop - kiepski workflow programisty

Workflow wielu programist贸w w serverless jest nieefektywny:

  1. Piszesz kod
  2. Deployujesz do chmury
  3. Odpalasz Lambd臋鈥 i nie dzia艂a.
  4. Wracasz do punku 1.

Po paru takich iteracjach w ko艅cu masz dzia艂aj膮cy kod, ale to zajmuje zdecydowanie zbyt du偶o czasu.

Proces deploymentu funkcji trwa oko艂o minuty, jej uruchomienie kolejne kilkana艣cie sekund - razem to powoduje, 偶e feedback loop jest d艂ugi, a Ty dostajesz informacj臋 zwrotn膮 czy co艣 dzia艂a czy nie po d艂u偶szej chwili. Na tyle d艂ugiej, 偶e cz臋sto co艣 zd膮偶y wybi膰 Ci臋 z flow programistycznego.

Oczywi艣cie to si臋 bezpo艣rednio wi膮偶e i jest efektem braku test贸w o czym ju偶 pisa艂em.

4. Ci臋偶ko znale藕膰 przyczyn臋 b艂臋d贸w

Nawet w stosunkowo prostych mikroserwisach zbudowanych w oparciu o serverless u偶ywamy minimum kilku us艂ug, kt贸re to aby zosta膰 poprawnie skonfigurowane na etapie deploymentu tworz膮 setki zasob贸w w chmurze (Resources w rozumieniu element贸w stack贸w CloudFormation). Oczywi艣cie, przyt艂aczaj膮ca wi臋kszo艣膰 jest generowana dla nas automatycznie ,ale to pokazuje ile rzeczy musi ze sob膮 wsp贸艂gra膰, aby system dzia艂a艂 poprawnie.

Mnogo艣膰 zasob贸w po stronie infrastruktury oraz fakt, 偶e serverless to s膮 systemy rozproszone powoduj膮, 偶e debugowanie aplikacji jest pracoch艂onne i cz臋sto trudne.

Odpowiedzi膮 na ten problem jest obserwowalno艣膰, czyli logowanie, monitoring i 艣ledzenie. U偶ycie dedykowanych rozwi膮za艅 (w tym komercyjnych) w celu monitoringu i 艣ledzenia tego jak informacje przep艂ywaj膮 mi臋dzy komponentami naszego rozwi膮zania jest jak najbardziej zalecane, szczeg贸lnie w systemach produkcyjnych o du偶ym wolumenie transakcji.

Je艣li kiedykolwiek s艂ysza艂e艣 o NoOPS w kontek艣cie serverless to jest to po prostu nieprawda.

5. Mnogo艣膰 opcji wyboru - wzgl臋dno艣膰 architektury

Skoro ju偶 wspomnia艂em o wolumenie transakcji to kontynuujmy ten temat. Jest to krytyczny wsp贸艂czynnik, kt贸ry powinien ostateczne decydowa膰 przy wyborze konkretnych us艂ug, a wi臋c i samej architektury. Dzieje si臋 tak dlatego, poniewa偶 r贸偶ne us艂ugi AWS mo偶emy u偶y膰 do realizacji tego samego zadania i dop贸ki nie we藕miemy pod uwag臋 wolumenu wyb贸r cz臋sto b臋dzie kwesti膮 gustu.

Za przyk艂ad niech pos艂u偶膮 nast臋puj膮ce us艂ugi: SNS, SQS, EventBridge oraz Kinesis. Wszystkie s艂u偶膮 do przesy艂ania wiadomo艣ci, ka偶da z nich ma inne limity oraz inn膮 charakterystyk臋 koszt贸w uzale偶nion膮 w艂a艣nie od wolumenu.

Przyk艂ad: Je艣li by艣my mieli wysy艂a膰 jedn膮 wiadomo艣膰 wielko艣ci 1KB, co jedn膮 sekund臋 przez ca艂y miesi膮c to SNS by nas kosztowa艂 1,296 USD (1 dolar 29 cent贸w), EventBridge 2,592 USD, a Kinesis a偶 10,836 USD. R贸偶nica, a偶 o jeden rz膮d! Jednak przy skali 1000 wiadomo艣ci na sekund臋 nast臋puje grube przetasowanie. SNS kosztuje 1296,00 USD, EventBridge 2592,00 USD, a Kinesis tylko 47,09 USD. (殴r贸d艂o: Yan Cui)

To powoduje, 偶e trudno jest wybra膰 optymaln膮 architektur臋.

Patrz膮c na ten problem od innej strony, mo偶na powiedzie膰, 偶e nawet osoby ze sporym do艣wiadczeniem, zdobytym na wielu projektach serverless o niskich wolumenach mog膮 by膰 zaskoczone, 偶e ich sprawdzone wzorce nagle przestaj膮 by膰 najlepszym mo偶liwym rozwi膮zaniem.

Nawet pomijaj膮c aspekt koszt贸w, w ko艅cu nie ka偶dy system przetwarza miliony transakcji dziennie, projektowanie mo偶e si臋 okaza膰 wyzwaniem. Mnogo艣膰 opcji i trudno艣膰 wyboru mi臋dzy nimi, zdecydowanie cz臋sto przewija艂a si臋 w wypowiedziach moich rozm贸wc贸w.

Tomasz Bre艣

Tomasz Bre艣, AWS Cloud Architect w firmie TT PSC, zilustrowa艂 to nast臋puj膮cym przyk艂adem ze swojego projektu:

Przy przetwarzaniu event based trafili艣my na problem r贸偶nych poziom贸w konkurencyjno艣ci dla r贸偶nych us艂ug AWS. Np. S3 -> S3 Event -> Lambda (konkurencyjno艣膰 1000) Przy za艂adowaniu 300 tys. Plik贸w Lambda nie wyrabia Rozwi膮zanie: SQS Np. S3 -> S3 Event -> SQS -> Lambda Problem zostaje, je偶eli ta Lambda uruchamia np. GlueJob (konkurencyjno艣膰 70) Np. S3 -> S3 Event -> SQS -> Lambda -> GlueJob Wiadomo艣ci pi臋trz膮 si臋 na kolejce, gdy Lambda pr贸buje uruchomi膰 GlueJoba dostaj膮c w odpowiedzi b艂膮d konkurencyjno艣ci. W efekcie przepustowo艣膰 ca艂ego rozwi膮zania jest ograniczona do 70 r贸wnoleg艂ych proces贸w na raz. Rozwi膮zanie: U偶ycie EFS w Lambdzie do za艂adowania wymaganych bibliotek, kt贸re by艂y za du偶e do standardowego (250MB) rozmiaru Lambdy i w ten spos贸b pomini臋cie w膮skiego gard艂a (Glue Job).

Karol Junde

Z problemami podobnej natury niejednokrotnie mierzy艂 si臋 Karol Junde, VP i CTO w firmie Chaos Gears, kt贸ry przedstawi艂 nast臋puj膮ce alternatywy do wyboru:

29 sekundowy timeout dla wszystkich rodzaj贸w integracji API Gateway z us艂ugami AWS mo偶e wprowadza膰 delikatne konsternacje. Rozwi膮zania kt贸re najcz臋艣ciej stosujemy to po艂膮czenie API Gateway z funkcj膮 Lambda (nazywamy j膮 鈥渇orwarderem鈥), kt贸rej jedynym zadaniem jest jak najszybsze odebranie eventu, przekazanie go dalej do SNS(model pub-sub), SQS lub ostatnio do EventBridge oraz oczywi艣cie zwr贸cenie odpowiedzi. W przypadku forwardera wa偶nym elementem jest zrozumienie paradygmatu 鈥渃oncurrency鈥 dla funkcji Lambda. Druga metoda to integracja API Gateway bezpo艣rednio z SQS i tutaj dochodzimy do scenariusza 鈥渨ebhooks鈥, gdzie user uderza z request do API Gateway, dostaje odpowied藕 o przyj臋ciu request, a nast臋pnie backend w postaci API Gateway + SQS + Lambda + SNS zwraca mu odpowied藕 w momencie kiedy request zosta艂 obs艂u偶ony.

My艣l臋, 偶e powy偶sze przyk艂ady pokazuj膮, 偶e nawet do艣wiadczonym in偶ynierom - a mo偶e przede wszystkim im, gdy偶 znaj膮 us艂ugi na wylot - czasem trudno jest wybra膰 t臋 jedn膮, ostateczn膮, najlepsz膮 architektur臋.

6. Pr臋dzej czy p贸藕niej musisz skorzysta膰 z serwerowych rozwi膮za艅!

Brzmi jak herezja!

Nie chodzi mi o to, 偶e ka偶dy jeden projekt b臋dzie do tego zmuszony. Bardziej o to, 偶e Ty jako programista w kt贸rym艣 z kolei projekcie b臋dziesz musia艂 skorzysta膰 z us艂ug serverFULL - wtedy poczujesz jak wielki overhead generuj膮 i dlaczego serverless jest wspania艂y! 馃槈

Ich konfiguracja jest czasoch艂onna i konieczna wsz臋dzie tam gdzie b臋dziesz musia艂 sie zintegrowa膰 z relacyjna baz膮 danych (RDS) lub pod艂膮czy膰 dysk sieciowy (EFS) do funkcji Lambda. To tylko dwie z szerszej grupy sytuacji gdzie b臋dziesz musia艂 skorzysta膰 z VPC. I o ile w przypadku RDS mo偶na zrzuci膰 win臋 na integracj臋 z legacy app to w przypadku EFS ju偶 tego tak si臋 uzasadni膰 nie da (ile z tym zabawy opisa艂em tutaj).

Poza dodatkow膮, konieczn膮 prac膮 niezb臋dn膮 do skonfigurowania i u偶ycia tych us艂ug nale偶y te偶 pami臋ta膰, 偶e serwerowe us艂ugi zupe艂nie inaczej si臋 skaluj膮 ni偶 te serverless i cz臋sto wymagaj膮 daleko posuni臋tych dzia艂a艅 maj膮cych na celu ich ochron臋 przed gwa艂townymi peakami, kt贸re mog艂yby - m贸wi膮c kolokwialnie - je zar偶n膮膰.

7. Dziury funkcjonalne w AWS

Po kilku latach pracy z AWS nabierasz do艣wiadczenia i rutyny. Aplikacje serverless projektujesz w g艂owie prawie natychmiast po tym jak us艂yszysz nowe wymagania od swojego szefa.

Siadasz do komputera i implementujesz. I tak po prostu jest!

Z drobnym ale.

My艣l膮c na wysokim poziomie zapominasz, 偶e us艂uga A nie integruje si臋 bezpo艣rednio z us艂ug膮 B. Tam gdzie by艂e艣 pewien, 偶e No przecie偶 niemo偶liwe, 偶eby AWS tego nie zrobi艂 okazuje si臋, 偶e jednak mo偶liwe.

Jest nawet taki hashtag na Twitterze #AwsWhishList - to oczywi艣cie dotyczy ca艂ej chmury, a nie tylko us艂ug serverless ale w obszarze Lambdy nadal jest par臋 rzeczy kt贸re mog艂yby by膰. 馃檪

Przyk艂ady? Prosz臋 bardzo: Amazon DynamoDB Streams nie pozwala ustawi膰 SQS jako celu. Eventy S3 nie mog膮 si臋 nak艂ada膰 na siebie. Lambda Destinations dzia艂a tylko przy asynchronicznym wywo艂aniu funkcji. Podobnym spostrze偶eniem podzieli艂 si臋 wspomniany ju偶 Wojciech Gawro艅ski:

Pod powierzchni膮 czaj膮 si臋 problemy - przyk艂ad: S3 Event Notifications, kt贸re 艣wietnie pasuj膮 do wielu zastosowa艅, ale nie maj膮 偶adnych gwarancji dot. kolejno艣ci, gwarancji dostarczania i czasu wysy艂ki - co ma znaczenie dla niekt贸rych przypadk贸w u偶ycia. Jedynym rozwi膮zaniem w takim przypadku jest nauka i eksperymentowanie (np. poprzez proof of concept), tak aby pozna膰 te rozwi膮zania w praktycznym wydaniu i pozna膰 ich wady/zalety.

Trzeba tutaj jednak wyra藕nie zaznaczy膰, 偶e ilo艣膰 pracy i zasob贸w inwestowana przez AWS w us艂ugi serverless, z Lambd膮 na czele, jest ogromna i z roku na rok, coraz pro艣ciej, 艂atwiej i przyjemniej budowa膰 w艂asne rozwi膮zania korzystaj膮c z tych nowych funkcjonalno艣ci.

8. Panta rhei

I p艂ynnie przechodzimy do ostatniego filozoficznego problemu. Wszystko p艂ynie, a w AWS to p艂ynie w osza艂amiaj膮cym tempie. Pr臋dko艣膰 z jak膮 si臋 rozwija ekosystem Lambdy oraz inne us艂ugi serverless powoduje, 偶e co p贸艂 roku, a ju偶 na pewno po ka偶dym re:Invent nasze rozwi膮zania mo偶na gruntownie przebudowa膰! 馃槈

Wyobra偶am sobie, 偶e niezmiernie ci臋偶ko by艂oby komukolwiek wr贸ci膰 do projektowania rozwi膮za艅 serverless po dwuletniej przerwie. Trzeba by膰 na bie偶膮co. Usprawnienia s膮 czasem na tyle du偶e, 偶e co艣 co kiedy艣 by艂o uwa偶ane za best practice dzi艣 jest antywzorcem (np. grzanie funkcji Lambda, aby unikn膮膰 cold start贸w).

Ci膮g艂e zmiany i wspomniana powy偶ej wzgl臋dno艣膰 architektury skutkuj膮 stosunkowo ma艂膮 ilo艣ci膮 sztampowych rozwi膮za艅 i najlepszych praktyk. W rezultacie na projektantach i architektach spoczywa ci臋偶ar przygotowania rozwi膮zania do kt贸rego maj膮 pe艂ne zaufanie, 偶e jest najlepszym z wielu zmieniaj膮cych si臋 alternatyw. To nie艂atwe zadanie wymaga du偶ej wiedzy oraz pewno艣ci siebie.

Podsumowanie

Mam wielk膮 nadziej臋, 偶e powy偶sza lista nie zniech臋ci Ci臋 do serverless. Jest to wspania艂a technologia, kt贸ra oferuje bardzo wiele (o czym niejednokrotnie pisa艂em) i praca z ni膮 to dla mnie osobi艣cie czysta frajda. 馃榾

Nie ma rzeczy idealnych, a te problemy potraktuj jako wyzwania i po prostu si臋 do nich przygotuj, albowiem na pewno b臋dziesz musia艂 si臋 z nimi zmierzy膰. Teraz ju偶 wiesz 馃槈