Am 16.11.2017 haben Torsten Jaeschke und ich einen Vortrag zu diesem Thema im Rahmen der Continuous Lifecycle Konferenz in Mainz gehalten. Es ist eine gute Idee sich die Folien als Ergänzung anzusehen.
Wir Softwareentwickler beschäftigen uns mit Methoden, wie wir Fachdomänen strukturieren und Prozesse erheben. Aber wann haben wir dies das letzte Mal auf unsere eigene Domäne angewandt? Sind unsere Produktionssysteme, d.h. von der Entwicklungsumgebung, über Ticketsysteme, Versionskontrolle, CI/CD Tools, Staging Umgebungen etc. einfach so gewachsen? Erliegen wir Entwickler, Architekten, IT-Leute also selber zu schnell der Gefahr, dass wir uns mit dem Lösungsraum auseinandersetzen und unseren Problemraum eigentlich gar nicht genau kennen?
Problem- vs Lösungsraum
Was hat es eigentlich mit diesen Begriffen vom Problem- und Lösungsraum auf sich? Warum ist es wichtig, erst das Problem genau zu verstehen und erst dann über die Lösung nachzudenken?
Fangen wir mit einem kleinen Beispiel an: Es ist eine nette Anekdote aus dem
Raumfahrtprogramm und dem kalten Krieg.
Das Problem: Schreiben in der Schwerelosigkeit.
Wie haben die USA das Problem verstanden: Die überall beliebten Tintenschreiber
funktionieren nicht in der Schwerelosigkeit. Wir brauchen also einen Tintenschreiber
der in der Schwerelosigkeit funktioniert. Entwicklungskosten: eine Million US Dollar.
Wie haben dir Russen das Problem verstanden: Wir brauchen etwas mit dem wir in
der Schwerelosigkeit schreiben können. Tintenschreiber geht nicht. Bleistift funktioniert. Nehmen wir den Bleistift.
Das ganze ist zwar ein Mythos, aber er macht doch deutlich, dass man zunächst einmal das Problem richtig verstehen sollte und verschiedene Lösungen abwägen muss.
Wenn wir dies nicht machen, dann kommen wir in die typischen Diskussionen: gitlab ist aber viel besser als Bitbucket…. nein… doch…
Methoden
Wie kann man sich jetzt dem Thema nähern. Eigentlich helfen da typische Methoden aus dem Bereich der SW Entwicklung.
Wir werden im folgenden kurz Personas + Empathy Maps, Event Storming und Domänenmodellierung ansprechen.
Personas + Empathy Maps
Will man mehr über seinen Kunden erfahren, den man häufig nicht direkt vor sich
sitzen hat, dann eignen sich Personas und Empathy Maps gut.
Sie sind auch dann interessant, wenn man später nochmal über Typen von Nutzern
sprechen will, für die eine ausgewählte Lösung besonders geeignet ist und auf die
hin man ggf. seine Auswahl optimiert hat. Aber Achtung: Im eigenen Unternehmen eignen sich kollektive Entscheidungsprozesse besser, um die Architekturtreiber (Qualitätsattribute) festzulegen.
Wir haben hier aber mal ein paar Beispiele aufgenommen, die uns in den
lezten Jahren im Beratungsalltag begegnet sind um die unterschiedlichen Anforderungen an eine Continuous Delivery Umgebung zu verdeutlichen.
Stellen wir sie einmal vor (wir beschränken uns hier wegen der Zeit auf 2 Extreme):
Petra, Head of Advanced Analytical Projects
Petra baut ein separates Team auf, um die Potenziale einer personalisierten Medizin auf Basis von Big Data Technologien zu erforschen. Dazu sollen Produktideen im Rahmen von Schnellbootprojekten verprobt werden. Die Projekte haben eine kurze Laufzeit.
Es soll keine Zeit für das Aufsetzen der notwendigen Infrastruktur vergeudet werden.
Die Entwickler sollen sich nicht um Infrastrukturfragen kümmern. Es handelt sich
um viele kleine eher isolierte Applikationen. Die Umgebung soll vor den ersten
Projekten fertig aufgebaut sein.
Tobias, Leiter Softwareentwicklung
Er steht vor dem Problem neue Methoden der Softwareentwicklung einzuführen.
Er möchte auch Continuous Delivery einführen, kann aber keine up-front
Investition rechtfertigen. Es fehlt auch an verfügbaren Know How. Er möchte
dem Motto „grow-as-you-go“ folgen und möglichst einfach anfangen und nach
und nach notwendige Technologien einführen und ergänzen.
Wir sehen hier schon zwei sehr unterschiedliche Kundenbedürfnisse.
Es gibt aber viele Stakeholder für eine solche Plattform. Da wären sicherlich
die Entwickler und je nachdem wie die Organisationsstruktur ist auch die Betriebsorganisation. Wir reden zwar viel von DevOps, aber da angekommen sind erst wenige. Einen Kulturwandel kann man nicht erzwingen oder forcieren, sondern nur ermöglichen.
Diese beiden Beispiele sind aus unserer Beratungspraxis abstrahiert. Aber wenn man
mit Kollegen zu tun hat, dann sollte man die Themen in Workshops erarbeiten.
Domänenmodell
Tun wir mal so, als ob wir Experten in unserer Domäne sind, dann sollten wir
doch schon wie für viele Fachdomänen so etwas wie eine Referenzarchitektur erarbeitet haben.
Dann könnten wir auch mal sehen, welche unterschiedliche Sichtweisen auf eine
Domänenzerlegung es gibt.
Sonatype hat mal eine kleine [Sammlung](https://de.slideshare.net/SonatypeCorp/nexus-and-continuous-delivery) zusammengestellt. Allerdings sind eine Beispiele schon sehr im Lösungsraum verortet, andere stellen Prozessmodelle dar (die brauchen wir auch, lassen wir aber hier mal außen vor).
Allerdings sind keine dieser Modelle so ausgefeilt wie einige Referenzarchitekturen für z.B. den IoT Bereich oder für Banken und Versicherungen.
Wir machen hier mal einen Vorschlag. Das hilft zur Strukturierung des Problemraums und hilft später Lösungen darauf abzubilden und zu evaluieren.
Unser Vorschlag auf der ersten Ebene ist wie folgt
- Enabling Tools
- Runtime Environment
- Development Environment
- CD Tooling
Lasst uns mal in jede Domäne einen kurzen Blick riskieren:
Enabling Tools
Unter der Domäne Enabling Tools sind alle Systeme zusammengefasst, die benötigt
werden, um eine Entwicklung zu starten und zu supporten. Mit den Enabling Tools ist eine lokale Entwicklung (auf dem Entwicklerlaptop) schon möglich.
Zu den Enabling Tools zählen unserer Sicht nach folgende Subdomänen
- VCS Hosting
- Ticket System
- Wiki
- (Binär-) Repositories
- Persistent Chat
- Provisioning
- SSO (IAM)
Die Liste erhebt keinen Anspruch auf Vollständigkeit und nicht immer werden alle
Aspekte gebraucht. Aber dies sind typische Bereiche, mit denen wir in
unseren Projekten immer wieder zu tun gehabt haben.
Für jede dieser Subdomänen gibt es eigenständige Systeme, welche optimiert sind.
Die meisten Punkte sind selbsterklärend.
Insbesondere, wenn es sich um eigenständige Systeme handelt, dann benötigt man
noch die letzten beiden Punkte.
Die Provisioning Subdomäne kümmert sich, dass für ein neues Projekt die entsprechenden Ressourcen in den anderen Domänen konfiguriert werden. Ebenso wichtig ist im Fall von separaten Systemen ein Single Sign On / Identity and Access Management, so dass man nicht für jedes Systeme anmelden oder gar eigenständige Accounts nutzen muss.
Es gibt aber auch integrierte Lösungen, die mehrere oder gar alle Subdomänen umfassen.
Runtime Environment
Unter dieser Domäne verstehen wir alle Funktionen, welche die Ablaufumgebungen
für verschiedene Environments (von Build Umgebungen, Dev, Test, UAT, CAP bis hin zu PreProd und Prod) bereitstellt und diese überwacht.
Als Subdomänen sehen wir hier
- Log Management
- Monitoring & Alert Management
- Distributed Application Scheduler
- Configuration Management
- Service Discovery
Es ist erst einmal unerheblich, welche Lösung zum Einsatz kommt, etwa VMs oder
Container.
Development Environment
Diese Domäne umfasst den „Entwicklungsrechner“, welcher bei den technischen
Stakeholdern steht, Entwicklern, Testern, CD Engineer oder den Betriebskollegen.
Er umfasst in der Regel IDE / Editor / Entwicklungswerkzeuge. Da Infrastruktur Code ist,
gibt es keinen prinzipiellen Unterschied zwischen den Beteiligten.
Neben diesen Werkzeugen enthält diese Umgebung in der Regel ein verkleinertes Abbild
des Runtime Environments und des CD Toolings.
Sei es zum Deployment im Rahmen der Entwicklung, sei es zur Entwicklung der
Deployment Pipeline oder administrativen Skripten.
Nicht funktionale Anforderungen
Die Domänen stellen nur eine statische Struktur dar. Was aber erwarten wir von Systemen, welche diese Domänen unterstützen. Was bedeutet für uns gute Qualität?
Unterschiedliche Stakeholder an den Tisch zu holen und mit Ihnen die Qualitätsattribute und -szenarien zu definieren und zu priorisieren ist eine gute Idee, wenn man Architekturarbeit betreibt.
Viel zu häufig sind diese nicht definiert. Eine Architektur aber ist genau dazu dar, insbesondere diese nicht-funktionalen Anforderungen zu erfüllen.
Im Fall von Petra, was können hier nicht-funktionalen Anforderungen sein?
Hier kann man in jedem Fall die Usability nennen. Petra möchte nicht, dass ihre
Entwickler Zeit verlieren und aus dem Schnellboot ein Schlepper wird. Sie sollen
schnell arbeiten können und das Umfeld soll so verständlich sein, dass sie das auch können. Performance ist hier erst einmal zweitrangig. Einfache Bedienbarkeit und das Vorhandensein von Funktionalität zählen hier.
Tobias hingegen möchte eine CD Umgebung aufbauen. Hier kommt neben der Funktionalität die Performance ins Spiel.
Die beste CD Umgebung bringt keinen Mehrwert, wenn ein manuelles Delivery schneller erfolgen kann.
Sofern aber Performance und Funktionalität stimmen, kann Tobias weitere Investitionen rechtfertigen und sein Team vorantreiben.
Alleine an diesem kleinen Ausschnitt an Anforderungen erkennt man schon, dass trotz der unterschiedlichen Bedürfnisse dennoch Überschneidungen existieren, auch wenn man Tobias und Petra aus Ihrem Blickwinkel heraus jeweils eine andere Gewichtung legen würden.
Die Herausforderung liegt meist darin dies in eine von allen tragfähige Priorisierung zu bringen.
Bei der Betrachtung von nicht-funktionalen Anforderungen fließen natürlich auch Überlegungen wie „Bin ich aufgrund der Unternehmenspolicy bereits auf einen bestimmten Stack festgelegt?“ mit ein. Man sollte aber, wenn dies der Fall ist, dennoch über den Tellerrrand schauen und Alternativen anhand der gemeinsam erarbeiteten Anforderungen prüfen und auch persönliche Vorlieben („das nutzen wir schon immer“) außer Acht lassen.
Event Storming
Wir haben hier ein kleines Domänenmodell aufgeführt und die Architekturtreiber definiert.
Wie aber sehen die konkreten Prozesse im Rahmen der Softwareentwicklung und des
Continuous Deliveries für unterschiedliche Projekte aus? Vielfach optimieren wir einzelne Domänen, aber das eigentliche Problem liegt genau in den Prozessen dazwischen, welche die unterschiedlichen Domänen verbinden.
Eine Workshop taugliche Form sich diesen Prozessen zu nähern und auch
verschiedene Varianten gleichzeitig darzustellen ist das Event Storming.
Ein gegenseitiges Verständnis der Prozesse, der Architekturtreiber und Randbedingungen kann dazu führen, dass man Trade-offs akzeptiert. Diese Trade-offs wird man immer haben, wenn man sich auf einen Technologiestack einigt.
Andererseits kann es auch sein, dass man bewusst entscheidet, dass man mit mehr
als einer Lösung leben will.
Beispiele
Ohne jetzt auf die einzelnen ausgewählten Technologien genau einzugehen, hier mal die Lösungen, welche für die oben dargestellten Probleme von Jens und Petra von unseren Kunden gewählt wurden. Dies ist also eine mögliche Implementierung aus dem gesamten Lösungsraum.
Langläufer
Tobias hat sich dazu entschieden einige Lösungen zu übernehmen, die im Unternehmen etabliert sind, wie Atlassian Confluence und Jira oder auch Gitlab.
Die gesamte Plattform wurde auf Basis von freien Tools basierend auf Docker aufgesetzt. Wichtig war hier, dass keine unnötigen Technologien genutzt wurden, sondern immer so viel, wie nötig war, um die parallel zum Projekt aufkommenden Herausforderungen zu meistern. Daher wurde bewusst nicht Kubernetes eingesetzt, sondern z.B. Docker Swarm, da die Administration einfacher war. Die Gesamte Entwicklungsplattform für 24 Entwickler und Tester wurde dabei von zwei externen Mitarbeitern aufgebaut und betreut, die sich eine Stelle teilten (ca 6 Tage / Woche von beiden erbracht).
Schnellbootprojekte
Petra wiederum entschied sich aufgrund der Konzernstrategie auf OpenShift zu setzen und in der AWS Cloud zunächst automatisiert einen Atlassian Stack bauen und über eine Provisioning App Projekte dort automatisiert mit allen benötigten Ressourcen aufsetzen zu können, so dass es von der Anlage eines Projekts bis zum clonen eines Projekts, Push und Build weniger als 5 min dauert. In den ersten 3 Monaten wurden schon 12 Schnellbootprojekte entwickelt.
Plattformen
Das letzte Beispiel geht davon aus, dass soweit wie möglich eine aPaas Plattform genutzt werden soll.
Man selber hat keine Arbeit und kann sich komplett auf das Entwickel konzentrieren.
Gerade dieser Ansatz verdient es genauer betrachtet zu werden.
Aus unserer Beraterpraxis heraus kann man sagen, dass es hier nicht den goldenen Weg gibt. Jede Plattform hat ihre Fallstricke, so dass man seine Anforderungen sehr genau kennen muss, um herauszufinden, ob eine Plattform mit ihren Trade-Offs das ist, was man haben möchte.
Man sollte immer die Lernkurve für die Handhabung der Plattform berücksichtigen, da jede Plattform ihre properitäre Nomenklatur mitbringt und meist gibt es Grenzen, die man auf den ersten Blick nicht erwartet hat, wie Unterschiede zwischen Cloud und On-Premise Varianten.
Wären wir in der Welt des Kochens, könnte man eine Plattform als das Maggie für das Essen sehen.
Man kann sein Essen damit würzen, erhält aber noch viele andere Geschmacksvarianten hinzu, die man unter Umständen nicht haben möchte, während man mit der richtigen Kombination einzelner erlesener Gewürze genau das Aroma produziert, das man haben möchte.
Resümee
Wir sehen, es gibt eine große Bandbreite. Und vieles haben wir bisher nur aus
der Sicht der Entwickler und CD Engineers betrachtet und noch nicht so sehr
aus der Sicht eines klassischen Administrators.
Wir Entwickler preisen überall gerade Microservices an. Ein wesentliches Argument
für Microservices ist die Replacability. Wenn Sie eine Plattform einsetzen ist unser
Rat: Fragen Sie sich, ob und mit welchem Aufwand es möglich ist eine Subdomäne
durch ein anderes System unterstützen zu lassen.
Klären Sie daher im Vorfeld ihre Architekturtreiber und Prozesse, um sich später nicht rechtfertigen zu müssen.