Architektura Serverless

API Backend

API Gateway + Lambda — REST lub GraphQL API bez zarządzania serwerami. Skaluje automatycznie.

API GW + Lambda, Cloud Run, Vercel Functions

Event Processing

SQS/Pub/Sub trigger Lambda — asynchorniczne przetwarzanie eventów, ETL, notifications.

SQS + Lambda, Pub/Sub + Cloud Functions

Scheduled Jobs

EventBridge Cron / Cloud Scheduler — raporty, cleanup, synchronizacja danych co N godzin.

EventBridge + Lambda, Cloud Scheduler + Cloud Run Jobs

File Processing

S3/GCS upload triggeruje Lambda — resize obrazu, konwersja video, parsowanie CSV.

S3 trigger + Lambda, GCS + Cloud Functions

Orchestration

Step Functions — multi-step workflows z warunkami, równoległością i retry logic.

AWS Step Functions, Google Workflows

Static + Serverless

JAMstack — CDN dla statycznego frontendu + serverless API. Najlepszy stosunek wydajność/koszt.

Vercel/Netlify + Functions, S3 + CloudFront + Lambda

Co to jest architektura serverless i jak różni się od tradycyjnych serwerów?

Serverless to model gdzie developer nie zarządza serwerami — platforma automatycznie alokuje, skaluje i zwalnia zasoby obliczeniowe. Nie chodzi o brak serwerów — serwery istnieją, ale są niewidoczne dla dewelopera. Tradycyjny serwer vs. Serverless: Tradycyjny: płacisz za czas działania serwera (24/7), skalujesz manualnie, zarządzasz OS/patches, odpowiadasz za dostępność. Serverless: płacisz per invocation + czas wykonania (milliseconds), auto-skalowanie do zera i milionów, platforma zarządza infrastrukturą. Modele serverless: FaaS (Function as a Service): AWS Lambda, Google Cloud Functions, Azure Functions. Piszesz funkcję, platforma uruchamia ją na event. BaaS (Backend as a Service): gotowe serwisy backendowe (auth, DB, storage) — Firebase, Supabase, Auth0. Serverless containers: AWS Fargate, Google Cloud Run — kontener bez zarządzania klastrem. Zalety serverless: Zero infrastruktura do zarządzania. Automatyczne skalowanie (0 do nieskończoności). Płacisz tylko za użycie. Built-in availability. Szybszy time-to-market. Wyzwania: Cold starts — pierwsze żądanie po bezczynności wolniejsze (Lambda 100ms-5s). Vendor lock-in — głęboka integracja z platformą. Stateless — brak persist memory między invocations. Limity: max execution time (Lambda 15 min), max memory (Lambda 10GB). Debugowanie trudniejsze. Idempotentność — funkcja musi być bezpieczna przy retry.

AWS Lambda — jak budować funkcje i integrować z innymi serwisami AWS?

AWS Lambda: wiodąca FaaS platforma. Zdarzenia (triggers): API Gateway — HTTP requests do Lambda. S3 — nowy obiekt, modyfikacja. DynamoDB Streams — zmiana w tabeli. SQS/SNS — wiadomości w kolejce. EventBridge — events z innych serwisów AWS. CloudWatch Events — scheduled (cron). Cognito, ALB, Kinesis. Runtimes: Node.js, Python, Java, Go, .NET, Ruby, Custom Runtime (binarny Linux). Konfiguracja: Memory: 128MB-10GB (więcej pamięci = więcej vCPU). Timeout: 1s-15 min. Concurrency: Reserved, Provisioned (pre-warm, eliminuje cold start). Environment variables, Layers (shared code/deps). Lambda Layers: współdzielone zależności między funkcjami. Np. layer z bibliotekami Python — nie musisz packować do każdej funkcji. Destinations: po wykonaniu sukces/fail → wyślij do SQS, SNS, Lambda, EventBridge. Dead Letter Queue (DLQ) — nieudane invocations. IAM Role: Lambda potrzebuje roli z uprawnieniami do innych serwisów. Zasada least privilege. Lambda@Edge: uruchamiaj Lambda na węzłach CloudFront CDN. Ultra-niskie latency, personalizacja content, A/B testing na edge. SnapStart (Java): pre-initialize Lambda snapshot — eliminuje cold start dla Java. Pricing: $0.20 per 1M requests + $0.0000166667 per GB-second. Free tier: 1M requests + 400K GB-second miesięcznie.

Google Cloud Run i Knative — serverless containers?

Cloud Run: serverless container platform od Google. Uruchamiasz dowolny kontener Docker — nie musisz pisać funkcji w konkretnym języku. Skalowanie: od 0 do N instancji automatycznie (min/max instancje konfigurowalne). Płacisz za faktyczny CPU/RAM/request (brak idle cost gdy min instances = 0). Cold start — nowa instancja kontenerowa (wolniej niż Lambda ale bardziej elastyczne). Przypadki użycia: web apps, APIs, microservices w kontenerach. Stateless HTTP request-response. Background jobs przez Pub/Sub trigger. HTTP/2 i WebSocket wsparcie. Współbieżność per instance: Cloud Run może obsługiwać 1000 concurrent requests per instancja (vs Lambda 1 per). Tańsze przy API z niską latency i wysokim concurrency. Cloud Run Jobs: batch tasks bez HTTP — uruchom kontener do completion. Knative: open-source serverless platform na Kubernetes. Składa się z Serving (autoscaling workloads, scale to zero) i Eventing (event-driven workflows). Używany przez Cloud Run internaly. Możesz self-hostować na własnym K8s. AWS Fargate: serverless containers w ECS lub EKS. Nie zarządzasz EC2 — platforma alokuje capacity. Płacisz za vCPU i RAM per task. Brak cold start (działa jak EC2 ale bez zarządzania). Droższe niż Lambda dla request-driven workloads ale lepsze dla long-running tasks. Azure Container Apps: managed Kubernetes + Dapr + KEDA (auto-scaling). KEDA: Kubernetes Event-Driven Autoscaling — scale na podstawie Kafka lag, SQS depth, itp.

Event-driven serverless — jak projektować workflows i orkiestrację?

Event-driven serverless: Lambda/Cloud Functions najlepiej sprawdza się w architekturze event-driven. Asynchroniczna komunikacja przez events — nie synchroniczne HTTP. AWS Step Functions: orkiestracja wielu Lambda funkcji jako workflow. Stany: Task (wywołaj Lambda), Choice (warunek), Wait (opóźnienie), Parallel (równolegle), Map (dla każdego elementu listy). Wizualna definicja w Amazon States Language (ASL lub JSON). Express Workflows — krótkie (<5 min) i tanie. Standard Workflows — długie (do roku) z dokładnym śledzeniem. Use cases: wieloetapowy checkout (validate → charge → fulfill → notify). Document processing pipeline. Human-in-the-loop (czekaj na potwierdzenie człowieka). Kompensacja transakcji (Saga). AWS EventBridge: event bus dla event-driven architecture. Events z 200+ AWS serwisów. Custom events z własnych aplikacji. Event rules + routing do Lambda, SQS, Step Functions. Schema Registry — definicje event schemas. EventBridge Pipes: point-to-point connector między event source i target. Filtrowanie, enrichment, transformacja. SQS + Lambda: SQS trigger dla Lambda — batch processing. Lambda przetwarza N wiadomości per invocation (batch size). DLQ dla nieudanych wiadomości. Visibility timeout musi być dłuższy niż Lambda timeout. Fan-out pattern: SNS → wiele SQS → wiele Lambda (parallel processing). Choreography vs Orchestration: Choreography — serwisy reagują na eventy (EventBridge). Orchestration — centralny koordynator (Step Functions).

Cold starts, observability i koszty w serverless — jak optymalizować?

Cold Start optymalizacja: Cold start to opóźnienie gdy nowa instancja Lambda musi być zainicjalizowana. Rozmiar deployment package: mniejszy package = szybszy cold start. Lambda Layer zamiast bundlowania deps. Provision Concurrency: pre-warm N instancji (płacisz za idle time). Eliminuje cold starty dla krytycznych paths. SnapStart (Java): snapshot po initialization — restore zamiast init (10x szybszy start). Wybór runtime: Node.js i Python mają krótsze cold starty niż Java, .NET. Dostosuj RAM: więcej RAM = więcej vCPU = szybsze inicjalizowanie. Observability w serverless: CloudWatch Logs — automatyczne logowanie Lambda output. X-Ray — distributed tracing dla Lambda (instrumentation SDK). Lambda Insights — metryki (duration, error, throttle, concurrent executions). Cold start rate — monitoruj procent cold starts. Third-party: Datadog Serverless, Lumigo, Epsagon (Cisco). Optymalizacja kosztów: Right-sizing memory — profil przez AWS Lambda Power Tuning. Reduce function duration — optimize kodu, use connection pooling (reuse między invocations). S3 Intelligent-Tiering zamiast Lambda dla storage-heavy. Batch processing — jeden event = wiele rekordów (SQS batching). Reserved Concurrency — ogranicz max concurrency per function (cost control). Compute Savings Plans — committed usage = 17% off Lambda. Cache computation — ElastiCache dla często używanych danych. Serverless Framework i SAM: Serverless Framework — IaC dla serverless (Lambda, API GW, DynamoDB). AWS SAM (Serverless Application Model) — AWS-native IaC dla serverless. CDK L2 constructs dla Lambda.

Wyślij zapytanie