Przypadki użycia chmury AWS i lambd w pracy

W jaki sposób korzystacie w pracy z AWS lambda? Jaki jest use case, możecie się pochwalić? Pozwoli mi to bardziej zrozumieć przydatność tego "narzędzia" w stosunku do zwykłej apki wrzuconej do chmury.

Zaczynam się uczyć chmury prywatnie i chciałbym wiedzieć jakie rzeczy są ważne, czego firmy najczęściej używają i potem pytają na rozmowach.
Często w ogłoszeniach widzę S3, SQS/SNS, Lambda, DynamoDB i API Gateway.

Lambdy możesz użyć do wszystkiego. Od zwykłego api calla, po mostek między innymi serwisami. W poprzednim projekcie np używaliśmy lambd do monitorowania źródła on premise spiętego przez apache nifi. Był to swojego rodzaju event listener, który reagował na zmiany po stronie on premis -> Zrzucał nowe dane na chmure.

Mam ten sam problem, nawet nie zauważyłem jak się pojawiło wszędzie aws labmda, kubernetes, terraform i tak dalej nawet w CV dla backendowca.

Na razie czytam ten artykuł, wnosi trochę jasności.

https://aws.amazon.com/blogs/compute/replacing-web-server-functionality-with-serverless-services/

supergosc napisał(a):

Często w ogłoszeniach widzę S3, SQS/SNS, Lambda, DynamoDB i API Gateway.

Usługi AWS to trochę jak Lego czy meble z Ikei. Można je łączyć ze sobą.

Ouliqk napisał(a):

Mam ten sam problem, nawet nie zauważyłem jak się pojawiło wszędzie aws labmda, kubernetes, terraform i tak dalej nawet w CV dla backendowca.

Na frontendzie też już tego często wymagają. Takie czasy.

Mamy system, nagle pojawiło się wymaganie, na zdarzenie XYZ zintegrujcie się z ABC - tylko, że ta integracja to wysłanie 1 requestu API z kluczem dostępowym - napisanie prostej funkcji i podłączenie je pod system wiadomości jest dużo prostsze niż pisanie serwera, który wejdzie w ramach CI/CD. Już nie mówiąc, że to robi się z palca i zamyka w "chwilę".

Natomiast ogólnie nie polecam ani CloudFunctions / AWS Lambda - wychodzą drogo, kod jest ciężki do zarządzania, już praktyczniejsze jest zrobienie monolitu "utilów" i jak zacznie to się powiększać i będzie uzasadnienie - zastanowienie czy nie podzielić na mniejsze kawałki

Lambdy maja wiele zastosowan. Ogolnie dzielac toporem albo idzie sie w kubernetesa albo w serverlessa. Ja pracuje juz dlugo z serverlessem.
Po jakims czasie generalnie nie ma to wiekszego znaczenia, ze uzywasz serverless (od dev experience). Jednak na poczatku jest troche 'inaczej'.
Cala apke da sie postawic na sls stacku. APi gw/lambda/dynamodb/sqs. Dobre do internal apek w jakims korpo albo apek z burstem/event driven tak to nazijmy, jednak jak skala jest naprwade duza to roznie z tym moze byc.

so pluzy so minuzy. Jedni znaja i beda fanbojowac, drudzi nie znaja i bedo [CIACH!] glupoty :D

Z racji tego, że siedzę w chmurach to było tego dużo. Z takich ciekawszych rzeczy to:

• integracja z zewnętrznym systemem, który w momencie zmiany swojego stanu wysyłał nam informację o tej zmianie. Wyglądało to tak, że wiadomość trafiała pod dedykowany endpoint w naszym AWS API Gateway, który następnie wrzucał tą informację na kolejkę AWS SQS, która robiła jako backend store dla lambdy i stamtąd Lambda już sobie pobierała te informacje w batchach i odpowiednio przetwarzała.
• serwis do powiadomień oparty o logi i metryki w CloudWatch i wysyłający powiadomienia na kanał MS Teams
• implementacji wzorca SAGI
• orkiestracja i planowanie prostych zadań administracyjnych jak backupy
• automatyczne tagowanie zasobów tworzonych z poziomu Terraforma/CloudFormation
• obsługa i przetwarzanie plików w locie jak dodawanie watermarków do uploadowanych/tworzonych dokumentów

Generalnie AWS-owe Lambdy, ale też Azure Functions dobrze sobie radzą w takich prostych zadaniach jak wymienione wyżej. Raczej nikt normalny nie buduje logiki aplikacji wyłącznie na Lambdach (choć znam jedną taką osobę, która w ten sposób prawie uwaliła projekt za kilka milionów EUR).

Plusem usług takich jak AWS Lambda czy Azure Functions jest możliwość ich szybkiego napisania i uruchomienia. Jeżeli nie robisz na nich skomplikowanych obliczeń to też wychodzą tanio. Przykładowo Azure Functions do miliona wywołań są za darmo. Można takie lambdy skonfigurować za pomocą cron expressions aby wykonywały się o określonej porze, a korzystając z AWS Step Functions można budować proste procesy biznesowe.

Do tego dochodzą zastosowania DevOpsowe i administracyjne, gdyż devopsi czy admini nie muszą pisać aplikacji, a potem tworzyć serwerów do nich, żeby sobie jakieś rzeczy zautomatyzować. Biorą lambdę piszą kawałek kodu w Node albo Python i gotowe.

Generalnie do prostych zadań jako uzupełnienie tradycyjnie pisanych usług i aplikacji i tam gdzie koszt napisania i utrzymywania tradycyjnej aplikacji ze względu na jej prostotę byłby wysoki, są jak znalazł.

@durdur:

Zależy jak rozumie się ETL-e. Jeżeli wymaganiem jest przesłać dane z A do B lekko je modyfikując po drodze to jest to dobre rozwiązanie i też tak robię bo nie widzę sensu używania Airflow, czy AWS Glue. Jeżeli mamy do czynienia z rasowym ETL to funkcje się nie opłacają.

A jak z maintainability tych lambd w dluzszym terminie? Ktos tu wspomnial, ze u niego one nie wchodza w ramach CI/CD , to w takim razie jak wchodzą na srodowisko - z laptopa kolegi? Da sie to sensownie automatycznie otestować (z efemeryczną/mockowana infrastrukturą) i wdrażać?

@sine:

A jak z maintainability tych lambd w dluzszym terminie?

Tak jak z każdym innym komponentem aplikacji. Dobrze napisana aplikacja korzysta z IaaC do tworzenia swojego środowiska w chmurze, więc lambdy nie są niczym innym jak modułem w takim Terraformie, który siedzi sobie w repo obok innego kodu infrastruktury oraz kodu aplikacji.

Pracowałem 2 lata w projekcie opartym na AWS Lambda i mogę bardzo polecić ten styl wytwarzania oprogramowania. Także moja opinia będzie poparta doświadczeniem a nie teorią.
Zaznaczę że pracowałem w projektach Legacy, Spring, Java EE i tym podobnych rzeczach. Dla mnie AWS Lambdy to kolejny lvl'up w stosunku do poprzednich doświadczeń. Opiszę plusy

Plusy:

• możliwość fajnie zaprojektowania architektury opartej na zdarzeniach, CRUDA też w tym idzie zrobić jak coś
• generowanie od razu diagramów architektury i obrazowania tego za pomocą funkcji biznesowych
• dzięki obrazowaniu funkcji biznesowych jako Lambd bardzo łatwo prowadzi się komunikację z biznesem, ponieważ obrazuje się im system za pomocą tych tych lambd i połączeń między nimi
• dochodziło do tego że na Refinmentach pokazywaliśmy architekturę Lambd i Project Manager, Product Owner ludzi z biznesu namacalnie widzieli jakie funkcje mamy i sugerowali co gdzie dodać nawet xD Product Owner był w stanie sam nawet na to spojrzeć i przeanalizować, a to bardzo duży plus
• gdy robiłem mikroserwisy musiałem robić Kubernetesy, Tracing, Telemetry, Load Balancing i wiele innych rzeczy dookoła, Security
• w przypadku osadzenia swojej pracy w AWS Lambdach, Java Developer taki przeciętny ma tak naprawdę w pompie wszystko dookoła i pozawala się mu skoncentrować na pisaniu czystych funkcji biznesowych
• AWS Lambdy mają out-of-the-box skalowanie, monitoring, pipeliny, security jest out of the box, logi i tym podobne rzeczy
• Jako Java Developerzy często przepalają hajs na stawianiu infrastruktury pół roku, urzymywaniu jej itd tutaj tego nie ma, w zasadzie można być już na produkcji w jeden miesiąc
• serverless

Minusy:

• na razie nie widzę,
• bardzo drogo
• nie wszystko idzie w tym zaprojektować, ale raczej póki co nie widziałem przeszkód
• coldstart

@sine:

A jak z testowaniem? Nie chodzi mi o logike funkcji (to powinno byc trywialne do otestowanie) tylko bardziej o cały proces biznesowy czy security, ktore sie konfiguruje nie w funkcji, tylko wlasnie w infrastrukturze. @oliver_ pisze w nastepnym poscie, ze programista nie musi sie tym martwic - to kto sie martwi (testuje) security?

Różnie to jest. Jeśli chodzi o security to jak masz zespół devops to oni dbają o to aby rozwiązanie od strony infrastruktury było bezpieczne. Gdy programiści robią też devops to oni.

Co do testów logiki biznesowej to masz coś takiego jak sam local invoke które służy do uruchamiania lambd lokalnie. Możesz też mieć testy automatyczne które testują ich zachowanie na środowisku testowym w chmurze. Nie różni się to od testowania integracyjnego jakie stosuje się w architekturach mikrousługowych, gdzie twoje testy uderzają pod różne endpointy usług i sprawdzają czy odpowiedzi i ich zachowanie jest takie jakie być powinno.

Dzięki wszystkim za dotychczasowe odpowiedzi (nie zamykam tematu xD), temat wydaje się bardzo ciekawy i teraz tym bardziej będę w niego brnął i postudiuję sobie. :)

sine napisał(a):

A jak z maintainability tych lambd w dluzszym terminie? Ktos tu wspomnial, ze u niego one nie wchodza w ramach CI/CD , to w takim razie jak wchodzą na srodowisko - z laptopa kolegi? Da sie to sensownie automatycznie otestować (z efemeryczną/mockowana infrastrukturą) i wdrażać?

Z testowaniem bieda, to chyba największy problem lambd i wszystkich usług cloud specific. Im więcej logiki w chmurze tym bardziej trzeba testować całą chmurę, żeby mieć jakiekolwiek przydatne testy. Jest taki fajny framework do takiego stylu programowania https://www.serverless.com/#How-It-works , gdzie każdy developer może postawić sobie kopię środowsika on demand za śmieszne pieniądze ale w takim wypadku musisz się zastanowić czy chcesz oddać swoją duszę AWSowi

@slsy: Teraz w GCP'ie idą mocno w promowanie standardów opensource chmuorywch i ich ustanawianie https://www.cncf.io/. Jesteś w stanie kodzić cloud functions (lambdy) czy cloud run (skonteneryzowane serwery) z naciskiem na pracę na localhoście u siebie.

Z jednej strony fajnie dla wszystkich osób, które mają alergię na chmurę i te rozwiązania - z drugiej strony GCP odszedł od całkowitego SDK developerskiego w formie PaaS i trzeba wszystko sobie samemu zestawić - przez co mocno spadł developer experience.