Serverless- jak się za to zabrać

Ostatnio coraz głośniej robi się o serverless, a konkretnie funkcjach jako serwis (FaaS). Głównie za sprawą pomoujących reklamę koncernów.

Czy ktoś ma doświadczenie z wyżej wymienioną technologią/technologiami i może polecić jakieś dobre materiały (idealnie online) do zgłębienia tematu? Najbardziej nurtuje mnie jak podejść do systemów opartych o FaaS od strony developerskiej. O ile sama idea funkcji jako jednostek odpalanych w chmurze kiedy uruchamia się dany trigger jest prosta, to nurtuje mnie jak pisze się większe systemy? Jak zarządza się dziesiątkami czy setkami takich funkcji które razem tworzą jedna całość? Jak podchodzi się do spinania tego w całość, utrzymywania itp?

Korzystałem z AWS Lambda trochę w poprzedniej pracy, ale to był tylko malutki fragment systemu, a nie jego całość. Nie wyobrażam sobie trochę oparcia całego systemu o coś takiego.
W naszym przypadku mieliśmy time trigger który co jakiś czas odpalał lambdę, ona czytała kolejkę zadań do wykonania, chunkowała ją a następnie rozsyłała do nodów obliczeniowych poszczególne chunki. Czemu lambda? Bo bez sensu stawiać cały nowy mikroserwis, który coś takiego robi, skoro potrzebujemy żeby to sie odpaliło np. raz na 10 minut i podziałało kilka sekund. Użycie lambdy wychodzi dużo taniej :)

Właśnie ciekawi mnie jak wyglądają całe systemy (lub przynajmniej ich większa część) oparte o funkcje jako serwis. Dla przykładu używam mobilnej apki do inwestowania na giełdzie (Freetrade) i na ich blogu chwalą się tym że ich system opiera się o serverless. No chyba że to takie buzzwordy i jak firma ma kilka funkcji w chmurze to mówią światu że ma system "oparty o" serverless :)

Własnie zabrałem się za pisanie czegos takiego jako prywatny projekt. Całosc oparta na AWS z dynamiczną synchronizacją między klientem w apce Mobilnej i inne bajery. Polecam ServerlessFramework to swojego rodzaju opakowanie na skrypty tworzące usługi w chmurach - Cloud Formation itd (obsługuje AWS azure i inne chmury). W pratktyce definicja środowiska odbywa się przez YAMLa i jest dosc przyjemna - calosc stawiasz jedna komenda serverless deploy - podobnie z updatem. Na razie nie mam jeszcze w pełni wyrobionego zdania - dużo pracy wymaga definicja uprawnien i relacji między komponentami - z dugiej strony nie martwisz się problemy z wydajnością, security itd. Na razie powiedziałbym że jest OK, nie pałam hypowym entuzjazmem ale widzę że da się na tym zrobic cos co będzie działająctym systemem dużej skali.

Na przykład u mnie:

• Apka Mobilna korzysta z AWS appsync (dnamiczna synchronizacja przez graph QL i subskrypcje oparte na MQTT)
• App sync korzysta z dynamo DB zamodelowane typowo pod apke mobilną ( jako model Backend for frontend - BFE)
• BFE i updaty DynamoDB są triggerowane przez kolejke SQS/SNS
• Analogicznie będzie działac apka webowa - Admin Panel
• Backend jest na lambdach triggerowanych przez SQS
• integracja z sytsemami zewnętrznymi i Aws IoT tez przez SQS i lambdy

W tej chwili 80% kodu aplikacji to YAMLe od Serverless Framework ;-)
Z zalet: AWS dostarcza Amplify który pozwala na generowanie i update klienta AppSync + out of the box masz cały Auth (auentykacja/autoryzacja) - mają nawet gotowe widoki logowania dla apki mobilnej.

Na pewno jest to fajna alternatywa dla klepania kolejnego API.

Odkryłem nowy podcast i jest akurat bardzo fajny odcinek o serverless, bardzo dobry przegląd zalet i wad, bez hajpu:
Patoarchitekci - Serverless

Zapoznać się np. doc. https://www.openfaas.com - poczytać bloga, przejrzeć blogi Alexa jego twittera .. itd.
Wyżej wspomniano o SQS jako triggerze - to są wybory, ja bym użył NSQ bo jest opens. Ogólnie przemawia do mnie stawianie Faas na K8s i użyciu do tego OpenFass, albo innych.

Nasz klient i jego zespół architektów zdecydował się pójść full serverless ale ze względu na trudność testowania lambd i ich utrzymywania część systemu piszemy w Javie. 3/4 tego co mamy (ilościowo na rysunku architektury) w jednej z usług serwisu to lambdy, SQS/SNS, dynamodb ze względu na skalowalność (dziennie mają latać miliony eventów) a reszta to Java (częściej aktualizowana niż lambdy, więc bardziej podatna na bugi) będzie na K8S. Głównym założeniem jest to, że nie chcą walczyć z maszynami, devopsować całym środowiskiem, ręcznie coś skalować tylko chcą żeby tym się zajął w większej części AWS. Jak to wypadnie - dam Ci znać po releasie :)
Większość rzeczy napisana w lambdach odpowiada za zapisanie do dynamo tego co przychodzi, strzelenie gdzieś na zewnętrzne API, nadanie ID do śledzenia obiektu, przepchania danych na kolejki, przeformatowania eventu, walidacji danych na wejściu requestów z zewnątrz, sprawdzenie czegoś w bazie, więc raczej same proste rzeczy

http://einaregilsson.com/serv[...]d-eight-times-more-expensive/

https://firebase.google.com/docs/firestore/quickstart

W pracy opieramy o to całe systemy / podsystemy nowe.
Plusy? Brak serwerów, masz samą bazę, hostujesz statyczny hosting w Angularze - możesz mieć zespół samych TypeScriptowców i mogą pracować.

Minusy? Utrzymywanie reguł bezpieczeństwa w bazie jest dosyć karkołomne dla endpointów.
Nie wszystko da się łatwo zaimplementować - czasami jest łatwiej postawić obok maszynę, która wykona coś, co wymaga zbyt dużej gimnastyki. Jest to baza NoSQL z transakcjami - nie jest to młotek na wszystko i trzeba mieć świadomość, że często będzie wymagane polyglot persistance.

Czasami warto wzbogacić ten serverless o serwer do przetwarzania server-side - jeśli czegoś nie ogarnie w/w narzędzie.

możesz mieć zespół samych TypeScriptowców i mogą pracować.

@MuadibAtrides Tego nie rozumiem. Przecież nie możesz mieć całej logiki biznesowej we froncie. Gdzie tu bezpieczeństwo?