Seminar Micronaut – Serverless mit AWS, Azure und Google Cloud

Serverless-Bereitstellung verändert Start, Zustandsmodell, Limits und Betriebsverantwortung. Das Seminar entwickelt eine portable Micronaut-Funktion beziehungsweise serverlose Anwendung und vergleicht die Umsetzung für AWS, Azure und Google Cloud anhand von Triggern, Konfiguration, Native Image, Tests und Observability.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• Serverless-Eignung und Anbieterabhängigkeiten eines Anwendungsfalls bewerten
• HTTP- und Ereignisfunktionen mit Micronaut strukturiert entwickeln
• Konfiguration, Secrets, Packaging und Native Image auf Cold Start und Limits ausrichten
• Lokale Tests, Deployment, Observability und Portabilität kontrolliert organisieren

Zielgruppe

DevOps, Plattformteams, Cloud-Entwickler, Systemadministration und Entwickler mit Betriebsverantwortung.

Voraussetzungen

Micronaut-Grundkenntnisse, Linux-, Netzwerk- und Containergrundlagen sowie Erfahrung mit Build- und Deploymentprozessen.

Seminarinhalte

1. Schritt 1: Serverless-Eignung prüfen

   Ausführungsdauer, Zustandslosigkeit, Ereignisrate, Latenz, Verbindungen, Kosten und Anbietergrenzen werden für den Beispielservice bewertet.

2. Schritt 2: Anwendungsmodell auswählen

   Funktion, serverlose HTTP-Anwendung und containerbasierter Serverless-Dienst werden nach Routing, Startzeit, Wiederverwendung und Portabilität unterschieden.

3. Schritt 3: Handler und Fachlogik trennen

   Provider-Event, Adapter, validierte Eingabe, Fachservice und Ausgabe werden so strukturiert, dass die Kernlogik unabhängig vom Anbieter testbar bleibt.

4. Schritt 4: HTTP- und Ereignistrigger umsetzen

   Ein HTTP-Fall und ein asynchroner Ereignisfall werden mit eindeutiger Idempotenz, Fehlerantwort und Wiederholungsstrategie entwickelt.

5. Schritt 5: Konfiguration und Secrets integrieren

   Umgebungsvariablen, providerseitige Konfiguration, Secret-Zugriff, Rotation und lokale Testwerte werden ohne feste Geheimnisse im Artefakt organisiert.

6. Schritt 6: Artefakt und Native Image bauen

   JAR-, Layer- und Native-Build werden hinsichtlich Größe, Cold Start, Buildzeit und Bibliothekskompatibilität verglichen.

7. Schritt 7: Cloud-Ressourcen und Rechte definieren

   Funktion, Trigger, IAM-Rolle, Netzwerkzugriff, Timeout, Speicher, Parallelität und Dead-Letter-Ziel werden mit minimalen Rechten konfiguriert.

8. Schritt 8: Lokal und integriert testen

   Handler-Tests, providernahe Ereignisse, externe Abhängigkeiten und Fehlerwiederholung werden reproduzierbar geprüft.

9. Schritt 9: Observability und Kosten kontrollieren

   Strukturierte Logs, Metriken, Traces, Kaltstarts, Fehler, Drosselung und Kostenindikatoren werden für den Betrieb festgelegt.

10. Schritt 10: Portabilität bewerten

    AWS-, Azure- und Google-Cloud-Adapter werden anhand desselben Fachservices verglichen. Providerbindung, Tooling und Betriebsaufwand fließen in eine Entscheidungsmatrix ein.

Praxisübungen

• Portabler Fachservice mit Provideradapter
• HTTP- und Ereignistrigger mit Idempotenz
• JVM- und Native-Cold-Start-Vergleich
• IAM- und Fehlerkonfiguration
• Portabilitätsmatrix

Methodik

Kurze fachliche Einordnungen wechseln mit Demonstrationen und schrittweisen Übungen. Jeder Arbeitsstand wird gebaut, ausgeführt und durch automatisierte oder betriebliche Prüfungen abgesichert. Fehlerfälle werden bewusst einbezogen, damit Diagnose und Wiederanlauf nicht erst im Produktivbetrieb entstehen.