Rozwiązania serverless

Cześć, jestem ciekawy jakie macie doświadczenia z serverlessemt :) a konkretnie:

1. Jakiego rozwiązania używacie, np. AWS Lambda, GCP cloud run, …
2. Jaki scenariusz obsługujecie tym rozwiązaniem?
3. Słowo komentarza - co jest fajne, co nie działa? Czego brakuje? Jaki próg wejścia? Jak z kosztami i wydajnością? Warto/nie warto?

U mnie korzystamy z (oraz jesteśmy na etapie migracji na) Azure Functions. Wcześniej wszystko było hostowane jako Web Jobs (długo działający proces, taki odpowiednik Windows Service albo Daemon).

Mówiąc szczerze to mam mieszane uczucia. O ile bez wątpienia znacznie to ułatwia skalowalność, o tyle nie jest to takie kolorowe jak się może wydawać jeśli ma się złożony system biznesowy, chce się mieć czysty kod i architekturę oraz ułatwiać życie programistom. Bo gdyby chcieć mieć "czysty" serverless to trzeba by tworzyć funkcje dla każdej logiki wykonywanej asynchronicznie (w naszym przypadku to event handlery, bo mamy kod reaktywny reagujący na eventy zachodzące w systemie). A to już oznacza że programista pracujący nad jakąś biznesową funkcjonalnością musi również zająć się tym całym podpinaniem tego pod nową funkcję. Taka funkcja musi zostać postawiona w Azure (to oczywiście może zostać zautomatyzowanego za pomocą IaC) ale nadal potrzebne jest jakieś podpinanie tego.

Co za tym idzie zastosowaliśmy rozwiązanie pośrednie- funkcja reaguje na eventy (każde), i wywołuje odpowiednią infrastrukturę w naszym kodzie która zajmuje się routingiem odebranego eventu do konkretnego handlera (logiki biznesowej).

Plus jest taki że w kodzie nadal mamy zachowany podział na odpowiednie warstwy (architektura onion) ale przychodzi to kosztem tego że tracimy część tego "prawdziwego" serverless bo jest więcej kodu który się wykonuje w ramach jednej funkcji. Zimny start oczywiście jest również odrobinę dłuższy (ale to różnica marginalna).

Wydaje mi się że funkcje najlepiej nadaje się do lekkiego, szybkiego kodu z pogranicza systemu- taki który niekoniecznie musi być "czysty" w kontekście architektury systemu.

Dzięki za komentarz! Żebym lepiej zrozumiał:

1. Ta „frontalna” funkcja wtedy subskrybuje wiele topicow i odpala dalej różne funkcje? To nie jest problem, ze tworząc nowa funkcje zawsze tam tez trzeba dodać „routing” (więcej kodowania i zużycia zasobów)? ;)
2. Dlaczego nie da się ładnie pisać takiej funkcji, chyba tez można wydzielić domenę od infry stosując normalne podejście jak w heksie?

Ta „frontalna” funkcja wtedy subskrybuje wiele topicow i odpala dalej różne funkcje? To nie jest problem, ze tworząc nowa funkcje zawsze tam tez trzeba dodać „routing” (więcej kodowania i zużycia zasobów)? ;)

Nie, niejasno opisałem o co konkretnie chodzi. Pisząc "routing" miałem na myśli routing na poziomie aplikacji, nie "fizycznej" infrastruktury.

Pozwól że po staram się pokrótce opisać jak to u nas wygląda z poziomu architektury ale i pewnej filozofii pisania oprogramowania. Mamy system oparty o mikroserwisy i event-driven, a więc komunikacja pomiędzy serwisami odbywa się właśnie na takiej zasadzie że jeden serwis publikuje event, i inne serwisy mogą nasłuchiwać tego eventu i odpowiednio na niego reagować. Na popzimie infrastruktury używamy Azure ServiceBus, wszystko leci do jednego topica. Każdy serwis ma swój proces nasłuchujący na tym topicu, i to subskrypcja danego serwisu definiuje jakie eventy się dostają do niego. Z perspektywy "filozofii" pisania nowych funkcjonalności, to wszystko to jest transparentne dla programistów. Jeśli programista pisze kod który musi nasłuchiwać danego eventu i go obsłużyć, to musi zrobić jedynie dwie rzeczy:

1. Zaimplementować interfejs IEventHandler<T> gdzie T jest konkretnym,silnie typowanym event domenowym. Taki event handler to po prostu jednostka logiki biznesowej, może dodatkowo przyjmować inne serwisy domenowe przez DI. Event handlery należą do warstwy domeny (bo mają logikę biznesową i operują na eventach domenowych), z punktu widzenia onion architecture są więc w corze systemu.

2. Nowy event musi zostać zarejestrowany, tak aby proces odbierający ten event z ServiceBusa wiedział gdzie go przekierować w kodzie aplikacji. Programista robi to w kodzie boostrapującym aplikację, wykorzystując do tego naszą warstwę infrastruktury (chodzi o infrastrukturę w kodzie, nie fizyczną). Mamy własną paczkę Messaging która dostarcza takie funkcjonalności, więc wygląda to mniej więcej tak jak poniżej (nie dokładnie tak, ale to tylko przykład):

// Rejestracja DI
services.AddServiceBusEventListeners(config =>
  config.UseConnectionString("")
    .UseSubscriptionName("")
    .Handle<MyEvent, MyEventHandler>() // To jest ten "routing"- mówimy do jakiego handlera skierować dany event
);

To jedyne co programista musi zrobić. Idea jest taka aby programista mógł skupić się na tym co naprawdę ma znaczenie- na logice biznesowej- i miał jak najmniej dodatkowej pracy. Całą resztą zajmuje się kod w naszej bibliotece od messagingu.

Za kulisami to wygląda tak że DI rejestruje kilka dodatkowych serwisów. Wtedy aplikacja hostująca ma podpięty moduł odpowiadający za odbiór eventów przychodzących z ServiceBus- to po prostu klasa która oznaczona jest atrybutem zawierającym trigger z ServiceBus. Moduł ten przyjmuje przez konstruktor procesor eventów- ten procesor właśnie odpowiada za zdeserializowanie surowych wiadomości z ServiceBus (obiekty typu Message) na konkretny, silnie typowany event, oraz przekazanie go do jednego lub więcej event handlerów zarejestrowanych wcześniej (wymieniony wcześniej routing). I to są te dwa kluczowe elementy stwarzające pewien problem- moduł odbierający surowe wiadomości, i cała podpięta logika obsługująca je odpowiednio.

Bo gdybyśmy chcieli to robić "czysto" w rozumieniu serverless, to każdy event handler musiałby mieć oddzielny, jawny "moduł" odbierający dany event, na danym topicu- czyli funkcję. Rzecz w tym że ze względu na to iż mamy architekturę event-driven, tych handlerów mamy całkiem sporo. Gdyby dla każdego programista musiał tworzyć oddzielne funkcje, to kolidowało by to z naszą filozofią ułatwiania programistom życia, oraz skupianiu się na warstwie domeny. Dodatkowo, u nas wszystkie eventy idą po jednym topicu, co tym bardziej kolidowałoby z koniecznością wydzielania tego dla każdego rodzaju eventu. Musielibyśmy "wycinać" te zależności które dla konkretnego event handlera są niepotrzebne, zamiast po prostu rejestrować wszystko co potrzebne do wykonania przez logikę biznesową jako całość.

Co za tym idzie w naszym przypadku funkcje (w Azure) wyglądają tak że mamy tak naprawdę jedną funkcję dla jednego mikroserwisu, przyjmuje ona wiadomość z ServiceBus, a następnie przekazuje ją do naszego procesora który zajmuje się całym routingiem na poziomie aplikacji (w procesie) tak jak opisałem to wyżej. Taka funkcja nie jest więc tak "lekka" jak powinna, ale z drugiej strony nadal mamy łatwość skalowania zapewnioną przez Azure Functions.

Mam nadzieję że to co napisałem ma chociaż trochę sensu, zdając sobie sprawę że po części opisywałem to dosyć abstrakcyjnie :P

Dodam jeszcze specjalnie w oddzielnym poście że nie do końca zrozumiałem oryginalne pytanie, i myślałem że chodzi tylko o szeroko rozumiane funkcje (lambda itp). To na ten temat się wypowiadałem.

Jeśli chodzi o serverless ogólnie to korzystamy u mnie w pracy również z bazy danych (Cosmos DB), w/w service busa (Azure ServiceBus) oraz hostowania aplikacji webowych (Azure App Service). Chociaż nie jestem pewny czy to ostatnie zalicz się jako szeroko rozumiane serverless.

1. Raz widziałem AWS Lambde na prodzie
2. Sprawdzało sie całkiem ok, jako handler pewnych czasowych zdarzeń - zamiast stawiać serwis który przez 99% nic nie robi, masz lambdę która jest triggerowana co jakiś czas. W tym przypadku logika była też dość prosta.

W przypadku Azure stawianie rozwiązań serverless czyli app functions jest banalnie proste, szczególnie jeśli chodzi o event handling np. trigger w przypadku pojawienia się nowego obiektu na blobie itp. Nie trzeba nawet pisać kodu tylko można użyć tzw. bindingu czyli konfiguracja konkretnego jsona. Rozwiązanie oprócz łatwości w utrzymaniu / szybkości implementacji, jest również tanie. M$ billuje per wywołanie funkcji z czego pierwszy 1mln masz za darmo.

Mam ogólnie kiepskie doświadczenia z serverless - w mojej działce (duże ecommerce głównie w PHP) nadal królują monolity typu Magento i wiele większych SH postanowiło przejść na szeroko rozumiany cloud bo "marketingowo to się sprzedaje" + klienci często przychodzą i mówią, że chcą być "nowocześni". I tak byłem już w kilku projektach, które były stawiane w chmurze z użyciem wielu różnych usług typu redis, db, grupy atoskalowalne itd.

Streściłbym to tak, że przenoszenie na siłę monolitów na serverless to jest działanie na szkodę klienta. Oczywiście czasami było to uzasadnione, ale w znacznie częściej rezultaty były opłakane.

Oczywiście widzę dobre zastosowania dla serverless - czy to świadome korzystanie z wybranych usług, czy też np. architektura budowana z myślą o serverless, ale to co widzę na rynku to ślepy pęd w tym kierunku ze wszystkim co się da.

Azurowe bardzo fajne jako wyzwalacze robiące "coś" po tym jak się pojawi nowa wiadomość na service bus, blob w magazynie itd. Jeżeli chodzi o stawianie w ten sposób czegoś dużego, to wciąż mam trochę obaw na poziomie zarządzania tym kodem. Boję się, że ostatecznie pojawi się w cholerę drobnych kawałków logiki, które musza trafić w bardzo określone miejsce infrastruktury, w dodatku o ile wiem, dość specyficzne dla każdej platformy. Czyli tracimy na "cloud agnostic" i trzeba mieć naprawdę przemyślany i przestrzegany software development plan, żeby być w stanie sensownie to wydawać, przenosić przez kolejne środowiska testowe, a w razie czego być w stanie w skończonym czasie odtworzyć całe środowisko zbudowane na tych drobiazgach. Ostatecznie z tych powodów nie wykorzystałem jeszcze w projekcie. W przypadku Azure minusem była siermiężna obsługa Javy, bo w razie czego start takiej funkcji był na tyle długi, że zabijało to cały zysk z "płacisz za wykorzystanie", ale zaglądałem do tego już dość dawno, coś się pewnie zmieniło.

@piotrpo:

Jeżeli chodzi o stawianie w ten sposób czegoś dużego, to wciąż mam trochę obaw na poziomie zarządzania tym kodem. Boję się, że ostatecznie pojawi się w cholerę drobnych kawałków logiki, które musza trafić w bardzo określone miejsce infrastruktury, w dodatku o ile wiem, dość specyficzne dla każdej platformy.

Dokładnie, był to jeden z powodów dla którego nie zrobiliśmy "pełnego" serverless tak jak opisałem to wyżej. U nas była zgoda co do tego że domena i cała filozofia z tym związana (łatwość dodawania nowej funkcjonalności biznesowej przez programistów itp) to sprawa nadrzędna, i cała warstwa biznesowa musi zostać agnostyczna co do metody hostingu tego. Niedawno było to WebJobs w Azure, teraz jest Functions, a kiedyś może być całkowicie inna platforma cloud- lub nie cloud. Zastosowaliśmy więc rozwiązanie pośrednie, ale dzięki temu zmiana sposobu hostowania tego to kwestia podpięcia wszystkiego na poziomie infrastruktury, bez zmian do kodu biznesowego.

Pracuje z serverless, obecnie 3ci projekt, jednak sa to systemy generalnie nieskomplikowane, kilka kolejek, api. Problemem z serverless jest fakt ze ludzie go nie znaja i nie potrafia uzywac, a duzo info w necie to jakies paplaniny o tym ze to tak na prawde nie serverless tylko sa dokery odpalane, ciezko znalezc odpowiedzi na rzeczy, ktore sa problematyczne.
Iaac, ktory uzywamy to serverless framework, raz byl to terraform i musze powiedziec ze sls framework mi bardziej podchodzi, chociaz tf jest bardziej uniwersalny (koniec koncow z sls'ie mozna uzywac cloud formation wiec tez duzo rzeczy da sie ogarnac).

Problem jest na poziomie testowania zeby miec dobry i szybki feedback loop - ale na to tez sa rozwiaznia. Obecnie dla mnie pisanie czegos w SLS nie rozni sie od stawiania tomcata, tyle ze scope zastosowan jest inny. Fakt faktem, ze wiele rozwiazan ala crudowych moglyby spokojnie byc opedzlowane sls'em i prawdopodobnie bylaby to tansza opcja.

U mnie kiedyś TL chciał użyć AWS lambda do formatowania komunikatów do loggera. To się liczy?