Recall Trainer – Eine serverless Web-App mit AWS

Einleitung

Im Rahmen der Vorlesung “Software Development for Cloud Computing” habe ich im vergangenen Semester eine Einführung in die Welt des Cloud Computings incl. der relevanten Konzepte und Technologien erhalten. Einige dieser Konzepte habe ich versucht in meinem Abschlussprojekt umzusetzen, das ich im Nachfolgenden vorstellen möchte. 

Idee/Projekt

Die Idee war es eine Webanwendung zu konzipieren und zu entwickeln, welche dem Nutzer beim persönlichen Wissensmanagement unterstützt. Die Applikation hilft dem Lernenden sich jeden Tag mit seinen Wissensgebieten auseinander zu setzen, indem diese ihm täglich eine Email mit einem Link zu seiner personalisierten Wissensabfrage sendet.

Mit einem Klick auf den Link landet der Nutzer bei einer zufälligen Auswahl von bis zu 25 Fragen seiner bisher erfassten Lerninhalte. Die Anwendung zeigt nun eine Frage und einen Timer an. Der Nutzer soll nun innerhalb von 10 Sekunden sich die Antwort ins Gedächtnis rufen. Wenn er eine Antwort im Kopf hat, klickt er den Button „Reveal“, welcher die korrekte Antwort aufdeckt. Nun muss der Nutzer angeben, ob seine Antwort im Kopf mit der tatsächlichen Antwort übereinstimmt. Schaft der Nutzer es nicht innerhalb von 10 Sekunden zu antworten wird automatisch eine neue Frage angezeigt. 

Das Ziel ist es das Gedächtnis zu trainieren. Die jeweiligen Fragen werden so lange per Zufallsauswahl wiederholt, bis der User alle Fragen einmal richtig mental abgerufen hat. 

Ziele für die Umsetzung

Mein Ziel war es eine derartige fachliche Problemstellung als Serverless Architektur zu realisieren. Zugleich wollte ich erste Erfahrungen mit der AWS Infrastruktur sammeln. Um eine zentrale und automatisierte Verwaltung aller Ressourcen sicherzustellen, die Lösung skalierbar zu gestalten und um Cloud Ressourcen zu minimieren sowie das Risiko von versteckten Kosten zu reduzieren, war das Ziel das Projekt als Infrastructure as Code zu implementieren.

Implementierung

Als Infrastructure as Code -Tool wurde AWS Sam (AWS Serverless Application Model) verwendet. Dieses baut auf Amazon’s Cloudformation Infrastructure as Code Syntax auf und liefert zusätzlich noch ein Command Line Interface, welches das Deployment und lokale Testing von Lambda Funktionen ermöglicht.

Die Frontend-Applikation wurde mit Hilfe des Frontend-Frameworks Angular erstellt, in welchem ich im Rahmen dieses Projektes erste Erfahrungen sammeln konnte. Deployed wird das Frontend mithilfe einer  AWS Amplify Build Pipeline, welche durch Commits auf den in SAM spezifizierten Branch ausgelöst wird.

Eine besondere Herausforderung hierbei war es,  dass der Link, den die Angular Anwendung nutzt um auf das Backend zuzugreifen dem aktuellen Link des API Gateways entsprechen muss. Dazu wird dieser durch SAM der Amplify Ressource als Environmental Variablen übergeben. Diese wird dann in der Build Pipeline verwendet um den Link in der Index.js des Angular Builds mit der Variablen zu substituieren.

Das Backend der Anwendung setzt basiert auf mehreren AWS Services.

Der Zugriff des Frontends auf das Backend erfolgt über API Gateway mit 2 Routen.

• post /subscribe: Leitet den Request an SubscribeEndpoint Lambda weiter
• get /daily-prompt:  Leitet den Request an DailyPromptsEnpoint Lambda weiter

Die Funktionalität der App ist über 3 Lambda Funktionen realisiert.

• DailyEMailGenerator: Wird täglich von einer CloudWatch Schedule aufgerufen und generiert für jeden registrierten Nutzer eine Selektion an täglichen Fragen aus der Menge aller hinterlegten Fragen.
• DailyPromptsEndpoint: Liefert die in der Datenbank hinterlegte Menge an täglichen Fragen für einen Nutzer
• SubscribeEndpoint: Fügt den Nutzer der Subscriber Tabelle hinzu und speichert das mitgelieferte Fragen / Antwort Paar

Die Datenbank ist als DynamoDb mit den 3 Tabellen Subscribers, SubscriberData und DailyPrompts realisiert. 

Alle Ressourcen und notwendigen Rollen und Policies sind in einem SAM Template File erfasst und können bequem per SAM CLI deployt werden. Dabei wurde Wert darauf gelegt sensible Daten wie den GitHub Access Token, den Amplify benötigt, als Environment Variables abzufragen, anstelle diese hart zu coden.

Probleme

Als Hauptproblem hat sich für mich der riesige Umfang von AWS herausgestellt, da es eine Vielzahl an Dokumentationen zu lesen gibt, so dass es für einen Einsteiger schwierig ist, sich direkt zurecht zu finden. Das Angebot an Informationen zu Cloud (Patterns, Best Practices, etc.) und Cloud Services ist gefühlt unendlich. Es ist deshalb schwierig das für die Problemstellung wirklich relevante Wissen zu finden und die Qualität der verfügbaren Informationen ist stark unterschiedlich. Da das User Interface von AWS-Diensten von Service zu Service variiert, ist auch die Navigation innerhalb der Dienste nicht immer einfach. 

Ursprünglich war geplant Terraform als plattformunabhängiges Infrastructure as Code-Tool einzusetzen. Jedoch stellte sich dessen Dokumentation bezüglich spezieller AWS Services teilweise als unvollständig heraus und hat somit nach vielen erfolglosen Versuchen dazu geführt, dass AWS SAM als Infrastructure as Code-Tool adaptiert wurde.

Des Weiteren gestaltet sich das Debugging schwieriger wie auf dem eigenen Rechner. Dies hängt mit dem komplexen Zusammenspiel der vielen AWS Services zusammen und macht eine Fehlersuche oft sehr schwierig. AWS bietet hierfür CloudWatch als zentrale Logging-Plattform an. Es kann aber vorkommen, dass Fehler auftreten ohne dass diese erfasst werden. Ich hatte beispielsweise das Problem, dass eine Lambda-Funktion plötzlich nicht mehr in die Datenbank geschrieben hat, ohne Fehler zu loggen, obwohl andere Funktionen denselben Code ohne Probleme auf dieselbe Datenbank anwenden konnten. Der Fehler hat sich nach einigen Stunden von selbst erledigt, es blieb allerdings intransparent, wodurch die Lösung erfolgt ist. 

Lessons Learned

Ich habe in diesem Projekt sehr viel spannendes über die Entwicklung für AWS und die Cloud gelernt, sodass ich durch diese Veranstaltung einiges an theoretischem als auch praktischem Wissen im Bereich Cloud Computing aufbauen konnte. Das Projekt war gezeichnet von sehr viel ausprobieren was sich häufig auch nicht in der finalen Lösung niedergeschlagen hat.

Darüber hinaus konnte ich praktische Erfahrungen in der Implementierung von Webanwendungen aufbauen. Ein weiteres Lessons Learned für mich ist, dass ich ein solches Projekt in einem komplexen Themengebiet, in welchem ich keinerlei Vorkenntnisse hatte zukünftig wohl nicht mehr alleine angehen würde da ich mir sicher bin das ich mir viele Stunden recherchieren und Trial und Error durch eine weitere Person hätte ersparen können.