Mobile Apps für bestehende Enterprise-Anwendungen
Mobile Apps sind im Enterprise angekommen. Firmen stehen mehr und mehr vor der Herausforderung, Teile ihrer Anwendungslandschaft auf Smartphones und Tablets verfügbar zu machen. Üblicherweise muss dabei nicht die vollständige Funktionalität bereitgestellt werden, sondern "nur" ausgewählte Geschäftsprozesse in vereinfachter Form. Eine wichtige Aufgabe in diesem Zusammenhang ist die Definition der Schnittstelle, die die zukünftige App verwenden wird.
Den Aufwand hierfür sollte man nicht auf die leichte Schulter nehmen, denn viele unternehmenskritische Eigenentwicklungen sind seit 15 Jahren oder länger in Produktion. Die von ihnen exponierten "Services" (eher: Remoting-Schnittstellen) sind praktisch immer auf die in Produktion befindliche Präsentationsschicht ausgelegt, bilden komplexe Objektgeflechte ab oder nutzen binäre Übertragungsprotokolle. Oft alles zusammen. Unglücklicherweise muss man zudem davon ausgehen, dass solche verteilten Anwendungen nicht besonders gut abgesichert sind. Schließlich wurden sie für den Einsatz im abgeschotteten Intranet entwickelt. Daran, dass man auf ihre Funktionalität aus dem notorisch unsicheren Internet zugreifen könnte, hat vermutlich niemand gedacht. Und falls doch, wären korrespondierende Kosten schnell dem Rotstift zum Opfer gefallen. Wie also gestaltet man eine moderne, zukunftssichere Schnittstelle, über die Apps sicher und zuverlässig auf Unternehmensanwendungen bzw. deren Daten zugreifen können?
Architektur sicherer und zuverlässiger Zugriffsschichten
Da mit zunehmendem Alter die Aufwände für Wartung und Weiterentwicklung von Software exponentiell steigen, steht ohnehin oft ein schrittweiser Austausch ihrer Komponenten in der IT-Strategie von Unternehmen. In so einem Fall lohnt es sich, den Umstieg auf Microservices bzw. Selfcontained Systems zu prüfen. Dadurch könnten die Module einer Anwendung von praktisch beliebigen Frontends angesprochen werden – neben der Weboberfläche für das Intranet also auch von mobilen Apps. Ob Microservices für das Unternehmen eine geeignete Umsetzungsform sind, muss allerdings sorgfältig untersucht werden. Hierzu gehört unter anderem die Beantwortung der folgenden Fragen:
- Passt der "Wenige-Services-pro-Team"-Gedanke zu den Strukturen der Organisation?
- Wurden schon die infrastrukturellen und betrieblichen Voraussetzungen geschaffen?
- Lässt sich die Anwendung überhaupt fachlich sinnvoll in kleinere Einheiten schneiden?
Sicher liegt Ihnen bei der letzten Frage ein "Klar, alles lässt sich fachlich sinnvoll verkleinern!" auf den Lippen. Bitte beachten Sie hierbei aber, dass bei vielen schon seit längerem produktiven Enterprise-Anwendungen die Datenbank ein komplexes Geflecht aus unzähligen kaum dokumentierten Tabellen, nicht mehr erklärbaren Fremdschlüsselbeziehungen, Triggern, Constraints und stored procedures enthält. Hier das Skalpell anzusetzen erfordert viel Planung und Analysearbeit.
Aus Sicht der mobilen App ist freilich nur wichtig, dass sie auf eine möglichst einfache, sichere, stabile Schnittstelle zugreifen kann. Ob die neu gebaut oder wiederverwendet wird, spielt für sie keine Rolle. Allerdings darf man keinesfalls der Versuchung erliegen, die Filetstücke eines Unternehmens "einfach so" außerhalb des gesicherten Firmennetzes verfügbar zu machen. Genau das wäre aber der Fall, wenn eine Mobile App mittels LTE und https direkt auf ein Anwendungsmodul zugreift. Stattdessen sollte in der DMZ des Unternehmens ein Torwächter stehen, der Anfragen von außerhalb des gesicherten Firmennetzes entgegen nimmt, offenkundig unautorisierte Anfragen abwehrt und legitime Aufrufe an den eigentlichen Microservice oder das alte Anwendungsmodul weiterleitet. Wie eine solche Architektur aussehen kann, ist in Abb. 1 dargestellt.
Neben dem Sicherheitsaspekt erfüllt ein solcher Stellvertreter (ich vermeide den Begriff Proxy, weil Sie sonst vielleicht an den klassischen Proxy-Server für Webzugriffe denken) oft noch weitere Aufgaben. Er kann bei Bedarf komplexe Strukturen vereinfachen und für mobile Clients aufbereiten, oder ältere Services um nicht vorhandene Mechanismen wie Paging erweitern. Ein weiterer Mehrwert mag sich aus der Vereinheitlichung von Benutzerverwaltungen ergeben. Gerade sehr alte Systeme haben noch ihre eigene. Unter Umständen kann der Stellvertreter hier automatisch eine Transformation vornehmen. Der Vorteil wäre, dass sich der Anwender nicht für jede App unterschiedliche Kombinationen aus Benutzernamen und Passwort merken muss. Ob ein Single-Sign-On für Apps gelten soll, ist freilich eine Governance-Frage, die unternehmensweit eindeutig beantwortet werden muss. Eines darf der Stellvertreter übrigens auf keinen Fall sein: ein Ersatz für eine bestehende Unternehmensfirewall. Diese bleibt – selbstverständlich – weiterhin bestehen.
Vom ESB zum API Gateway
Systeme für die Protokolltransformation kennen wir schon aus den Zeiten, in denen SOA der heilige Gral der Unternehmensarchitektur war. Dem Enterprise Service Bus wurde damals die zentrale Rolle der Spinne im Netz zugedacht, über die jegliche Kommunikation zwischen Anwendungen und Services laufen sollte. Der Charme dabei: ESBs konnten Binärprotokolle transformieren und so beispielsweise Bestandteile von CORBA-Anwendungen, Datenbanken oder Textdateien als (SOAP-)Webservice zur Verfügung stellen. Ferner enthielten sie Mechanismen zum Load Balancing und Fail Over. Diese Fähigkeiten machen sie zu einem guten Kandidaten für einen Stellvertreter. Auch das Feature, vorhandene Services zu kombinieren und zu orchestrieren, könnte bei der Anbindung von Mobile Apps an bestehende Unternehmensanwendungen gewinnbringend eingesetzt werden. Unglücklicherweise ist der korrespondierende Begriff "Composed Service", wie auch der ESB selbst, in den letzten Jahren in Verruf geraten.
Bevor ich aktuelle Alternativen anspreche, möchte ich auf ein paar Fragen hinweisen, die vor der Implementierung der mobilen App gestellt und beantwortet werden müssen:
- Bleibt die Unternehmensanwendung in ihrem Aufbau im Backend unverändert?
In diesem Fall muss die mobile App letztlich mit den vorhandenen Remoting-Schnittstellen zurechtkommen. Die Themen Protokolltransformation, Objekt-Mapping, Authentifizierung und Autorisierung sind dann von entscheidender Bedeutung. - Hat die Unternehmensanwendung ihre eigene Benutzerverwaltung?
Sofern sie nicht an einen zentralen Verzeichnisdienst angeschlossen ist, müssen Sie klären, ob die Benutzerverwaltung nach außen durchgereicht werden muss, oder ob die Mobile App einen modernen Login-Mechanismus verwendet und an geeigneter Stelle ein Benutzer-Mapping stattfindet. - Wird bei der Zerlegung der Unternehmensanwendung und ihrem Wiederaufbau als Microservices die Nutzung durch Mobile Apps berücksichtigt?
In diesem Fall sollte darauf hingewirkt werden, dass die angebotenen Schnittstellen für Mobile Apps eine geeignete Granularität haben. Es muss also Ausprägungen von Serviceoperationen geben, die nur die von der App tatsächlich benötigten Informationen transportieren.
Wer aber sorgt für diese "geeignete Granularität"? Hier kommen API Gateways ins Spiel. Sie gelten derzeit als Mittel der Wahl für das situationsgerechte (das heißt: für bestimmte Nutzungsszenarien optimierte) zur Verfügung stellen von Programmierschnittstellen. Ihr Funktionsumfang variiert je nach Hersteller. Generell lassen sich aber folgende Einsatzgebiete definieren:
- Request-Weiterleitung bzw. -Verteilung
- Protokoll-Übersetzung
- Service-Composition und Model-Transformation
- Optimierung für spezielle Geräte
- Service-Versionierung
- Authentifizierung und Autorisierung
- Caching und Logging
Kommen Ihnen die Einsatzgebiete bekannt vor? Der eine oder andere ESB feierte unter anderem Namen als API Gateway fröhliche Wiederkehr.
Mit der Rolle des zentralen Vermittlers zwischen sicherem Intra- und unsicherem Extranet geht allerdings eine gehörige Portion Verantwortung einher. Zum einen muss die Software allen Angriffen standhalten (die es durch die Firewall geschafft haben), Unternehmensdaten schützen und potenziell einer Flut von Anfragen gewachsen sein. Zum anderen muss die Existenz des zentralen Torwächters von Allen im Unternehmen akzeptiert und mitgetragen werden. Nicht zu empfehlen ist die verbindliche Einführung mit einem Big Bang. Oktroyierte Glückseligkeit hat schon zu Zeiten von SOA für viel Missmut gesorgt. Empfohlen sei an dieser Stelle deshalb ein vorsichtiges Ausrollen für eine Mobile App. Wenn der Ansatz für das Unternehmen trägt, können Stück für Stück weitere Apps das API Gateway nutzen. Ein langsames und kontrolliertes Einschwingen ist auch deshalb sinnvoll, weil der Betrieb einer so mächtigen und zentralen Komponente alles andere als trivial ist. Selbst dann, wenn im Unternehmen DevOps kein Fremdwort mehr ist.
Backend for Frontend
Kommt Software von der Stange nicht in Betracht (zum Beispiel, weil man den Vendor Lock-in fürchtet), können Torwächter für Mobile Apps auch eigenständig entwickelt werden. Die Idee ist hierbei, ihn als Microservice zu realisieren. Also ein schlankes, stark fokussiertes Modul, das gezielt zwischen mobilen Anwendungen und den von ihnen verwendeten Backend-Systemen vermittelt. Ein solches Muster wird gelegentlich als "Backend for Frontend" [1] bezeichnet. Es handelt sich hierbei um eine Variante des API Gateways, die sich (im Unterschied zum API Gateway) auf einen Frontend-Typ konzentriert.
Welche Technologien ein solcher Microservice verwendet, hängt von der Ausgestaltung der ihn nutzenden Apps sowie der vorhandenen anzubindenden Services beziehungsweise Unternehmensanwendungen ab. Liefern die existierenden Systeme große, komplexe Datenstrukturen, bietet es sich beispielsweise an, sie mit Hilfe von GraphQL zu verschlanken. Ist das alte Backend anfällig für zu viele Anfragen (in zu kurzer Zeit), kann es sinnvoll sein, im Microservice eine Art Cache zu realisieren. Möchte man für die App ein unternehmsweites Single Sign-on, die alte Anwendung hat aber eine eigene Benutzerverwaltung, lohnt unter Umständen die Anbindung an den zentralen Verzeichnisdienst, verbunden mit der anwendungsspezifischen Ad-hoc-Umwandlung der Nutzerdaten. Die Architektur eines solchen Service ist in Abb. 2 zu sehen. Wie bereits geschrieben, ergeben sich die umzusetzenden Bausteine aus den Anforderungen der Mobile App sowie der fachlichen und technischen Umsetzung der Unternehmensanwendungen. Beispielsweise sollten Sie die Umsetzung des Webservice als Spring-Boot-Anwendung in Erwägung ziehen, wenn auch die Backends in (Enterprise-)Java gebaut wurden.
Der Vorteil von selbst entwickelten Microservices gegenüber großen Infrastrukturen (ESB oder API Gateway) ist, dass sie sich wesentlich schmerzfreier in die DMZ bringen lassen. Ein sicher nachvollziehbares Argument ist, dass Systeme in der DMZ sicher konfiguriert werden müssen. Je weniger Aufwand bei der Installation einer solchen Software entsteht, umso geringer ist das Risiko, dass sie ein Sicherheitsloch in die Mauern des Unternehmens reißt. Auf der anderen Seite steigt so der Druck auf das Team, das den Microservice für die Mobile App entwickelt.
Fazit
Der Schnittstelle zwischen sicherem Intranet und der gefährlichen Welt außerhalb der beherrschbaren Mauern des Unternehmens kommt bei Konzeption und Umsetzung einer Mobile App existenzielle Bedeutung zu. Ein solcher Stellvertreter muss unter allen Umständen das wertvollste Gut einer Firma – ihre Daten – schützen. Das direkte Exponieren von Anwendungsmodulen scheidet – nicht nur aus Gründen der Sicherheit – aus. API Gateways sind Softwarelösungen, die in die Systemlandschaft des Unternehmens integriert werden können. Sie bieten sich an, wenn schon feststeht, dass mehrere Anwendungen von außen auf Schnittstellen von Anwendungen zugreifen sollen. Eine Alternative kann die Implementierung spezialisierter Microservices sein, die ausdrücklich für die Nutzung durch eine App entwickelt werden. Dem einfacheren Roll out von API Gateways in das Unternehmen gegenüber steht ein nicht zu unterschätzender Druck auf das Entwicklungsteam, stabile, schnelle und unter allen Umständen sichere Software zu liefern.
