,

Splid 2.0 – Die Zukunft des gemeinsamen Ausgabenmanagements

David Christoph Scheifers

Im Rahmen der Vorlesung “Software Development for Cloud Computing” haben wir uns dafür 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äten und Gruppenausgaben ist es sehr hilfreich, einfache und effiziente Tools zu haben, um Geldbeträge aufzuteilen und Ausgaben zu verwalten. Hier kommt “Splid 2.0” ins Spiel – eine Anwendung, die es Benutzern ermöglicht, Ausgaben unkompliziert und effektiv zu organisieren und aufzuteilen. In diesem Blogbeitrag werden wir einen umfassenden Einblick in das Projekt “Splid 2.0” geben.

Hier eine Übersicht der Hauptfunktionen unserer App:

Nachdem wir unsere Funktionen definiert hatten, haben wir uns Gedanken zum Aufbau und Entwurf der App gemacht.

Entwurfsentscheidungen

Frontend

Aufgrund bereits vorhandener Vorkenntnisse und guter Erfahrungen haben wir uns für die Umsetzung des Frontends mit dem React Framework in Kombination mit Typescript entschieden. Die Gestaltung als Web App hat zudem den Vorteil, dass “Splid-2.0” plattformübergreifend zugänglich ist.

Backend

1. AWS

Da wir das Backend bereits bei einem bestehenden Projekt mit ASP.NET Core umgesetzt hatten, haben wir uns dazu entschieden die API auf AWS Services umzustellen, um so einen Serverless-Ansatz zu verfolgen. Bei der Entscheidung standen nicht nur die Stärken von AWS als Cloud Provider im Vordergrund, sondern auch der bewusste Schritt hin zum Serverless-Ansatz. Gleichzeitig wurde uns durch die Einblicke in der Vorlesungen und eigener Recherche ein Bewusstsein für den Funktionsumfang von AWS geschaffen. Zum einen bedeutete das einen hohen Lerneffekt, zum anderen jedoch auch kein einfacher Umstieg, da keine Erfahrungen im Team mit AWS vorhanden waren. 

Vorteile von AWS:

  • Skalierbarkeit: AWS bietet eine unübertroffene elastische Skalierbarkeit. Dies bedeutet, dass Splid in der Lage ist, Ressourcen automatisch je nach Bedarf hinzuzufügen oder zu entfernen. Für eine Anwendung wie Splid, die unterschiedliche Auslastungsspitzen erlebt, ist dies von entscheidender Bedeutung.
  • Zuverlässigkeit: AWS ist für seine erstklassige Zuverlässigkeit und Verfügbarkeit bekannt. Dies gewährleistet, dass Splid 24/7 zugänglich ist und minimale Ausfallzeiten verzeichnet.
  • Sicherheit: Die AWS-Plattform bietet eine umfangreiche Palette an Sicherheitsdiensten und -funktionen, die dazu beitragen, Daten und Anwendungen zu schützen. Die Sicherheit der Daten ist sehr wichtig und AWS bietet uns hierfür die notwendige Unterstützung.
  • Vielfalt an Services: AWS bietet eine beeindruckende Vielfalt an Diensten, die für Splid von großem Nutzen sind. Von AWS Lambda für Serverless-Computing über Amazon RDS für Datenbanken bis hin zu AWS Cognito für die Benutzerauthentifizierung – diese umfangreiche Palette ermöglicht es uns, eine leistungsstarke und vielseitige Plattform zu schaffen.

Vorteile Serverless-Ansatz:

  • Kosteneffizienz: Der Serverless-Ansatz ermöglicht es uns, nur für tatsächlich genutzte Ressourcen zu bezahlen. Dies senkt die Kosten im Vergleich zu traditionellen Server-basierten Ansätzen erheblich.
  • Skalierbarkeit: Mit AWS Lambda können wir unsere Funktionen unabhängig voneinander skalieren, was die Anwendung agiler und reaktionsschneller macht.
  • Entwicklungseffizienz: Obwohl der Einstieg in AWS und die Verwendung von Infrastruktur-as-Code (IaC) -Tools wie AWS CDK Zeit in Anspruch nahmen, führten diese Anstrengungen zu einem erheblichen Lerneffekt für das Team.
  • Automatische Skalierung: Der Serverless-Ansatz ermöglicht es Splid, automatisch auf Veränderungen in der Nutzung zu reagieren, ohne manuelle Intervention. Dies gewährleistet eine reibungslose Benutzererfahrung, unabhängig von der Anzahl der Benutzer. 

Nachteile:

  • Testen & Lokale Entwicklung: Das Testen und Debuggen von Serverless-Anwendungen kann eine Herausforderung darstellen, da es nicht einfach ist, die Serverumgebung ohne tatsächlichen Server zu replizieren. Dies kann zu Unsicherheiten bei der Performance und Funktionalität in der Produktionsumgebung führen. Dies bestätigt die Notwendigkeit umfassender Tests.
  • Debugging & Überwachung: Das Überwachen und Debuggen von serverlosen Anwendungen kann schwierig sein, da sie aus vielen einzelnen Funktionen bestehen, die zusammenarbeiten.
  • Performance: Als Entwickler muss man sich den Auswirkungen von “Cold Starts” bewusst sein, insbesondere wenn man zeitkritische Anwendungen entwickelt. Auch wir hatten einige Performance Probleme bei der Initialisierung der Lambda-Funktionen.
  • Anbieter-Lock-in Risiko: Man ist an den Anbieter gebunden.
  • Laufzeitbeschränkungen: Bei längeren Prozessen kann es zu Laufzeitbeschränkungen kommen.

2. IaC (Infrastructure as Code)

Wir haben uns bewusst gegen die AWS Web Console entschieden, da wir uns wegen dem Lerneffekt an IaC-Tool ausprobieren wollten.

Anfangs war IaC etwas herausfordernd, da man initial einen relativen hohen Zeitaufwand hat, da die Infrastruktur manuell und textbasiert erstellt werden muss. Das setzt zunächst auch eine größere Einarbeitung voraus.

Als IaC-Tool kamen zunächst Terraform und AWS CDK (Cloud Development Kit) in Frage. Wir haben uns dann aber für das AWS CDK entschieden. Die Hauptgründe dafür waren:

  • Integration mit AWS Services: AWS CDK bietet eine native Integration mit AWS-Services und -Ressourcen. Das bedeutet, dass man direkt auf AWS-Ressourcen zugreifen und diese in der Codebasis nutzen kann.
  • Flexiblere Entwicklung: Programmiersprache wählbar und nicht YAML.
  • Abstraktionsebenen: AWS CDK bietet Abstraktionsebenen, die die Definition von Ressourcen vereinfachen.

Architektur & Implementierung

AWS Services

1. RDS

Amazon RDS ist ein verwalteter Datenbankdienst der uns ermöglicht hat, unsere relationale Datenbank mühelos in der Cloud zu erstellen und zu verwalten. Vorteile von Amazon RDS sind unter anderem die vereinfachte Verwaltung, Skalierbarkeit und Sicherheit, sowie die Datenorganisation mit Schemas und komplexen Datenabfragen. Als Datenbankmanagementsystem haben wir PostgreSQL verwendet, da uns die Entwicklung damit schon vertraut war.

2. Lambda

AWS Lambda ist unser Serverless-Compute-Dienst, der die Geschäftslogik von Splid 2.0 ausführt. Hier werden Funktionen für das Hinzufügen von Ausgaben, das Verwalten von Zahlungen und die Berechnung von Abrechnungen implementiert. Da Lambda-Funktionen ereignisgetrieben sind, lassen sie sich gut mit Services wie API Gateway verbinden.

Auf dem Bild sieht man ein Beispiel einer Lambda-Funktion, die mit der Datenbank interagiert und die Gruppendetails zurückgibt.

3. API Gateway

Mit AWS API Gateway konnten wir die Lambda-Funktionen verwenden, um HTTP-Endpunkte für unsere APIs bereitzustellen. Wir verwenden das API Gateway also um RESTful APIs für die Kommunikation zwischen dem Frontend und dem Backend von Splid 2.0 bereitzustellen. Dies ermöglicht eine sichere und effiziente Datenübertragung.

Swagger ermöglichte es uns, die API in einem übersichtlichen und benutzerfreundlichen Format zu dokumentieren. Dank diesem Werkzeug konnten wir eine klare und umfassende Anleitung zur Nutzung unserer API bieten.

4. AWS Amplify

Um unserer Frontend zu deployen, verwenden wir den AWS Dienst Amplify. Ursprünglich wollten wir Amplify ebenfalls in den CDK-Stack mit einbinden, jedoch hatten wir Probleme mit der Kompabilität von CDK 2.0. und haben es deshalb über die AWS Web-Oberfläche umgesetzt, da es unteranderem auch sehr einfach über das UI bedienbar ist.

CI/CD & Testing

Die CI/CD Pipeline haben wir mit AWS Amplify und Github Actions umgesetzt. Dabei wird zunächst auf einen Development Branch gepusht, welcher dann automatisch Tests ausführt. Bei einem Pull-Request auf den Master Branch werden die neuen Änderungen automatisch deployed.

Beim Testen lag unser Schwerpunkt auf den grundlegenden Funktionen. Mit dem Jest-Tool haben wir die Unit- und Snapshot-Tests implementiert. Die CDK-Infrastruktur wurde mithilfe von Integrations-Tests überprüft. Die Basisfunktionen der Benutzeroberfläche wurden mit Cypress-End-to-End-Tests getestet.

Lessons Learned: Erkenntnisse bei der Entwicklung von Splid 2.0

1. Frühzeitige Architekturplanung: Wir haben festgestellt, dass eine frühzeitige Architekturplanung in der Welt des Cloud Computing entscheidend ist. Sie schafft die Grundlage für Stabilität, Skalierbarkeit und Kostenkontrolle. Außerdem gibt sie vor, wie die Infrastruktur am optimalsten aufgebaut werden soll.

2. Lokales Testen und Debuggen: Das lokale Entwicklung war zunächst eine große Herausforderung. Die Verwendung von AWS SAM (Serverless Application Model) für das lokale Testen und Debuggen war daher ein Game Changer. Es verkürzte die Entwicklungszyklen erheblich, da wir die Änderungen sofort überprüfen konnten.

3. Wahl der Tools je nach Anwendungsfall: Wir haben erkannt, dass es in einigen Fällen effizientere Technologien gibt, die den Entwicklungsprozess beschleunigen und Kosten sparen können. Gerade bei unserem eher kleineren Projekt ist das CDK vielleicht zu umfangreich/komplex und wir hätten daher für unseren Anwendungsfall auf zum Beispiel das Serverless-Framework setzen können. Die Wahl der richtigen Technologien sollte stets auf den spezifischen Anforderungen und Zielen basieren.

4. Kostenüberwachung und Ressourcenoptimierung: In der AWS-Cloud ist die Überwachung der Kosten und die Optimierung der Ressourcen entscheidend. Gerade bei Services wie Lambda können die kosten teilweise unvorhersehbar werden. Wir haben gelernt, den AWS-Kostennutzungsdienst und das Free-Tier effektiv zu nutzen, um unerwartete Kosten zu vermeiden. Die regelmäßige Überprüfung der Ressourcenauslastung half uns, effizienter zu arbeiten.

Ausblick: Die Zukunft von Splid 2.0

Für die Weiterentwicklung von Splid 2.0 haben wir uns noch weitere mögliche Funktionen und Integrationen überlegt, die im Rahmen der Vorlesung zeitlich nicht mehr möglich waren, man aber in Zukunft noch umsetzen könnte:

1. Integration von PayPal: Dies wird den Benutzern ermöglichen, Zahlungen noch einfacher und sicherer abzuwickeln. Mit einem einfachen Klick können Benutzer “Jetzt über PayPal abrechnen” auswählen und direkt zur PayPal-Plattform weitergeleitet werden.

2. Integrierte Chat-Funktion: Wir planen die Einführung eines integrierten Chat-Systems in Splid 2.0. Dies ermöglicht es Benutzern, in Echtzeit über Kosten zu kommunizieren, Fragen zu stellen und Klarstellungen vorzunehmen. Diese Funktion wird die Benutzerinteraktion und die Transparenz weiter verbessern.

3. Beleganhang zu Zahlungen: In Zukunft könnte Splid 2.0 die Möglichkeit bieten, Belege zu Zahlungen anzuhängen. Benutzer können Fotos oder Scans von Quittungen, Rechnungen und anderen relevanten Dokumenten direkt zu ihren Zahlungen hinzufügen. Dies macht die Nachverfolgung von Ausgaben noch einfacher und genauer.

4. Automatische Gruppenerstellung: Um die Benutzererfahrung weiter zu verbessern, planen wir die automatische Erstellung von Gruppen. Wenn Benutzer beispielsweise in Messaging-Apps wie WhatsApp eine Urlaubsgruppe haben, wird Splid 2.0 automatisch eine entsprechende Gruppe mit den gleichen Namen und Telefonnummern erstellen. Dies spart Zeit und minimiert den manuellen Aufwand.

Fazit

Insgesamt konnten wir, ausgehend von keinerlei Grundkenntnissen im Bereich Cloud Computing, uns mit Hilfe der Umsetzung des Projektes im Rahmen der Vorlesung einen Überblick und ein Grundverständnis für die Welt des Cloud Computings erarbeiten, welche eine solide Basis bietet um zukünftig die vorliegenden Ansätze noch wesentlich weiter zu vertiefen.


Posted

in

,

by

David Christoph Scheifers

Comments

Leave a Reply