Das Trainingsevent Jax on Tour – Architecture 2012

Letzte Woche waren wir auf der Jax on Tour in Wiesbaden von und für Software Architekten. Hier wurde von erfahrenen Architekten viel Praxiserfahrung vermittelt, typische Herausforderungen verdeutlicht und bewährte Praktiken vorgestellt. Hier sind einige Eindrücke zusammengefasst.

Cloud Computing war eines der Themen. Hier ist inzwischen eine Vielzahl von Diensten entstanden, welche den Umgang mit der Cloud vereinfachen sollen. Grundlegend sind jedoch die folgende Stufen zu unterscheiden

  • Infrastructure as a Service (IaaS)
  • Platform as a Service (PaaS)
  • Software as a Service (SaaS)

Während IaaS nur die virtuellen Server bereitstellt, kommen bei PaaS auch Application Server und Load Balancer mit. Skalierung und Failover-Handling wird also vom PaaS-Anbieter übernommen. Die Steigerung dazu ist dann SaaS, womit auch die Software vom Dienstleister betrieben wird. Während PaaS zwar am komfortabelsten erscheint, um eine neue Software auf den Markt zu bringen, ist es häufig jedoch nicht flexibel genug, um allen Anforderungen gerecht zu werden, so dass meistens weiterhin auf IaaS zurückgegriffen wird.

Generell möchte der Cloud-Ansatz Betriebskosten für einzelne Server niedrig halten und die Einrichtungsdauer für neue Server möglichst kurz. Dies wurde auf der jax on tour live demonstriert. So konnte eine neue Server-Instanz in weniger als einer Minute installiert werden. Der Preis dafür ist jedoch, dass die jeweiligen Server nicht hochverfügbar sind. Beim Design von Cloud-fähigen Systemen ist also darauf zu achten, dass sie mit Ausfällen umgehen können und den Service-Level über kurzfristige Hinzunahme neuer Systeme aufrechterhalten können.

Diese Erkenntnis wirkt sich insbesondere auf das Design der Persistenzschicht aus. Die relationalen Datenbanksysteme sind bisher das Standardmittel gewesen und werden es auch bleiben, jedoch wird man zukünftig klassifizieren müssen, welche Teile der zu persistierenden Daten auf alternativen Datenbanksystemen gehalten werden sollten. Sogenannte NoSQL-Systeme (Not only SQL) sind das Ergebnis. Eine Einordnung ist mit Hilfe des CAP-Theorem möglich.

Architekturdokumentation bildete einen weiteren Themenschwerpunkt. Anhand eines Kleiderschranks wurde hier demonstriert, dass alles sein festen Platz braucht. Struktur ist wichtig und, dass in jedem Fach etwas drin ist, auch wenn es wenig ist. Eine gute Vorlage für eine solche Struktur ist auf arc42.de zu finden. Damit die Dokumentation nicht zu kurz kommt, empfiehlt es sich, während Design und Umsetzung zu dokumentieren, um das „kurzfristige Wissen“ einzusammeln. Eine Aufbereitung in „langfristiges Wissen“ kann dann ggf. durch einen definierten Wiki-Gärtner erfolgen. Um Vertrauen in die Dokumentation nicht zu verlieren, ist Korrektheit unerlässlich. Es ist daher bei der Dokumentation auch darauf zu achten, wie viele Informationen man überhaupt aktuell halten kann. Hieraus kann man den Grundsatz ableiten: „So viel wie nötig und so wenig wie möglich.“

Im Gespräch über die Rolle des Architekten zeigte sich, dass Architekturaufgaben sehr wohl auf mehrere Schultern verteilt werden sollten, da ein einzelner, ausgezeichneter Software Architekt schnell zum Engpaß werden kann. Außerdem darf nicht übersehen werden, dass es viele Entwickler gibt, die Systeme mitgestalten möchten. Manche möchten es nicht. Es gilt daher, die entsprechenden Projektmitarbeiter gemäß ihrer Schwerpunkte einzusetzen. In Beispielen wurde gezeigt, wie man dies in Projekten organisieren kann.

Insgesamt war es eine sehr gelungene Veranstaltung mit erfahrenen Sprechern, interessanten Inhalten und guter Organisation. Ich freue mich schon auf das nächste mal.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>