Eigenes Backend vs. Backend as a Service

Während man in der Vergangenheit das Backend einer Anwendung meist eigens implementiert und auf einem dedizierten Server installiert hat, so geht der neueste Trend in Richtung „Backend as a Service“. Wo früher eigene Entwickler nötig waren, reichen nun wenige Klicks des Frontend-Entwicklers selbst, um einen fix fertigen Server zu haben, den man mittels bereitgestellter APIs oder einer automatisch generierten REST-Schnittstelle ansprechen kann. Solch ein „Backend as a Service“ erscheint im ersten Moment wie eine eierlegende Wollmilchsau, doch sind diese Backends wirklich so gut oder gibt es auch Nachteile bei diesen Services?

Ein BaaS (die Abkürzung steht für „Backend as a Service“) bringt viele Möglichkeiten. Man kann mit wenigen Klicks die Tabellen am Server anlegen und bearbeiten, muss sich nicht um die Datenbank Anbindung kümmern und hat sofort eine funktionierende Schnittstelle für seine Frontend-Anwendung. Man benötigt keinen Entwickler mehr für das Backend, keine zeitaufwendige Kommunikation zwischen Frontend- und Backend-Entwickler, keine Dokumentation der Server-Schnittstelle und man hat auch keine Probleme mit der Benutzung der Schnittstelle. Das spart Zeit und Geld. Möchte man die Daten aufbereiten, so kann man auch eigene Zugangspunkte am Server definieren und mit wenig Programmcode die gewünschten Daten abrufen.

Steigt die Last am Server, so skaliert dieser automatisch, man braucht sich um nichts kümmern, muss den Server nicht von Hand migrieren oder aufrüsten. Doch gerade hier verbergen sich die Kosten eines „Backend as a Service“. Während man die Services bei sehr kleinen Anwendungen sogar kostenlos nutzen kann, so steigen die Kosten mit der Anzahl der Anfragen pro Sekunde, mit jedem zusätzlich benötigten Gigabyte Festplatten- sowie Datenbankenspeicher und mit jedem Gigabyte Datentransfer. Bei einem dedizierten Server wusste man genau, wieviel Speicher man hat und wieviel Datentransfer inkludiert ist (oftmals unbegrenzt), das Gesamtpaket hatte einen fixen Preis, die Kosten waren einfach kalkulierbar. Nutzt man beispielsweise den Service Parse, so ist es bis zu 30 Anfragen pro Sekunde, 20 GB Festplattenspeicher, 20 GB Datenbankenspeicher und 2 TB Datentransfer kostenlos. Für jedes weitere Gigabyte Festplattenspeicher zahlt man 3 Cent, für weitere 20 Gigabyte Datenbankspeicher sogar $200, für jedes weitere Gigabyte Datentransfer 10 Cent und für jeweils 10 weitere Anfragen pro Sekunde stolze $100 pro Monat. Die eigentlichen Kosten kann man also sehr schwer berechnen, denn diese Werte hängen sehr stark von der Verbreitung und dem Inhalt der App, sowie vom Nutzerverhalten ab. Andere „Backend as a Service“ Anbieter haben wieder andere Arten der Abrechnung, ein Vergleich ist daher schwer möglich.

Eine weitere Schwachstelle von „Backend as a Service“-Diensten ist, dass man als Anwender keine Kontrolle darüber hat, wann und wie Datensicherungen durchgeführt werden. Alle Anbieter werben damit, dass die Daten in der „Cloud“ sicher gespeichert sind. Die tatsächliche Art der Datensicherung der einzelnen Anbieter findet man erst im Kleingedruckten. Parse speichert die Daten alle 30 Minuten und Konfigurationen alle drei Stunden. Bei Firebase findet man nur in einem Nebensatz der Dokumentation, dass Login-Daten einmal täglich gespeichert werden und Kinvey verschweigt auf der Webseite gänzlich, wann und wie die Daten gesichert werden. Auch eine Ausfallsicherheit ist oft nicht gegeben. Man hat im Grunde keinerlei Kontrolle über den Server, man weis nicht, was genau geschieht, wenn er ausfällt: Welche Daten werden gesichert? Wie schnell ist der Server wieder online? Man weiß auch nicht, wie sicher die Daten abgespeichert werden – vor allem wenn man mit sensiblen Nutzerdaten arbeitet, ist das ein kritischer Faktor.

Vor allem in Österreich ist auch der Standort der Server von entscheidender Rolle. Aus datenschutzrechtlichen Gründen ist beim Speichern von Benutzerdaten nämlich ein Server in der Europäischen Union empfehlenswert, doch das können einem die großen Anbieter wie Parse nicht garantieren. Die Daten liegen in der Cloud, der genaue Standort ist nicht definiert. Gründe wie dieser – und allein auch die aktuelle Beliebtheit von „Backend as a Service“-Providern – führen dazu, dass immer mehr kleine Anbieter auftauchen. Doch hier ist Vorsicht geboten, denn entscheidet man sich einmal für einen Anbieter, so ist man von diesem abhängig. Jeder Anbieter hat seine eigene Serverschnittstelle und native SDKs. Wird irgendwann ein Anbieterwechsel nötig, so reicht es nicht, die Server Adresse in der App zu ändern, beziehungsweise die Anfragen auf einen neuen Server umzuleiten, man kann keine Rückwärtskompatibilität gewährleisten. Und gerade durch die Übersättigung des Marktes mit „Backend as a Service“-Anbietern verschwinden einige davon recht schnell wieder von der Bildfläche – nicht nur kleine Anbieter, sondern auch große wie beispielsweise StackMob, die im Mai 2014 ihren „Backend as a Service“-Dienst stillgelegt haben, nachdem sie im Dezember 2013 von PayPal gekauft wurden.

Man darf nicht vergessen, dass „Backend as a Service“-Dienste neben den Nachteilen auch viele Vorteile aufweisen. Parse bietet beispielsweise auch gleich Statistiken zur Nutzung der Anwendung, (bis zu einer gewissen Anzahl) kostenlose Push-Benachrichtigungen sowie Social-Logins (Facebook, Twitter). Man sollte bei jeder Anwendung abwägen, welcher Weg beschritten werden soll. Denn welche Funktionen benötigt werden und wie Komplex das Backend am Ende sein wird, hängt stark von der Art und Anforderung der Anwendung ab. Man kann nicht grundsätzlich sagen, ob ein „Backend as a Service“ oder ein eigenes Backend auf einem dedizierten Server die bessere Wahl ist, beides hat seine Vor- und Nachteile. Man sollte jedenfalls bedenken, dass ein „Backend as a Service“ kein vollständiger Serverersatz ist. Wenn eine Anwendung und damit die Anforderungen an den Server wachsen, kann solch ein Dienst schnell an seine Grenzen stoßen. Wenn gewisse Sicherheitsrichtlinien eingehalten werden müssen oder eine Anbindung an ein Fremdsystem notwendig ist, dann entwickelt sich ein „Backend as a Service“ schnell zum Wegwerf-Produkt. „Backend as a Service“ Systeme eignen sich gerade für Startups sehr gut um die Time-to-Market extrem zu verringern und mit minimalen Investitionskosten schnell etwas auf die Beine zu stellen. Wenn ein Geschäftsmodell einschlägt und man es professionell aufziehen möchte, dann wird man früher oder später einen eigenen Server mit dezidierten Backend aufstellen müssen.