Dieser Beitrag ist älter als drei Jahre. Es könnte also sein, dass auch der Inhalt - zumindest in Teilen - bereits veraltet ist.

Mit dem Luftschiff in die Wolke (Gastbeitrag von Christopher Supnig)

Als wir im Jahr 2015 mit der Entwicklung von appointmed der Praxissoftware für Physiotherapeuten begonnen hatten haben wir im Backend auf Java-basierte Microservices gesetzt. Wir hatten 3 Server im Rechenzentrum eines Bekannten angemietet, die wir selbst warten konnten. Das funktionierte anfangs sehr gut. Wir hatten gleich von Beginn an drei gutgesinnte Testkunden, die das Programm begleitet haben. Auf einem der Server lief unser Produktivsystem, auf einem unser Testsystem und auf dem letzten unser Entwicklungssystem und ein Buildserver, der es uns ermöglichte neue Versionen direkt auf die einzelnen Umgebungen auszuliefern.

Das hört sich doch eigentlich sehr gut an, nicht?
Dieses Luftschiff wollte jedoch nicht so recht abheben. Wie man sich schon denken kann, erzeugen drei Kunden nicht gerade eine übermäßige Last auf dem System und als wir mehrere Kunden dazu bekamen und die Requests mehr wurden, hatten wir immer mal wieder Probleme mit Systemupdates und einzelne Services, die in manchen Situationen nicht genügend Speicher bekamen.
Uns war klar, dass wir unsere Architektur überarbeiten mussten und da wir auch langfristig aus dem kleinen Rechenzentrum in Wien ausziehen wollten, haben wir uns nach Alternativen umgesehen. Bernhard, unser Backendspezialist, ist zu dieser Zeit auf die AWS Re:Invent nach Las Vegas geflogen und hat einige interessante Konzepte mitgebracht. Für mich war der Begriff “Serverless” damals noch sehr neu. Serverless bedeutet eine Applikation auf einer Infrastruktur laufen zu haben, ohne auf die darunterlegenden Server bzw. Container Rücksicht nehmen zu müssen.

Auf in die Wolke

Nach einigen Überlegungen sind wir dann zu dem Schluss gekommen, dass eine Migration in die AWS Cloud für uns am besten ist. Der Einfachheit halber hatten wir einfach unsere Microservices auf EC2 Instanzen gestartet und diese miteinander verbunden. Wie ihr euch vorstellen könnt, bedeutete das einiges an Kosten und wir hatten wieder “Server” um die wir uns kümmern mussten. Zwar waren diese einfacher zu verwalten, da die Updates größtenteils automatisch durchgeführt wurden, doch so ganz glücklich waren wir damit noch nicht.

Lambda to the rescue

Wir haben uns immer mehr in die AWS Infrastruktur eingelesen und sind auf den Lambda-Service gestoßen. Dieser ermöglicht es Funktionen direkt auszuführen, ohne diese auf einem bestimmten Server installiert zu haben. Diese Funktionen können auf unzählige Methoden angesprochen bzw. angestoßen werden. Die für uns wichtigsten sind REST-Requests, Events, Zeitgesteuert und durch E-Mails. AWS erlaubt es diese Funktionen in unterschiedlichen Programmiersprachen zu erstellen, was sehr angenehm ist. Aufgrund der Gewschwindigkeits- und Speichervorteile haben wir uns für NodeJS entschieden.
Einen der ersten Services, die wir auf so eine Funktion umgestellt hatten, war unser Terminerinnerungsservice. Dieser prüft zeitgesteuert, welche Termine anstehen und informiert die Patienten entweder per SMS oder per E-Mail darüber. Alleine durch diese Umstellung konnten wir knapp €50,— von unserer monatlichen Infrastrukturrechnung streichen.

Aufgrund der guten Erfahrungen mit AWS Lambda sind wir nun dabei alle restlichen Services umzustellen bis wir hoffentlich bald wirklich “Serverless” in der Wolke unterwegs sind.

Christopher Supnig ist Webentwickler und Co-Founder von appointmed. Wenn Sie mehr Erfahren möchten, besuchen Sie ihn auf https://www.supnig.com