Java in the Cloud - Erfahrungen beim Deployen einer Applikation mit der Spring "CloudFoundry"

Liebe Leser!

Gestern habe ich erstmals eine Java Applikation in der Cloud gestartet. Das Spring Service CloudFoundry stellt einen vollständigen Spring Stack zur Verfügung:

• Apache
• Spring tc Server (das ist der Spring Enterprise Tomcat) oder Tomcat 5.5
• mySQL.

CloudFoundry verwendet als Träger-Cloud-Service Amazon EC2 und bietet also einen Platform as a Service (PaaS) Aufsatz auf das Amazon Infrastructure as a Service (IaaS) Angebot.

Soweit - so gut. Was waren nun die Fallstricke?

• Zuerst muss man einen Amazon Web Services Account anlegen.Wenn man danach in CloudFoundry seinen Amazon Access Key validieren will, schlägt das fehl. Warum? 
• Nun, man muss sich zuvor bei Amazon für EC2 anmelden, dann funktioniert auch die Validierung. Danach kann man sich die notwendigen Key Pairs von CloudFoundry generieren lassen.
• Beim Deployen einer Applikation wird das Eingabefeld "Web Server - Public IP" angezeigt. Sobald man hier etwas einfüllt, schlägt die Feldvalidierung immer fehl. Was tun? 
• Nun, das Feld einfach freilassen, dann wird die Applikation deployed und man gelangt über einen angebotenen Link auf die deployte Applikation in der Cloud - Voila!

Weiterführende Probleme, die mir bei meinem ersten Test aufgefallen sind:

• Applikations-Logfiles
• Beim Tracen von Problemen ist es essentiell, ein "tail -f" auf die Applikationslogfiles mitlaufen zu lassen. Fraglich ist, wie das über CloudFoundry geht bzw. ob so etwas Feines wie bei Hudson (CI Server) angeboten wird - hier kann man einem Build in Echtzeit im Web beobachten. Alternative: Ich nehme an, man kann auch auf den Amazon Server direkt verbinden und die Logfiles dort auswerten.
• Daten in der Datenbank
• Falls die Instanz gestoppt wird - aus welchem Grund auch immer - wie kommt man zu den Daten in der Datenbank? Vermutung: Wie oben direkt auf die Amazon Instanz verbinden und einen Export machen - ist das auch automatisierbar?
• Deployment einer Version mit minimaler Downtime
• Das Deployen einer Mini Applikation hat ca. 4 Minuten gedauert. Wenn ich eine neue Version deployen will (und vorausgesetzt, es ist keine Änderung der Datenstruktur mit Datenmigration notwendig), wie halte ich die Downtime so gering als möglich? So wie ich es verstanden habe, kann man nicht einfach den Apache auf einen neu deployten Stack umschalten bzw. habe ich dazu noch keine Informationen gefunden. Wahrscheinlich muss man dazu wieder auf die Amazon Instanz gehen und das Procedere händisch ausführen.

Ad Kosten: Soweit ich gesehen habe, routet CloudFoundry - das übrigens noch im BETA Stadium ist - einfach die Amazon kosten durch und verrechnet keinen Aufschlag. Die Frage ist, ob mit der Verfügbarkeit von VMforce das CloudFoundry Service nicht eingestellt werden wird. VMWare tut sich ja mit Salesforce.com zusammen, um nicht Amazon das Geschäft mit dem IaaS zuschanzen zu müssen.

Euer 

JWR@coopXarch.

Ich bau mir einen Cluster oder "Die Geschichte des BossBlade"...

In der Vergangenheit habe ich mich auch mit dem Bau von Cluster Systemen beschäftigt und den "BossBlade" entwickelt - damals waren Blade Server noch in aller Munde und die Cloud noch nicht erfunden. Ich dachte mir, das könnte Euch interessieren - im Folgenden also der Werbetext des BossBlade "Produkts"...

Der "BossBlade" ist ein komplett auf Open Source basierender, hochausfallsicherer, skalierbarer Shared Nothing Cluster ohne Single Point of Failure: HA HTTP/HTTPS Load Balancer, HA JBoss Cluster mit Cache Synchronization und Farming, HA Datenbank Cluster (PostgreSQL, mySQL, etc.).

Bis jetzt waren hochausfallssichere, skalierbare Applikationsserver-Cluster grossen Unternehmen vorbehalten, die die beträchtlichen Summen für Serverhardware und Speichersubsysteme (RAID, SAN, NAS) und Lizenzen für Betriebssystem, Clustersoftware, Datenbanken, Applikationsserver, Web Server, Netwerkmanagementsoftware nebst Wartungsverträgen aufbringen konnten. Diese Servercluster sind die Basis für Enterprise Java Softwaresysteme (J2EE), die sich durch zentralisierte Architektur, hohe Wartbarkeit und Flexibilität und bedarfsgerechte Skalierbarkeit auszeichnen. In kleinen und mittleren Unternehmen regiert bis heute oft ein Flickwerk an unterschiedlichen Applikationen in verschiedenen Skript- und Programmiersprachen auf verschiedenen Plattformen ohne zentrales Software-Architektur-Konzept. Mit dem BossBlade steht nun erstmals auch kleinen und mittleren Firmen eine vollständig auf Open Source Software basierende, skalierbare Infrastruktur für Enterprise Software zu Verfügung, die kostengünstig und stabil ist und mit dem Unternehmen wächst. Die Migration und Zentralisierung der historischen Softwarelösungen auf das BossBlade bringt Kostenvorteile bei der Weiterentwicklung und Wartung der Software und erhöht die Stabilität, Verfügbarkeit und Skalierbarkeit des Systems. Durch die Shared Nothing Technologie (keine einfach ausgelegten gemeinsamen Komponenten - z.B. externes RAID) kann das BossBlade auf zwei Serverräume aufgeteilt werden, um die Systemverfügbarkeit bei Strom- und Leitungsausfall bzw. anderen physischen Einflüssen zu garantieren.

Der "BossBlade" - Links die Säule der 2 Webserver, mittig die Applikationsserver, rechts die Datenbankserver - soviel zur anschaulichen Darstellung von "Tiers" - die Ausfallsicherheit im Testaufbau ist natürlich durch die Verwendung einer Steckerleiste und eines Switches begrenzt ;-)

JWR@coopXarch.

Korrektive Wartung - wer bezahlt für Fehler?

Folgendes schreibt mir ein Bekannter, der IT Koordinator in einem größeren Betrieb ist, zum Thema korrektive Software Wartung, da er meine Vorlesungsfolien (TU Wien - Software Wartung und Evolution) im Internet gefunden hat:

In der Praxis läuft es aber immer wieder auf die selben Diskussionspunkte hinaus:

• Fehler oder "works as designed"
• Fehler oder Änderungswunsch -> Unterscheidung korrektive bzw. adaptive Wartung
• Fehler: bezahlen oder nicht.

Gerade der letzte Punkt ist strittig, da die korrektive Wartung in unserer Wartungspauschale enthalten ist. Jedoch wird eine Entwicklung erst nach Abnahme produktiv gesetzt. Der Fehler wurde also beim Test nicht festgestellt. Und wer ist nun schuld, dass es den Fehler im Produktivsystem überhaupt gibt?

Und das ist meine Antwort:

Die Probleme sind mir – als Individualsoftwarehersteller und Ziviltechniker für Informatik – gut bekannt. Also kurz mein Statement dazu:

Die Korrektheit ist der Grad, zu dem ein implementiertes Feature einer Anforderungsspezifikation entspricht. Das Problem ist, dass Anforderungen in den meisten Fällen nicht eindeutig sind (weil sie meist in Prosa und nicht mathematisch abgefasst sind; ein paar UML Grafiken helfen da auch nur ein bisschen) und daher im Nachhinein immer Interpretationsspielraum bieten – das kann nun der Hersteller für seine Zwecke ausnutzen (das ist „works as designed“). Leider ist es ebenso schwierig, eine ganz eindeutige Anforderungsspezifikation im Vorhinein („up-front“) zu liefern, daher sind neuerdings lernende Ansätze wie Scrum so populär.

Es liegt im Interesse des Herstellers, einen Fehler („korrektive Wartung“) wenn möglich als Änderungswunsch zu titulieren, um den Aufwand für die Änderung (Behebung des Fehlers oder Erweiterung der Funktionalität) bezahlt zu bekommen.

Bei meinem Projekten/Kunden halten wir es mit Fehlern – auch in Übereinstimmung mit der mir bekannten relevanten Gesetzgebung - so: Es gibt 6 Monate Gewährleistung ab der Abnahme (6 Monate weil B2B und nicht B2C), in dieser Zeit sind Fehler der Klasse 1 (betriebsverhindernd) und Klasse 2 (betriebsstörend) auf Kosten des Herstellers zu beheben. Dabei ist es auch irrelevant, ob der Fehler im Test nicht aufgefallen ist („versteckter Mangel“), selbst wenn der Kunde mitgetestet hat. Es ist dem Kunden nicht zuzumuten, alle Fehler beim Akzeptanztest aufzudecken – selbst wenn eine Mitwirkungspflicht bei der Durchführung der Tests vertraglich vereinbart ist. Bei Fehlern der Klasse 3 (Kosmetik) weisen wir unserer Kunden darauf hin, dass hier eine strenge Auslegung der Anforderungen besteht – für den Hersteller ist es schwer, wirtschaftlich zu bleiben, wenn der Kunde ab der Abnahme alle 3 Tage meldet, dass er jene Farbe und jenen Dialog gern anders gestaltet hätte. Hier wird generell der Dialog gesucht und Mediation durch den Projektleiter betrieben. Größere Änderungen in der Klasse 3 sind vom Kunden zu bezahlen.

Ist die korrektive Wartung in der Wartungspauschale enthalten, liegt also die Behebung von Fehlern beim Hersteller – hier ist eine genaue Definition von Fehlerklassen - siehe oben - zu empfehlen. Neben dem Fehlergewicht kann man z.B. auch den Fehlertyp (falsch, fehlend, überflüssig, ungenau) zur Klassifizierung heranziehen.

Ein weiteres Problem hierbei ist die Arbeitsweise in der adaptiven oder erweiternden Wartung – wenn der Kunde schlechte Anforderungsqualität „auf Zuruf“ liefert und den Entwicklungsprozess chaotisch managed, kommen wir bei der Verantwortlichkeit für Fehler im System auch ins Diskutieren.

Wie auch immer – denke ich – dass dieses Thema immer Spielraum für Diskussion bietet. Daher muss man möglichst viel Munition vorrätig haben - und eine Mediation von außen - vor allem in heiklen Fällen - kann hier auch helfen, um dem Hersteller zu zeigen, dass er nicht nur den Kunden überzeugen muss (bzw. überrumpeln kann). 

Und was denkt ihr?

Euer

JWR@coopXarch.

Und wo ist die Dokumentation?

Das Thema Softwaredokumentation ist kein leichtes - oft fragt man sich am Ende des Projektes, welche Dokumentation eigentlich beauftragt war und nun zu liefern ist. Damit das nicht passieren kann, habe ich vor einiger Zeit einen Projektauftrag für Softwaredokumentation erstellt. Dieser ist in der Projektstartphase gemeinsam mit dem Kunden auszufüllen und formal zu bestätigen (z.B. durch Unterschrift oder Commitment-Abgabe). Man beachte, dass z.B. ein Pflichtenheft nicht verpflichtend zu erstellen und zu liefern ist - in kleineren Projekten kann das Pflichtenheft aus einer Reihe von Einträgen (z.B. User Stories) in einem Issue Management Tool bestehen. Den QS-Plan samt Testdokumentation würde ich aus heutiger Sicht aber in den verpflichtenden Teil aufnehmen. Vielleicht findet Ihr die Idee ja nett und könnt das Template verwenden bzw. ergänzen - ich bin sicher, es gibt noch ganz viele andere Arten von Dokumentation...

Projektname
Projektcode
Mandatorisch
	Projekthandbuch (IPMA konform, Ausfüllungsgrad je nach Projektgröße)
	Technische Spezifikation
	Source Code Kommentare
	Entwickler Javadoc
Optional
	Pflichtenheft
	Requirementsspezifikation
	Dokumentation der Machbarkeitsstudie
	Architekturspezifikation
	Designspezifikation
	GUI Spezifikation
	Package- oder Modulspezifikation
	Qualitätssicherungsplan und Testdokumentation
	Wartungshandbuch
	API Javadoc
	API Dokument
	Benutzerhandbuch
	Administrationshandbuch
	Installationshandbuch
	Betriebshandbuch
	Schulungsunterlagen
Name
Datum, Ort
Unterschrift

JWR@coopXarch.

Was macht die IT Abteilung?

Dies scheint eine generelle Frage zu sein: Schaffe ich es, meine verstreuten Architekturen auf einige wenige zu reduzieren und damit Kosten und Personal zu sparen? Manche Firmen müssen laut der Hackett-Group täglich damit kämpfen, "einfach nur alles am Laufen zu halten, statt IT-Investitionen zu tätigen, die ihre Gesamtkosten reduzieren oder ihre Effektivität steigern". Tappen wir in die Wartungsfalle, in der alle organisatorische Kapazität darauf verwendet werden muss, das rasch aufgebaute komplexe soziotechnische System am Leben zu erhalten, ohne Chance auf Optimierung und Innovation? Was kann man dagegen tun? Und in welcher Reihenfolge? Antworten bitte als Kommentare! Danke!

JWR@coopXarch.

Vortrag am 4. Oktober 2010 in der Wirtschaftskammer Österreich in Wien

Liebe Leser!

Ich spreche in meinem Vortrag im Rahmen der CON.ECT Eventmanagement Veranstaltung "Software Trends" über das Spannungsfeld Qualitätssteigerung versus Kostensenkung im Kontext von Individualsoftware.

Das Prinzip der Ökonomie: Höhere Qualität zu geringeren Kosten - ist das für Individualsoftware machbar?

Warum ist Software so teuer, nie fertig und funktioniert nicht optimal? In der Softwareindustrie ist man fast täglich mit diesen Fragen konfrontiert und der Druck, weitere Kosteneinsparungen zu erzielen, erscheint angesichts der ungelösten Qualitätsprobleme kontraproduktiv. Das Spannungsfeld Kosten versus Qualität führt zu folgender Frage: Werden Produktivitätssteigerungen durch Technologie- und Prozessinnovationen in absehbarer Zeit zu höherer Kosteneffizienz in der Fertigung von Individualsoftware führen oder wird dieser Kostenvorteil durch Investitionen in die Qualitätssicherung immer komplexerer Systeme kompensiert? Der Sprecher nimmt sich als Softwarearchitekt und  Projektmanager dieser spannenden Frage an und kommentiert in diesem Kontext aktuelle Trends zur Qualitätssteigerung bzw. Kostensenkung.

Montag, 04. Oktober 2010 von 13:20 bis 14:00 Uhr (Die Gesamt-Veranstaltung findet von 12:00 bis 18:00 statt: Veranstaltungsprogramm). Anmeldung erforderlich.

Wirtschaftskammer Österreich, HS 7, 1040 Wien, Wiedner Hauptstraße 63

Ich freue mich natürlich über Euren Besuch!

Euer
JWR@coopXarch.

Was ist Software Architektur? Gibt es eine klare Antwort? Eine Betrachtung.

Wenn wir über Architektur sprechen, denken wir intuitiv, wir alle sprächen über das gleiche Thema. Jedoch gibt es viele Definitionen von Software Architektur und noch mehr Darstellungen derselben. Es gibt Architecural Views, Styles und Patterns, Architekturbeschreibungssprachen und -notationen und Architekturbewertungsverfahren. Ist Architektur immer auch Design und umgekehrt? Was tut ein Software Architekt den lieben langen Tag?

James: "Wir suchen einen Software Architekten!"
Dean: "Was werde ich am ersten Tag machen?"
James: "Wir wollen die Architektur unserer Software dokumentieren!"
Dean: "Kein Problem! In welchem Format?"
James: "Ich hoffte, das würdest Du uns sagen!"
Dean: "Ich kann mich ja mal in den Code einlesen..."

Es gibt viele Wege, Architektur zu beschreiben - sicher gibt es besser und schlechter geeignete Repräsentation, was ist aber nun wichtig, wenn man über Architektur spricht?

• Erstens sollten wir in einer Gruppe eine einheitliche Sprache entwickeln. Nach der Sapir-Whorf Hypothese schafft Sprache Wirklichkeit, und um uns nicht in einem semantischen Albtraum zu verlieren, ist es sinnvoll eine "Gesamtsprache" - so etwas wie die Ubiquitous Language (UL) aus dem Domain Driven Design Bereich - zu entwickeln. Erzeugen wir dieselben Bilder im Kopf, können wir zufrieden sein. Ein Bild sagt mehr als 1000 Worte - und darum ist eine grafische Architekturbeschreibung auch so sinnvoll.
• Zweitens sollten wir uns nicht panisch an postulierte Vorgaben halten - legt man alle Bücher zu Software Architektur aufeinander, kann man bald getrost dem Eiffelturm Konkurrenz machen. Gut ist, was gefällt - was unserem Problem in unserer Umgebung am Effektivsten zu Leibe rückt. Mut zum Anderssein - wenn es Sinn macht. Mut zum Experiment, wenn man das Gefühl hat, da ginge noch etwas besser - und Mut, sinnlose Ansätze formlos wieder zu verwerfen.
• Drittens sollten wir als Entwickler Architekten nicht vorsorglich verdammen und als Architekten Entwickler nicht bevormunden. Diversität der Meinungen und der konstruktive Dialog produzieren - ein Aufeinander hacken, sei es, um Justament Standpunkte zu verteidigen oder persönliche Überzeugungen aus Eigeninteresse zum Postulat hochzustilisieren, zerstört. Zerstörte Architektur ist auch Architektur - nur macht sie keinen Spaß. Erfahrene Architekten haben so ein ungutes Gefühl in der Magengegend, wenn ihnen ein zerrüttetes soziotechnisches System eine zerstörte Architektur als "einzig machbaren Weg" vorstellt - da weiß man, dass Arbeit auf einen zukommt.

Architektur (und Architekturmanagement) ist die Courage, aus einer Menge von möglichen Wegen einen gangbaren (viablen, würden die Konstruktivisten sagen) einzuschlagen, ihn konsequent zu verfolgen und evolutionär anzupassen. Dann wird der Weg durch den steinigen Entwicklungsalltag breiter und sicherer, das Produkt übersichtlicher und seine Evolution einfacher - und es macht bedeutend mehr Spaß, mit von der Partie zu sein.

Euer
JWR@coopXarch.