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
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