Geekstammtisch
Geekstammtisch
Dirk Breuer, Sebastian Cohnen
Episodes
About
Reviews
Promote
GST038 - Microservices aus dem Gewürzregal
2 hour 11 minutes Posted Feb 3, 2016 at 9:32 am.
Uwe Friedrichsen
Trendgeschichte der IT
Designgrundlage: UseCase
Problem etablierte Ansätze und Konzepte
Qualitativer unterschied zwischen Server und Mainframe
Ab wann ist Data Big?
Angemessene Lösungen finden
Spieltrieb
Entscheider und Entscheidungen
Buzzword Standards
Microservices aus dem Gewürzregal
Monolitische Microservices zur Laufzeit
Verteilte Systeme
Einfluss von SOA und Microservices auf Organisationen
PDCA vs OODA
Organisationsstrukturen im Wandel
Von Visionen und Agilität
Der Homo-Ja-Aber
Unternehmen bei denen der Wandel funktioniert hat?
Ausnahmen
Von Null auf Legacy in unter 3 Monaten
Beim neu Bauen wird alles besser
Schlusswort
0:00
2:11:44
Download MP3
Show notes
Wir sprachen mit Uwe Friedrichsen über IT-Geschichte, SW Architektur und mehr
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?
Wenn ich einen nicht-effizienten Markt habe
Markt wird künstlich träge gehalten (Lobbyismus)
Auf technischer Ebene
Wenn technische Ebene komplett intern ist und keinem Marktdruck ausgesetzt ist
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
← See all 42 episodes of Geekstammtisch
Podbay © 2026 Fancy Soups
About