FaaS

Model chmury, w którym uruchamia się pojedyncze funkcje kodu w odpowiedzi na zdarzenia, bez zarządzania serwerami. Stanowi fundament architektury serverless.

FaaS (Function as a Service) to model chmury, w którym wgrywasz pojedyncze funkcje kodu, a dostawca uruchamia je dopiero wtedy, gdy coś je wyzwoli — request HTTP, plik wrzucony do bucketa, wiadomość w kolejce czy cykliczny timer. Nie dotykasz systemu operacyjnego, nie patchujesz serwera, nie skalujesz maszyn ręcznie. Piszesz funkcję, mówisz „odpal ją przy tym zdarzeniu” i tyle. FaaS to praktyczny rdzeń tego, co marketing nazywa serverless — serwery oczywiście istnieją, po prostu to nie twój problem.

Jak to działa

Twój kod leży uśpiony. Gdy pojawia się zdarzenie, platforma wstaje, ładuje funkcję, wykonuje ją i po chwili gasi. Płacisz tylko za czas wykonania (zwykle liczony w milisekundach) i liczbę wywołań — przy zerze ruchu rachunek wynosi praktycznie zero. Skalowanie jest automatyczne: dziesięć równoczesnych żądań to dziesięć instancji funkcji odpalonych obok siebie, bez twojego udziału.

Cena za tę wygodę to bezstanowość. Funkcja nie powinna zakładać, że cokolwiek przetrwa między wywołaniami — stan trzymasz w bazie, cache albo storage. Dochodzi też cold start: pierwsze odpalenie po przerwie bywa wolniejsze, bo środowisko trzeba dopiero postawić.

Przykład z praktyki

Najbardziej znany przedstawiciel to AWS Lambda (2014, pionier gatunku), obok Google Cloud Functions, Azure Functions czy Cloudflare Workers. Klasyczny scenariusz: użytkownik wrzuca zdjęcie do bucketa S3, to wyzwala Lambdę, która generuje miniaturkę. Deploy bywa banalny, np. przez framework Serverless:

serverless deploy --stage prod

A samą funkcję w Node.js piszesz tak: exports.handler = async (event) => { return { statusCode: 200 }; };

Na co uważać

Najczęstszy mit: „serverless jest zawsze tańszy”. Przy stałym, wysokim ruchu kontener czy VM potrafią wyjść taniej — FaaS błyszczy przy obciążeniu nierównym i nieprzewidywalnym. Druga pułapka to traktowanie funkcji jak monolitu: wrzucasz całą aplikację do jednej Lambdy i dziwisz się timeoutom (limit wykonania to zwykle kilka–kilkanaście minut). Trzecia to ignorowanie cold startów w ścieżkach wrażliwych na opóźnienie. I pamiętaj — debugowanie rozproszonych funkcji bez porządnego logowania i tracingu to droga przez mękę.

Pojęcia powiązane

Serverless, AWS Lambda, event-driven architecture, microservices, BaaS (Backend as a Service), kontenery, API Gateway, cold start.