© Excellent backgrounds/Shutterstock.com
Backend as a Service

Backend-Plattform für mobile Applikationen


Mit dem Begriff „Backend as a Service“ (BaaS) stellt sich das Open-Source-Projekt Usergrid der Apache Software Foundation vor [1]. Hinter diesem Marketingbegriff verbirgt sich das Konzept für eine Backend-Plattform, die geeignet ist, eine Vielzahl von Applikationen für mobile Geräte und Rich Clients zu realisieren. Das Projekt basiert auf der NoSQL-Datenbank Cassandra [2], einer Applikationsschicht und SDKs für Cliententwickler unterschiedlicher Plattformen.

Mit Usergrid soll die Entwicklung von Backends für mobile Applikationen so einfach wie die Entwicklung von Webapplikationen mit dem LAMP Stack sein [1]. Um dieses Ziel erfüllen zu können, bietet Usergrid beispielsweise ein Rollen- und Rechtekonzept sowie Funktionen zur Benutzerverwaltung. Hierzu zählen u. a. das Anlegen von Benutzern, Log-in und Passwortänderungen. Notwendig sind außerdem SDKs für verschiedene Zielgruppen. Das Spektrum reicht von Android über HTML/JS bis Ruby on Rails.

Die Idee hinter BaaS ist nicht neu. Schon seit einigen Jahren findet man im Markt verschiedene Full-Stack-Cloud-Systeme, die intern oder extern als Dienst verwendet werden. Typischerweise werden sie als Backend für mobile Applikationen eingesetzt. Zu nennen sind vor allem Parse von Facebook, StackMob von PayPal, Firebase von Google und Kinvey.

Warum würde man trotzdem ein eigenes BaaS wie Usergrid einsetzen wollen? Ein offensichtlicher Vorteil ist die Vermeidung eines Vendor-Lock-ins, denn ein Anbieterwechsel ist mit enormen Kosten verbunden. Auf sich verändernde Anforderungen kann wahrscheinlich leichter reagiert werden, wenn man das Backend selbst betreibt und Kontrolle über dessen Implementierung hat. Aus diesem Grund kann auch die Integration von Legacy-Systemen mit dem eigenen BaaS einfacher sein. Ein weiterer wichtiger Vorteil für den Einsatz eines eigenen BaaS ist der Datenschutz, denn bei einem externen Backend laufen alle Kundendaten durch die Infrastruktur des Anbieters.

Um das Open-Source-Projekt besser verstehen und einordnen zu können, sollen in diesem Artikel zwei wesentliche Themenkomplexe betrachtet werden:

  • Wie ist Usergrid aufgebaut, und welche Architektur liegt zugrunde?

  • Welche Funktionen bietet Usergrid, und wie können sie verwendet werden?

Bevor diese Fragen beantwortet werden, sei noch darauf hingewiesen, dass sich Apache Usergrid derzeit im Inkubationsstadium befindet. In dieser Zeit wird die Codebasis an die Apache-Konventionen angepasst. Das Inkubationsstadium dient außerdem dem Aufbau einer ausreichend großen und stabilen Community. Usergrid ist seit 2011 Open Source und wurde in mehreren großen Installationen bei Korea Telecom, Globo, Apigee und anderen Unternehmen der Fortune Global 500 produktiv eingesetzt [1].

Systemaufbau

Usergrid wurde in Java geschrieben und nutzt Standardkomponenten wie den HTTP-Servlet-Server des Grizzly-Projekts [3]. Dieser leichtgewichtige Server kann eingebettet gestartet werden und ist zur Umsetzung des Web-API auf Basis von JAX-RS geeignet. Alternativ kann Usergrid auch in Apache Tomcat deployt werden. Das Web-API von Usergrid spricht JSON, das mit der Bibliothek Jackson verarbeitet wird. Es ist möglich, über die JSON-Daten Volltextsuchen durchzuführen. Die Suchfunktionen wurden durch die Integration von Elasticsearch implementiert. Die Index Shards von Elasticsearch werden in Cassandra, einem skalierbaren Wide Column Store, gespeichert. Die wichtigsten technischen Komponenten zeigt Abbildung 1 im Überblick.

spichale_usergrid_1.tif_fmt1.jpgAbb. 1: Systemaufbau Usergrid

Als Persistenzlösung für diese semistrukturierten Daten eignen sich vor allem NoSQL-Datenbanken. Obwohl die JSON-Dokumente optimal in einer dokumentenorientierten Datenbank wie MongoDB gespeichert werden könnten, fiel die Wahl auf Cassandra. Der ausschlaggebende Grund für diese Architekturentscheidung war die Skalierbarkeit dieser Open-Source-Alternative. Zwar unterstützt auch MongoDB Sharding für Performanceverbesserungen und Replikation für Ausfallsicherheit, aber die Datenbank soll nicht eine Applikation, sondern potenziell tausende unterstützen können. Cassandra bietet Shard­ing auf Basis eines Distributed Hash Tables, mit dem Datensätze anhand ihrer Schlüssel einzelnen Knoten im Cassandra-Cluster zugeordnet werden. Die Knoten sind aus diesem Grund in einer Ringtopologie angeordnet. Cassandra stellt Ausfallsicherheit durch Datenredundanz sicher, sodass der Ausfall einiger Replikate mit den verbliebenen kompensiert werden kann. Die Möglichkeit, Cassandra dynamisch durch Hinzufügen bzw. Entfernen von Cassandra-Knoten anzupassen, ist ideal für die Anforderungen von Usergrid.

Intern verwendet Usergrid Hector als Datenbankclient. Die Schreib- und Leseoperationen werden an einen oder mehrere Cassandra-Knoten weitergeleitet. Diese Knoten fungieren für die Bearbeitung der Operation als Koordinator und senden weitere Nachrichten innerhalb des Cassandra-Clusters zur Abwicklung der verteilten Operation.

Mehrmandantenfähigkeit ist eine wichtige Anforderung an die Datenbank. Denn die Plattform soll geeignet sein für mehrere Entwicklerteams, die etliche Applikationen haben, und die Applikationen haben wiederum eine Vielzahl an Benutzern. Da alle Applikationen auf der Usergrid-Plattform eine gemeinsame Datenbank verwend...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang