Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
+49 (0) 351/850 33-0

Verteilte Architektur auf der prio.conference 2010

Ralf Westphal in Double ActionVor ein paar Stunden hat die diesjährige prio.conference zum Thema „Verteilte Architektur“ ihre Tore geschlossen, was übrig bleibt, sind diverse in PowerPoint gegossene Präsentationen, einige Fotos und Videos, eine erkleckliche Anzahl Twitter Posts – und hoffentlich Köpfe voller Wissen, Eindrücke und Erinnerungen. Für alle, die nicht dabei sein konnten, hier eine kleine Reminiszenz.

Wie jedes vernünftige Märchen begann die Konferenz mit „Es war einmal…“ – nein, das ist kein Scherz! Es gab nämlich eine Märchenerzählerin, die in mehreren kleinen „Sessions“ über den Tag verteilt mit ihrer Märchenstunde einmal anders – Was Softwareentwickler aus der „Moral von der Geschicht“ lernen können die Tracks voller geballtem Wissen nicht nur auflockerte, sondern hier und da auch zum Nachdenken anregte. Da gab es das Märchen von Mäuschen, Vögelchen und Bratwurst (Moral von der Geschicht: Never change a running system!), den Gestiefelten Kater (interessant: der Vergleich von Programmierern mit Katzen) und die Geschichte von Hase und Igel (Moral von der Geschicht: Work smarter, not harder!).

Wer in der sich anschließenden Keynote Der Softwarearchitekt als Regisseur nun „Coding Inside Wissen“ erwartete, der täuschte sich. Der schweizerische Filmregisseur Ivan Engler zeigte stattdessen verblüffende Parallelen zwischen Softwareentwicklung und Filmproduktion auf und ließ keinen Zweifel daran, welche Aufgaben dem Softwarearchitekten zukommen. Erinnernswert für mich die 3 „Frameworks“ Hierarchie (klar und transparent), Kommunikation (Kurze Kommunikationswege, kein Micromanagement) und Vision (je klarer die Vision, desto weniger Motivierung und Kommunikation sind erforderlich) sowie das Zitat „Failing to prepare is preparing to fail“.

Danach zog es mich zu Verteilte Architekturen und ihre Qualitätsmerkmale mit Michael Wiedeking. Wer sich bereits mit den Basics zum Thema Softwarearchitektur befasst hat, konnte hier sein Wissen etwas auffrischen. Zum Nachdenken regten mich die folgenden Aussagen an:

  • Qualität ist eigentlich ein inneres Bedürfnis, aber: Software wird genau so gut wie ihre Umgebungsfaktoren
  • Exkurs in Lebensphilosophie:
    • Alles hat seinen Preis.
    • Man kann nicht alles haben.
  • Eine Architektur ist IMMER ein Kompromiss.
    • Es gibt keine wiederverwendbare Architektur.
    • Es können nur die Erfahrungen wiederverwendet werden.

In der folgenden Session The wizardry of Scaling zeigte Ayende Rahien,was er unter Skalierbarkeit versteht (dies auch bildlich in Form eines „extremly scalable“ Zuges voller „Außenmitfahrer“) und wie man zu diesem Ziel gelangen kann. Stichworte waren hier Caching, Tailoring, Divide & Conquer. Interessant auch die gängigen Fehlannahmen zum Thema Skalierung:

  • We can have a single view on the entire system
  • Single source of truth
  • One size fits all

Hier begegnete mir auch zum ersten Mal das „Buzzword“ der Konferenz CAP (Consistency, Availabilty, Partition tolerance – Pick any two! Alle 3 zusammen sind nicht möglich), wie sich herausstellen sollte, nicht zum letzten Mal.

Auch in Mechansimen für verteilte Kommunikation konfrontierte Martin Huber uns zuerst mit den 8 Fehlannahmen zu diesem Thema:

  • Das Netzwerk ist ausfallsicher.
  • Die Netzwerklatenzzeit ist gleich Null.
  • Datendurchsatz ist unendlich.
  • Das NW ist sicher.
  • Die NW-Topologie ändert sich nicht.
  • Es gibt nur einen NW-Administrator.
  • Die Kosten des Transportes sind Null.
  • Das NW ist homogen.

Danach ging er auf die möglichen Kommunikationsmuster ein und bewertete diese:

  • Socket Kommunikation (very basic)
  • File Transfer (via FTP zwischen Anwendungen kommunizieren)
  • Shared Database
  • Messaging (z.B. MSMQ)
  • RPC (z.B. DCOM, SOAP)
    • Maschinenlesbare Schnittstellenbeschreibungssprache, z.B. WSDL
    • Nachteil: Feste Kopplung durch Vorgabe der Datenformate
    • Achtung: SOAP unterstützt die 8 Fehlannahmen zu 100%
  • RESTful HTTP
    • Schnittstelle: Standardmethoden GET, POST, PUT, DELETE
    • durch unterschiedliche Repräsentationen ist losere Kopplung möglich

In Patterns für verteilte Architekturen stellte Michael Wiedeking diverse Patterns vor und bewertete diese hinsichtlich ihrer Eignung für bestimmte Einsatzgebiete. Namentlich waren dies Layers, Pipes & Filters, Blackboard, Microkernel, Broker, Workflow Engine, Asynchronous Completion Token (ACT), Leasing, Disposal, Lazy und Eager Akquisition.

Die Abschluss-Session des ersten prio-Tages war Command Query Responsibility Segregation mit Udi Dahan. Hier zum Nachlesen ein Blogpost vom Meister selbst sowie die gezeigten Folien.

Nach dem leckeren Abendessen zog es mich noch zum Coding Dojo mit Ralf Westphal und Stefan Lieser. Da beide sich sehr zurückhielten, ging es beim Coden bald ziemlich anarchisch zu – jeder verwarf erst einmal die begonnene Lösung seines Vorgängers. Irgendwann brachten mein Nachbar und ich eine eigene Lösung „zu Papier“ – dort funktionierte zwar am Ende etwas mehr als in der Gemeinschaftslösung, aber wir befanden sie als durchaus refactoring-würdig. Mitgenommen habe ich mir: Test Driven Design ersetzt nicht das technische Konzept für eine Lösung! Wenn man immer nur den kleinstmöglichen nächsten Schritt implementiert, ohne das Gesamtziel vor Augen zu haben, kann es schnell passieren, dass man sich „verzettelt“ und am Schluss nur Randfälle implementriert hat.

Der nächste Tag begann mit Bounded Contexts und Stefan Lieser. Aus Sicht eines Onlineshops ist der Begriff Kunde mit einer anderen Vorstellung verbunden als im Kontext des Fulfillments oder der Buchhaltung. Warum also nicht die Kontexte auch in der Softwareentwicklung klar trennen? Die Folge ist, dass jeder Bounded Context als eigenständiges Programm mit jeweils eigener Datenhaltung implementiert wird. Stefan zeigte die Vorteile, aber auch die Herausforderungen („Eventual Consistency“ – schlussendlich ist das System konsistent, aber zwischenzeitlich kann es inkonsistent sein) bei Verwendung von Bounded Contexts auf. Und natürlich war auch CAP wieder mit von der Partie ;-).

In Cloud, On-Premise & Co. war es Golo Roden offensichtlich ein Herzensbedürfnis, nach all den werbewirksamen Lobgesängen auch einmal einen kritischen Blick auf dieses Thema zu werfen. Die Nachteile sind nicht nur vielfältig, sondern auch gravierend: Datenschutz und Sicherheit sind zwar die nächstliegenden Aspekte, aber nur die Spitze des Eisbergs…

Fazit:

  • Die Cloud ist keine Silberkugel.
  • Es gibt Vor- und Nachteile.
  • „It’s just another platform.“
  • Letztlich: „The right tool for the right job.“

Danach konfrontierte Ayende Rahien uns in That NoSQL Thing noch einmal mit den 8 Fehlannahmen für Verteilte Anwendungen. Und natürlich durfte auch CAP nicht fehlen. Where the relational model fails:

Folgende NoSQL-Lösungen stellte Ayende vor:

Gegen Ende gab es dann noch einmal Udi Dahan: High availability – a contrarian view. Udi stellte die heute üblichen Hochverfügbarkeitslösungen vor und ging auf offene Probleme (Zuverlässigkeit bei Crash des Webservers, bei Datenbank-Deadlocks, Verfügbarkeit bei Updates) ein. Natürlich gab es für die Probleme auch Lösungsansätze (z.B. Queuing der Messages auf dem Webserver). Die Folien gibt es hier zu sehen. Schlusssatz von Udi: “High availability leads to high agility”.

Die Abschlusskeynote Event-Based Components als Bausteine verteilter Anwendungen bestritt Ralf Westphal. Die Kernfrage war: „Softwarebausteine zusammenstecken wie Legobausteine – ist das möglich?“ Ralfs Antwort: „Ja, das ist möglich und gar nicht schwer.“ Das Problem sind die Abhängigkeiten zwischen den Bausteinen. Diese gilt es aufzulösen. Dann ist schon das folgende, von Ralf skizzierte Szenario vorstellbar: Brad Pitt wirft seine Hemden in die Luft und fragt „Wer bügelt die mir?“ Irgendjemand wird sie auffangen und bügeln. Vielleicht ist es gerade mal Angelina Jolie. Vielleicht aber auch die Putzfrau. Das nennt man dann Softwareentwicklung 2.0. No Comment.

Kommentar hinterlassen


Pin It on Pinterest