Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Verteilte Architektur auf der prio.conference 2010

Ralf Westphal in Double ActionVor ein paar Stunden hat die dies­jäh­rige prio.conference zum Thema "Verteilte Architektur" ihre Tore geschlos­sen, was übrig bleibt, sind diverse in PowerPoint gegos­sene Präsentationen, einige Fotos und Videos, eine erkleck­li­che Anzahl Twitter Posts – und hof­fent­lich Köpfe vol­ler Wissen, Eindrücke und Erinnerungen. Für alle, die nicht dabei sein konn­ten, hier eine kleine Reminiszenz.

Wie jedes ver­nünf­tige Märchen begann die Konferenz mit "Es war ein­mal…" – nein, das ist kein Scherz! Es gab näm­lich eine Märchenerzählerin, die in meh­re­ren klei­nen "Sessions" über den Tag ver­teilt mit ihrer Märchenstunde ein­mal anders – Was Softwareentwickler aus der "Moral von der Geschicht" ler­nen kön­nen die Tracks vol­ler geball­tem Wissen nicht nur auf­lo­ckerte, son­dern 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 run­ning sys­tem!), den Gestiefelten Kater (inter­es­sant: der Vergleich von Programmierern mit Katzen) und die Geschichte von Hase und Igel (Moral von der Geschicht: Work smar­ter, not harder!).

Wer in der sich anschlie­ßen­den Keynote Der Softwarearchitekt als Regisseur nun "Coding Inside Wissen" erwar­tete, der täuschte sich. Der schwei­ze­ri­sche Filmregisseur Ivan Engler zeigte statt­des­sen ver­blüf­fende Parallelen zwi­schen Softwareentwicklung und Filmproduktion auf und ließ kei­nen Zweifel daran, wel­che Aufgaben dem Softwarearchitekten zukom­men. Erinnernswert für mich die 3 "Frameworks" Hierarchie (klar und trans­pa­rent), Kommunikation (Kurze Kommunikationswege, kein Micromanagement) und Vision (je kla­rer die Vision, desto weni­ger Motivierung und Kommunikation sind erfor­der­lich) sowie das Zitat "Failing to pre­pare is pre­pa­ring 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 auf­fri­schen. Zum Nachdenken reg­ten mich die fol­gen­den Aussagen an:

  • Qualität ist eigent­lich ein inne­res Bedürfnis, aber: Software wird genau so gut wie ihre Umgebungsfaktoren
  • Exkurs in Lebensphilosophie: 
    • Alles hat sei­nen Preis.
    • Man kann nicht alles haben.
  • Eine Architektur ist IMMER ein Kompromiss. 
    • Es gibt keine wie­der­ver­wend­bare Architektur.
    • Es kön­nen nur die Erfahrungen wie­der­ver­wen­det werden.

In der fol­gen­den Session The wizardry of Scaling zeigte Ayende Rahien,was er unter Skalierbarkeit ver­steht (dies auch bild­lich in Form eines "extremly scala­ble" Zuges vol­ler "Außenmitfahrer") und wie man zu die­sem Ziel gelan­gen kann. Stichworte waren hier Caching, Tailoring, Divide & Conquer. Interessant auch die gän­gi­gen Fehlannahmen zum Thema Skalierung:

  • We can have a sin­gle view on the ent­ire system
  • Single source of truth
  • One size fits all

Hier begeg­nete mir auch zum ers­ten Mal das "Buzzword" der Konferenz CAP (Consis­tency, Avai­la­bilty, Parti­tion tole­rance – Pick any two! Alle 3 zusam­men sind nicht mög­lich), wie sich her­aus­stel­len sollte, nicht zum letz­ten Mal.

Auch in Mechansimen für ver­teilte Kommunikation kon­fron­tierte Martin Huber uns zuerst mit den 8 Fehlannahmen zu die­sem 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ög­li­chen Kommunikationsmuster ein und bewer­tete diese:

  • Socket Kommunikation (very basic)
  • File Transfer (via FTP zwi­schen 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 unter­stützt die 8 Fehlannahmen zu 100%
  • RESTful HTTP
    • Schnittstelle: Standardmethoden GET, POST, PUT, DELETE
    • durch unter­schied­li­che Repräsentationen ist losere Kopplung möglich

In Patterns für ver­teilte Architekturen stellte Michael Wiedeking diverse Patterns vor und bewer­tete diese hin­sicht­lich 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 ers­ten prio-Tages war Command Query Responsibility Segregation mit Udi Dahan. Hier zum Nachlesen ein Blogpost vom Meister selbst sowie die gezeig­ten Folien.

Nach dem lecke­ren Abendessen zog es mich noch zum Coding Dojo mit Ralf Westphal und Stefan Lieser. Da beide sich sehr zurück­hiel­ten, ging es beim Coden bald ziem­lich anar­chisch zu – jeder ver­warf erst ein­mal die begon­nene Lösung sei­nes Vorgängers. Irgendwann brach­ten mein Nachbar und ich eine eigene Lösung "zu Papier" – dort funk­tio­nierte zwar am Ende etwas mehr als in der Gemeinschaftslösung, aber wir befan­den sie als durch­aus refactoring-würdig. Mitgenommen habe ich mir: Test Driven Design ersetzt nicht das tech­ni­sche Konzept für eine Lösung! Wenn man immer nur den kleinst­mög­li­chen nächs­ten Schritt imple­men­tiert, ohne das Gesamtziel vor Augen zu haben, kann es schnell pas­sie­ren, dass man sich "ver­zet­telt" und am Schluss nur Randfälle imple­men­triert hat.

Der nächste Tag begann mit Bounded Contexts und Stefan Lieser. Aus Sicht eines Onlineshops ist der Begriff Kunde mit einer ande­ren Vorstellung ver­bun­den als im Kontext des Fulfillments oder der Buchhaltung. Warum also nicht die Kontexte auch in der Softwareentwicklung klar tren­nen? Die Folge ist, dass jeder Bounded Context als eigen­stän­di­ges Programm mit jeweils eige­ner Datenhaltung imple­men­tiert wird. Stefan zeigte die Vorteile, aber auch die Herausforderungen („Eventual Consistency“ – schluss­end­lich ist das System kon­sis­tent, aber zwi­schen­zeit­lich kann es inkon­sis­tent sein) bei Verwendung von Bounded Contexts auf. Und natür­lich war auch CAP wie­der mit von der Partie ;-).

In Cloud, On-Premise & Co. war es Golo Roden offen­sicht­lich ein Herzensbedürfnis, nach all den wer­be­wirk­sa­men Lobgesängen auch ein­mal einen kri­ti­schen Blick auf die­ses Thema zu wer­fen. Die Nachteile sind nicht nur viel­fäl­tig, son­dern auch gra­vie­rend: Datenschutz und Sicherheit sind zwar die nächst­lie­gen­den Aspekte, aber nur die Spitze des Eisbergs…

Fazit:

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

Danach kon­fron­tierte Ayende Rahien uns in That NoSQL Thing noch ein­mal mit den 8 Fehlannahmen für Verteilte Anwendungen. Und natür­lich durfte auch CAP nicht feh­len. Where the rela­tio­nal model fails:

Folgende NoSQL-Lösungen stellte Ayende vor:

Gegen Ende gab es dann noch ein­mal Udi Dahan: High avai­la­bi­lity – a con­tra­rian view. Udi stellte die heute übli­chen 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 avai­la­bi­lity leads to high agility”.

Die Abschlusskeynote Event-Based Components als Bausteine ver­teil­ter Anwendungen bestritt Ralf Westphal. Die Kernfrage war: "Softwarebausteine zusam­men­ste­cken wie Legobausteine – ist das mög­lich?" Ralfs Antwort: "Ja, das ist mög­lich und gar nicht schwer." Das Problem sind die Abhängigkeiten zwi­schen den Bausteinen. Diese gilt es auf­zu­lö­sen. Dann ist schon das fol­gende, von Ralf skiz­zierte Szenario vor­stell­bar: Brad Pitt wirft seine Hemden in die Luft und fragt „Wer bügelt die mir?“ Irgendjemand wird sie auf­fan­gen und bügeln. Vielleicht ist es gerade mal Angelina Jolie. Vielleicht aber auch die Putzfrau. Das nennt man dann Softwareentwicklung 2.0. No Comment.

Related Posts

Pin It on Pinterest