Nachhaltigkeit, Effizienz und Compliance in der Applikationslandschaft von Grossunternehmen wird nicht mit Technologie-Einkäufen allein erreicht

Dr. Peter Schnorf

 

Applikationslandschaft von Grossunternehmen

Bis eine nicht-triviale Applikation in einem Unternehmen entwickelt ist, zuverlässig läuft, alle Anforderungen im Betrieb erfüllt und günstig weiterentwickelt, angepasst oder portiert werden kann, müssen typischerweise viele Hindernisse ausgeräumt werden. Eine ganze Landschaft solcher Applikationen für ein Unternehmen entlang den komplexen Anforderungen optimal zu gestalten, ist erst recht eine Herkulesaufgabe. Diese Aufgabe soll hier etwas genauer beleuchtet werden. Wir konzentrieren uns dabei aber ‘nur’ auf die letzte Meile von technischen Applikationsservices in der Cloud oder im eigenen Rechenzentrum; es geht nicht um vorgelagerte oder umfassendere Prozesse wie z.B. Entwicklungs-Methoden oder Bestell-/Abrechnungs-Workflows.

Während die spezifische Applikationslogik den eigentlichen Mehrwert für die Benutzer darstellt, bilden aber auch die Arbeiten zur Erfüllung der nicht-funktionalen Anforderungen einen signifikanten und unvermeidlichen Kostenblock. Auf dem Spiel stehen Risiken von Folgekosten z.B. durch Reputationsverlust (z.B. wegen Mängeln bei Sicherheit oder Nachvollziehbarkeit) oder durch Betriebsausfälle (z.B. mangelnde Massnahmen für Hochverfügbarkeit oder Katastrophen-Ueberbrückung). Zudem sind auch Wartbarkeit, Portabilität, Performance/Ressourcenverbrauch/Skalierbarkeit, oder Betreibbarkeit wichtige Anforderungen.

Verwaltet ein Unternehmen eine grössere Anzahl eigener Applikationen, ist es nicht verantwortbar, es jedem Entwicklungsprojekt selber zu überlassen, wie es die nicht-funktionalen Anforderungen abdeckt und deren Erfüllung garantiert. Zu hoch wären die akkumulierten Kosten und zu unüberschaubar die Risiken. Als probates Gegenmittel gilt anerkanntermassen das Anstreben von Wiederverwendbarkeit durch Standardisierung. Allerdings variiert das Ausmass oder der Durchsetzungsgrad solcher Massnahmen in Unternehmen stark und entsprechend unterschiedlich fällt die Effizienzbilanz aus.

Technologie-Einkauf und Produkt-Standardisierung ist höchstens ein Anfang

Meist beschränkt man sich leider auf generische Standardisierungen auf der untersten Stufe von Infrastrukturprodukten (Umsysteme wie Monitoring oder Inventory, aber auch Server-Hardware, HW-Hypervisor oder eine kleine Auswahl von Operating System Produkten). Je näher man den Applikationen “auf den Pelz” rückt, umso komplexer wird die Aufgabe und umso schwieriger erweist sich die Durchsetzung, z.B. nur schon bei Middleware- oder Datenbank-Produkten.

Festlegen der erlaubten Infrastrukturprodukte bringt vielleicht Skaleneffekte beim Einkauf und beim Engineering, aber es genügt noch lange nicht. Um Wiederverwendbarkeit von Lösungen für die erwähnten nicht-funktionalen Anforderungen zu erzielen, braucht es zusätzlich saubere Architektur-Designs, schlanke Prozesse, automatisierte technische Services und Durchsetzungs-Governance. Schon auf unterster Stufe kann man z.B. nicht einfach sagen “unser Standard Server OS ist Linux von Hersteller X” und alles weitere jeder Applikation einzeln überlassen. Stattdessen sollte man die genaue Version fixieren, sowie die Detailkonfiguration (z.B. Sicherheits- oder Administrationseinstellungen) zentral vornehmen und Zusatzteile für die Einbindung in die Betriebsumgebung integrieren (z.B. für Logging/Monitoring oder für Sicherheitskomponenten wie Zertifikate). Und je besser die Prozesse und technischen Services rund um den Standard sind (z.B. schnelles Provisioning, verlässliches Release Management, einfache Benutzer- und Rechte-Verwaltung, etc.), desto höher wird die Akzeptanz und desto einfacher wird auch die Durchsetzung des Standards. Entsprechend besser wird auch der Business Case bzw. die Amortisation des zentralen Aufwandes für die Entwicklung und den Unterhalt des Standards. Typischerweise erfüllt allerdings nicht ein Standard alle Anforderungen über das ganze Applikationsspektrum hinweg, sondern man wird nach grösseren zusammengehörigen Bereichen unterscheiden müssen, insbesondere auf höheren Stufen als der generischen Basis-Infrastruktur. Und es wird auch meist vereinzelte Applikationen geben, die aus dem Raster fallen und einen eigenständigen Business Case aufweisen können, zumindest teilweise nicht-standardisiert aufgebaut zu sein.

Erweiterbares Framework zur Umsetzung von Strategie und Architektur

Die langjährige Erfahrung in der zentralen Infrastruktur-Architektur in einem Grossunternehmen im Finanzsektor zusammen mit den neueren technologischen Möglichkeiten, insbesondere bei Virtualisierung oder im Cloud-Umfeld, inspirierten den Autor zu einem Projekt, das verbesserte Hilfestellung für die oben geschilderte Problematik liefern soll. Auf YouTube ist eine ausführliche Dokumentation zum Projekt zu finden (siehe Referenzen unten). Hier soll eine kürzere Uebersichtsvorstellung genügen.

Das erwähnte Unternehmen kann als Beispiel dienen, um die Problematik zu verdeutlichen. Ausgangspunkt dort war, dass zwar schon relativ weitgehend standardisiert worden war. Sogenannte Applikationsplattformen für verschiedene Teilbereiche stellten gute Produkte mit zugehörigen Prozessen, Integration in die Umgebung und vorgefertigte, Architektur-getriebene Lösungen von nicht-funktionalen Anforderungen zur Verfügung. Trotzdem dauerte es viel zu lange bis nach Ressourcenbestellungen eine Applikation vollständig deployed war, alles im Zusammenhang richtig konfiguriert war und die Applikation durchgehend lief. Ressourcen wurden entsprechend kaum je zurückgegeben und damit eine wesentliche Voraussetzung verletzt, um Ressourcen Cloud-mässig optimal zu verwalten. Zudem hatte die Operation wenig Uebersicht, was alles zu einer Applikation gehörte und wie die einzelnen Teile zusammenspielten. Entsprechend schwierig war es, Sekundär-Probleme von primären Ursachen zu unterscheiden oder ausgefallene Einzelteile wieder im Gesamtkontext zum Laufen zu bringen.

Das Projekt startete damit, den Applikationen eine aus ihrer Perspektive einfache Modellierung ihrer benötigten Infrastruktur zu ermöglichen und darin die Deployment-Pfade für SW-Artefakte darzustellen. Darauf beruhend war dann vollständiges Deployment auf Knopfdruck möglich, d.h. ein Automatisierungsservice für ganze Applikationen. Und der Betrieb hatte erstmals eine Sicht auf die gesamte Infrastruktur einer Applikation. Seither wurde das Projekt ausserhalb des Unternehmens weiter entwickelt.

Oberstes Ziel war es immer, ein hocheffizientes, anpassungsfähiges System zu erhalten, das unterschiedlichsten Unternehmen helfen kann, den Applikationsentwicklern auf einfache Weise standardisierte Lösungen für nicht-funktionale Anforderungen sowie schnelle technische Services für ganze Applikationen zur Verfügung zu stellen. Ueber allem steht die abstrahierte, Anwender-gerechte Modellierungsmöglichkeit vollständiger Applikationen bezüglich Infrastruktur-Ressourcen und SW-Artefakte sowie deren Verbindungen und Abhängigkeiten, mit anderen Worten also der Modellierung der Infrastruktur- und Applikations-Topologie. Das Metamodell für Topologie-Spezifikation basiert auf einer wohl definierten Grammatik und war ursprünglich inspiriert durch TOSCA (Topology and Orchestration Specification for Cloud Applications) von OASIS. Entsprechend heisst das ganze System ‘Topology as a Service (TaaS)’ Framework.

Entsprechend den Ausführungen oben bietet TaaS nicht nur ein technisches Tool sondern eben auch ein konzeptionelles Framework, das eine gewisse Architektur vorgibt. Diese Architektur erlaubt es Unternehmen, ihre bereits bestehenden (und sich laufend ändernden) Umsystem-Produkte, Automatisierungstools und von Applikationen direkt verwendeten OS-, Middleware, oder DB-Produkte als Customizations einzubinden. Mit diesen Produkten lassen sich dann ganze, standardmässig konfigurierte Setups vorgeben, die den Applikationen helfen, die nicht-funktionalen Anforderungen zu erfüllen. Der technische Teil des Frameworks implementiert voll automatisierte Topologie-basierte Applikations-Services wie z.B. das Provisionieren der gesamten Infrastruktur oder das Deployment aller Applikations-Artefakte wie in der Topologie spezifiziert. Alle diese Services sind sehr performant und enthalten immer auch die nötigen additiven oder subtraktiven Konfigurationsschritte, die durch die Verbindungen in der Topologie impliziert werden. Die Produkt-spezifischen oder Strategie-getriebenen Einzelheiten können in einfachen, semantisch klar umrissenen Customizations angegeben werden. Das alles erlaubt es, voll funktionsfähige und konforme verteilte Unternehmens-Anwendungen auf frischer Infrastruktur sehr schnell zu instantiieren, anzupassen und wieder zu beseitigen.

Unterstützte Zielgruppen

Zusammenfassend adressiert das Projekt hauptsächlich drei Zielgruppen.

• Applikationsentwickler. Das Topologie-Modell der benötigten Infrastruktur kann einfach und intuitiv ohne Detailkenntnisse verwendeter Produkte mit vorgefertigten Teilen aus einem Katalog zusammengestellt und die Deployment-Spezifikation ähnlich leicht ergänzt werden. Danach lassen sich voll lauffähige Applikationen auf neuer Infrastruktur sehr schnell aufbauen, anpassen und wieder demontieren. Das heisst, dass z.B. schnelles Testen im ganzen Applikationskontext auch nach nur kleinen, individuellen Code-Aenderungen problemlos möglich wird. Damit sollten Qualitäts- und Time-to-market-Verbesserungen erreicht werden können. Zudem, solange sich Applikationsprojekte an die vorgegebenen Design- und Architektur-Vorgaben halten, sind sie von der Lösung nicht-funktionaler Aufgaben weitgehend befreit und können sich auf die Entwicklung der Applikationslogik konzentrieren.
• Operators (in DevOps- oder separaten Spezialisten-Teams). Durch die mitgelieferten Automatisierungsservices können Risiko-behaftete manuelle Eingriffe zur Produktionszeit vermieden werden. Die im Inventory abgelegten Topologien erlauben Einsicht in die Gesamtinfrastruktur von Anwendungen inklusive den wichtigen Abhängigkeiten zwischen den Einzelteilen.
• Organisationen (Unternehmen, Cloud Anbieter, …). Dank der klar vorgegebenen Architektur und Struktur können strategische Kunden-Vorgaben recht einfach an expliziten Anpassungspunkten eingebracht und durchgesetzt werden. Das gilt für portable Anbindungen verwendeter Infrastrukturprodukte (Umsysteme oder im Applikationsstack) als auch für standardisierte Lösungen von nicht-funktionalen Anforderungen. Die umfassende Automatisierung für ganze Applikationen kann nicht nur die Akzeptanz und Wirksamkeit der Standardisierungen erhöhen, sondern auch helfen, den Ressourcenverbrauch im Rechenzentrum zu optimieren (Rückgabe unbenötigter Ressourcen ist stark erleichtert und gefördert).

Wer mehr wissen möchte über das ‘Topology as a Service’ Framework findet auf YouTube eine ausführliche Dokumentation: youtube.com

Quelle: cloud-finder.ch