Continuous Delivery bei der VW Group IT Maximale Flexibilität durch Microservices

Agiles Arbeiten wird auch in Konzernen immer mehr zur Normalität. Agile Softwareentwicklung setzt hier auf Microservices-Architekturen und eine Continuous Delivery Pipeline, um neue Anforderungen schnell umzusetzen und den Anwendern rasch erste Ergebnisse zu liefern. Ein Best Practice am Beispiel der Lizenz-Monitoring-Software VWLIC des Volkswagen-Konzerns.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Confluent Germany GmbH

Die Digitalisierung bewirkt gerade in der Automobilindustrie einen tiefgreifenden Wandel. Sie fordert eine Vielzahl neuer Services um bestehende Produkte, bringt veränderte Geschäftsmodelle hervor und revolutioniert die Produktionsmethoden. Um vor diesem Hintergrund innovativ und produktiv zu bleiben, sind ein hohes Reaktionsvermögen und Flexibilität gefragt.

Agile Entwicklung und Continuous Delivery werden hier zu entscheidenden Erfolgsfaktoren. Anders als in der klassischen Softwareentwicklung, können die Entwickler Konzept- und Entwicklungsphase, Testphase und Release mit Continuous Delivery inkrementell und iterativ in kurzen Abständen durchführen.

Der Vorteil liegt in der Kombination von Geschwindigkeit und Qualität: Zum einen setzen Entwickler fertige Releases rasch produktiv, zum anderen läuft die Qualitätssicherung in hoher Frequenz mit automatisierten Tests ab. Dieses agile, testgetriebene Vorgehen wählten die Autoren auch für die Entwicklung eines Lizenz-Monitoring-Systems.

Das Softwareprojekt VWLIC realisiert ein ganzheitliches Lizenz-Monitoring für den Engineering-Bereich des Volkswagen-Konzerns mit weit über 200 Lizenzservern und ca. 50.000 Anwendern. Klassische Softwareprojekte haben im Automobilbereich häufig extrem lange Release-Zyklen zwischen sechs und 18 Monaten.

Das Problem dabei sind oft die langen Testphasen, sie dauern teilweise bis zu drei Monate. Nicht so VWLIC: Ziel des Projektteams war es von Anfang an, binnen acht Wochen das erste Altsystem abzulösen. Dafür waren eine hohe Release-Frequenz und das Deployment von Teilanwendungen nötig. Die Entwickler lieferten während ihrer dreiwöchigen Sprints durchschnittlich ein- bis zweimal pro Woche – und beschleunigten die Time-to-Market wesentlich.

Über 200 Lizenz-Server: Alle Protokolle unter einen Hut bringen

Die Systemlandschaft sah im Vorfeld extrem heterogen aus: Verschiedene Fachbereiche und Abteilungen hatten eigene Lizenz-Monitoring-Lösungen – zum Teil kleine kommerzielle Produkte, zum Teil Skriptlösungen. Der übergreifende Ansatz fehlte.

Die Einzellösungen hatten in der Regel das gleiche Problem: Sie waren relativ gut gestartet, waren gewachsen. Dann wechselten die Entwickler, es gab keine Dokumentation. Zum Teil hatten sich die Entwickler nicht an gängige Konventionen gehalten. Die Qualität des Codes war mitunter mittelmäßig. Die Folge: Die Deployment-Zyklen wurden immer länger, die Support- und Wartungskosten stiegen.

Zwar evaluierte das Projektteam im Vorfeld verschiedene, am Markt verfügbare Lösungen, doch sie stießen immer wieder auf das gleiche Problem: Die Vielzahl der verschiedenen Software-Produkte, deren Lizenzen zu monitoren waren. Bei der Ausweitung des Projektes auf weitere Fachbereiche wuchs die Zahl der Technologien weiter. Und mit jedem neuen Softwareprodukt nahm auch die Wahrscheinlichkeit zu, dass das Lizenz-Monitoring anzupassen war.

Ein weiterer Aspekt waren die großen Datenmengen: Bis zu 200 Gigabyte (GB) Rohdaten gehen am Tag über das Netzwerk. Auch in dieser Hinsicht reichten viele kommerzielle Produkte nicht aus. Sie sind eher für Mittelständler ausgelegt, wo drei Lizenzserver 200 Anwender versorgen – nicht 50.000 Anwender und 200 Lizenzserver. Damit gab es am Markt praktisch kein System, das diese Anforderungen in vertretbarem Aufwand und Zeitrahmen erfüllen konnte.

Faktoren der Beschleunigung: Continuous Delivery und DevOps

Die Notwendigkeit, auf neue Software-Releases auch im Monitoring schnell zu reagieren, gab einen wesentlichen Ausschlag für den Einsatz von Microservices. Ein wichtiger Faktor für die Beschleunigung und Flexibilität des Systems sind kleine Deployment-Einheiten.

Besteht das System hingegen aus einem großen Deployment-Monolithen, durchläuft eine Code-Änderung die Pipeline – und damit die automatisierten Tests – nur sehr langsam. Tritt beim Deployment ein Fehler auf, ist nicht selten der ganze Zyklus unterbrochen.

Mit einer modularen Microservices-Architektur reduziert sich dieses Risiko erheblich. Denn jeder Microservice kann unabhängig von anderen Microservices als eigenes Deployment-Artefakt in Produktion gebracht werden. Darüber hinaus ist es den Entwicklern möglich, sukzessive einzelne Services aufzubauen und neue Anforderungen aufzunehmen.

Ein Beispiel hierfür ist der der Collector Service: Er ist für das Einsammeln von Lizenznutzungsdaten eines Lizenz-Servers zuständig. Der Service verfügt über eine eigene Persistenz-Schicht zur Speicherung der Daten. So lässt er sich unabhängig vom Rest der Systems betreiben und skalieren. Untereinander kommunizieren die einzelnen Services mittels http-Protokoll auf Basis von REST und JSON.

Die Microservices sind hier nicht mit Docker realisiert, sondern als Java-Prozesse, die „Stand-alone“ weitestgehend ohne Application Server auskommen. Eine neue Lizenztechnologie lässt sich durch diese Architektur rasch ins System einsteuern, ohne Einfluss auf den Rest des Systems zu nehmen. Das Entwickler-Team priorisiert dazu das neue Produkt zunächst im Backlog und entscheidet dann, mit welchem Sprint die Anforderung umgesetzt wird. Erst in der Kombination mit einer Microservice-Architektur kann eine Continuous Delivery Pipeline ihre Stärken so voll ausspielen.

Die Modularisierung durch Microservices hat einen weiteren Vorteil: Das System ist relativ ausfallsicher und hochverfügbar. Im Fall von VWLIC bedeutet das, dass bei Ausfall einer Komponente kein Datenverlust in der Lizenznutzung eintritt. Auf schwankende Lasten können Entwickler aufgrund der flexiblen Skalierbarkeit darüber hinaus schnell reagieren.

Zentraler Presentation Service

An einem Punkt entschied sich das Team von Volkswagen jedoch gegen den klassischen Microservices-Ansatz: Im letzten Schritt entwickelte das Projektteam ein interaktives Front-End, das die Weichen für die Live-Auswertung der Lizenznutzung der derzeit rund 50.000 Anwender stellte. Dieses Front-End setzten die Entwickler als Webclient auf Basis von HTML, CSS3 und JavaScript um. Hier ist die UI-Schicht über eine RESTful-Datenübertragung (AJAX) an das Back-End gekoppelt.

Um die Server-Infrastruktur weniger zu belasten und für den Anwender eine hohe Usability mit schneller Reaktionszeit zu gewährleisten, ist das Front-End als „Fat Client“ ausgelegt. Das bedeutet: Viele Analyse-Operationen sind in den Client ausgelagert. Beim klassischen Microservice-Ansatz liefert jeder Service seine eigene UI. Die Entscheidung fiel hier aber zu Gunsten eines zentralen Presentation Service, der alle UI-Komponenten ausliefert und über ein API-Gateway auf die Daten der Services zu greift.

Test-first: 90 Prozent weniger Fehler

Im Projekt hatten die Entwickler das Ziel, von Anfang an testgetrieben zu entwickeln. Das Team arbeitet nach dem Test-first Ansatz. Das heißt, das Testen wird noch vor das Entwickeln des Quellcodes gestellt. Noch vor der Implementierung der eigentlichen Funktion schreiben die Entwickler deshalb einen Unit Test. Auf ihn folgt die Entwicklung des Produktivcodes. Bei der Umsetzung steht die geforderte Funktionalität somit stärker im Vordergrund, da die Entwickler diese zunächst für den Test formulieren müssen. Dieser Test-first-Ansatz reduziert Fehler um bis zu 90 Prozent.

Ganz konkret arbeitet VWLIC mit der Continuous Integration Toolkette der Firma Atlassian und den Produkten JIRA, Bitbucket und Bamboo. Mit JIRA geschieht dabei die Sprintplanung und das Anforderungsmanagement. Als Versionsverwaltung auf Basis von Git dient Bitbucket, Bamboo ist als zentraler Build-Server im Einsatz. Die statische Codeanalyse zur Bewertung der Software-Qualitätsmetriken übernimmt SonarQube.

Fazit

Mit dem eigens entwickelten Lizenz-Monitoring-System VWLIC entstand für den Engineering-Bereich des Volkswagen-Konzerns ein ganzheitliches Lizenz-Monitoring, das mit über 200 Lizenzservern rund 50.000 Anwender abdeckt. Continuous Delivery und die damit verbundene hohe Testautomatisierung waren die entscheidenden Erfolgsfaktoren für dieses Projekt.

Nur so ist es möglich, neue Anforderungen kurzfristig in den produktiven Betrieb zu übernehmen. Durch die Microservice-Architektur ist es kein Problem, das System auf höhere Lasten durch neue Server, Daten und Anwender einzustellen. Entscheidend bei Continuous Delivery ist eine enge Zusammenarbeit zwischen Entwicklung und Betrieb sowie das schnelle Feedback durch die Anwender.

* Dr. Christoffer Menk und Dr. Sebastian Bindick sind Experten für Agile Entwicklung und Continuous Delivery in der Group IT der Volkswagen AG.

(ID:44960249)