Przejdź do głównej zawartości

Serverless - idea i przykłady zastosowan

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.

  1. Co to jest serverless? - Definicja i wyjaśnienie nazwy
  2. Jak to działa? - Funkcje uruchamiane zdarzeniowo
  3. Jakie sa zalety? - Skalowalnosc, koszty, prostota
  4. Jakie sa wady? - Cold start, vendor lock-in, ograniczenia
  5. Kiedy stosowac? - Przykłady użycia i anty-wzorce
  1. 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.

  2. 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
  3. 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
  4. 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
  5. 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

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.

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

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.

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.

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.

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”.

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.