Das Hauptproblem bei workflow-basierten Deployment-Lösungen besteht hauptsächlich darin, dass damit jedes Deployment einzigartig ist und jede Änderung der Anwendung (z. B. wenn neue Komponenten hinzukommen) eine Änderung des Workflows bedingt. Dieser muss dann zusammen mit vorhandenen Umgebungskonfigurationen jedes Mal manuell angepasst werden. Außerdem müssen häufig zwei Workflows gepflegt werden, einer für das Roll-Out und einer für das Roll-Back. Die Maintenance über einen längeren Zeitraum ist mit workflow-basierten System eine Herausforderung, der die meisten IT-Organisationen nicht gewachsen sind.
Eine Lösung, die sehr häufig in der IT (und nicht nur da) für dieses Problem angewendet wird, sind Abstraktionen des Problem- und Lösungsraums auf eine höhere Ebene, Beispiele dafür sind Assembler vs. Hochsprachen, Provisionierung mit Puppet/Chef/Ansible vs. handgebauter Provisionierungsscripte oder ein Container-Scheduler (Kubernetes, OpenShift) statt expliziter Orchestrierung.
Im Vortrag betrachten wir die folgenden Fragestellungen:
- Wie würde es aussehen, wenn man dieses Paradigma auf das Applikationsdeployment übertragen würde?
- Welche Vorteile hat das?
- Worauf muss man achten?
- Was heißt das konkret für die unterschiedlichen Zielsystem – vom SharePoint über JEE AppServer bis hin zu Docker, Cloud und Serverless-Applikationen?