Geekstammtisch

Unser Gast ist heute: Oliver Jucknath (http://www.jubeco.de/)

Synopsis: Heute geht es um (Software) Architektur, Testing, Agile Entwicklung in großen Teams und SOA. Außerdem bietet unser Gast einige interessante Einblicke in seine Erfahrung mit Großprojekten.

• Oliver ist Entwickler, SOA Evangelist, Architekt und Social Debugger
• Angefangen zu programmieren mit 11, macht aktuell vor allem Java
• lange Zeit Entwickler gewesen
• mittlerweile mehr in Richtung Consulting
• schreibt auch Computerspiele Service-orientiert

• Was ist Architektur? Auswahl von Tooling, Deployment, Performance, ...
• Manchmal ist etwas neu entwickeltes weg werfen und neu machen eine sehr gute Idee
• Explorative Architektur
• Oliver hat einen sehr weiten Blick auf Architektur
  • Architektur fängt bei der fachlichen Seite an
  • …und endet beim Entwickler
• Oliver hat Konzerne mit Write-only Architekturen erlebt, wo ein Architekt ein System baut, ohne wirkliches Feedback zu bekommen
• Oliver's kleinstes Projekt: nur er selber – das größte 2000 Entwickler
• Erste Grundregel des Consultings: "Arbeite nicht für einen dummen Chef"
• Task Force: Projektarbeit unter extremen Umständen. Weit über Time & Budget. Projektrettung.
• Der Übergang von Architekturaufgaben zum Entwicklungsprozess sind teilweise fließend

• Agile Entwicklung zielt darauf ab, immer wieder lauffähige Zwischenergebnisse zu erzielen
• Lieber eine Woche in die falsche, dann zwei Wochen in die fast richtige und dann in die richtige Richtung laufen
• Clean HEAD, Dirty HEAD
  • Lieber Clean HEAD, nur in Ausnahmesituationen Dirty HEAD

• Continuous Deployment ist für viele der heilige Gral
• Continuous Deployment erfordert zwingend kontinuierliches Testen
• Oliver: "Testen ist Teil der Architektur"
• Durch zu vieles (Unit) Testen, kann die Agilität abnehmen (viele Tests für einen kleinen Change)
• Oliver bevorzugt mittlerweile Application Level Testing (z.B. mit jmeter)
• Entwickler sind häufig keine guten Tester (falsche Perspektive)
• Ab Teams mit sieben Entwicklern, würde Oliver gerne einen Tester dabei haben
• In großen Unternehmen, haben Entwickler keinen Einblick in Produktionsdaten und können somit nicht immer verstehen, was die Benutzer brauchen.
• Olivers Debugging Abenteuer: Es gab bei einem großen deutschen Telco mal ein Handy für 87 Fragezeichen
• Testing auf einer pre-Stage Umgebung (siehe Continuous Deployment)
• Optionale Service Parameter und Featureflags (Loose Coupling)
• Continuous Deployment (CD) ist richtig teuer:
  • gute Entwickler
  • vernünftiges Projektmanagement
  • Pre-Stage Hardware
• Wo lohnt sich CD?
  • Handelsplattformen, Banken, die sich schnell auf Situationen einstellen müssen
• Bei kleinen Projekten: CI und CD machbarer
• Man will aber in jedem Fall Metriken haben, das ist (natürlich) auch ein Thema für die Architektur

• Oliver: Der Sprung zur SOA ist wie der Sprung zur Objekt-orientierten Programmierung
• Änderungen an einem System über fünf Jahre bei einer großen Telco
  • GUI: extrem viele Änderungen, sehr variabel
  • Datenbank: ebenfalls nicht sehr stabil
  • Services: sind am stabilsten
• Was ist ein Service?
• Ein Service ist eine Schnittstelle zu einer fachlichen (selten technisch) Funktionalität, die unabhängig von der Implementierung ist
• Service Anti-Pattern: Ein Service, der eine OO-Schnittstelle, exportiert.
• Ein Service muss die Fachlichkeit beschreiben, dass können am besten Leute aus der Fachseite
• Entwickler passen sich besser an die "komischen" fachlichen Services an, als die Fachseite an die Services, die Entwickler definieren würden.
• Services sind NICHT Objekt-orientiert!
• Reusability ist keine gute Idee für Services, mehrfache Verwendung durch verschiedene Kanäle ist hingegen eine gute Idee
• "Menschen denken nicht Objekt-orientiert"
• Services sind leichtgewichtig, man kann sie einfacher ändern, oder neue, parallel zu bestehenden einführen
• Noch ein Anti-Pattern: "Do what I mean Service", bestehend aus einem String "XML in" und Return-Wert "XML out"
• Services sollen wohl definiert sein
• Ein Service-Bus ist ein zentrales Medium, welches benutzt wird, um als Servicenutzer einen Service aufzurufen.
• Ein Bus kann auf fachlicher Ebene beobachtet werden, denn auf dem Bus werden Fachliche Dinge versendet
• Vor SOA war EAI (http://en.wikipedia.org/wiki/Enterprise_application_integration)
• SOA Architekturen haben eine bessere Performance als andere Architekturen
• Mit CRUD fährt man SOA mit richtiger Wonne gegen die Wand
• Und CRUD ist der Tot jeder Performance
• Der (nächste) heilige Gral: Modellierung von Prozessen
• Wechsel im Medium sind ein Problem: Anmeldung via Webseite, Support via Telefon
• Was man will: Eine Business Process Engine (im Prinzip eine große State Machine)
• Ein Prozess mit persistiert werden können
• Eine SOA in Kombination mit einer Process Engine erlaubt es sehr gute Beobachtungen und Aussagen über Systeme und Geschäftsabläufe zu treffen

• Die Cloud ist interessant für Architekten
• …hat aber auch eigene Schwierigkeiten: z.B. anvertrauen von Daten
• Cloud ist hervorragend um (hoch) parallel und mit hoher Verfügbarkeit zu arbeiten
• …setzt aber viel Knowhow im Bereich Kryptographie voraus
• Oliver würde User Authentifizierung nicht in der Cloud machen
• Warum will man in die Cloud?
  • Geringere Kosten
  • Hohe Verfügbarkeit
  • Hohe Sicherheit
• Oliver meint, dass hohe Verfügbarkeit ist kein wirkliches Argument für die Cloud ist, weil heutige Hardware ohnehin sehr gut ist
• 90% der Downtimes sind Security Relevant, der Rest ist meist ein Fehler von Entwicklern
• Daher hauptsächlicher Grund für Downtimes: Security
• Pro Cloud: Anonymous Angriff auf Amazon, gemerkt hat Amazon aber kaum was

• Kleine Firma und StartUps: Open Source, yeah!
• Dann wird es ernst und die Firma seriös: Wir können uns Oracle leisten!
• Dann will man aber five-nines Uptime haben… das geht nur noch mit Open Source, weil man ggf. selber Dinge patchen muss
• Weil: Stecker ziehen ist schlecht für die Uptime
• Unterm Strich will man alle Systeme, die an der Front stehen, in Open Source haben