Synopsis

DelOps – Delivery to Operations

Es existieren zwei Aspekte in den „traditionellen“ DevOps Ansätzen, die teilweise unzureichend implementiert sind bis in Gänze fehlen. Nachfolgend versuche ich den Kern beider Aspekte anzureißen. Sie betreffen meist Unternehmen aus dem Finanzsektor bzw. nicht-Technologie Unternehmen, die ihre internen Prozesse durch externe Softwarelösungen automatisieren. Privatbanken sind hier sehr oft von betroffen, wegen besonderen Regulierungen und Einschränkungen durch Sicherheitsprozesse und mangelnden IT Knowhow.

Erster fehlender Puzzle:

Vollautomatische Verarbeitung externer Softwarepakete und machinenlesbare Paketdokumentation. 

Die typische und publizierte Build und Deployment Pipeline beginnt fast immer in-house, sodass es ein Einfaches ist Deployables – Pakete und deren Inhalte – auf eine interne Infrastruktur zu mappen. Bspw. ein Nuget Paket von Microsoft oder ein EAR File von JBoss. Wie aber können inhaltlich volatile Pakete von externen Softwarelieferanten auf ähnliche Weise in die internen DevOps Prozesse eingebettet werden. Ansätze stellen beliebte Design Pattern aus der Softwareentwicklung zur Verfügung. Über das Adapter Pattern, einer DSL (Domain Specific Language) oder den Transformationsansatz á la XSLTkann hier eine standardisierte Behandlung von inhaltliche volatilen Paketen eingeführt werden. Wir haben als DerSalvador GmbH eine Open Source Initiative diesbezüglich gestartet. Die Lösung besteht im Kern aus einer XML-DSL die für generische Paketeinhalte ausgelegt ist. Diese DSL kann und wird natürlich erweitert gemäß den lokalen Anforderungen des Kunden. Sie umfasst nicht nur typische DevOps Prozesse sondern auch alle intern involvierte Prozesse wie Change- und Releasemanagement, Monitoring, Security und Provisionierung der Infrastruktur. Ziel ist es diese Prozesse ebenfalls in automatisierter Form in den gesamten DevOps Deployment Prozess zu integrieren. Zum Beispiel könnte ein ITIL Standard Change automatisch erkannt werden, die Security Checks als auch die automatisierten UAT Test ausgeführt werden, sodass ein Produktionsdeployment von externe Pakete in Sekunden erfolgen könnte. Heutzutage dauert die Einführung eines Standard-Changes in Privatbanken in Produktion oft noch ca. 2 FTE. Diesen Flaschenhals trifft man oft in Unternehmen mit einer rigiden Change und Releasemanagementkultur an. Unser Ansatz kann auch hier Deploymentzeiten in Produktion ähnlich wie bei Google und Amazon auch für externe Vendor Pakete erzielen. Für weitere Informationen zu den Implementierungsdetails und Features kann unsere Website www.dersalvador.com und die verlinkte Github-Seite kontaktiert werden.

Zweiter Fehlender Puzzle:

Stetiger Überprüfung auf Sicherheitslücken in den Build- und Deployment Pipelines 

Im Zuge der Vollautomatisierung von Applikations- und Infrastruktur- Deployments bis hin zur Produktion werden die Möglichkeiten ausgiebiger manuelle Security,- Compliance, und Policy Tests basierend auf dem Konzept von „Segregation of Duties (SoD)“ oft vergessen oder auch unzureichend implementiert. Gefahren entstehen dann wenn externe Bibliotheken in den tiefen Abhängigkeiten aus der Open Source Community, bspw., eingesetzt werden, von denen nicht einmal der Entwickler Kenntnis hat. Diese Bibliotheken können sowohl Verwundbarkeiten als auch explizite Viren enthalten. Diese vollautomatisch zu entdecken fällt schwer. Die OWASP (Open Web Application Security Project) Community bspw. oder offizielle Online-Datenbanken mit Informationen über Third-Party Libraries und ihre Sicherheitslöcher können hier Abhilfe schaffen. Sie sind meist für die Einbettung in Buid,- und Deploymentpipeline mit REST-Apis gerüstet um eine vollautomatische Überprüfung zu ermöglichen. Entwickler sind meist nicht geneigt diese Plugins einzusetzen, sodass oft die Verantwortung dafür in den Ops Bereich fällt. Erst durch die DevOps Kultur können solche wichtigen Prozesse in eine gemeinsame Pipeline integriert werden.