Abheben mit AWS und Webiny

Abheben mit AWS und Webiny

Allgemein, Content Management, OEV digital campus 360, Webiny 19. November 2020

Ü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.

Das Projekt

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.

S3 in Verbindung mit CloudFront bietet unbegrenzten Storage und Performance. Ebenfalls ist eine Versionierung der Inhalte sowie Verschlüsselung möglich. Anstelle eines Apache- Webservers, kann über diesen Service ziemlich einfach ein Endpunkt definiert werden. CloudFront bildet dabei das notwendige Caching ab, so dass unabhängig der Nutzeranzahl performant auf die Anwendung zugegriffen werden kann.

Lambda Services bieten die Möglichkeit, Quellcode in Python, nodeJS, Java etc. ohne die Notwendigkeit eines Application- Servers zu implementieren. Auf diese Weise können sich Entwickler*innen um die Entwicklung kümmern ohne, die Notwendigkeit, Server- Infrastrukturen managen und verstehen zu müssen. Das API- Gateway ist dabei die Schnittstelle aus dem Netz. Es erlaubt, die Fachlogik von der Schnittstelle zu trennen und bietet nochmal Möglichkeiten, Requests zu cachen.

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.

Ein Kopfloses CMS bedeutet im Wesentlichen, dass die kompletten Mehrwerte eines CMS vorhanden sind, d.h. Versionierung, Redaktions- Backend, etc., jedoch die GUI Repräsentation fehlt. Anstelle dessen bietet das System Schnittstellen und Contentmodelle, die bedient werden müssen. Der Vorteil ist, dass im Frontend mit React, Gatsby, Vue o.ä. Frameworks gearbeitet werden können Redakteur*innen nur noch definierte Contentmodelle füllt. Diese Modelle müssen jedoch nicht nur im Webauftritt genutzt werden, sondern können vielmehr auch für eine weitere Verteilung Bspw. in Apps oder Social Media verwendet werden.

Serverless bedeutet: ohne Server. Dabei geht es natürlich im Hintergrund nicht wirklich ohne Blech, allerdings ist das über mehrere Abstraktionsschichten gekapselt. Entwickler*innen brauchen sich nur um die eigentliche Implementierung vom Quellcode oder der Datenbank zu kümmern, die zugrunde liegende Server-Infrastruktur sorgt dabei selbst für Themen wie Skalierung, Performance oder im Beispiel der Datenbank für Replikation.

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 Redakteur*innen 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 Redakteur*innen 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 Entwickler*innen und Designer*innen bedeutet. 

In der folgenden Abbildung wird die Verbindung zwischen Content und Modell aufgezeigt. Ein Element der Seite wird in der Mitte dargestellt. Der dazugehörige Content kommt aus den definierten Modellen, die oben bzw. unten abgebildet sind. Am Beispiel der Testimonial lässt sich erkennen, dass relativ einfach neue Elemente hinzugefügt werden können. Die Live-Seite ist auch unter www.s-pflegepartner.de zu finden. 

Webiny Content-Modell

A-B Tests

Die Content-Modelle ermöglichen auch ein relativ einfaches automatisiertes A-B-Testing. Hierbei können zwei oder mehr Modelle parallel erstellt werden, die dann unterschiedlich ausgespielt werden. Damit kann die UX einer Webseite parallel ausgetestet werden. Noch besser ist, dass es gar nicht notwendig ist, sich für eine Variante (A, B oder C) zu entscheiden, sondern dass das System anhand von definierten KPIs allein entscheiden kann, welches Contentmodell gerade am besten passt und es ausspielt. Das könnte sich im Laufe der Zeit sogar ändern.

Webiny A-B Test

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.

Fazit

Auch wenn es erstmal nur darum geht, einen kleinen MVP zu entwerfen, bietet es sich an, größer zu denken. Im Beispiel von www.s-pflegepartner.de wurde ein MVP entwickelt, dessen Architektur mit dem Einsatz von Function as a Service (FaaS),  über den MVP hinaus gedacht ist.

Referent

Nico Schönnagel

Nico Schönnagel

Nico Schönnagel leitet bei der OEV Online Dienste GmbH den OEV digital campus 360. nschoennagel@oev.de

    Name

    E-Mail-Adresse*

    Ihre Nachricht

    Multi-Accounts Umgebu… 3. September 2020 AWS Infrastruktur moodle aws Moodle: Skalierbar in… 7. Januar 2021