Serverless - idea i przykłady zastosowan

O czym jest ta prezentacja?

Serverless - serwer jest, ale nie Twoj problem

Serverless to model architektury, w którym nie musisz zarzadzac serwerami - infrastruktura jest w pełni zarzadzana przez dostawce chmury. W tej prezentacji wyjasni, czym naprawde jest serverless (spoiler: serwery nadal istnieja!), jak działają funkcje uruchamiane zdarzeniowo, jakie sa zalety i wady tego podejscia oraz gdzie ma sens jego stosowanie. Zrozumienie serverless pomaga w projektowaniu nowoczesnych, skalowalnych aplikacji.

Kluczowe pytania do odpowiedzi

Co to jest serverless? - Definicja i wyjaśnienie nazwy
Jak to działa? - Funkcje uruchamiane zdarzeniowo
Jakie sa zalety? - Skalowalnosc, koszty, prostota
Jakie sa wady? - Cold start, vendor lock-in, ograniczenia
Kiedy stosowac? - Przykłady użycia i anty-wzorce

Zakres merytoryczny

Elementy obowiązkowe

Czym jest serverless Wyjasnij, że “serverless” nie oznacza braku serwerow - serwery istnieja, ale sa zarzadzane przez dostawce (AWS, Google Cloud, Azure). Programista pisze tylko kod funkcji, nie martwi się o infrastrukture.
Funkcje jako usługa (FaaS)
- Funkcja uruchamiana w odpowiedzi na zdarzenie (event)
- Zdarzenia: żądanie HTTP, upload pliku, timer, wiadomość z kolejki
- Funkcja działa, konczy się, zasoby sa zwalniane
- Przykład: AWS Lambda, Google Cloud Functions, Azure Functions
Zalety serverless
- Płacisz tylko za czas wykonania (nie za idle)
- Automatyczne skalowanie (od 0 do tysiecy instancji)
- Brak zarzadzania serwerami, aktualizacjami, security patches
- Szybkie wdrażanie nowych funkcji
Wady i ograniczenia
- Cold start: opoznienie przy pierwszym uruchomieniu
- Vendor lock-in: uzaleznienie od dostawcy
- Limity: czas wykonania, pamiec, rozmiar pakietu
- Trudniejsze debugowanie i monitoring
Kiedy serverless ma sens
- Webhooki i integracje
- Przetwarzanie plikow (obrazy, dokumenty)
- API z nieregularnym ruchem
- Zadania harmonogramowe (cron)
- NIE: aplikacje wymagajace stałego połączenia, długie procesy

Wymagane elementy wizualne

Schemat event-driven

Event (HTTP/Upload/Timer) → Function → Response/Action → Koniec (zasoby zwolnione)

Porownanie z tradycyjnym hostingiem

Tradycyjny: serwer działa 24/7, płacisz stałe. Serverless: funkcja działa sekundy, płacisz za użycie.

Warianty realizacji

Zawartosc:

Wytłumacz co to jest serverless (definicja)
Podaj 2 przykłady zastosowan
Pokaz 1 schemat event → function → response

Forma: 10 slajdow, 10 minut prezentacji

Ocena: 3.0

Struktura prezentacji

Slajd tytułowy - Tytuł, autorzy, data
Agenda - Co omowicie w prezentacji
Problem - Zarzadzanie serwerami to praca (aktualizacje, skalowanie, koszty)
Co to jest serverless? - Definicja, wyjaśnienie nazwy
Jak to działa? - Event → Function → Response (schemat)
Przykłady użycia - Webhook, przetwarzanie plikow, API
Zalety - Skalowalnosc, koszty, prostota
Wady - Cold start, vendor lock-in, limity
Serverless vs tradycyjny hosting - Porownanie
Kiedy stosowac? - Dobre i źle przypadki użycia
Podsumowanie - Kluczowe wnioski
Źródła i pytania

Scenariusze i przykłady

Scenariusz 1: Webhook do powiadomien

Sklep internetowy chcę wysyłać powiadomienia SMS po złożeniu zamowienia. Zamiast utrzymywac serwer 24/7, używa funkcji serverless: zamowienie → webhook → funkcja Lambda → SMS. Funkcja działa sekundy dziennie, kosztuje grosze miesiecznie.

Scenariusz 2: Generowanie miniaturek

Użytkownik uploaduje zdjecie na S3. Event uruchamia funkcje, która tworzy miniaturke i zapisuje ja w innym katalogu. Bez serverless musiałbyś utrzymywac serwer do przetwarzania obrazow.

Mini case study (dla wariantu C)

Przypadek: Startup i koszty infrastruktury

Startup tworzył aplikacje mobilna z backendem. Na początku mieli 100 użytkowników dziennie, potem 10,000. Tradycyjny hosting: musieliby z góry zapłacić za mocny serwer lub ciągłe skalowac. Serverless: płacili proporcjonalnie do użycia. W pierwszym miesiacu rachunek wynosił 5$, po roku - 500$. Ale: musieli przepisac część logiki, bo funkcje maja limit 15 minut wykonania. Lekcja: serverless swietnie skaluje koszty, ale wymaga przemyslenia architektury.

Wskazowki do wystapienia

Tłumacz na przykładach

“Event → Function → Response” to klucz. Daj konkretny przykład: “Ktos wrzuca plik, funkcja go przetwarza, wynik laduje w bazie”.

Nie wchodź w detale usług

Nie musisz uczyc AWS Lambda - skup się na IDEI serverless. Wspomnij nazwy usług, ale nie rob tutoriala.

Bądź uczciwy o wadach

Cold start, vendor lock-in - to realne problemy. Nie sprzedawaj serverless jako rozwiązania wszystkich problemow.

Porownuj wizualnie

Schemat: “serwer działa 24/7” vs “funkcja działa sekundy”. Koszt: “100$/mies stałe” vs “5$/mies za użycie”.

Najczestsze błędy

Błąd	Jak unikac?
”Serverless = brak serwerow”	Wyjasnij: serwery sa, ale zarzadzane przez dostawce
Zbyt techniczne detale (IAM, VPC)	Skup się na idei, nie na konfiguracji AWS
Brak przykładów zastosowan	Daj 2-3 konkretne use case’y
Pomijanie wad	Omow cold start i vendor lock-in
Porownywanie z kontenerami	To inny temat - skup się na serverless vs tradycyjny hosting

Zasoby

MDN: Serverless Krótka definicja serverless.

AWS Lambda - What is Serverless Wprowadzenie do serverless od AWS.

Serverless Framework Popularne narzędzie do wdrażania funkcji serverless.

When to use Serverless Artykuł Martina Fowlera o serverless (zaawansowany).

Do dziela!

Serverless to przyszłość (i terazniejszosc) wielu aplikacji!

Architektura serverless zmienia sposób myslenia o infrastrukturze. Zamiast “ile serwerow potrzebuje” pytasz “ile funkcji wykonam”. To cenna wiedza na rynku pracy.

Wykorzystajcie lekcje - zastanowcie się, która część waszego projektu semestralnego mogłaby być serverless (np. wysyłanie maili, generowanie raportow).

Współpraca to klucz - podzielcie się: jedna osoba może zając się idea i schematami, druga przykładami i porownaniem z tradycyjnym hostingiem.

Pamietajcie: dobra prezentacja o serverless to taka, po której słuchacze rozumieja KIEDY i DLACZEGO warto rozwazyc te architekture.