AWS Lambda - kod bez serwerów
A gdyby tak nie musieć w ogóle myśleć o serwerach? Nie provisionować instancji, nie patchować systemów, nie martwić się o skalowanie? Witaj w świecie serverless. I witaj w AWS Lambda, usłudze, która zmieniła sposób myślenia o compute w chmurze.
Czym jest serverless?
Serverless nie oznacza „bez serwerów". Serwery nadal istnieją, ale Ty się nimi nie zajmujesz. AWS zarządza całą infrastrukturą. Ty dostarczasz tylko kod. Tyle.
Jak działa Lambda?
Lambda działa w prostym cyklu:
- Wrzucasz swój kod (funkcję)
- Definiujesz trigger (co uruchamia funkcję)
- Gdy trigger wystąpi, Lambda automatycznie uruchamia Twój kod
- Po wykonaniu, środowisko jest wyłączane (lub reużywane)
Wspierane języki: Python, Node.js, Java, C#, Go, Ruby, a także dowolny język przez custom runtime.
Triggery Lambda
Lambda nie działa „sama z siebie". Potrzebuje zdarzenia (event), które ją uruchomi. Oto najczęstsze triggery:
- API Gateway - HTTP request (REST API, WebSocket)
- S3 - nowy plik w buckecie (np. generuj thumbnail po uploadzie zdjęcia)
- DynamoDB Streams - zmiana w tabeli DynamoDB
- SQS - nowa wiadomość w kolejce
- CloudWatch Events / EventBridge - harmonogram (cron) lub zdarzenia systemowe
- SNS - powiadomienie z tematu SNS
- Kinesis - dane ze streamu
Model cenowy Lambda
To jest piękno Lambda. Płacisz za:
- Liczbę wywołań - pierwsze 1 mln wywołań miesięcznie za darmo (!)
- Czas wykonania (w milisekundach) × przydzielona pamięć
Jeśli Twoja funkcja wykonuje się 200 ms i jest wywoływana 1000 razy dziennie, koszt to grosze. Dosłownie. Zero ruchu = zero kosztów. To fundamentalna różnica vs EC2, gdzie płacisz za running instancję nawet gdy nic nie robi.
Limity Lambda
- Timeout - maksymalnie 15 minut na jedno wywołanie
- Pamięć - od 128 MB do 10 GB (CPU skaluje się proporcjonalnie)
- Rozmiar paczki - 50 MB (zip), 250 MB (uncompressed)
- Concurrent executions - domyślnie 1000 na region (można zwiększyć)
- /tmp storage - do 10 GB tymczasowego storage
- Pełna kontrola nad serwerem
- Dowolny czas działania
- Płacisz za running time (nawet idle)
- Musisz zarządzać OS, patching, skalowanie
- Idealne: długo działające aplikacje, specyficzne wymagania
- Zero zarządzania infrastrukturą
- Max 15 minut na wywołanie
- Płacisz za faktyczne wykonania (ms)
- Automatyczne skalowanie do tysięcy równoległych wywołań
- Idealne: event-driven, API, krótkie zadania
Sklep online otrzymuje zamówienia. Każde zamówienie trafia do kolejki SQS. Lambda odbiera wiadomość z kolejki, waliduje zamówienie, zapisuje w DynamoDB, generuje potwierdzenie i wysyła e-mail przez SES.
W normalny dzień: 500 zamówień. W Black Friday: 50 000 zamówień. Lambda skaluje się automatycznie bez żadnej interwencji. Koszt w normalny dzień? Dosłownie kilka centów. A na EC2 musiałbyś utrzymywać serwer 24/7 „na wszelki wypadek".
Gdy Lambda jest wywoływana po dłuższej przerwie, musi zainicjalizować środowisko (pobrać kod, uruchomić runtime). To cold start, który dodaje kilkaset milisekund (w przypadku Javy nawet kilka sekund) do pierwszego wywołania.
Rozwiązania:
- Provisioned Concurrency - prewarmujesz N instancji Lambda (płacisz za gotowość, ale zero cold startów)
- SnapStart (Java) - snapshot pamięci funkcji, drastycznie szybszy cold start
- Używaj lekkich runtime (Python, Node.js) zamiast ciężkich (Java, .NET)
- Lambda = serverless compute, Ty piszesz kod, AWS zarządza resztą
- Event-driven: Lambda reaguje na triggery (S3, API Gateway, SQS, Schedule)
- Cennik: za wywołania + czas wykonania. Zero ruchu = zero kosztów
- Limit: max 15 minut na wywołanie, do 10 GB RAM
- 1 mln wywołań miesięcznie za darmo (Free Tier)
- Nie do wszystkiego: długie procesy, stałe obciążenie → EC2/ECS
Firma ma zadanie przetwarzania danych, które trwa 2 godziny. Czy Lambda jest dobrym wyborem?
Za co płacisz w Lambda?
Który trigger pozwala uruchomić Lambda jako REST API?