Fazit

Das Ziel dieser Semesterarbeit – ein Werkzeug zur standardisierten, schnellen und einfachen Bereitstellung von AWS-EC2-Instanzen – wurde erreicht. Aus der manuellen, fehleranfälligen “Point-and-Click”-Provisionierung ist ein interaktives Bash-Skript geworden, das eine Instanz in den Standard-Umgebungen reproduzierbar in unter zwei Minuten (Custom rund vier) ausrollt und dabei die Konfiguration zentral aus den Abyss-Standards bezieht. Der eingangs beschriebene Configuration Drift zwischen Dev, Int und Prod ist damit eliminiert.

Inhaltlich wurden alle drei geplanten Releases (MVP, MMP, MLP) abgeschlossen und sämtliche werthaltigen User Stories umgesetzt. Genauso wichtig wie das Produkt war für mich aber der Weg dorthin: Diese Arbeit war mein erster vollständiger Durchlauf eines agilen Projekts nach SCRUM. Entsprechend lag ein erheblicher Teil des Lernens nicht im Technischen, sondern im Projektmanagement – vom Schreiben sinnvoller User Stories über das Schätzen mit Story Points bis zum Planen und Abschliessen einzelner Sprints. Der Fortschritt über die drei Sprints hinweg ist für mich der wertvollste Ertrag dieser Arbeit.

Reflexion und Vorbehalte

So zufrieden ich mit dem Ergebnis bin, gibt es bewusst gesetzte Grenzen, die ich nicht verschweigen möchte:

  • SSH-Keys im Klartext: Die autorisierten Schlüssel liegen fix im userdata.yml.template. Produktiv wäre die Auslagerung in den AWS Secrets Manager oder Parameter Store die sauberere Lösung. Dies wurde bereits im Review von Sprint 1 als ausserhalb des Rahmens dieser Arbeit eingestuft – die Entscheidung war also bewusst, nicht aus Unkenntnis.
  • Monolith statt Module: Die Architektur-Evaluierung fiel nur knapp zugunsten des funktionalen Monolithen aus. Für ein wachsendes, teamgepflegtes Werkzeug wäre eine modulare Struktur die nachhaltigere Wahl. Im Kontext dieser Semesterarbeit (Fokus Endbenutzer-Einfachheit, 80 % Projektmanagement-Bewertung) war der Monolith jedoch die stimmigere Entscheidung.
  • Begrenzter Scope: IAM-Rollen, Monitoring und der Betrieb nach dem Deployment sind bewusst out of scope. Für einen echten Produktivbetrieb wären diese Punkte zwingend zu ergänzen.
  • Aussagekraft der Messung: Wie im Kapitel “Ergebnisse & Analyse” offengelegt, beruhen die Werte auf manuellen Testläufen eines Ein-Personen-Projekts. Sie sind indikativ, nicht unter Laborbedingungen abgesichert.

Diese Vorbehalte schmälern das Ergebnis nicht – sie zeigen, wo die bewusst gezogene Grenze zwischen “Prototyp für die Semesterarbeit” und “produktivem Werkzeug” verläuft.

Ausblick

Aus den obigen Punkten ergibt sich ein klarer Pfad für eine mögliche Weiterentwicklung. Nach Priorität geordnet:

  1. Secrets-Handling: SSH-Keys und sensible Werte aus dem Template lösen und über AWS Secrets Manager / Parameter Store beziehen.
  2. IAM & Berechtigungen: Saubere, minimal berechtigte IAM-Rollen für das Deployment statt breiter Account-Rechte.
  3. Monitoring & Lifecycle: Einbindung von CloudWatch sowie ein definierter Prozess für Wartung und Deprovisionierung der Instanzen.
  4. Multi-Region / Skalierung: Unterstützung mehrerer Regionen und das Ausrollen mehrerer Instanzen in einem Lauf.
  5. Won’t-Do-Spalte & Tooling: Die in der Nachbesprechung angeregte “Won’t Do”-Spalte im Issue Board sowie der Wechsel auf ein dediziertes Board-Tool werden in der nächsten Semesterarbeit berücksichtigt.

Schlusswort

Rückblickend hat mir diese Arbeit weniger über AWS oder Bash beigebracht – diese Grundlagen waren vorhanden – als über das strukturierte, agile Vorgehen in einem Projekt. Genau das war als erste Semesterarbeit mit Fokus auf die Lernbegleitung auch der Anspruch. Das Werkzeug ist fertig, dokumentiert und übergabefähig; und ich gehe mit deutlich mehr Sicherheit im Projektmanagement in die nächste Semesterarbeit.

Danksagung & Ehrung

Obschon ich als “Die Projektleitung” dieses Mock-Project selbstständig geführt habe, hatte ich selbstverständlich als “Nerd” Hilfe. Deswegen kommt hier eine Danksagung sowie ein Auszug von allen Personen welche mir in dieser Arbeit geholfen haben.

Menschen

Ein grosses Dankeschön geht selbstverständlich an die “Stakeholder” dieses Projekts. Somit: Herzlichen Dank Armin Dörzbach & Michel Rodriguez. Euer Feedback hat mir sehr weitergeholfen und ich bin froh, euch als meine “Stakeholder” gehabt zu haben.

Technik

Selbstverständlich geht auch ein Dankeschön an folgende “virtuelle Assistenten” raus:

  1. Gemini CLI
  2. Aino (Eigene KI)
  3. Claude Code

Auch diese drei virtuellen Assistenten haben mir sehr geholfen.

This site uses Just the Docs, a documentation theme for Jekyll.