{"id":28084,"date":"2025-09-14T19:29:18","date_gmt":"2025-09-14T17:29:18","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=28084"},"modified":"2025-09-14T19:29:29","modified_gmt":"2025-09-14T17:29:29","slug":"springboot-zu-serverless-probleme-und-paradigmen","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/09\/14\/springboot-zu-serverless-probleme-und-paradigmen\/","title":{"rendered":"Springboot zu Serverless: Probleme und Paradigmen"},"content":{"rendered":"\n

Im Rahmen der Vorlesung \u201eSoftware Development for Cloud\u00a0Computing\u201c<\/strong> sollte jedes Team ein eigenes Cloud\u2011Projekt umsetzen. Unser Projekt Taskflow<\/strong> sollte dabei ein serverloses Todo\u2011Management\u2011System werden. Ziel war es dabei, neue und vor allem industrierelevante Cloud\u2011Technologien praktisch zu erlernen. Der Backend\u2011Teil ist mit Spring\u2011Boot realisiert, welcher \u00fcber AWS\u00a0Lambda und API\u00a0Gateway bereitgestellt modular eingesetzt werden kann. Als Persistenz kommt DynamoDB zur Verewendung. Der Frontend\u2011Teil ist eine React\u2011Anwendung, die Aufgaben anzeigt, anlegt, bearbeitet und l\u00f6scht. Zur Authentifizierung wird JWT verwendet, die CI\/CD\u2011Pipeline basiert auf GitHub\u00a0Actions.<\/p>\n\n\n\n

Folgend beschreiben wir, wie wir von monolithischen Denken zu einem serverless\u2011orientierten Mindset gewechselt haben, welche Technologien zum Einsatz kamen, welche Stolpersteine es gab und unsere Learnings auf dem Weg.<\/p>\n\n\n\n

Projektidee und grober Funktionsumfang<\/h2>\n\n\n\n

Taskflow ist ein \u201eTo\u2011Do\u2011Manager\u201c<\/strong> mit folgenden Kernfunktionen:<\/p>\n\n\n\n

    \n
  • Benutzerregistrierung und \u2011anmeldung \u00fcber JWT<\/strong>: Das Backend stellt Endpunkte zum Registrieren, Anmelden und Aktualisieren von Tokens zur Verf\u00fcgung. Nach erfolgreicher Anmeldung liefert der Server ein JWT zur\u00fcck, das bei allen weiteren API\u2011Aufrufen im Authorization\u2011Header gesendet wird.<\/li>\n\n\n\n
  • CRUD\u2011Operationen f\u00fcr Aufgaben<\/strong>: Es gibt Endpunkte zum Erstellen, Abrufen, Aktualisieren und L\u00f6schen von Todos. Aufgaben geh\u00f6ren zu einem Benutzer und beinhalten neben Titel und Beschreibung einen Status (offen\/abgeschlossen) sowie Zeitstempel f\u00fcr Erstellung und Aktualisierung.<\/li>\n\n\n\n
  • Health\u2011Endpunkte<\/strong>: F\u00fcr das Monitoring stehen verschiedene Health\u2011Checks zur Verf\u00fcgung, darunter ping<\/code>, database<\/code> und status<\/code>. Sie lassen sich z.\u00a0B. f\u00fcr Load\u2011Balancer\u2011Checks nutzen, vor allem kamen diese aber bei dem lokalen Testen zum Einsatz, um zu \u00fcberpr\u00fcfen, ob alle einzelnen Komponente individuell funktionieren.<\/li>\n\n\n\n
  • React\u2011Frontend<\/strong>: Das Frontend bietet eine minimalistische Oberfl\u00e4che mit Dark\/Light\u2011Mode, Benutzer\u2011Anmeldung und \u2011Registrierung, Aufgabenliste, einzelne Felder zur Aufgabenbearbeitung sowie einem Bereich f\u00fcr bereits erledigte Aufgaben.<\/li>\n<\/ul>\n\n\n\n

    Architektur und Technologieauswahl<\/h2>\n\n\n\n

    Backend: Spring Boot + AWS Lambda + DynamoDB<\/h3>\n\n\n\n

    Das Backend basiert auf Spring\u00a0Boot<\/strong> und wurde so strukturiert, dass es sowohl als klassische REST\u2011Anwendung laufen kann als auch serverlos via AWS\u00a0Lambda<\/strong>. In der Produktionsumgebung wird die Anwendung als Lambda\u2011Funktion<\/strong> mit einer REST\u2011API \u00fcber API\u00a0Gateway betrieben. Die template.yaml<\/code> (SAM) definiert eine standard Lambda\u2011Konfiguration (1\u00a0GB\u00a0RAM, 30\u00a0Sekunden Timeout) und erstellt DynamoDB\u2011Tabellen f\u00fcr Todos und Benutzer. Vorteile des serverlosen Ansatzes sind Skalierung, keine Serveradministration und die M\u00f6glichkeit, die AWS\u2011Free\u2011Tier zu nutzen.<\/p>\n\n\n\n

    Die Datenbank ist AWS DynamoDB<\/strong>, eine NoSQL\u2011Datenbank. Die Todos\u2011Tabelle verwendet eine ID als Partition\u2011Key und eine sekund\u00e4re Indexe auf userId. Als Neulinge im NoSQL\u2011Bereich mussten wir umdenken, dass es keine klassischen Joins gibt; stattdessen werden Daten eher denormalisiert gespeichert. Das Wegfallen eines festen Schemas machte das Hinzuf\u00fcgen neuer Attribute einerseits einfacher, erforderte aber sorgf\u00e4ltiges Design, um effiziente Abfragen zu erm\u00f6glichen.<\/p>\n\n\n\n

    Frontend: React + Context + JWT<\/h3>\n\n\n\n

    Das Frontend basiert auf React<\/strong>. react-router-dom<\/code> erm\u00f6glicht Routing (Startseite, erledigte Aufgaben, Login und Signup). Mehrere Context\u2011Provider kapseln Anwendungszustand:<\/p>\n\n\n\n

      \n
    • AuthContext<\/strong> verwaltet JWT, h\u00e4lt den Anmelde\u00adstatus und stellt Funktionen zum Login\/Logout bereit.<\/li>\n\n\n\n
    • TaskContext<\/strong> verwaltet eine Liste lokaler Aufgaben, l\u00e4dt diese \u00fcber todoAPI<\/code> vom Backend und speichert zus\u00e4tzliche Metadaten wie F\u00e4lligkeit oder Notizen in localStorage<\/code>.<\/li>\n\n\n\n
    • ThemeContext<\/strong> realisiert den Dark\/Light\u2011Mode.<\/li>\n\n\n\n
    • NotificationContext<\/strong> erm\u00f6glicht Benachrichtigungen.<\/li>\n<\/ul>\n\n\n\n

      Die Komponente Home zeigt offene Aufgaben, erlaubt das Hinzuf\u00fcgen via Input\u2011Feld und verwendet TaskModal<\/code> f\u00fcr die Bearbeitung einer Aufgabe. Erledigte Aufgaben werden mit \u00dcbergangsanimationen ausgeblendet und k\u00f6nnen in einer eigenen Route eingesehen werden.<\/p>\n\n\n\n

      CI\/CD\u2011Pipeline<\/strong><\/h3>\n\n\n\n

      Einer der Schwerpunkte des Projekts war eine GitHub\u2011Actions Pipeline<\/strong>. Das Ziel war, m\u00f6glichst viele Praktiken aus dem DevOps\u2011Bereich auszuprobieren, und den Entwicklungs- und Deploymentaufwand einfacher zu machen. Die Pipeline ist in drei Hauptphasen unterteilt :<\/p>\n\n\n\n

        \n
      1. Continuous Integration (CI)<\/strong> \u2013 Jeder Push und Pull\u2011Request triggert eine Build\u2011Pipeline. Diese f\u00fchrt Unit\u2011Tests aus, cached Maven\u2011Abh\u00e4ngigkeiten, generiert Test\u2011Reports, f\u00fchrt eine Sicherheitsscanner (OWASP Dependency Check) aus und erstellt einen JAR\u2011Artifact. Anschlie\u00dfend analysiert SonarCloud den Code auf Qualit\u00e4t und Testabdeckung t\u00e4glich.<\/li>\n\n\n\n
      2. Continuous Deployment (CD)<\/strong> \u2013 Abh\u00e4ngig vom Ziel\u2011Branch wird die Anwendung automatisiert mit SAM CLI nach AWS deployt. Ein Push auf develop erzeugt eine Development\u2011Umgebung, ein Push auf main eine Staging\u2011Umgebung, w\u00e4hrend Produktion manuell per Workflow Dispatch ausgel\u00f6st wird. Jede Umgebung nutzt separate AWS\u2011Secrets und hat eigene CORS\u2011Konfigurationen. Nach dem Deployment werden Smoke\u2011 oder Integrationstests ausgef\u00fchrt und das Ergebnis in die Pull\u2011Request kommentiert. Dies basiert auf vorherbestehende CD Templates, bei uns kam nur eine (Production) Umgebung zum Einsatz<\/li>\n\n\n\n
      3. Performance\u2011Tests<\/strong> \u2013 Es existiert ein optionaler Workflow f\u00fcr Lasttests mit k6. Dieser kann manuell gestartet werden, erzeugt Berichte und \u00fcberpr\u00fcft, ob 95 % der Anfragen unter zwei Sekunden bleiben .
        Weitere GitHub\u2011Features wie Dependabot, Secrets Scanning und branch protection rules sind aktiviert. Aufgrund von Problemen mit AWS\u2011Secrets schlagen aktuell einzelne Tests fehl (das Deployment selbst funktioniert lokal).<\/li>\n<\/ol>\n\n\n\n

        Lokales Testen<\/strong><\/h3>\n\n\n\n

        F\u00fcr das lokale Testen gibt es zwei Ans\u00e4tze:<\/p>\n\n\n\n

          \n
        • LocalStack<\/strong> simuliert AWS\u2011Services komplett in Docker. Ein Script startet LocalStack, DynamoDB Local und erstellt die n\u00f6tigen Tabellen. Danach k\u00f6nnen die Lambda\u2011Funktion und API Gateway lokal getestet werden, z. B. per curl auf die Health\u2011Endpunkte.<\/li>\n\n\n\n
        • SAM\u00a0Local<\/strong> erm\u00f6glicht das Ausf\u00fchren und Debuggen einzelner Lambda\u2011Funktionen oder der gesamten REST\u2011API. \u00dcber das Script sam-local.sh<\/code> kann die API auf Port\u00a03000 gestartet werden; anschlie\u00dfend lassen sich Endpunkte f\u00fcr Registrierung, Login und Todos testen.<\/li>\n<\/ul>\n\n\n\n

          Learnings \u2013 Missverst\u00e4ndnisse und Erkenntnisse<\/strong><\/h2>\n\n\n\n
            \n
          1. Serverless\u2011Mindset statt Monolith<\/strong><\/li>\n<\/ol>\n\n\n\n

            Was ist Serverless?<\/strong><\/p>\n\n\n\n

            Serverless\u2011Architekturen basieren auf Funktionen, die durch Ereignisse wie HTTP\u2011Anfragen nur “on demand” ausgel\u00f6st werden. Der Cloud\u2011Provider skaliert automatisch und verrechnet nur die tats\u00e4chliche Nutzung. Die bekannte monolithische Struktur mit dauerhaft laufendem Server entf\u00e4llt.<\/p>\n\n\n\n

            Missverst\u00e4ndnis<\/strong>: Zun\u00e4chst gingen wir davon aus, dass man einfach eine komplette Spring\u2011Boot\u2011Anwendung schreibt und diese dann als Lambda \u201ehochl\u00e4dt\u201c. Das h\u00e4tte bedeutet, dass alle Controller immer mitstarten und der Cold\u2011Start sehr lange dauert, quasi ein normaler Webserver der Endpunkte offenlegt.<\/p>\n\n\n\n

            Learning und Umsetzung<\/strong>: Tats\u00e4chlich kapselt man nur die ben\u00f6tigten Handler in einer speziellen Lambda\u2011Klasse (AwsLambdaHandler::handleRequest<\/code>). API\u00a0Gateway fungiert als Router; einzelne Controller\u2011Methoden werden durch Pfad\u2011Pattern aufgerufen. Dadurch ist die Startzeit akzeptabel. Auch das Thema Cold\u00a0Start<\/strong> war neu \u2013 beim ersten Aufruf einer Lambda vergehen 10\u201315\u00a0Sekunden. Sp\u00e4ter ist die Funktion \u201ewarm\u201c und reagiert schnell.<\/p>\n\n\n\n

              \n
            1. Environment\u2011Variablen und Secrets<\/strong><\/li>\n<\/ol>\n\n\n\n

              Was sind Environment-Variable und Secrets?<\/strong><\/p>\n\n\n\n

              Konfigurationsparameter und geheime Schl\u00fcssel sollten nicht im Code landen, sondern \u00fcber Umgebungsvariablen bereitgestellt werden. In Spring\u00a0Boot k\u00f6nnen sie via @Value<\/code> oder application-*.yml<\/code> annotiert und gelesen werden.<\/p>\n\n\n\n

              Missverst\u00e4ndnis<\/strong>: Anfangs waren unsere Zugangsdaten in application.yml<\/code>. Das ist offensichtlich unsicher und erschwert den Wechsel zwischen Umgebungen, falls auf anderen Computern andere Konfigurationen vorliegen.<\/p>\n\n\n\n

              Learning und Umsetzung<\/strong>: Das Projekt verwendet .env<\/code>\u2011Dateien und das Spring\u2011Profile\u2011System. Die README erkl\u00e4rt, welche Variablen f\u00fcr die Profile local, docker und prod gesetzt werden m\u00fcssen (u. a. jwt_secret<\/code>, aws_access_key_id<\/code>, aws_secret_access_key<\/code>, cors_allowed_origins<\/code>) . F\u00fcr GitHub Actions werden Secrets pro Umgebung hinterlegt und in den Workflows referenziert. Durch diese Trennung konnten wir die Anwendung lokal ohne echte AWS\u2011Zugangsdaten ausf\u00fchren und bei Bedarf production Schl\u00fcssel verwenden.<\/p>\n\n\n\n

                \n
              1. JWT\u2011Authentifizierung<\/strong><\/li>\n<\/ol>\n\n\n\n

                Was ist JWT?<\/strong><\/p>\n\n\n\n

                JSON Web Tokens sind selbstsignierte Tokens, die einen Benutzer identifizieren. Ein Nutzer meldet sich mit Username und Passwort an, das Backend erzeugt ein JWT und sendet es dem Client, der es bei zuk\u00fcnftigen Anfragen mitsendet. Das Backend validiert das Token, ohne bei jedem Request die Datenbank zu befragen.<\/p>\n\n\n\n

                Missverst\u00e4ndnis<\/strong>: Wir waren unsicher, wie das Token generiert und sicher gespeichert wird, und wie man es entsprechend sicher lagert, verwaltet und wie ein kompletter Authetifizierungshandshake aussieht.<\/p>\n\n\n\n

                Learning und Umsetzung<\/strong>: Die Anwendung nutzt BCrypt<\/strong> zum Hashen von Passw\u00f6rtern in der Datenbank und erstellt JWTs \u00fcber einen eigenen JwtService. Die Controller\u2011Tests belegen, dass Registrierung und Login ein g\u00fcltiges Token zur\u00fcckgeben. Im Frontend wird das Token im AuthContext<\/code> gespeichert; bei Ablauf kann \u00fcber einen Refresh\u2011Endpoint ein neues Token geholt werden.<\/p>\n\n\n\n

                  \n
                1. NoSQL mit DynamoDB<\/strong><\/li>\n<\/ol>\n\n\n\n

                  Was ist NoSQL?<\/strong><\/p>\n\n\n\n

                  DynamoDB ist eine NoSQL\u2011Datenbank. Daten werden in Tabellen mit prim\u00e4rem Schl\u00fcssel (Partition\u2011Key) und optional Sort\u2011Key gespeichert. Es gibt keine Joins und keine relationalen Constraints. Stattdessen werden Entit\u00e4ten h\u00e4ufig denormalisiert.<\/p>\n\n\n\n

                  Missverst\u00e4ndnis<\/strong>: Als Postgres\u2011Nutzer wollten wir klassisch Relationen definieren und JOINs definieren bei der Planung unser Schemata. Bei DynamoDB ist dies nicht m\u00f6glich; man plant den Zugriff anhand der Abfragepfade und modelliert entsprechend.<\/p>\n\n\n\n

                  Learning und Umsetzung<\/strong>: Die Todos\u2011Tabelle speichert neben ID, Titel, Beschreibung, Status und Zeitstempeln eine userId<\/code> zur Zuordnung. Ein sekund\u00e4rer Index erm\u00f6glicht das Abrufen aller Todos eines Benutzers. Die Frontend\u2011Metadaten (F\u00e4lligkeit, Notizen) werden lokal gespeichert, da sie momentan noch nicht im Backend Code implementiert sind.<\/p>\n\n\n\n

                    \n
                  1. Docker Compose, LocalStack & SAM Local<\/strong><\/li>\n<\/ol>\n\n\n\n

                    Was versteht man darunter?<\/strong><\/p>\n\n\n\n

                    Docker Compose erm\u00f6glicht das Starten mehrerer Container (z. B. DynamoDB Local, LocalStack). LocalStack simuliert AWS\u2011Services, w\u00e4hrend SAM Local die Lambda\u2011Funktion lokal ausf\u00fchrt.<\/p>\n\n\n\n

                    Missverst\u00e4ndnis<\/strong>: Anfangs versuchte ich, alles alternativ lokal zu testen, um mit der Gesch\u00e4ftslogik abschlie\u00dfen zu k\u00f6nnen, und dann separat AWS lernen zu k\u00f6nnen.<\/p>\n\n\n\n

                    Learning und Umsetzung<\/strong>: Nach vielen alternativen L\u00f6sungen und Implementationen von z.B. JPA, welche sehr viel Zeit in Anspruch genommen haben, habe wir einen Schritt zur\u00fcck genommen, und uns nochmals auf LocalStack konzentriert.<\/p>\n\n\n\n

                      \n
                    1. AWS SAM und CI\/CD<\/strong><\/li>\n<\/ol>\n\n\n\n

                      Was ist SAM und CI\/CD?<\/strong><\/p>\n\n\n\n

                      SAM (Serverless Application\u00a0Model) erweitert CloudFormation und vereinfacht das Deployment von Lambda\u2011Funktionen und API\u00a0Gateways. SAM\u00a0CLI bietet Befehle zum Bauen (sam build<\/code>), Lokalen Testen (sam local start-api<\/code>) und Deployen (sam deploy<\/code>).<\/p>\n\n\n\n

                      Learning und Umsetzung<\/strong>: Mit SAM\u00a0CLI und GitHub\u00a0Actions lie\u00df sich das Deployment automatisieren. Die Datei CI-CD-ARCHITECTURE.md<\/code> beschreibt, dass f\u00fcr develop<\/code> automatisch in eine Dev\u2011Umgebung, f\u00fcr main<\/code> in eine Staging\u2011Umgebung und per manueller Aktion in die Produktion deployt wird. Parameter wie JwtSecret<\/code> und CorsAllowedOrigins<\/code> k\u00f6nnen per Kommandozeile entsprechend \u00fcbergeben werden.<\/p>\n\n\n\n

                      Problem<\/strong>: Wir hatte zwar bereits Ber\u00fchrugspunkte mit CI\/CD Pipelines, jedoch mit anderen Technologien, und au\u00dferdem haben wir sie noch nicht selber aufgesetzt und eingerichtet. Somit war dies quasi ein komplett neues Gebiet.<\/p>\n\n\n\n

                        \n
                      1. Modulare React Frontends<\/strong><\/li>\n<\/ol>\n\n\n\n

                        Was ist zu beachten wenn man ein Frontend baut f\u00fcr eine solche App?<\/strong><\/p>\n\n\n\n

                        Wichtig ist, mittels Kontext gesch\u00fctzte Inhalte sichtbar, oder nicht sichtbar zu machen, und dass alle Anfragen entsprechende Header beinhalten, sodass auch die korrekten Daten geladen werden k\u00f6nnen.<\/p>\n\n\n\n

                        Problem<\/strong>: Der Umgang mit API Gateway war noch unbekannt, und somit waren tats\u00e4chliche Tests eingeschr\u00e4nkt. Da das Frontend eher Nebensache unseres Projekts war, mussten wir auch lernen wie wir Kompetenzen und Zeit einteilen, sodass beide Seiten des Projekts effektiv unabh\u00e4ngig voneinander vorangetrieben werden.<\/p>\n\n\n\n

                        Learning und Umsetzung:<\/strong> Wir haben gelernt, dass ein Cloud-Frontend nicht nur UI ist, sondern aktiv in Authentifizierung und Datenfluss eingebunden wird; durch die konsequente Nutzung von React Contexts f\u00fcr Auth und Tasks sowie das Mitgeben der JWT-Header bei allen Requests konnten wir gesch\u00fctzte Inhalte zuverl\u00e4ssig steuern, und obwohl uns API Gateway f\u00fcr echte End-to-End-Tests noch fehlte, halfen lokale Mockups, Postman und eine klare Arbeitsteilung zwischen UI-Entwicklung und Backend-Schnittstellen dabei, das Frontend modular und unabh\u00e4ngig voranzutreiben.<\/p>\n\n\n\n

                        Vor\u2011 und Nachteile der gew\u00e4hlten Architektur<\/h2>\n\n\n\n
                        <\/td>Vorteil<\/td>Nachteil<\/td><\/tr>
                        Serverless mit AWS\u00a0Lambda & API\u00a0Gateway<\/strong><\/td>Kein Serverbetrieb, automatische Skalierung, Abrechnung pro Nutzung; ideal f\u00fcr geringe Last und schnelles Prototyping\u00a0<\/td>Vendor\u00a0Lock\u2011in, eingeschr\u00e4nkte Laufzeit und Konfiguration, Cold\u2011Start\u2011Latenz, Alptraumgeschichten von hohen AWS Rechnungen<\/td><\/tr>
                        DynamoDB (NoSQL)<\/strong><\/td>Schemalos, hohe Skalierbarkeit, vollst\u00e4ndig verwalteter Service<\/td>Kein ACID\u2011Support wie bei relationalen Datenbanken, Planung der Datenstruktur anhand der Abfragen erforderlich<\/td><\/tr>
                        JWT\u2011Authentifizierung<\/strong><\/td>Stateless, einfach zu validieren, kein Session\u2011Store n\u00f6tig<\/td>Token m\u00fcssen sicher gespeichert werden, bei Verlust kein Widerruf; ben\u00f6tigt Refresh\u2011Mechanismus, Risiken auf Entwickler Seite, kein Social Sign-In<\/td><\/tr>
                        CI\/CD mit GitHub\u00a0Actions<\/strong><\/td>Automatisierte Tests, Security\u2011Scans und Deployments erh\u00f6hen Codequalit\u00e4t und reduzieren manuelle Fehler\u00a0<\/td>Komplexe Konfiguration; abh\u00e4ngig von korrekter Verwaltung der Secrets<\/td><\/tr>
                        LocalStack & SAM\u00a0Local<\/strong><\/td>Schnelle lokale Entwicklung ohne Cloud\u2011Kosten, Tests laufen offline<\/td>Simulieren nicht alle AWS\u2011Edgecases (z.\u00a0B. Latenz), erfordern Einarbeitung<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

                        Reflexion und Ausblick<\/h2>\n\n\n\n

                        Die Arbeit an Taskflow war ein starker Lernprozess. Zun\u00e4chst hatten wir eine starke monolithische Denkweise<\/strong> und wollte \u201eeinfach ein Spring\u2011Boot\u2011Projekt in AWS deployen\u201c. Der Umstieg auf serverless jedoch erforderte ein Umdenken: Code wird als Funktion bereitgestellt, die nur f\u00fcr einen einzelnen Request lebt, und alles, was persistent bleiben soll, liegt au\u00dferhalb in Services wie DynamoDB. Dieses Paradigma hat mir verdeutlicht, was serverless tats\u00e4chlich bedeutet.<\/p>\n\n\n\n

                        Die Einrichtung der CI\/CD\u2011Pipeline<\/strong> war weniger komplex als erwartet, und hat sich ausgezahlt. Automatische Tests und Security\u2011Scans geben Sicherheit; Fehlermeldungen weisen fr\u00fchzeitig auf Probleme hin. Hierzu gab es schon fertige Konfigurationen f\u00fcr unsere Verwendung, die in unserem Fall eher umfassender als notwendig waren, jedoch aber gute Einblicke geboten haben. Die gr\u00f6\u00dfte Herausforderung hier war der Umgang mit Secrets<\/strong>. In der lokalen Umgebung funktionierte alles, in GitHub\u00a0Actions fehlten jedoch anfangs die n\u00f6tigen AWS\u2011Zugangsdaten \u2013 daher sind aktuell einige Tests rot.<\/p>\n\n\n\n

                        Aus Zeitgr\u00fcnden ist das Deployment in die Cloud (S3 f\u00fcr das Frontend, Lambda f\u00fcr das Backend) noch nicht erfolgt. Die Pipeline ist jedoch vorbereitet; mit g\u00fcltigen Secrets k\u00f6nnten Dev\u2011, Staging\u2011 und Prod\u2011Stacks erzeugt werden.<\/p>\n\n\n\n

                        Insgesamt haben wir folgende Kernkompetenzen aufgebaut:<\/p>\n\n\n\n

                          \n
                        • Verst\u00e4ndnis f\u00fcr Serverless\u2011Architekturen<\/strong> und die Unterschiede zu klassischen Monolithen.<\/li>\n\n\n\n
                        • Nutzung von AWS SAM<\/strong>, LocalStack<\/strong> und Docker Compose<\/strong> zur lokalen Entwicklung.<\/li>\n\n\n\n
                        • Implementierung von JWT\u2011Authentifizierung<\/strong> und sicheren Passwortspeicher mit BCrypt.<\/li>\n\n\n\n
                        • Grundlagen von NoSQL<\/strong> und Datenmodellierung in DynamoDB.<\/li>\n\n\n\n
                        • Aufbau einer CI\/CD\u2011Pipeline<\/strong> mit Tests, Sicherheitsanalysen und automatisiertem Deployment.<\/li>\n<\/ul>\n\n\n\n

                          Dieses Projekt wurde durchgef\u00fchrt von: Julian Schniepp, Lian Krabel und Raphael Pulfferm\u00fcller<\/p>\n\n\n\n

                          <\/p>\n","protected":false},"excerpt":{"rendered":"

                          Im Rahmen der Vorlesung \u201eSoftware Development for Cloud\u00a0Computing\u201c sollte jedes Team ein eigenes Cloud\u2011Projekt umsetzen. Unser Projekt Taskflow sollte dabei ein serverloses Todo\u2011Management\u2011System werden. Ziel war es dabei, neue und vor allem industrierelevante Cloud\u2011Technologien praktisch zu erlernen. Der Backend\u2011Teil ist mit Spring\u2011Boot realisiert, welcher \u00fcber AWS\u00a0Lambda und API\u00a0Gateway bereitgestellt modular eingesetzt werden kann. Als Persistenz […]<\/p>\n","protected":false},"author":1258,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"ppma_author":[1121],"class_list":["post-28084","post","type-post","status-publish","format-standard","hentry","category-allgemein"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":25800,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2023\/09\/14\/splid-2-0-die-zukunft-des-gemeinsamen-ausgabenmanagements\/","url_meta":{"origin":28084,"position":0},"title":"Splid 2.0 – Die Zukunft des gemeinsamen Ausgabenmanagements","author":"David Christoph Scheifers","date":"14. September 2023","format":false,"excerpt":"Im Rahmen der Vorlesung \u201cSoftware Development for Cloud Computing\u201d haben wir uns daf\u00fcr entschieden, einen Klon der App Splid auf Basis unterschiedlicher Cloud Technologien als Web App zu entwickeln, um uns so die Grundkenntnisse des Cloud Computings anzueignen. Projektidee Bei gemeinsamen Aktivit\u00e4ten und Gruppenausgaben ist es sehr hilfreich, einfache und\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":23517,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/08\/29\/multiplayer-game-with-aws-stadtlandfluss\/","url_meta":{"origin":28084,"position":1},"title":"Multiplayer Game with AWS |\u00a0StadtLandFluss","author":"gi004","date":"29. August 2022","format":false,"excerpt":"Dieser Blogbeitrag soll einen Einblick in die Entwicklung unserer Webanwendung mit den unten definierten Funktionen geben sowie unsere L\u00f6sungsans\u00e4tze, Herausforderungen und Probleme aufzeigen.\u00a0 Cloud Computing VorlesungProjekt Idee & InspirationZielEinblick in das Spiel \u2013 DemoFrameworks - Cloud Services - InfrastructureArchitekturCloud KomponentenAWS ServicesDynamo DBS3LambdaAmazon API- GatewayAmazon CloudWatchTestingCI\/CD PipelineSchwierigkeitenFazit Cloud Computing Vorlesung Ziel\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/08\/image.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/08\/image.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/08\/image.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/08\/image.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":23579,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/08\/30\/google-geodata-visualizer\/","url_meta":{"origin":28084,"position":2},"title":"Google Geodata Visualizer","author":"sk331","date":"30. August 2022","format":false,"excerpt":"Ein Projekt von Kai Kustermann, Michael Litschko, Sarah Mauff und Sebastian K\u00f6pp Einleitung Im Sommersemester 2022 haben wir uns als 4-k\u00f6pfige Gruppe dazu entschlossen, einen Google Geodata Visualizer zu erstellen. Das Projekt ist aus der Idee einer McDonald\u2019s-Achievement-Card entstanden. Die Idee war eine Website, die dem Benutzer anzeigt, welche McDonald\u2019s\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/08\/16.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":11711,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/09\/29\/perfekter-gluhwein-fur-zuhause-thermometer-mit-raspberry-pi-und-aws\/","url_meta":{"origin":28084,"position":3},"title":"Perfekter Gl\u00fchwein f\u00fcr Zuhause: Thermometer mit Raspberry Pi und AWS","author":"jg129","date":"29. September 2020","format":false,"excerpt":"Abstract Kein anderes Getr\u00e4nk ist mit Weihnachtsm\u00e4rkten so verbunden wie Gl\u00fchwein. Und so trinkt sich der ausschweifende Weihnachtsmarktbesucher im Laufe der Adventszeit von Stand zu Stand bis er schlie\u00dflich am Ende des Jahres seinen Lieblingsstand gefunden hat. Doch auch daheim kann der perfekte Gl\u00fchwein gelingen.\u00a0 Wir zeigen, wie man sich\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/lh3.googleusercontent.com\/rbu36fXExVo14XfyUicXbIFjAgh1bvNnXHlaUVRfqLevpyZx4KVyjeuYdgItPx6y39R8L9Ub_hug03LYM3AIAW_F14vhBiXOZlt92qIpN0Y2h0H-czZ65ERnn3qUoWVh7JfI5ihA","width":350,"height":200,"srcset":"https:\/\/lh3.googleusercontent.com\/rbu36fXExVo14XfyUicXbIFjAgh1bvNnXHlaUVRfqLevpyZx4KVyjeuYdgItPx6y39R8L9Ub_hug03LYM3AIAW_F14vhBiXOZlt92qIpN0Y2h0H-czZ65ERnn3qUoWVh7JfI5ihA 1x, https:\/\/lh3.googleusercontent.com\/rbu36fXExVo14XfyUicXbIFjAgh1bvNnXHlaUVRfqLevpyZx4KVyjeuYdgItPx6y39R8L9Ub_hug03LYM3AIAW_F14vhBiXOZlt92qIpN0Y2h0H-czZ65ERnn3qUoWVh7JfI5ihA 1.5x"},"classes":[]},{"id":28021,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/09\/13\/multiplayer-web-game-mit-aws-schiffe-versenken\/","url_meta":{"origin":28084,"position":4},"title":"Multiplayer Web-Game mit AWS | Schiffe versenken","author":"Leon Obertopp","date":"13. September 2025","format":false,"excerpt":"Projektidee: Im Rahmen der Vorlesung \"Software Development for Cloud Computing\" sollen die Studierenden in Gruppen ein eigenes Projekt, mit Hilfe von in der Vorlesung gezeigten Cloud Technologien umsetzen. Wir hatten Anfangs Probleme ein geeignetes Thema zu finden, da unser Wissenstand im Thema Cloud nicht besonders gro\u00df war. Letztendlich haben wir\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/09\/image-4.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/09\/image-4.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/09\/image-4.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":12032,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/09\/30\/admin-panel-web-app-in-der-aws-cloud\/","url_meta":{"origin":28084,"position":5},"title":"Admin Panel (Web App) in der AWS Cloud","author":"ss447","date":"30. September 2020","format":false,"excerpt":"1. Einleitung Im Rahmen der Vorlesung \u201eSoftware Development for Cloud Computing\u201c haben wir uns als Gruppe dazu entschieden aufbauend auf teilweise bereits vorhandener Codebasis an einem Startup-Projekt weiterzuarbeiten. Der Hauptfokus lag bei uns auf dem Ausbau von DevOps-Aspekten und auf dem eines stabilen und sicheren Systems, welches auch in der\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/img.youtube.com\/vi\/qw9ZkWnvR4M\/0.jpg?resize=350%2C200","width":350,"height":200},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":1121,"user_id":1258,"is_guest":0,"slug":"julian_schniepp","display_name":"Julian Schniepp","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/e361563675cba2fec16ef9b99a5c0dbb64dcbb452e6e200171dd763481c5dcd3?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/28084","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/1258"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=28084"}],"version-history":[{"count":5,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/28084\/revisions"}],"predecessor-version":[{"id":28093,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/28084\/revisions\/28093"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=28084"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=28084"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=28084"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=28084"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}