Geekstammtisch

Mehr oder weniger regelmäßiger Stammtisch rund um Geektum, (Web)development und was immer unsere Gäste an interessanten Dingen zu erzählen haben

https://geekstammtisch.de/

subscribe
share





GST005 - HistorieLöschenService


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.

Unser Gast
  • 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
Architektur
  • 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
  • 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 und Testing
  • 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
SOA: Service-oriented Architecture
  • 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
  • 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
Olivers kleine Geschichte zu Open Source
  • 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


share







 2013-02-14  1h26m