Abheben mit AWS und Webiny

Übers MVP hinaus

Ziel war es zusammen mit der Versicherungskammer Bayern, der S-Markt & Mehrwert sowie der Reha Assist , einen MVP als Mehrwertmodul im Pflegebereich zu entwickeln.

Der Internetauftritt als Teil des gesamten Projektes, wurde dabei von der OEV entworfen und umgesetzt. Die agile Arbeitsweise und die dadurch erst mit der Zeit sich manifestierenden Anforderungen verlangten größte technische Flexibilität. Es war erforderlich bereits in der Entwicklungsphase jederzeit schnell auf wechselnde Rahmenbedingungen reagieren zu können. Auch wenn es sich erstmal „nur“ um ein MVP handelt, war es uns von vornherein wichtig eine Architektur zu wählen, die auch nach dem MVP noch was taugt.

Die Cloud war gesetzt

„Wir wussten, dass sich Anforderungen jederzeit ändern können, dass das Frontend flexibel sein muss und der Content einfach veränderbar sein soll“, sagte Nico Schönnagel, unser Solution Architekt, der seit sechs Jahren mit seinem Team Anwendungen in der AWS Cloud designt und implementiert. Was nicht prognostiziert werden konnte, waren die Zugriffe auf die Seite und damit die benötigten Ressourcen. Aus diesen Gründen war sofort klar, dass nur eine Cloud-Lösung in Frage kommt.

Da „Server irgendwie auch von gestern sind“, sagt Nico Schönnagel, sollte auf eine serverless Architektur zurückgegriffen werden. Die AWS Cloud bietet hier diverse Möglichkeiten. Statische Inhalte sollten über den Objektstorage S3 abgebildet werden.

Das letzte große Element einer Anwendung ist die Datenbank, hier sollte auch eine her, die nicht aktiv gemanaged werden muss. Aurora als serverless SQL Datenbank oder DynamoDB standen dabei zur Auswahl.

Content Management System (CMS)

Die Überlegung war zunächst, eine Anwendung auf Basis der Architekturüberlegungen selbst zu entwickeln. Eine Angular oder React- Anwendung auf S3 für volle Flexibilität und im Backend eine Microservice Architektur mit nodejs. Für das Managen des Contents wäre eine eigene Lösung zum Tragen gekommen. Als Alternativen standen diverse CMS Systeme wie der Platzhirsch WordPress zur Disposition. WordPress ist jedoch nicht serverless und hat im Bereich der flexiblen Anpassung des Frontends einige Einschränkungen. Für den geforderten MVP war es damit nicht das Richtige. Eine weitere Alternative war Webiny. Webiny ist ein relativ neues CMS, was einerseits serverless und andererseits headless ist. Damit erfüllte dieses System genau die Anforderungen und gab dem Entwicklerteam die Möglichkeit, sich nicht auf den Nachbau eines CMS- Systems zu konzentrieren, sondern die Anforderungen für die Kunden umzusetzen.

Webiny

Webiny ist ein OpenSource Projekt für ein Headless CMS, das nativ und serverless in AWS arbeitet. Das System erfüllt damit genau die Anforderungen für eine moderne Architektur. Das CMS kommt mit Graph-QL-APIs, die zur Kommunikation mit dem Backend dienen. Das CMS setzt auf einer MongoDB auf, soll aber bis Ende des Jahres weitere Datenbanken wie DynamoDB unterstützen. Die Entwicklung im Frontend fand mit Angular statt, wobei dynamischer Content über GraphQL APIs abgerufen wurde. Der Vorteil dabei ist, dass Redakteurinnen nur noch den Content in Modellen pflegen muss. Das Design wird dabei wieder (anders als bei einem klassischen CMS) auf die Entwicklungsebene gebracht. Das ermöglicht einerseits mehr Dynamik bei der grafischen Gestaltung, anderseits eine schnellere Produktion von Content. Auf die Frage nach Herausforderungen bei einem solchen System antwortet Nicolas Kumnick (Frontend Engineer): “Der Preis für Geschwindigkeit und Vereinfachung in der Pflege ist, dass Redakteurinnen keine direkte Möglichkeit mehr hat Content durch CSS oder HTML Injection zu beeinflussen bzw. zu gestalten”. Es ist eine neue Art Content zu denken, die gleichzeitig eine enge Zusammenarbeit zwischen Entwicklerinnen und Designerinnen bedeutet.

A-B Tests

Was bei der Cloud-Lösung noch ein Vorteil ist. Moodle ist Open Source und frei nutzbar. Die Infrastruktur, d.h. die Cloud, muss natürlich bezahlt werden. Hier fallen jedoch nur Kosten an, wenn auch wirklich eine Nutzung besteht. Damit sind Nachts und in den Ferien die Kosten sehr gering und zwischen 08:00 Uhr und 12:00 Uhr die Kosten höher, dafür stehen dann aber auch bei Bedarf mehrere Hochleistungsrechner zur Verfügung.

Anpassungen und Performance-Boost um 300 %

Im Wesentlichen setzt unser Team auf Standards bei der Entwicklung: AWS, Webiny und Angular im Frontend. Ein paar kleine Anpassungen mussten trotzdem vorgenommen werden, so nutzen wir beispielsweise bis zum Release der Unterstützung von DynamoDB, eine MongoDB auf einer EC2- Instanz. Hintergrund war hier, dass nicht die native Atlas-DB außerhalb von AWS genutzt werden sollte und eine native Document-DB als managed Service in AWS relativ teuer ist.

Weiterhin haben wir etwas an der Performanceschraube gedreht. Grundsätzlich werden alle dynamischen Inhalte über die Datenbank abgefragt. Bei einem CMS sind die dynamischen Inhalte jedoch größtenteils sehr langlebig, so dass nicht jede Abfrage des Contentmodells direkt wieder auf die Datenbank gehen muss. Das Standardcaching mit Cloudfront brachte keine spürbaren Effekte, da es sich bei den Graph-QL Requests um POST-Requests handelte. Über ein paar Anpassungen und das API-Caching konnten wir das Problem lösen und einen enormen Performace-Boost (300%) erreichen.