>

GST038 - Microservices aus dem Gewürzregal

Synopsis: Uwe Friedrichsen nimmt uns mit auf eine historische Rundreise der IT-Geschichte und schafft eine Grundlage, um aktuelle Problematiken der Unternehmenswelt zu verstehen. Durch die Veränderung der Märkte und Organisationsstrukturen in den letzten Jahrzehnten wuchs die IT als Nervensystem eines jeden Unternehmens heran. Dies bedingt eine Wechselwirkung zwischen den organisatorischen Strukturen eines Unternehmens und dem Architekturdesign der Softwarelösungen.

Uwe Friedrichsen (00:00:00)

  • Uwe Friedrichsen, CTO bei codecentric.de
  • Seit über 30 Jahren in der IT Szene unterwegs
  • Hat Kinder, Studieren bereits
  • Vor 33 Jahren erste kommerzielle Software verkauft
  • Hat Informatik studiert
  • Hat so ziemlich alles gemacht rund um Softwareentwicklung
  • Von Anforderungserhebung über Architekturdesign und Entwicklung bis Testmanagement
  • Aktuell für thematische Entwicklung und Aufstellung von codecentric.de zuständig
  • Interesse an skalierbare verteile Systeme

Trendgeschichte der IT (00:06:00)

  • Erste Züge von CORBA mitbekommen
  • Anschließend JAVA Komponenten (EJB)
  • SOA Welle mit SOAP
  • WS* Standards
  • RESTafarians
  • Funktionsorientierung vs Ressourcenorientierung
  • Objekte als Ressourcen?
  • Ressourcen auf Funktionen aufsetzen?

Designgrundlage: UseCase (00:14:00)

  • Viele versuchen Ressourcenmodell auf Entitätsmodell aufzubauen
  • Sinnvollerer Ansatz: UseCase Modell
    • Ressource soll Ende-zu-Ende Dienstleistung anbieten
    • System nach UseCases zuschneiden
    • UseCases sinnvoll kapseln
    • Services autonom gestalten

Problem etablierte Ansätze und Konzepte (00:21:20)

  • CORBA, ECB, SOA
    • Fingen alle mit fluffiger, leichter Idee an
    • Niedrige Lernkurve
    • Dann ging Fragerei los (was ist mit Naming? wie ist das mit verteilten Transaktionen?, usw.)
    • Einzelne Lösungen für immer mehr Probleme
    • Ansätze unter eigener Last zusammengebrochen
  • REST ist REST geblieben

Qualitativer unterschied zwischen Server und Mainframe (00:29:00)

  • Mainframe
    • Hat das Verfügbarkeitsproblem und das Verteilungsproblem für lange Zeit sehr gut gelöst
    • War von seiner Hardware so gestaltet, dass er extrem hoch verfügbar ist
    • Hat hervorragendes Ressourcenmanagement (Ressourcenallokation)
    • Für frühere Verhältnisse sehr vertikal skalierbar
    • Keine Notwendigkeit für Verteiltheit
    • Man konnte alles auf einer Maschine laufen lassen
    • EJB Container auf Steroiden
    • Auf einem 266er Pentium konnten simultan über 250 User bedient werden (Benchmark)
    • Extreme Verfügbarkeit durch Infrastruktur
    • Probleme
      • Schwierigkeit für international agierende Unternehmen
      • Monolitisches System für lokal verteilte Nutzer
      • Geschäftsmodelle haben sich geändert
      • Neukunden steigen nicht mehr mit Mainframe ein
      • Neugeschäft dümpelt auf sehr niedrigem Niveau
      • Vertikale Skalierung ist irgendwann zu ende
      • Preise für CPU, Storage und Netzzeit sind irgendwann nicht mehr konkurrenzfähig
      • Fehlendes Know-How und Preis töten Mainframes
      • Ära ist einfach vorbei
    • Anekdote von Uwe
      • Kunde mit Online Suchmaschine
      • 2 große Unix-Maschinen
      • Darauf liegt sehr namenhafte Suchmaschine
      • Lizenzkosten waren sehr hoch (jährlich im 7-stelligen Bereich)
      • (SLA) 300 Anfragen/s mit der Antwortzeit von 250ms
      • "Das können wir billiger."
      • 3 normale "Kisten" von Dell (o.ä.) mit 2 Xenon, 12 Kerne (24 virtuell)
      • ca. 5000€ pro Kiste
      • 20 Mio. Datensätze des Kunden
      • Proof of Concept System: MongoDB, Solr, UI
      • Lasttest wurde bei 3000 simultanen Clients wurde abgebrochen, weil das Testnetz nicht mehr Leistung hergegeben hat
      • Es konnte nicht mehr Durchsatz erzeugt werden
      • Normale Kiste lief im "Idle"; es wurde nur eine von drei benötigt

Ab wann ist Data Big? (00:41:50)

  • 20 Mio. Datensätze ist Micky Mouse Data
  • IBM Mitarbeiter erzählte das BigData bei 40MB anfängt
  • BigData ist dann, wenn du wirklich viele Daten bekommst!
  • BigData sind Datensätze im Milliardenbereich
    • 20 Mio. Datensätze kann man entspannt in relationaler Datenbank verwalten
    • BigData ist auch, wenn man Daten so schnell bekommt (Velocity-Thema), dass man nicht mehr in der Lage ist, diese zu speichern und dann zu bearbeiten, sondern im vorbeifliegen bearbeiten muss

Angemessene Lösungen finden (00:44:40)

  • Ziel ist es immer, eine angemessene Lösung zu finden
  • Kunde will Hadoop Cluster für 20 Mio. Datensätze
  • Mit Hadoop hat man mehr Stress
  • Diese Menge an Daten kann man entspannt in transaktionaler Datenbank verwalten
  • Weniger komplexes Programmiermodell
  • Unterschied ob man im Moment kein echtes BigData hat aber Thema lernen will
  • ODER
  • Ob man in einem Produktionsszenario ist, Wartung, Betrieb, Weiterentwicklung etc. hat und BigData Technologien einsetzen will
  • Ergebnis ist dann oftmals:
    • Betrieb wird aufwendiger,
    • Überwachung wird aufwendiger,
    • Rausfinden was schief geht, wird aufwendiger
    • Tooling ist schlechter
    • Laufzeiten sind höher,
    • Mehr Ressourcen werden benötigt,
    • Weiterentwicklung ist lausiger
  • --> Dann wurde keine gute Designentscheidung/Architekturentscheidung getroffen

Spieltrieb (00:48:05)

  • Jeder, der in die IT Branche kommt, weil er gerne programmiert, hat ausgeprägten Spieltrieb
  • Problem ist, dass Unternehmen diesen kreativen Menschen jedoch kein Ventil für diesen Spieltrieb geben
  • Diese Menschen wollen neue Dinge irgendwo ausprobieren
  • Das nächste Projekt wird dann als Spielwiese missbraucht

Entscheider und Entscheidungen (00:49:40)

  • Sehr viele IT Entscheider haben keine Ahnung was sie da entscheiden
  • Zwei Möglichkeiten: entweder was von der Materie verstehen oder man braucht einen Vertrauten, der etwas davon versteht
  • Es gibt zu viele Entscheider die ihre Themen nur auf Basis von Computerwoche verstehen
  • Computerwoche ist Bildzeitung der Computerbranche
  • Artikel sind Informationshäppchen, die nicht in die Tiefe gehen
  • Keine Grundlage für Entscheidung, die sich auf Unternehmen auswirkt
  • Entscheider versuchen sich über diese Zeitung zu informieren
  • Letztendlich Entscheidung auf Basis von Buzzword-Bingo durch Zeitung, Marketing, Sales- und Consultants

Buzzword Standards (00:53:00)

  • Buzzwords wie Agil, Microservices, ... lassen Interpretationsspielraum
  • Problem der Verwässerung
  • Multimilliardenmarkt IT Branche ist von Entscheidern durchsetzt, die keine Ahnung haben
  • Bzw. keine Ahnung auf der Ebene, als dass sie sagen können: "Du erzählst mir gerade hier jede Menge Bullshit."
  • Anforderung: Auf einer Flughöhe von 3000m sollte ein Entscheider ein Verständnis dafür haben, was da unten passiert
  • Grundverständnis aufbauen, was das tut, warum das tut, usw...

Microservices aus dem Gewürzregal (00:56:00)

  • Kunde macht neues System und das soll auch mit Microservices
  • Will eigtl. klassischen Deploymentzyklus haben (1 Mal im Monat)
  • Skalierung reicht wenn man innerhalb von 1-3 Tagen skalieren kann
  • Gegenüberstellung von monolitischem System und Microservices
  • In 10 Minuten erzählt, was das ist und wo die Unterschiede sind, Vor- und Nachteile aufgezeigt
  • Spannungsfeld zwischen den beiden Entwürfen
  • Dann gefragt, was er haben will
  • --> für Monolit entschieden

Monolitische Microservices zur Laufzeit (00:59:13)

  • Abhängigkeiten von Services zur Build-Zeit auflösen
  • Services, im Java Umfeld, als Jar File im Repo reinnehmen
  • Einbinden von Bibliotheken in Anwendung, die an sich unabhängig sind
  • Zur Laufzeit von aussen wie ein Monolit, der zur Build-Zeit aus einzelnen Services zusammengesetzt wird
  • Nachteil: man hat immer Full Deployment
  • Wenn System logisch diese Komponenten rausgeformt hat, dann sollte der Schritt, dass man zur Laufzeit das System in unabhängige Komponten bringt, nicht mehr so weit hin sein
  • Services, die man hat, als externe Schnittstelle zur Verfügung stellen
  • Zur Laufzeit zugreifbar machen
  • Problem: man hat verteiltes System
    • Bislang hatte man nur einen großen Brocken
    • Plötzlich hat man statt 2-3 deployment Einheiten, 20-30 Deployment-Einheiten
    • Jetzt schlagen die ganzen Verfügbarkeits-Wahrscheinlichkeiten zu

Verteilte Systeme (01:03:18)

  • Uwe ist absoluter Liebhaber verteilter Systeme
  • Es gibt 2 Harte Themen in der IT: Security und verteilte Systeme
    • Oder Naming und Cache-Invalidation?
  • Naming ist Teilaspekt von verteilten Systemen
  • Projekt mit guten Anwendungsentwicklern, die aber keine Cracks in verteilter Systementwicklung sind
    • Wenn ich die auf ein verteiltes System los lasse
    • Und gleichzeitig Sicherstellen, dass man das System zur Laufzeit überwachen kann
    • Dem System Selbstheilungsfähigkeiten beibringen
    • Da kein Admin ein System dieser Größe unter Kontrolle halten kann
    • Bevor ich mir diesen Schmerz nehme, brauch ich auch einen Treiber für diesen Schmerz

Einfluss von SOA und Microservices auf Organisationen (01:07:55)

  • Märkte haben sich verändert
  • Wir waren lange Zeit im industriellen Zeitalter, geprägt von Taylorismus
    • Sehr flexibel, sehr spezifisch, handgefertigt
    • Sehr individuell auf Kundenbedürfnisse eingegangen
    • Problem: Man konnte nicht skalieren
  • Heute hat man große, weite, nahezu unlimitierte Märkte
    • Wie will man diesen Markt bedienen?
    • --> Standardisieren
    • Vereinfachung und Zerlegung der einzelnen Schritte der Prozesskette
    • Dadurch relativ langsam sich veränderten Markt skaliert
  • (seit 70er/80er) Marktsättigung, stärkere Globalisierung
    • Märkte immer enger, die Kunden wurden wählerischer, mehr Wettbewerber
    • Plötzlich musste man wankelmütigen Kunden schneller angehen
    • Dynamisch robustes Unternehmen für dynamischen, sehr aktiven Markt
    • Nicht mehr skalierung das Hauptthema, sondern die Reaktionsgeschwindigkeit
    • "Time To Market"
  • Markt hat sich massiv gewandelt
    • Wirtschafts-Darwinismus
    • IT ist das Nervensystem eines jeden Unternehmens
      • IT hatte Skalierungsproblem
      • Problem war: es konnte nicht so schnell geliefert werden, wie es gefordert wurde
      • Ideen des Software Engineering (Ende 60er)
        • Prinzipien aus Taylorismus
      • 80er Siegeszug der PCs
      • Vernetzung
      • Immer komplexere Sachen durch IT gelöst
      • Bis auf Geschäftsprozessebene
      • Irgendwann kam Internet dazu
      • Internet Handel
      • Noch mehr Vernetzung
    • Gesamte IT Landschaft war soweit, dass es das komplette Nervensystem eines Unternehmens geworden ist
      • Jetzt haben wir das Problem:
        • Wenn IT 2 Stunden ausfällt, haben wir ein massives Problem.
      • Entscheider haben das wiederwillig akzeptiert
      • --> Sicherungsmaßnahmen wurden eingerichtet
      • Mit dem Ziel: Stabilen und zuverlässigen Betrieb
      • Problem Heute: Wenn IT Nervensystem des Unternehmens ist, dann sind sämtliche Geschäftsprozesse wie DNA in IT reincodiert
      • Man kann kein neues Produkt launchen, kein Feature, kein neuen Prozess auf der Businessebene ändern, ohne die IT anzufassen
      • IT ist integraler Bestandteil eines Unternehmens
  • IT als Nervensystem
    • Mittlerweile keine komplizierten Projekte mehr, sondern komplexe Projekte
    • Weil man nicht mehr einzelne Geschäftsfunktionen unterstützt, sondern kompletter Dynamik des Marktes ausgeliefert ist
    • Nicht mehr Anforderung, dass man skalieren muss, sondern dass die Reaktionsgeschwindigkeit das neue A und O wird
    • "Mehrwert ist erst in Produktion"
    • Anforderung von Geschäftsseite: *Man möchte in der Lage sein, etwas in Tages- oder Wochenzeitraum rausbringen
    • Teilfeature raus hauen, um die Kundenreaktion einzuholen

PDCA vs OODA (01:20:25)

  • Plan Do Check Act vs. Observe Orient Decide Act
  • Bei beiden macht man einen Schritt, guckt wie die Leute reagieren und macht den nächsten Schritt
  • Example A
    • Unternehmen stellt Hypothese auf:
      • "Kunden werden auf dieses Produkt fliegen."
    • Baut Produkt und ist nach 9-15 Monaten live
  • Example B
    • Lean Start Up
    • Hypothese
    • Man macht Minimal Viable Product
    • Bringt das raus, misst
    • Passt Produkt an
  • Frage: Wer wird nach einem Jahr näher an den Kundenbedürfnissen dran sein?

Organisationsstrukturen im Wandel (01:23:15)

  • Aufstellung nicht mehr nach Skalierung und Fehlervermeidung, sondern nach Reaktiongeschwindigkeit
  • Reaktionsgeschwindigkeit benötigt autonome Teams, dezentrale Steuerung, usw...
  • Ende zu Ende Verantwortung für meine Themen
  • Man landet bei DevOps,
  • Wertschöpfungskette wird nicht mehr nach Spezialistenteams aufgebaut, mit dem Ziel der maximalen Fehlervermeidung
  • Sondern jetzt mit dem Ziel der Reaktionsgeschwindigkeit
  • Daher crossfunktionale Teams, die Ende zu Ende alles machen können
  • Die ganzen Leute sind beieinander und interagieren direkt miteinander
  • Notwendige Komplexität auf der Lösungsseite aufgebaut, die auf der Anforderungsseite entsteht
  • "Die Architektur meines Systems wird normalerweise immer der Kommunikationsstrukturen in meinem Unternehmen entsprechen." - Conway's Law
  • Organisation kann nur effektiv und effizient werden, wenn Architektur, die ich auf der technischen Seite anbiete, zur Unternehmensstruktur passt
  • Problem: Man kann keine autonomen Teams, die reaktionsschnell sein sollen, auf einem großen Monoliten zusammen arbeiten lassen
  • Microservices liefern das Architekturparadigma, um diese Autonomie auf der IT-Organisationsebene zu liefern
  • Wird über DevOps Teams abgebildet

Von Visionen und Agilität (01:27:30)

  • Man Benötigt eine gemeinsame Vision
  • Aufgabe eines Architekten ist es die Vision darzustellen, das Zielbild
  • Agile Teams: Selbstorganisation als indirekte Steuerung
  • "Ich will, dass ihr da ankommt, unter diesen Rahmenbedingungen."
  • Man muss Lücken zwischen Teams füllen
  • Team muss mit Services von anderen Teams reden
  • Damit Kommunikation zwischen Teams und Services funktioniert, muss es Satz an Constraints geben
  • Spielregeln zur effizienten Zusammenarbeit definieren
  • Auf Prozessebene hat man Agilität der Lean- und DevOps Prinzipien
  • Auf Organisationsebene fängt man mit autonome Teams an, End-to-End Verantwortung
  • Auf menschlicher Seite hat man Craftmanship
    • bzw. die Gedankenwelt hinter Craftmanship: Professionalisierung der Arbeitsweise und Kollaboration miteinander
  • Auf technischer Ebene wird Diversität zugelassen:
    • Microservices
    • Cloudinfrastruktur
    • Self-Service-Prinzip

Der Homo-Ja-Aber (01:35:40)

  • Unternemerischer und Organisatorischer Wandel ist die Hölle, besonders in Deutschland
  • Hindernisse in der deutschen IT Szene:
    • Der Deutsche ist die Weiterentwicklung des Homosapians in den Homo-Ja-Aber
    • Der Deutsche neigt dazu, Gründe gegen eine Veränderung zu finden
    • SWAT Analyse (aus Marketing), Deutsche guckt nur auf Weaknesses und Threats
      • Beharrungsvermögen der Deutschen (Ja, aber...)
    • Unternehmen haben Kultur, die seit 20 Jahren oder länger entwickelt wurde
      • Deutsche Unternehmen sind träger
    • Viele Unternehmen stellen fest, dass sie ein Problem haben, dass es so nicht weiter gehen kann
    • Erkennen, dass sie sich ändern müssen, haben jedoch keine Idee wohin und wie
  • Viele Unternehmen bauen Piloten nebenan, StartUps im Unternehmen
    • Wird so weit wie möglich entkoppelt
    • Ist notwendig, da man bis hin zu Governance Modellen (Führung, Steuerung) die IT neu gedacht werden muss
    • Man will hohe Reaktionsgeschwindigkeit erschaffen in den Teams
    • Entkopplung von dynamischen, agilen Teams aus trägem System
    • Um zu lernen, wie anderer Ansatz funktioniert, muss sich so weit wie möglich entkoppelt werden
  • Zu verstehen wie neue Struktur funktioniert ist Lernzyklus
    • Man muss Zyklus auf Metaebene durchlaufen
      • Bis man kapiert hat wie neue Organisation auf allen Ebenen wie Technologie, Prozessorganisation und Governance Modell funktioniert

Unternehmen bei denen der Wandel funktioniert hat? (01:45:40)

  • Bei Otto wurde Shop neu aufgestellt, mit neuen Prinzipien, sowohl technisch als auch organisatorisch
  • Bei der Post ist man mit einigen internen StartUps unterwegs
  • Telekom hat auch Ansätze in dieser Richtung
  • Einige weitere versuchen es
  • Bei Organisationen, die einen hohen Wettbewerbsdruck haben, sieht man Änderungen massiv

Ausnahmen (01:51:00)

  • Wann kann ich mich dem Wettbewerbsdruck entziehen?
    1. Wenn ich einen nicht-effizienten Markt habe
      • Markt wird künstlich träge gehalten (Lobbyismus)
    2. Auf technischer Ebene
      • Wenn technische Ebene komplett intern ist und keinem Marktdruck ausgesetzt ist
    3. Produkt-Lebenszyklus:
      • Neues Produkt, dass ich durch die IT unterstütze, bzw. IT ist selber das Produkt
      • Boston Consulting Group Hype Cycle
      • Versuche rauszufinden, was die Kunden haben wollen
      • Kosten überschaubar halten
      • Ding hebt ab
      • Mich interessiert keine Kosteneffizient
      • Versuchen jeden potentiellen Kunden auf mein Produkt drauf kriegen
      • Solange dran drehen (IT Systeme nacharbeiten) bis ich maximalen Marktanteil rausgeholt habe
      • Dann wechsel ich den Zyklus in Cash Cow rüber
      • Markt ist klar, Anteile sind vergeben
      • Reaktionsgeschwindigkeit runter fahren, Kosteneffizienz hoch fahren
      • Kann in anderes Paradigma wechseln, rein auf Kosteneffizient trimmen
      • Quality of Service wird aufrecht erhalten, um keine Kunde zu verlieren

Von Null auf Legacy in unter 3 Monaten (01:56:00)

  • Agile Projekte die nur Code gekloppt haben
  • Velocity ist runter gegangen
  • Der normale ITler ist ein Messi, löscht keinen Code
  • Man hat auf der Fachseite Leute die gar nicht wissen warum Sachen gemacht werden, sondern nur wie sie gemacht werden
  • Haben den Sinn nicht verstanden
  • Auf der IT Seite hat man sehr viele Entwickler, die sich wehren Fachlogik zu verstehen
  • können daher kein gutes Design machen und wissen nicht, ob Code noch irgendwo gebraucht wird

Beim neu Bauen wird alles besser (02:00:30)

  • Wenn ein System komplett neu gebaut wird, begeht man zwar die alten Fehler nicht mehr, dafür aber sehr viele neue
  • Man hat keine Chance wenn man keine guten Leute im Design hat
  • Wenn man ein gutes, wartbares System haben möchte, ist Design das wichtigste
  • Unternehme erkennen nur schwer: Wenn ich so etwas hoch ziehe, muss ich gute Leute reinsetzen, die Dinge gut beurteilen und abwägen und entscheiden können
  • Das sind dann die Leute, auf die man dann in einem kosteneffizienten Unternehmen niemals in dem Fachbereichen verzichten kann, weil sie unersetzlich sind
  • Hybridlösung: 30% der Zeit, Tauchen 2 Stunden die Woche mal auf
  • Entwickler sind wo anders untergebracht als der Fachbereich: verteilte Entwicklung
  • Das macht es schwierig
  • Idealzustand:
    • Crossfunktionales Team
    • Alle Kompetenzen vorhanden
    • Alle vor Ort
    • Idealerweise in einem Büro
    • Wenn das richtig gemacht ist, kann das gut funktionieren.

Schlusswort (02:08:20)

  • Markt hat sich geändert
  • IT muss sich darauf anpassen und sich neu erfinden
  • Amazon, Google, Netflix usw. haben vorgemacht wie es funktionieren kann
  • haben Lernkurven hinter sich. Da kann man wunderbar drauf gucken
  • man muss aufhören Ja-Aber zu sagen und gucken, was man da raus ziehen kann

Info:

  • Veröffentlichung:
  • Autor:
    Dirk Breuer, Sebastian Cohnen
  • Link:
    Website
  • Abonnieren:
    Feed