Das nahtlose Zusammenspiel zwischen Apps und einem App-Backend sicherzustellen ist ein zentrales Ziel von Mobile Backend as a Service (MBaaS). Erst durch eine einfache, schnelle und sichere Integration des App-Backends mit Public- oder Private-Clouds, mit proprietären Unternehmenslösungen oder mit in die Jahre gekommenen Legacy-Systemen können die meisten Mobile-Apps einen wahren Mehrwert bieten.

Die Nachfrage nach der Modernisierung alter Anwendungen und für das Erstellen neuer mobiler Anwendungen (Apps) steigt exponentiell. Denn für viele Nutzer sind mobile Anwendungen die präferierte und erwartete Zugriffsmöglichkeit auf Daten und Informationen – es ist das „New Normal“. In diesem Rausch müssen Entwickler mit limitierenden Werkzeugen, Technologien und verkürzten Entwicklungszyklen schnell reagieren können und höchst produktiv sein, um überhaupt eine Chance zu haben, den wachsenden und sich rasch ändernden Anforderungen gerecht zu werden.

Entwickler, deren Hauptaufgabe darin liegen sollte, herausragende App-Frontends und eine flüssige User Experience zu realisieren, investieren den größten Teil ihrer Zeit damit, die Integration mit dem Backend zu implementieren. Verstärkt wird das Problem noch dadurch, dass dieselbe Lösung oft auf verschiedenen Plattformen wie iOS, Android und vielleicht auch noch Windows laufen soll. Es werden mehrfach, teilweise von verschiedenen Entwicklern, die gleichen Integrationsfragestellungen gelöst. Dabei besteht die Gefahr, dass Themen wie Sicherheit, Qualität und funktionale Aspekte darunter leiden. Die klassische Unternehmens-IT, die nicht auf die neuen Anforderungen hinsichtlich Flexibilität und schneller Anpassbarkeit vorbereitet war, leidet darunter, dass Fachbereiche notgedrungen in U-Boot-Projekten und mit einer Schatten-IT eigene Lösungen bauen, um nicht bei der Time-to-Market ins Hintertreffen zu geraten. Richtlinien und Anforderungen aus der offiziellen IT bleiben dabei auch gerne mal auf der Strecke, was zu noch komplexeren und teilweise nicht wartbaren und nicht unterstützten oder gar unsicheren Systemen führt. Besonders problematisch wird es dann, wenn sie auch noch wichtige Kernprozesse des Unternehmens abbilden.

Diese offensichtlichen Ineffizienzen kann nur durch die Zusammenarbeit unterschiedlicher Stakeholder ausgeräumt werden. Tabelle 1 gibt einen Überblick über die beteiligten Stakeholder und ihre teilweise konkurrierenden Anforderungen. Die dort aufgelisteten Punkte können nicht für jede neue Entwicklung oder jedes neue Vorhaben frisch adressiert werden. Man benötigt eine Plattform (Mobile Enterprise Application Platform, kurz MEAP). Für die Einführung einer MEAP sprechen insbesondere folgende Kriterien:

Mehrere Apps
Unterschiedliche Entwicklungsansätze für Mobile
Hohe Fragmentierung (Plattformen, Endgeräte)
Diverse Backend-Systeme (nicht dediziert für Mobile)
Viele Entwickler
Parallele Bereitstellung unterschiedlicher Versionen

Stakeholder	Wichtige Anforderungen und Bedürfnisse
CIO	– Nachhaltige Innovationen – Datensicherheit und Datenschutz – Verwaltung und Einhaltung von Unternehmensrichtlinien – Beherrschung von „Mobiler Komplexität“ – Geringere TCO – Offene Technologie/einheitliche Architektur/Standards – Wiederverwendung bestehender Assets – Teamzusammenarbeit auch bereichsübergreifend
Fachbereich	– Time-to-Market – Möglichkeit und Fähigkeit für Innovation – Schnelle Verifikation von Ideen – User Experience – Reaktionsfähigkeit (schnelle Updates) – Einsichten in Nutzerverhalten – Wettbewerbsvorteile
IT-Betrieb	– Sicherheit auf Unternehmenslevel – Zentrale Verwaltung und Steuerung von – Sicherheit auf Unternehmenslevel – Zentrale Verwaltung und Steuerung von Sicherheits-, Integrations- und Compliance-Aspekten – Einfache Integrationsfähigkeit – Reife und marktrelevante Technologien – SLA und Support für eingesetzte Technologien – Einbettung in bestehende Werkzeugkette
Softwareentwicklung	– Agilität und Flexibilität – State-of-the-art-Technologien – Kurze „Turnaround Zeiten“ bei der Entwicklung – Einfache Zusammenarbeit im Team – Einfache Integrierbarkeit – Einheitliche Architektur/Standards
Nutzer	– Einfache, intuitive, zeitgemäße Bedienung – Performance – Funktionalität – Hohe Qualität und schnelle Fixes/Updates – Konnektivität und Integrationsfähigkeit mit anderen Apps

Tabelle 1: Die beteiligten Stakeholder haben im Kontext Enterprise Mobility teilweise konkurrierende Anforderungen

MBaaS? Was ist das?

Die Begriffe MEAP und MBaaS (Mobile Backend as a Service) werden oft vermischt und sind nicht 100 Prozent voneinander abgegrenzt. Die Unterscheidung liegt für uns insbesondere bei der Berücksichtigung von Cloud-Aspekten. Während MEAP schon ein etwas älterer Begriff ist, der auch der traditionellen Enterprise-Entwicklung entstammt, sind MBaaS von Anfang an auf Skalierbarkeit, Containerisierung und Self-Service-Aspekten ausgerichtet.

MBaaS unterstützt aus unserer Sicht einen agile Ansatz, um Unternehmens-Apps zu entwickeln, zu deployen und zu integrieren. Dabei spielt es keine Rolle, ob es sich um native, hybride oder mobile Web-Apps handelt. Ein MBaaS stellt Steuerungs- und Kontrollmöglichkeiten von Sicherheitsaspekten und Unternehmensrichtlinien bei der Integration mit Unternehmenssystemen bereit. Deployments werden idealerweise auf Public-, Private- und Hybrid-Clouds ermöglicht.

Do it yourself!

Einige der bereits genannten Anforderungen lassen sich recht elegant mit modernen Open-Source-Werkzeugen und -Technologien selbst umsetzen. Dies bietet sich insbesondere dann an, wenn nur wenige Apps mit einem kleinen Entwicklerkreis, der diese Technologien kennt, entwickelt werden soll. Dabei bieten sich oftmals folgenden Bausteine an:

SSL-Offloading, Load Balancing und Bereitstellung von statischen Inhalten: nginx
Identity- und Access-Management (z. B. LDAP, OAuth2): Keycloak
API-Gateway und Integrationspunkt für Apps (hoch skalierbar, für kurzlaufende Prozesse): Node.js, Vert.x oder Akka
Plattformübergreifende Push Notifications: AeroGear UnifiedPush Server
Cache (verteilt): Redis, Infinispan
Persistenz (NoSQL/relational): MongoDB oder PostgreSQL
Containerisierung, Deployment: Docker
Typischerweise kommen noch weitere Elemente wie Analytics, Crash Logging und App-Verteilung (Private/Enterprise Stores) hinzu. Diese Anforderungen lassen sich mit SaaS-Angeboten wie Google Analytics, HockeyApp und Crashlytics gut abdecken. Der gesamte Stack kann sowohl On-Premise als auch auf PaaS-Lösungen wie OpenShift oder Amazon AWS betrieben werden. Dadurch sind auch komplexe Skalierungsanforderungen im produktiven Einsatz möglich.

Zu beachten ist, dass ein solcher Do-it-yourself-MBaaS nicht darauf ausgelegt ist, langlaufende Prozesse oder Fachlogik abzubilden, sondern nur eine einfache und optimierte Integration von mobilen Endgeräten gewährleisten und spezielle Anforderungen wie Offlineverfügbarkeit, Übertragungseffizienz und Toleranz hinsichtlich instabiler Netzwerkverbindungen umsetzen soll. Für eine Integration in die Unternehmens-IT empfehlen sich weiterhin etablierte Mechanismen wie ein Enterprise Service Bus – oft vorhanden – oder ein Message Broker.

Bei dem skizzierten Technologiestack gibt es jedoch auch Nachteile. Das erforderliche Know-how für die einzelnen Komponenten und das reibungslose Zusammenspiel derselben ist umfangreich und einem stetigen Wandel unterzogen. Im Fehlerfall sind verantwortliche Bausteine nicht immer einfach zu identifizieren. Die Komplexität des Gesamtsystems erfordert daher eine hohe Leidenschaft des Entwicklungsteams. Daher lohnt sich der Blick auf Alternativen, die einen Großteil der Komplexität in einem Produkt bündeln und dadurch einfacher zu beherrschen sind.

MBaaS: Red Hat Mobile Application Platform

Die Red Hat Mobile Application Platform (RHMAP) nutzt viele Basistechnologien, die auch in einer Do-it-yourself-Lösung verwendet werden. Im Kern basiert RHMAP auf Best-of-Breed- und Open-Source-Technologien. Das Zusammenspiel der Bausteine durchläuft eine umfangreiche Qualitätssicherung, und Red Hat bietet für den professionellen Einsatz unterschiedliche SLAs. Zusätzlich sind noch viele weiterer Dienste vorhanden. Insbesondere die Administration und Strukturierung von Mobile-Projekten ist einfacher (Abb. 1 und 2). Abbildung 2 verdeutlicht den grundsätzlichen Aufbau eines Projekts in der RHMAP.

Abb. 1: Das RHMAP-Dashboard zeigt gebündelt die verschiedenen Funktionen der Plattform

Abb. 2: Die Projektansicht in RHMAP ist klar gegliedert und übersichtlich

Mit der Plattform lassen sich verschiedene Apps konfigurieren. Die Cloud-Apps (Node.js) stellen Integrationsschnittstellen der Apps mit Backend-Diensten zur Verfügung. Diese Cloud-Apps enthalten typische Aufbereitungen und Optimierungen für mobile Clients. Die MBaaS-Services (Node.js) sind Integrationskomponenten, die in verschiedenen Projekten wiederverwendet werden können. Jede Komponente ist in einem eigenen Git Repository abgebildet. Neben der grafischen Oberfläche (Browser) gibt es auch ein Command-Line-Tool (FHC) mit dem vollen Funktionsumfang. Hiermit ist eine Integration in bestehende Entwicklungsprozesse und Praktiken einfach zu realisieren.

Die Hauptbestandteile der RHMAP lassen sich in sechs Unterpunkte gliedern: Collaboration, Bring-your-own-Tools, Backend-Integration, Security und Authentifizierung, Codeless Development und Cloud und On-Premise Deployment:

Zum Thema Collaboration unterstützt die Plattform verteilte Teams und Teamrollen. Sie bietet Mobile-Application-Lifecycle-Management und einen Git-basierten Workflow für die Entwicklung.
Unter dem Motto Bring-your-own-Tools unterstützt die Plattform native SDKs (iOS, Android, Windows Phone), Apache Cordova, HTML5 und Appcelerator sowie Xamarin, Sencha, Ionic, Backbone.js, AngularJS und Ember.js. Lokale Entwicklung sowie Entwicklung im gehosteten Service (Cloud) ist möglich; die Nutzung des eigenen Build-Systems oder Verwendung der integrierten Cloud-basierten Build-Farm ebenso.
Für die einfache, leichtgewichtige, sichere und skalierbare Integration von Backend-Systemen auf Basis von Node.js mit Bereitstellung von Diensten wie Data Storage, Data Management, Notifications und Analytics gibt es wiederverwendbare Microservices und APIs. Die bidirektionale Datensynchronisierung erfolgt mit dem Data Sync Framework für Offlinefunktionalität.
Zum Thema Sicherheit ist eine optionale Verschlüsselung von lokal gecachten Daten mit HTTPS möglich. Die Plattform unterstützt Unternehmensrichtlinien für die Integration von Backend-Systemen mittels VPN und DMZ sowie eine Nutzerauthentifizierung und -authorisierung.
Für Codeless Development gibt es Drag-and-Drop-Formulargenerierung, erweiterbare Templates und Beispiele.
Bei Cloud und On-Premise Deployment hilft die Cloud-agnostische Architektur für unterschiedliche Deployment-Szenarien wie öffentliche, mandantenfähige Clouds (AWS, Rackspace, HP Cloud), private, dedizierte und managed Clouds und hybride Clouds (Anwendungs- und Integrationscode in unterschiedlichen Clouds).

Abbildung 3 gibt einen Überblick über die Hauptbestandteile der RHMAP.

Abb. 3: Die Hauptbestandteile einer RHMAP in der Übersicht

Die RHMAP basiert mit FeedHenry auf einer etablierten MEAP und hat in vielen Projekten ihre Praxistauglichkeit bewiesen. FeedHenry war jedoch eine reine SaaS-Lösung, und erst mit der Akquisition durch Red Hat wird ein On-Premise-Modell unterstützt. Im Gegensatz zu anderen Red-Hat-Produkten gibt es zum heutigen Stand noch kein Community-Upstream-(Open-Source-)Projekt. Aktuell wird daran gearbeitet, offene rechtliche Themen bezüglich der ursprünglich in FeedHenry verwendeten Komponenten abzuarbeiten, daher gibt es derzeit keine öffentlich verfügbaren Zeitpläne für eine Open-Source-Version. Mit FeedHenry steht jedoch schon der Name des Upstreamprojekts fest.

Für uns ist die RHMAP eine gute Alternative zu den bisherigen Do-it-yourself-Ansätzen. Im Vergleich zu Wettbewerbern macht die RHMAP einen sehr reifen und kompletteren Eindruck, der sich hoffentlich mit den nächsten Versionen weiter festigt.