Co oznacza serverless?
Serverless computing oznacza, że zasoby maszynowe wymagane do uruchomienia kodu są zarządzane przez cloud provider. Mówiąc dokładniej, serverless nie oznacza, że w ogóle nie używamy servers. Oznacza to, że nie musimy się martwić o infrastrukturę, a zadania związane z zarządzaniem są zautomatyzowane.
Z perspektywy developers, kluczową korzyścią jest oszczędność czasu na zadaniach związanych z provisioningiem i maintenance, oraz skupienie się na pisaniu kodu i dostarczaniu nowych funkcji.
Serverless architecture jest ściśle związana z cloud computing. Pierwsza usługa serverless computing, Google Cloud Engine, została wprowadzona przez Google w 2008 roku. Jest to platforma obsługująca wiele języków programowania do hostingu web applications.
Obecnie na rynku jest więcej serverless computing providers. Najbardziej znane to Amazon Web Services (AWS), Microsoft Azure i Google Cloud Platform (GCP), ale istnieją inne opcje, takie jak instalacja serverless framework na własnym clusterze, np. Kubless, OpenFaaS, Serverless Framework lub Apache OpenWhisk.
Głównym celem tego artykułu jest model Function as a Service (FaaS). FaaS to odmiana serverless computing, która umożliwia wykonywanie kodu w odpowiedzi na zdarzenia, takie jak HTTP request lub nowy element w kolejce. Jest to dobry wybór dla single purpose, short tasks.

Zalety i wady serverless applications
Zalety
- Pay only for what you use – w wielu sytuacjach serverless computing może pomóc zaoszczędzić pieniądze, np. gdy Twoja aplikacja jest używana tylko w godzinach pracy lub potrzebujesz bardzo dużej capacity tylko w określonym okresie. W takich sytuacjach możesz zaplanować, kiedy Twoja aplikacja ma być włączona i jak ma się skalować.
- Less management work – ten punkt wynika z poprzedniego. Zamiast zatrudniać ludzi do wykonywania zadań administracyjnych i operacyjnych, możesz użyć serverless i skupić się na designie i developmentcie. Oczywiście, możesz mieć pewne low level limits, których nie możesz zmienić, ale dzięki temu zyskujesz lepsze security i scalability.
- Better productivity – używając Functions as a Service, developers mogą korzystać z event driven programming, co może uprościć kod.
Wady
- Performance – jeśli nie ma uruchomionej instance danej serverless function, czas oczekiwania jest dłuższy. Jest to znane jako Cold start.
- Timeout – zazwyczaj istnieje maksymalny czas trwania pojedynczego wykonania. Poniżej znajdują się limity timeout dla najpopularniejszych cloud providers:
- AWS Lambda - 15 minut
- Azure Functions - 10 minut (w Premium Plan – unlimited)
- GCP Cloud Functions – 9 minut
- Trudniejsze testing i debugging niż traditional server code.
- Dependance on a specific provider – trudniej jest przenieść rozwiązanie do innego providera.
- Bardziej kosztowne w sytuacjach stable resource usage.
Kiedy powinieneś używać serverless architecture? (Scenariusze)
Możesz stworzyć dowolny serverless computing, ale nie zawsze ma to sens (patrz sekcja "wady" powyżej). Niezależnie od technicznej możliwości stworzenia konkretnego rozwiązania przy użyciu serverless approach, istnieją typowe sytuacje, w których serverless jest najbardziej korzystny.
- HTTP triggered requests – możesz stworzyć serverless computing, np. API do zapisywania się do newslettera.
- Event-driven architecture – serverless computing jest świetny do przetwarzania incoming files, takich jak images lub JSONs, np. automatyczne zmienianie nazw i resizing files umieszczonych w buckecie.
- Serverless computing może być przydatny w sytuacji unpredictable usage patterns, np. jeśli nie jesteś w stanie oszacować ilości zasobów, których potrzebujesz i nie chcesz, aby zabrakło Ci zasobów.
- FaaS jest przeznaczony do small, independent i non-compute intensive tasks, takich jak wysyłanie e-maila.
Budowanie serverless applications - best practices
Design & Scaling
- Serverless applications są zwykle częścią distributed systems i powinny być stateless.
- Staraj się, aby FaaS applications były tak proste, jak to możliwe.
- Oszacuj odpowiednią liczbę active instances. Pamiętaj nie tylko o zapewnieniu availability Twojej usługi, ale także o kosztach. Jeśli chcesz uniknąć unpredictable expenses, ogranicz liczbę max instances.
- Oblicz ilość pamięci wymaganej do wykonania function i skonfiguruj memory limit. Pamiętaj, płacisz za to, co używasz.
Debugging & Testing
Biorąc pod uwagę, że testing distributed i serverless computing jest znacznie trudniejsze niż centralized ones, powinieneś:
- Przygotować reliable i detailed logging.
- Monitorować status executions, aby identyfikować failure i ustawiać alerts, jeśli się zdarzy.
- Nie failować po cichu – upewnij się, że każde nieoczekiwane zachowanie zostanie zauważone.
Configuration & Security
- Zawsze oddzielaj configuration od application code i przechowuj ją w innym pliku, np. JSON lub YAML.
- Pamiętaj o timeouts w FaaS – functions powinny być używane do short tasks z predictable execution times.
- Utrzymuj jeden codebase śledzony w systemie version control dla wszystkich environments (development, staging, production). Pomaga to w utrzymaniu bardziej spójnego kodu i ułatwia process deployment.

Przykłady
- Serverless API
- Opis: HTTP request wywołuje function, a function wykonuje query na database, np. insert record w table.
- Use case: CRUD operations.
- Processing files
- Opis: Dostarczenie nowego pliku do storage wywołuje function. Files muszą zostać resized i compressed, aby zaoszczędzić miejsce i muszą być zapisane przy użyciu zdefiniowanego file name pattern.
- Use case: handling delivered files.
- Adding tasks to the queue
- Opis: HTTP requests wywołują pierwszą function, która po prostu dodaje nowy task do queue. Druga function konsumuje queue elements i wykonuje dłuższy task.
- Use case: sending confirmation e-mail.
Podsumowanie
Serverless computing staje się coraz bardziej popularny. Jednocześnie stoi w obliczu dynamicznych zmian i developmentu. Korzystanie z tego rodzaju rozwiązań wymaga nowych umiejętności i różnych approach w wielu obszarach, takich jak designing, developing, testing i maintaining applications, ale przynosi nowe możliwości i może ułatwić życie developers.
Cloud vs tradycyjne it przewaga
Niezawodne dag i local development z airflow i docker
Gcp dla firm do czego sluzy google cloud platform