Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung

© OPITZ CONSULTING 2017
 Überraschend mehr Möglichkeiten
WAS GEHÖRT ZU EINER MODERNEN
CONTINUOUS-DELIVERY-UMGEBUNG UND WIE
FÜHLT SICH DAS AN?
Seite 1
Richard Attermeyer
Torsten Jaeschke
DAS GANZE IST MEHR
ALS SEINE TEILE

 Überraschend mehr Möglichkeiten
@OC_WIRE OPITZCONSULTING opitzconsultingWWW.OPITZ-CONSULTING.COM
Kenne Dein Problem, bevor du dich
mit der Lösung befasst
Richard Attermeyer
Senior Solution Architect
@rattermeyer
github.com/rattermeyer
richard.attermeyer@opitz-consulting.de
Torsten Jaeschke
Senior Consultant
torsten.jaeschke@opitz-consulting.de

© OPITZ CONSULTING 2017 OC Powerpoint CI 2017 V 0.933 Seite 3
Problem- vs. Lösungsraum
 Ein Kundenproblem, Bedürfnis
oder Vorteil, den das Produkt lösen
oder befriedigen soll
Problemraum Lösungsraum
 Eine spezifische Implementierung,
um den Bedarf zu adressieren
Urban Myth: https://www.scientificamerican.com/article/fact-or-fiction-nasa-spen/
CC-BY-SA-4.0, https://commons.wikimedia.org/wiki/File:Tip_of_a_ballpoint_pen.jpg
NASA: Space pen ($1M R&D costs)
Russians: Pencil

Was ist unser Problemraum?
CC BY-NC-ND 2.0, Taftsville Covered Bridge (before Irene), WickedVT, https://goo.gl/xRtwwN

© OPITZ CONSULTING 2017 Seite 5
Effiziente Softwareentwicklung
CC BY-NC-ND 2.0, October Kanban Board, Spoonstein, https://goo.gl/Uwepbx

© OPITZ CONSULTING 2017 Softwareentwicklung 2022 Seite 6
Wann haben Sie dieses Problem so analysiert, wie
eine Domäne für die Sie Software bauen?

Empathize Define Ideate Prototype Test
OC|Design Thinking -Teaser Seite 7
Design Thinking – Ein iteratives und inkrementelles Vorgehen
Schritt 1: Empathize
 Sammeln möglichst vieler Daten
und Fakten
 Verständnis für das Thema
erzeugen
 Tiefgehende Erkenntnisse zum
Nutzer bekommen
 Ziel: Vielzahl an Problemen und
Bedürfnissen identifizieren.
Verstehe das Problem!

Personas
Empathy Map

© OPITZ CONSULTING 2017 Petra,Head of Digitalization-KSC 2017 Seite 9
Tobias, Leiter Softwareentwicklung
Tobias, 43 Jahre
Was sieht er?
• Hat ein Projekt / Programmteam von 30
Mitarbeitern
• Entwickler, CD Engineering Skills, Lasttest Skills
vorhanden
Was hört er?
• TDD funktioniert bei uns nicht
• Wir wollen agil entwickeln
• Wir wollen stolz auf unsere Arbeit sein
• Wir müssen mehr automatisieren
Was denkt und fühlt er?
• Chance die besten internen und externen
Ressourcen heranzuziehen fürs Projekt
• Schritt machen hinsichtlich Entwicklungskultur
• Attraktivität als Arbeitgeber steigern
Was sagt und tut er?
• Löst ein Altsystem (Cobol) mittels eines
grüne Wiese Projekts ab
Was schmerzt und nervt ihn? (Pains)
• Hosting Provider hat Lizenzmodell auf Basis
von virtuellen Maschinen
• Effiziente Nutzung der Hardware für
verschiedene Umgebungen
• Wenig Ressourcen, um komplexe Plattform zu
managen
• Kein Geld, um ein Plattformprojekt
durchzuführen
Wann fühlt er sich gut? (Gains)
• Entwickler arbeiten gern im Projekt
• Wir zeigen, dass CD funktionieren kann
Wie kann ich moderne Methoden der Softwareentwicklung einführen?
Die SW Entwicklungsabteilung ist sehr
heterogen. Cobol und SAP Entwicklung
existiert neben Java und JavaScript
Entwicklung. Moderne Engineering Methoden
wie systematisches TDD und CI sind nicht
etabliert. Agile Projekte tendieren zu einer
Featurefabrik. Verantwortung für den Betrieb
wird nur ungenügend übernommen.
Aufgrund eines neuen großen Projekts gibt
es die Möglichkeit neue Methoden
einzuführen und auszutesten.

CD ist ein neues Konzept
Großes Projekt
Plattformaufbau Seite an Seite mit Projekt
Kein Extrabudget für CD Plattform

Petra, Head of Advanced Analytical Projects
Petra, 37 Jahre
Was sieht sie?
• Sie hat ein Team von 10 Mitarbeitern
• Prototyping / Experimente sind der Fokus
Was hört sie?
• Potenziale der personalisierten Medizin
werden diskutiert
• Wie erweitern wir dass Business Modell:
Pharmahersteller?
Was denkt und fühlt sie?
• Sie steht unter Erfolgsdruck
• Sie ist unsicher bezüglich erforderlicher Skills
• Sie wird anhand neu generierter Produktideen
beurteilt
Was sagt und tut sie?
• Baut gerade ein neues Team aus
Anwendungsentwicklern und Data
Scientists auf
Was schmerzt und nervt sie? (Pains)
• Fehlende Kompetenzen und Mitarbeiter für
Plattformbetrieb
• Mitarbeiter sollen Ideen verproben nicht
Infrastruktur managen oder Projekte
aufsetzen
Wann fühlt sie sich gut? (Gains)
• Entwickler können einfach entwickeln
• Keine Gedanken über Infrastruktur machen
• Werkzeugkasten (Sprachen, Frameworks,
Enabling Tools) wird einfach unterstützt
Wie kann ich als Verantwortliche AAP Experimente umsetzen?
Um die Möglichkeiten von Big Data und
Advanced Analytics im Umfeld der
Arzneimittelforschung und
Krankheitsbehandlung auszuloten führt sie
eine neue Abteilung aus Data Scientists und
Anwendungsentwicklern, die im Rahmen von
Schnellbootprojekten Ideen verproben
sollen. Erfolgsversprechende Ideen werden
über etablierte Entwicklungsabteilung
produktreif weiterentwickelt.

Schnellbootprojekte durchführen
Wenige komplexe Projekte
Definierter Werkzeugkasten
Ramp-Up Zeit für Projekte schmerzt

© OPITZ CONSULTING 2017 Petra,Head of Digitalization-KSC 2017 Seite 13
Richard, CD Engineer
Richard, 42 Jahre
Was sieht er?
• Kein Projekt ist wie das andere
• Jede Plattform hat eine eigene Philosophie
Was hört er?
• Wir müssen uns auf eine Plattform einigen
• Wir haben eine Plattform eingeführt. Ihr
seid das erste Projekt, welches sie benutzt
(und wir haben euch nicht vorher gefragt)
Was denkt und fühlt er?
• Hätte gerne einen Werkzeugkasten den er
beherrscht
• Möglichkeit den Werkzeugkasten
entsprechend der Projektbedürfnisse
weiterzuentwickeln
• Fühlt sich gut, wenn er Projekte passgenau
unterstützen kann
• Angst davor Teil eines "Plattformteams" zu
werden
Was sagt und tut er?
• Arbeitet und unterstützt einzelne Projekte
bei der Umsetzung ihrer CD Anforderungen
Was schmerzt und nervt ihn? (Pains)
• Vendor Lock-Ins
• Einengung durch Plattformphilosophie
• Veraltete Deployment Prozesse
• Manuelle Prozesse mit viel Maintenance
Overhead
Wann fühlt er sich gut? (Gains)
• Komplexität bleibt beherrschbar
• Kann sich um die Bedürfnisse der Projekte
kümmern
• Projekte sind mit der CD Plattform
zufrieden
Ich will maximale Kontrolle, um meinen Kollegen die bestmögliche und einfachste CD Lösung für ihr
Problem zu liefern
Ich liebe es mich aus den Komponenten am
Markt zu bedienen und eine passgenaue CD
Lösung für meine Kollegen und Kunden
aufzubauen. Ich will einen lock-in vermeiden
und eine best-of-breed Lösung bauen.
Gleichzeitig soll die Lösung für meine
Kollegen beherrschbar sein, die sich auf die
Entwicklung konzentrieren wollen.

Passgenaue Lösungen für jedes Projekt
Pain: Einengung durch Plattformphilosophie
Teil eines Projekts-, nicht eines Plattformteams
Überschaubarer Werkzeugkasten

Take Aways
 Stakeholderanalyse durchführen
 Bedürfnisse und Motivationen verstehen
 Besser: Zusammen erarbeiten
 Dies waren nur ein paar Beispiele aus unserer Beratungspraxis

Domänenanalyse: Beobachtungen
 Es gibt diverse Reference Architekturen / Blueprints für Fachdomänen
 Telekommunikation: eTOM und TAM
 IoT reference architectures
 Banking / Financials reference architectures
 ….
 Es gibt verschiedene Möglichkeiten eine Domäne zu zerlegen
 Wer kennt eine Referenzarchitektur für Continuous Delivery?
 Sammlung von Prozessen, Architekturen, Tools:
https://de.slideshare.net/SonatypeCorp/nexus-and-continuous-delivery

Domänenvorschlag: Continuous Delivery
Enabling Tools
Development Environment
Runtime Environment
CD Tooling

CD Tooling
OC Powerpoint CI 2017 V 0.933 Seite 19
Domänenmodell: Subdomänen
Enabling Tools
Development Environment
Runtime Environment
CD Tooling
Runtime
Environmen
t
 VCS
 Ticket System
 Wiki
 Repositories
 Persistent Chat
 Provisioning App
 SSO (IAM)
 IDE / Editor / Entwicklungstools
 Build
 Test
 Deploy
 Release (Pipeline Orchestration)
 Log Management
 Monitoring
 Distributed Application Scheduler
 Configuration Management
 Service Discovery

Architekturtreiber / Qualitätsattribute identifizieren
 Definiere für die einzelnen Subdomänen die
Szenarien
 Definiere für die Gesamtlösung auch nochmal
Qualitätsziele
 Evaluiere später unterschiedliche Lösungen
gegen diese Ziele
 Vermeide: Jira ist aber besser als Gitlab Issue
Tracker
 Welche Treiber werden davon nicht erfüllt?
 Welche Trade-Offs gehe ich ein, wenn ich separates
Produkt wähle?

Architekturtreiber / Qualitätsattribute identifizieren
 Definiere für die einzelnen Subdomänen die
Szenarien
 Definiere für die Gesamtlösung auch nochmal
Qualitätsziele
 Evaluiere später unterschiedliche Lösungen
gegen diese Ziele
 Vermeide: Jira ist aber besser als Gitlab Issue
Tracker
 Welche Treiber werden davon nicht erfüllt?
 Welche Trade-Offs gehe ich ein, wenn ich separates
Produkt wähle?
Ticket
System

Problem
Domäne: Ticket
System
Domäne: VCS
Häufig werden
Probleme hier gelöst
… oder hier
Aber das Problem liegt häufig
hier

Kenne Deine Prozesse
Wie funktionieren Prozesse?

http://www.opensourcerers.org/continuous-delivery-using-paas/

Event Storming
 Einfach mehrere
Varianten zu
modellieren
 Welche Events lösen
Seiteneffekte in
anderen Domänen
aus?
 Welche Events
triggern andere
Prozesse?

Beispiele

Problem Lösung Kundensegment
Kleine Entwicklungsabteilungen ohne
dediziertes OPS know how
Digital Labs, die viele kurzlaufende
Experimente / Schnellbootprojekte
durchführen
 Viele, kurzlaufende Projekte
 Projekt-Ramp-Up Zeiten für Schnell-
bootprojekte zu lang
 Fokus auf Fachlichkeit
 Keine Ablenkung durch Infrastruktur-
management
 Reproduzierbarkeit für andere Regionen
(weltweit)
Randbedingungen
 Kein Cloud Lock In
 Nutzung einer separaten Installation des
Atlassian basierten "Enabling Stacks"
(Confluence, Jira, Bitbucket)
 Definierter Technologiestack (Entwicklung)
 OpenShift Plattform
(dedicated Modell für Entwicklung)
VCS Bitbucket
Wiki Confluence
Ticket System Jira
Repositories Sonatype Nexus
OpenShift Image
Repo
SSO Crowd
OpenID Connect
Provisioning App Eigenentwicklung
Log Management OpenShift
Monitoring OpenShift
Application Scheduler OpenShift
Service Discovery OpenShift
Configuration
Management
Nicht genutzt
CD Tooling Jenkins

Kleine Entwicklungsabteilungen ohne
dediziertes OPS know how
Digital Labs, die viele kurzlaufende
Experimente / Schnellbootprojekte
durchführen
 Viele, kurzlaufende Projekte
 Projekt-Ramp-Up Zeiten für Schnell-
bootprojekte zu lang
 Fokus auf Fachlichkeit
 Keine Ablenkung durch Infrastruktur-
management
 Reproduzierbarkeit für andere Regionen
(weltweit)
Randbedingungen
 Kein Cloud Lock In
 Nutzung einer separaten Installation des
Atlassian basierten "Enabling Stacks"
(Confluence, Jira, Bitbucket)
 Definierter Technologiestack (Entwicklung)
 OpenShift Plattform
(dedicated Modell für Entwicklung)
VCS Bitbucket
Wiki Confluence
Ticket System Jira
OpenShift Image
Repo
SSO Crowd
OpenID Connect
Provisioning App Eigenentwicklung
Log Management OpenShift
Monitoring OpenShift
Application Scheduler OpenShift
Service Discovery OpenShift
Configuration
Management
Nicht genutzt
CD Tooling Jenkins
OpenShift
dedicated
Atlassian
Toolstack
Bringe Unternehmens Standardstack
in die Cloud und lass andere sich um
die Laufzeitumgebung kümmern
Custom

 Wenige, langlaufende Projekte
 Kapazitätsanpassung mit Vorlauf möglich
 Anforderungen an DR sollen erfüllt
werden
Randbedingungen
 Nutzung von bekannten (im
Unternehmen) genutzten Produkten, wie
Jenkins, Gitlab, Standard-Docker, Ansible
 Keine zusätzlichen Lizenzkosten für
Entwicklungsplattform
 Umgebung von VMs
VCS gitlab
Wiki Confluence
Ticket System Jira
Docker Registry
Persistent Chat Rocket.Chat
SSO Kein SSO
Anbindung an AD
Provisioning App Kein Use Case
Log Management Graylog
Monitoring Prometheus /
Grafana
Application Scheduler Docker Swarm
Service Discovery Consul
Configuration
Management
Consul
CD Tooling Jenkins 1 / 2
Ansible / Python
Größere Entwicklungsabteilung ohne
besonderes CD Know How
Aktuell noch klare Trennung von
Verantwortlichkeiten für Plattformen /
Infrastruktur und Entwicklung

 Wenige, langlaufende Projekte
 Kapazitätsanpassung mit Vorlauf möglich
 Anforderungen an DR sollen erfüllt
werden
Randbedingungen
 Nutzung von bekannten (im
Unternehmen) genutzten Produkten, wie
Jenkins, Gitlab, Standard-Docker, Ansible
 Keine zusätzlichen Lizenzkosten für
Entwicklungsplattform
 Umgebung von VMs
VCS gitlab
Wiki Confluence
Ticket System Jira
Docker Registry
Persistent Chat Rocket.Chat
SSO Kein SSO
Anbindung an AD
Provisioning App Kein Use Case
Log Management Graylog
Monitoring Prometheus /
Grafana
Application Scheduler Docker Swarm
Service Discovery Consul
Configuration
Management
Consul
CD Tooling Jenkins 1 / 2
Ansible / Python
Größere Entwicklungsabteilung ohne
besonderes CD Know How
Aktuell noch klare Trennung von
Verantwortlichkeiten für Plattformen /
Infrastruktur und EntwicklungBest of Breed
"gewachsen"
"was ist die
minimalste
Lösung, die
uns dem
aktuellen Ziel
näher bringt"

Application platform as a service (aPaaS) is a PaaS
offering that supports application development,
deployment and execution in the cloud,
encapsulating resources such as infrastructure and
including services such as those for data management
and user interfaces.
(Source: Gartner Magic Quadrant aPaaS 2016)

Marketing Versprechen:
„We do the magic, you do the code“

Erfahrung mit Plattformen
 Kenne deine Anforderungen
 Kenne die Plattformgrenzen
 Managed Umgebungen weisen häufig Unterschiede zu on-premise Umgebungen auf
 Unterschiede sind dem Anbieter (oder deren Consultants) manchmal nicht bewusst
 Beispiele: Netzwerkzugriffe (nur HTTP oder auch TCP/IP)
 Achtung: Leaky Abstractions
 Lösungen sind tlw. nur zu finden, wenn man weiß wie die zugrunde liegende SW
funktioniert
 Lernkurve
 Andere Nomenklatur als häufig bekannt

Erfahrung mit Plattformen
 Wenn mehr als eine Plattform im Einsatz:
 Seid ihr wirklich sicher, dass ein Docker Image überall läuft?
 … uups wenn die Produktionsplattform stärkere Vorbedingungen hat
… etwa openshift mit root
 Das gilt auch bei mehreren Plattformen vom gleichen Hersteller

CC BY-ND 2.0, , https://www.flickr.com/photos/cenasdreams/22756699217

CC BY-SA 2.0 https://www.flickr.com/photos/marfis75/2145194044/

Zentrale Aussagen
 Kenne deine Use Cases / Architekturtreiber und deren Trade-Offs
 Es gibt nicht die eine Plattform, welche alle Bedürfnisse erfüllt
 Insbesondere bei mehreren Teams / Projekten / Produkten / Stakeholdern
 Betrachte mehrere alternative Lösungen, nicht nur deinen Favoriten
 Eine Plattform ist häufig eine technologische Lösung für ein
organisatorisches Problem (etwa fehlendes Know-How)
 Das kann nur eine Zwischenlösung sein
 Ist in einem bestimmten Kontext / mit bestimmter Philosophie entstanden. Versuche die
zu verstehen
 Neben Software Craftsmanship wird CD Craftsmanship wichtig
 Stolz qualitativ hochwertige und passgenaue Lösungen entwickeln
 Professionelle Nutzung und Kombination von Komponenten

http://thecattlecrew.net

Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung

Weitere ähnliche Inhalte

Was ist angesagt?

Ähnlich wie Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung

Mehr von OPITZ CONSULTING Deutschland

Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung

Hinweis der Redaktion