Mobile Backend as a Service beschleunigt Entwicklung und Integration

MBaaS mit RHMAP
Kommentare

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.

Es ist also an der Zeit, sich mit dem Thema Mobile Backend as a Service – kurz MBaaS – zu beschäftigen. Zunächst aber sollten wir einen Blick auf die Ausgangssituation werfen: 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 – ein Bereich, in dem eine große Nachfrage auf dem Arbeitsmarkt zu spüren ist. 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.

Stakeholder Wichtige Anforderungen und Bedürfnisse
CIO – Nachhaltige Innovation
– 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
– Wettbewerbsvorteil
IT-Betrieb – 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
Die beteiligten Stakeholder haben im Kontext Enterprise Mobility teilweise konkurrierende Anforderungen

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

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; auf der MobileTech Conference werden wir uns damit ausführlich in MBaaS – Mobile Backend as a Service in der Praxis beschäftigen. 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.

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.

MBaaS – Die Hauptbestandteile einer RHMAP in der Übersicht

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.

tl;dr

Die digitale Transformation und Mobile-First-Strategien sorgen für eine wachsende Komplexität mobiler Lösungen. Um diese in ihrer Gesamtheit zu beherrschen und darauf aufbauend neue Innovationen agil zu ermöglichen, ist der Einsatz einer Mobile Enterprise Application Plattform notwendig. Das wird sich in Zukunft durch die weitere Verschmelzung von IoT und Mobile und der dadurch resultierenden exponentiellen Anzahl möglicher Clients zunehmend verstärken.

Eine MEAP kann durch eigenen Lösungen – basierend auf offenen Standards und Open-Source-Software – realisiert werden. Für umfangreiche Unternehmensanforderungen kann der Einsatz eines MBaaS-Produkts sinnvoll sein und einen schnellen Mehrwert bieten. Die Red Hat Mobile Application Platform ist hierfür ein vielversprechender Kandidat, den es sich näher zu betrachten lohnt.

Aufmacherbild: Network von Shutterstock / Urheberrecht: Rachael Arnott

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -