Serverless to model przetwarzania w chmurze, w którym piszesz i wgrywasz sam kod (najczęściej w postaci pojedynczych funkcji), a o całą resztę — serwery, system operacyjny, skalowanie, łatanie i utrzymanie — dba dostawca chmury. Nazwa jest myląca: serwery oczywiście istnieją, tylko ich nie widzisz i nie obchodzą cię. Twoja działka kończy się na logice biznesowej, a płacisz wyłącznie za faktyczne wywołania i zużyty czas obliczeniowy, a nie za maszynę, która stoi i grzeje powietrze przez 24 godziny na dobę.
Jak to działa
Najpopularniejsza odmiana to FaaS (Functions as a Service): wgrywasz funkcję, definiujesz trigger (np. żądanie HTTP, wrzucenie pliku do storage, wiadomość w kolejce), a platforma sama uruchamia kontener z twoim kodem dokładnie wtedy, gdy trzeba. Jest jedno wywołanie na sekundę — odpala jedną instancję. Przychodzi tysiąc na raz — platforma w tle podnosi tysiąc instancji i po obsłudze je gasi. To skalowanie „do zera” jest sednem: gdy nikt nie korzysta z twojej funkcji, nie płacisz nic.
Serverless to nie tylko funkcje. Pod tym parasolem mieszczą się też bazy danych (np. DynamoDB, Aurora Serverless), kolejki czy storage — wszystko, gdzie nie zarządzasz infrastrukturą, tylko korzystasz z gotowej usługi i płacisz za użycie.
Przykład z praktyki
Klasyk to AWS Lambda — pioniera tego podejścia uruchomiono w 2014 roku. Powiedzmy, że chcesz generować miniatury obrazków po wrzuceniu zdjęcia do bucketa S3. Piszesz funkcję, ustawiasz trigger na zdarzenie „nowy plik w S3″ i tyle. Wdrożenie z poziomu terminala wygląda mniej więcej tak:
aws lambda create-function --function-name thumbnailer --runtime python3.12 --handler app.handler --zip-file fileb://function.zip --role arn:aws:iam::123456789:role/lambda-exec
Konkurencja to m.in. Google Cloud Functions, Azure Functions i Cloudflare Workers (te ostatnie działają na edge, blisko użytkownika).
Częste mity i pułapki
- „Serverless zawsze jest tańszy” — nieprawda. Przy stałym, dużym ruchu klasyczny serwer albo kontener często wychodzi taniej. Serverless błyszczy przy ruchu nieregularnym i nieprzewidywalnym.
- Cold start — gdy funkcja długo nie była używana, jej pierwsze wywołanie ma opóźnienie (platforma musi „rozgrzać” kontener). Dla API z niskim ruchem bywa to odczuwalne.
- Limity czasu — funkcja ma maksymalny czas działania (Lambda to 15 minut). Do długich, ciężkich zadań to zły wybór.
- Vendor lock-in — kod i konfiguracja triggerów potrafią mocno przywiązać cię do konkretnego dostawcy.
Pojęcia powiązane: FaaS, BaaS (Backend as a Service), cold start, AWS Lambda, autoscaling, mikroserwisy, event-driven architecture, edge computing, kontenery (jako alternatywa).