arago
UpDate! B2B-Magazin mit IT-Fokus Ausgabe 13 · Juli 2010
Editorial Fokus
Inhalt
3
Ohne Autopilot keine Cloud
9
Der Weg in die Private Cloud
13
Geschwindigkeit vs. Wissen – Wie Automation die wenigen IT-Gurus nutzbar macht
Development 17
Cloud Pilot – Ein Überblick
20 Modell, Master Data Management oder CMDB – Einfache Best Practices 22 Den Autopiloten mit Wissen versorgen 26 AJAX Framework
Inside arago 28 Auftakt zur Roadshow – Automatisierung im Systembetrieb 29 Next 2010 30 Cloud Storm Düsseldorf 30 Neue Mitarbeiter der arago AG 31
15 Jahre arago AG
31 Impressum
Comment 32 Boos Comments
UpDate! ist das Magazin für Kunden, Partner und Freunde der arago AG arago Institut für komplexes Datenmanagement AG Eschersheimer Landstraße 526–532 · 60433 Frankfurt am Main Internet: www.arago.de · E-Mail: info@arago.de Telefon: 0 69 / 405 68‑0 · Fax: 0 69 / 405 68‑111
13
Editorial
2 Liebe Kunden und Freunde der arago AG, das Thema Cloud Computing beherrscht derzeit die Schlagzeilen der Fachpresse und ist eines der zentralen Themen der IT Provider. Zum einen lassen sich erhebliche Kostenersparnisse erzielen, zum anderen ist ein kurzfristiger Mehrbedarf an Rechnerkapazität zum Beispiel für Marketingaktionen ohne zusätzliche Investition zu realisieren. Allerdings können bisher nur spezielle Anwendungen in eine Cloud überführt werden. Genau an diesem Punkt aber setzt der arago Autopilot an und zeigt Wege auf, wie der Schritt in die Cloud mit der eigenen IT gelingen kann. Rasant voran schreitet auch die Umstellung der eigenen IT in eine Private Cloud. Hierbei hat arago einen neuen Ansatz entwickelt und bereits erfolgreich bei Kunden umgesetzt: Die Autopilot gesteuerte Private Cloud. Zwei Gesichtspunkte stehen hierbei im Vordergrund: „echte“ Automation des System- und Applikationsbetriebes, die auch mit kundenindividuellen Anwendungen umgehen und den Systemadministrator wirklich entlasten kann und die Nutzung einer Private Cloud, um Skaleneffekte auch für kurzfristigen Ressourcenbedarf zu nutzen. Zusammenfassend ist festzustellen, dass in der Kombination mit Automatisierung Cloud-Konzepte auch für Anwendungen interessant werden, die nicht speziell für eine Cloud entwickelt wurden. Ein weiterer Schwerpunkt dieser Ausgabe behandelt das Thema Geschwindigkeit vs. Experten-Wissen im Rennen gegen die
UpDate! Ausgabe 13 · Juli 2010
Uhr im Betrieb von IT-Umgebungen. Mit einem Erfahrungsspeicher, der Expertenwissen in kleinen Bausteinen ablegt, und dem von arago im Autopilot eingesetzten Algorithmus können gleich drei Vorteile erzielt werden: offensichtlich arbeitet jede Maschine schneller als der Mensch und abgelegtes Wissen kann wieder und wieder verwendet werden. Als Drittes kommt hinzu, dass die Maschine im Gegensatz zu den Experten an mehreren Problemen gleichzeitig arbeiten und eine automatische Korrelation der Aufgaben vornehmen kann. Mit Stolz und Freude erfüllt uns 15 Jahre erfolgreiche Arbeit im Dienst unserer Kunden. Dies nehmen wir zum Anlaß, mit Ihnen und allen arago Mitarbeitern zu feiern. Tragen Sie sich am besten bereits heute den Veranstaltungstermin 3. September 2010, 16:00 Uhr in Ihren Terminkalender ein. Ich wünsche Ihnen viel Freude bei der Lektüre und verbliebe herzlichst, Ihr
Martin Friedrich
Fokus
3
Ohne Autopilot keine Cloud Cloud Computing ist nicht nur das derzeit beliebteste Thema in allen IT-Marketingabteilungen, sondern auch der Strohhalm, an dem sich die IT-Budget-Verwalter momentan festhalten. Umso wichtiger ist es, im Bereich Cloud Computing nicht nur Forschung zu betreiben, sondern greifbare Ergebnisse zu erreichen. Im Folgenden wird beschrieben, was die Cloud so attraktiv macht, wofür Cloud Computing im momentanen Zustand eingesetzt werden kann, warum die Legacy IT – und damit über 70 % aller IT – nicht einfach in die Cloud überführt werden kann und wie Automation den Schritt in die Cloud auch mit der eigenen IT ermöglicht.
Hans-Christian Boos
sind. Ebenso leicht kann man sich darauf einigen, dass die Anzahl dieser IT-Systeme über die Zeit einem quasi exponentiellen Wachstum unterworfen und kein Ende dieses Wachstums in Sicht ist. Weniger gern wird zugegeben – auch wenn es niemals verneint wird –, dass sich die Betriebskosten für diese IT-Umgebungen proportional zu ihrer Anzahl entwickeln und damit ebenso exponentiell – sogar im größeren Maße – steigen. Diese Betriebskosten ihrerseits fressen mindestens 70 % des Gesamtbudgets auf und lassen so nur einen relativ kleinen Spielraum für Innovation und tatsächliche Weiterentwicklung. Wieder einmal bewahrheitet sich, dass Wachstum am schwersten zu managen ist – in diesem Fall das Wachstum der benötigten IT-Systeme. Bedenklich stimmt allerdings die Erkenntnis, dass selbst diese Zahlen – also der große Anteil der Betriebskosten an den Gesamtkosten der IT und die exponentielle Entwicklung dieser Betriebskosten – nur erreicht werden konnten, indem eine erhebliche Innovation im Systembetrieb stattgefunden hat. So hat man zum Beispiel verschiedene Arten von Management- und Automationswerkzeugen
Ein Statement zur Lage der IT und zum Charme der Cloud Ist man gezwungen, ein Statement zur Lage der IT von abstrakter Warte aus abzugeben, kann man sich schnell darauf einigen, dass ITSysteme heute aus keinem Bereich des Lebens in der entwickelten Welt mehr wegzudenken Staff
Number of IT Applications
IT Budget Operational Cost (RTB)
Infrastructure
You Are Here
Time
Entwicklung der IT
UpDate! Ausgabe 13 · Juli 2010
Fokus
4 eingeführt, die die von den Administratoren durchgeführten Tätigkeiten multiplizieren oder einfach die Arbeitsgeschwindigkeit der Administratoren erhöhen. Um das mit der wachsenden IT einhergehende Wachstum der Anzahl Administratoren und IT-Experten überhaupt verwalten zu können, hat man außerdem erhebliche Fortschritte bei der Verwaltung und Steuerung des IT-Betriebes und seiner Prozesse durch organisatorische Innovation – zum Beispiel ITIL – erreicht. Wie von organisatorischen Maßnahmen nicht anders zu erwarten, wurden dadurch Overheadaufwände erzeugt, die das Gesamtkonstrukt aber überhaupt erst am Laufen halten. Nicht erst vor dem Hintergrund der Wirtschaftskrise unterliegen die IT-Budgets genauer Kontrolle und einem Sparzwang. Aber erst mit der Wirtschaftskrise wird der Sparzwang auch zu einer Aufgabe, die nicht nur den Status Quo erhalten muss, sondern zu einer Aufgabe, die trotz steigender System- und Anwendungszahlen die Gesamtkosten (und nicht nur die Stückkosten) senken soll. Die Kosten, die im Fokus stehen, setzen sich zu ca. 50 % aus Hardware, Strom und anderen Fixkosten und zu weiteren 50 % aus Personalkosten für die Administration und ihren organisatorischen Overhead zusammen. Da kommt
ein Konzept wie Cloud Computing, das darauf abzielt, die 90 % nicht genutzte Hardware und damit auch alle verbundenen Folgekosten wie Energie, Gebäude, etc. überflüssig zu machen, gerade recht. Greift dieses technische Konzept, wird man nicht nur für die in Zukunft steigenden Energiekosten gewappnet sein, sondern auch ganz direkte Einsparungen realisieren, die das Dilemma auflösen. Die Vorteile liegen auf der Hand und ergeben eine Win-Win Situation für die Unternehmen als Ganzes und in den Unternehmen für die IT genauso wie für die Fachabteilungen, aber auch für die Umwelt und damit für die gesamte Gesellschaft. Es stellt sich also die Frage, ob dieses Konzept erfolgreich eingeführt werden kann und wenn dem noch nicht so ist, was man dafür tun kann, um diesem Charme nicht nur zu erliegen, sondern auch die Ergebnisse zu realisieren.
Die Cloud ist für den größten Teil der IT nicht zugänglich Lässt man bisher noch nicht komplett gelöste Themen wie Sicherheitskonzepte und nationale Gesetzgebung außer Acht, sollte man meinen, dass eine bestehende IT Landschaft relativ leicht in einer Cloud-Landschaft zu betreiben
Staff
Number of IT Applications
IT Budget Operational Cost (RTB)
Infrastructure
You Are Here
Time
Erwartete IT-Entwicklung mit Cloud
UpDate! Ausgabe 13 · Juli 2010
Fokus
5
sein muss, weil es sich ja letztendlich um dieselbe Landschaft – nur virtualisiert und dynamisiert – handelt. Dem ist aber leider nicht so. Folgt man den Cloud Konzepten, gibt es eigentlich nur drei Gruppen von IT-Systemen oder Anwendungen, die einfach in einer Cloud Umgebung nach aktuellen Konzepten zu betreiben sind. 1. R & D (Entwicklungssysteme, Simula tionen, …) Hier kommen entweder eine relativ geringe Anzahl Systeme zum Einsatz, die nicht unter Produktionsbedingungen (Entwicklungssysteme) verwaltet werden müssen oder eine große Anzahl an Systemen, die speziell für den dynamischen Betrieb eingerichtet wurden (Number Crunching, Simulationen) in Frage. Beide Arten Systeme zusammen machen einen sehr geringen Teil der heute verwendeten und betriebenen IT aus. 2. SaaS Software as a Service kann überall dort eingesetzt werden, wo Standardisierung und Konsolidierung möglich sind – also in allen Unternehmensbereichen, in denen man sich keinen marktdifferenzierenden Vorteil durch den Einsatz von IT erwartet. Da auch in der bisherigen IT-Umgebung durch die
Standardisierung große Kostenvorteile erreicht werden konnten, ist das Potenzial für SaaS relativ klar und leider relativ zum Gesamtmarkt eher klein umrissen – zumindest solange die Unternehmen im technischen Bereich eine recht hohe eigene Kontrolle des Funktionsumfanges und eventuell sogar der Fertigungstiefe anstreben. 3. Neuimplementierungen Dies betrifft sowohl Startups (die heute als größte Nutzer der Cloud gelten) als auch diejenigen Unternehmen, die Anwendungen neu entwickeln lassen und dabei in der Architektur auf Cloudfähigkeit (dynamische Skalierbarkeit, Applikationsadministration, Parallelisierung) achten. Allein bei der Betrachtung des für Innovation und damit auch Neuentwicklung zur Verfügung stehenden Budgets ist deutlich zu sehen, dass die meisten großen und intensiv genutzten kommerziellen Anwendungen nicht durch Neuimplementierung in die Cloud überführt werden. Für alle anderen Anwendungen, die sogenannten Legacy Anwendungen – und diese machen selbst bei vorsichtigen Schätzungen ca. 80 % aller IT-Anwendungen aus – kann ein Umstieg
Staff Infrastructure “Cloud Staff” Number of IT Applications
IT Budget Operational Cost (RTB)
Cloud Infrastructure You Are Here
Time
Realistische Kostenentwicklung mit Cloud
UpDate! Ausgabe 13 · Juli 2010
Fokus
6 Staff
Number of IT Applications
IT Budget Operational Cost (RTB)
Infrastructure
You Are Here
Time
Kostenbasis mit Cloud und Autopilot auf die Cloud noch gar nicht in Frage kommen. Das liegt in erster Linie daran, dass sie • nicht auf dynamische Skalierung ausgelegt sind, • nicht mit den standardisierten Umgebungen der verfügbaren Clouds arbeiten können oder • mehrere Plattformen beinhalten, die noch nicht in einer Cloud zusammenspielen können. Weiter unten wird gezeigt, dass sich das Thema technisch mit einem neuen Ansatz lösen lässt. Nimmt man also an, dass sich Legacy Anwendungen in die Cloud portieren lassen, sieht man sofort eine zweite Herausforderung. Während sich durch den Einsatz von Cloudtechnologie die Kosten für Hardware, Gebäude und Energie stark senken lassen, steigen die Kosten der Administration selbst in ähnlichem Maße und machen damit den Gewinn durch die Cloud zunichte. Diese höheren Administrationskosten entstehen in erster Linie durch die Dynamik, die eine Cloud Landschaft als Grundvoraussetzung hat. Diese Dynamik hat drei Auswirkungen, die jede für sich den administrativen Aufwand und noch mehr den Aufwand für Overhead erhöhen:
UpDate! Ausgabe 13 · Juli 2010
1. Parallelisierung Durch die Parallelisierung der Infrastruktur müssen besondere administrative Verfahren eingeführt werden, die Race-Conditions verhindern. Das bedeutet insbesondere die Erweiterung des administrativen Overheads. Aber auch die Administration, selbst in einer parallel betriebenen Umgebung, steigt erheblich, wenn der Grad der Parallelität flexibel ist. 2. Skalierung Eine Cloud reagiert dynamisch auf die Anforderungen der Benutzer und teilt Ressourcen dynamisch zu. So werden im laufenden Betrieb die für eine Anwendung verfügbaren Ressourcen oder auch die genutzten Anwendungskomponenten skaliert. Das bedeutet erneut eine Erhöhung des administrativen Overheads, denn diese Skalierung muss in der Administration nachvollzogen werden, weil sie erhebliche Auswirkungen auf Incident-, Problem- und Changemanagement aber auch Availability- und Capacity Management hat. All diese Prozesse werden mit zusätzlichen Schleifen und Dokumentationsverfahren versehen, um der Skalierung der einzelnen Anwendungen gerecht zu werden.
Fokus 3. Verteilung In einer Cloud werden die Ressourcen dynamisch verteilt, d. h. dass einzelne Komponenten einer Anwendung sich im laufenden Betrieb durch die physische Infrastruktur bewegen. Da eine feste Zuordnung meist der Einstiegspunkt in Betriebsaktivitäten ist und dieser Einstiegspunkt vollkommen verloren geht, wird erneut sowohl organisatorischer als auch administrativer Mehraufwand erzeugt. Aus diesen Erkenntnissen ist zusammenzufassen, dass die schlechte Standardisierung und der erhebliche Verteilungsgrad der meisten IT-Anwendungen dazu führt, dass sie nicht direkt cloudfähig sind und die Dynamik, die den Vorteil der Cloud Technologie ausmacht, erheblichen Mehraufwand in der Administration und vor allem im Overhead des IT-Betriebs nach sich zieht. Damit bleibt beim Einsatz der modernen Cloud Technik und den herkömmlichen Anwendungen mit üblichen Betriebsverfahren der Traum von der Cloud nur ein Tropfen auf den heißen Stein.
Cloud für Alle mit Autopilot Wie dargelegt gibt es drei große Herausforderungen, die heute zwischen dem vollen Ausschöpfen der Vorteile einer Cloud und den normalen IT-Anwendungen stehen. Dabei ist nicht die Rede von Standardisierung oder dem Nutzen neuer SaaS Angebote durch Startups – letztendlich auch Standardisierung –, sondern von der Überführung der jetzigen IT-Architekturen in eine Cloud Umgebung: 1. Migration in die Cloud 2. Management verschiedener Cloud Plattformen 3. Vermeidung von administrativem Mehraufwand durch Cloudbetrieb Alle drei Herausforderungen sind technischer Natur und betreffen die heute in der IT übliche Arbeitsweise. Nicht betrachtet wurden hier die betriebswirtschaftlichen Herausforderungen wie die korrekte Budgetzuordnung, Risikoab-
7 wägungen für Sicherheitsthemen und eventuell Berechnungen zur Marktdifferenzierung, die aber an ganz anderer Stelle im Unternehmen und bei genügend Kostendruck mit großer Sicherheit gelöst werden. Alle drei technischen Herausforderungen haben damit zu tun, dass sich die verschiedenen notwendigen administrativen Tätigkeiten nicht schnell genug durchführen lassen, die Durchführenden sich nicht schnell genug in die Umgebung einarbeiten können oder die eingesetzten Werkzeuge nicht flexibel genug sind, weil sie darauf ausgelegt sind, entweder eine einzige genau beschriebene Aufgabe stetig zu wiederholen oder durch einen Administrator gesteuert zu werden. Diese Erkenntnis zeigt, dass mit den derzeitig verwendeten Werkzeugansätzen (Data Center Automation, Run Book Automation, etc.) der Cloud Betrieb nicht zu erreichen ist. Besser wäre es, wenn man die Administratoren selbst beschleunigen könnte. Weil dies aber nicht möglich ist, stellt sich die Frage, wie die Administratoren arbeiten und ob man diese Arbeitsweise nicht maschinell abbilden kann. Das Ergebnis dieser Überlegungen ist eine Art „Autopilot für den IT-Betrieb“. Dieser Autopilot greift auf das Wissen der Administratoren zu, ruft es in menschlich nicht möglicher Geschwindigkeit ab und stellt sich so seine eigenen Arbeitsabläufe – abhängig von der gestellten Aufgabe oder Situation – zusammen. Dieses Vorgehen kennen wir aus dem Bereich der Avionik, aus dem auch der Terminus Autopilot stammt; aber auch andere Bereiche versuchen derartige Ansätze umzusetzen. Im Gegensatz zu den klassischen Ansätzen der IT wird hier nicht ein festes Programm gefordert, das den optimalen Weg zur Erfüllung einer Aufgabe oder den besten Weg zur Lösung eines Problems abbildet. Vielmehr wird eine Aneinanderreihung von Aktionen gefordert, an deren Ende das gewünschte Ergebnis steht; Teile dieser Aktionskette dürfen unnötige Aktionen sein oder Aktionen die benötigt werden, um den weiteren Fortgang der Kette zu bestimmen. Diese Arbeitsweise bildet – verglichen mit
UpDate! Ausgabe 13 · Juli 2010
Fokus
8 einem noch so dynamischen Programm – viel eher das menschliche Verhalten ab, das sich als so flexibel erwiesen hat. Analysiert man diese Verhaltensweise, so ruft dieser Autopilot Wissen in kleinen Bausteinen aus einem großen Wissenspool ab. Durch das Abrufen eines Wissensbausteins wird eine Aktion durchgeführt oder eine Entscheidung getroffen. Beides führt zu einem Ergebnis, also zur Erzeugung vorher nicht bekannter Informationen. Mit diesen zusätzlichen Informationen können wieder neue Aktionsbausteine aus dem Wissens- oder Erfahrungspool abgerufen werden. Dies lässt sich so lange fortsetzen, bis die Aufgabe gelöst ist oder der Erfahrungspool erschöpft ist. Im letzteren Falle kann man die Aufgabe wieder einem Menschen übertragen, der dann seine Kreativität nutzen kann, um einen unkonventionellen Lösungsweg zu finden (und diesen anschließend dem Erfahrungspool hinzuzufügen). Im Gegensatz zu allen anderen Werkzeugansätzen kann ein Autopilot flexibel auf gegebene Situationen reagieren, bildet die menschliche Erfahrung ab und kann auch mehrere Aufgaben gleichzeitig ausführen und deren Ausführung miteinander kombinieren. Wendet man einen solchen Autopiloten auf eine herkömmliche IT-Landschaft an, geht man die Personalkosten, also die zweiten 50 % der Betriebskosten, die nicht von Cloudansätzen betroffen sind, an. Gleichzeitig erschließt man durch die Geschwindigkeit und plattformübergreifenden Anwendung von Erfahrungen des Autopiloten aber auch die Cloud Technologie für eine Legacy IT-Umgebung. Der Ansatz eines Autopiloten erschließt also die Ansätze des Cloud Computing für einen
UpDate! Ausgabe 13 · Juli 2010
sehr großen Teil (70–80 %) aller IT-Anwendungen und schlägt damit die Brücke, die Cloud Computing wirklich für alle IT-Landschaften anwendbar macht. Dabei kommt es nicht so sehr auf die Größe einer IT-Landschaft an, die effizient betrieben oder in die Cloud gebracht werden soll, als darauf, dass sie von einem Menschen zu administrieren ist. Wenn dies der Fall ist, können die Erfahrungen der Administratoren in den Wissenspool des Autopiloten übertragen werden und dieser kann alle Standardaufgaben erfüllen. Die IT-Experten werden wieder zu wirklichen Experten, die ihre Mental- und Arbeitskraft darauf fokussieren können, schwierige und interessante Betriebsprobleme zu lösen oder noch eher sich um die Architekturen und Anwendungen der Zukunft zu kümmern. Mit der Einführung von Autopilottechnologie ergibt sich nicht nur enormes Einsparungspotenzial, sondern auch ein enormes Potenzial, der IT einen Schub in Richtung Innovationsmotor und weg vom Geld verschlingenden BürokratieMonster zu geben. Ohne den Einsatz eines Autopiloten allerdings bleibt Cloud Computing eine Rand erscheinung in der aktuellen IT-Wirtschaft, die von den jetzt großen IT-Anwendern neidisch beäugt wird und die es vielen neuen Unternehmen – die von vornherein auf automatisierte und standardisierte Umgebungen setzen – ermöglichen, den jetzigen Marktteilnehmern den Rang abzulaufen. Dies spricht für eine sehr schnelle Adaption der Autopilotkonzepte und damit für einen enormen Schub in der IT-Produktivität.
Fokus
9
Der Weg in die Private Cloud In kaum einem Unternehmensbereich nimmt man die Notwendigkeit zur Kostensenkung so wahr wie im IT-Betrieb. Wo vor nicht allzu langer Zeit steigende Budgets noch als gesichert galten, ist mittlerweile die Forderung nach einer Reduzierung der Betriebskosten um mehr als zehn Prozent im Jahr keine Seltenheit mehr. Andererseits steigen die Anforderungen permanent. Wo in einem SLA früher die Vereinbarung einer garantierten Verfügbarkeit der Infrastruktur ausreichend war, steht heute oftmals die Nutzbarkeit der jeweiligen Applikation im Vordergrund – es hat der IT-Betrieb also beispielsweise auch dafür Sorge zu tragen, dass eine Datenbank die richtigen Daten ausliefert oder die Performance der Applikation den Ansprüchen der Anwender genügt. Initiales Ziel des Outsourcings bei einem unserer Kunden war die Sicherstellung eines störungsfreien Betriebs nicht nur der Hardware, sondern vor allem der Kundenapplikation, und die Ablösung nicht ausfallsicherer Altsysteme unter wirtschaftlichen Rahmenbedingungen. Dieses Ziel wurde 2006 mit den klassischen Mitteln des Outsourcings erreicht. Für eine anstehende Vertragsverlängerung setzte der Kunde zwei große Ziele. Erstens sollte die derart betriebene Umgebung deutlich flexibler werden, da das Business für das starken Schwankungen unterliegende Geschäft rasche Skalierungsmöglichkeiten fordert. Zweitens war eine erhebliche Senkung der Betriebskosten gefordert, um den eigenen Kostendruck abzufedern, ohne eine positive Geschäftsentwicklung zu behindern. Der klassische Ansatz, um im OutsourcingGeschäft Kosten einzusparen, ist es zu standardisieren und zu konsolidieren. Dabei wird der Fokus auf die beiden größten Kostenblöcke gelegt: IT-Infrastrukturkosten und Administrationskosten (Personal).
Hans-Christian Boos
Bei der Infrastruktur versucht man einmal durch Standardisierung die Einkaufspreise zu senken, zum anderen schafft man von mehreren Kunden gemeinsam genutzte Infrastrukturen (Shared Infrastructure), so dass große Vorab- oder Pufferinvestitionen vermieden werden. Außerdem kann durch eine Standardisierung der Umgebung sowohl in Hardwareals auch in Software-Infrastruktur der administrative Aufwand im Sinne der Skaleneffekte und der Stückkostensenkung verringert werden, was sich auf die für den Betrieb benötigte Personalstärke positiv auswirkt. Diese Konsolidierung funktioniert für entsprechend massenfertigbare Dienste wie SAPAnwendungen, File-Services oder Datenbanken recht gut, entsprechende Hosting-Farmen werden von allen großen Outsourcern angeboten.
Administration 5%
Fehlerbehebung 10%
Technische Analyse 25%
Teamkommunikation 45%
Kundenkommunikation 15%
Zeitverbrauch bei der Fehlerbehebung
UpDate! Ausgabe 13 · Juli 2010
Fokus
10 Der durch Skaleneffekte erzielbaren Ersparnis sind allerdings natürliche Grenzen gesetzt. Um bei den Administrationskosten weiter zu sparen, wird naturgemäß Personal reduziert oder in Regionen mit niedrigen Personalkosten ausgelagert. Solche Ansätze werden schnell problematisch, wenn das eingesetzte Personal das Geschäft des Kunden nicht mehr aus eigener Anschauung kennt, auf Grund kultureller Grenzen nicht nachvollziehen kann oder regelmäßig Reibungsverluste durch scheinbare Kleinigkeiten wie Sprachprobleme, Kommunikationsprozesse und unterschiedliche Zeitzonen auftreten. Erfahrungsgemäß nimmt jeder Manager, der eine Offshoring- oder NearshoringStrategie wählt, einen Qualitätseinbruch in Kauf, der wenn überhaupt nur mittelfristig wieder aufgeholt werden kann. Einen Ausweg verspricht die Automatisierung von Rechenzentrums-Prozessen. Aus diesem Grund ist ein breites Spektrum an neuen Softwareprodukten entstanden, die wie Run Book Automation, Data Center Automation, IT Process Automation oder Workload Automation eine höhere Produktivität des eingesetzten Personals versprechen. Dabei bekommen die vorhandenen IT-Experten bessere Werkzeuge, die die Durchführung einer genau beschriebenen Tätigkeit wesentlich beschleunigen. Theoretisch macht sich die IT damit die Tugenden der industriellen Fertigung zu eigen: geringere Qualitätsvarianzen und höhere Effizienz durch Automation. Allerdings ist den genannten Methoden gemein, dass sie im Gegensatz zu industriellen Prozessen lediglich darauf abzielen, den menschlichen Administrator zu Tätigkeiten aufzufordern bzw. ihm die Durchführung von bestimmten Tätigkeiten zu erleichtern, statt ihm diese abzunehmen, so dass in letzter Konsequenz der Mensch nach wie vor den Flaschenhals bildet. Außerdem wird der meiste Aufwand im IT-Betrieb eben gerade nicht durch das standardisierte Massengeschäft, sondern durch die Abarbeitung nicht standardisierter Anforderungen verursacht. Unvorhersehbarer Aufwand entsteht immer dann, wenn die funktio-
UpDate! Ausgabe 13 · Juli 2010
nierende produktive Umgebung in irgendeiner Weise verändert werden soll oder wenn ein unbekanntes Problem eintritt, das zunächst in mühsamer Kleinarbeit und unter Hinzuziehen diverser Experten diagnostiziert werden muss, bevor es schließlich gelöst wird. Vor allem bieten die klassischen Verfahren bislang überhaupt keine befriedigende Lösung für einen qualitativ hochwertigen, aber preiswerten Betrieb von echten Individualentwicklungen – dabei bergen gerade diese Umgebungen die größten Differenzierungschancen für den Kunden und sind am Markt am interessantesten
Der neue Ansatz: Autopilot-gesteuerte Private Cloud Um in Anbetracht der oft individuellen Applikationen bei arago-Kunden den Kostenaufwand im IT-Betrieb bei gleichbleibender Qualität weiter zu senken und die gewünschte Flexibilität beim Auf- oder Abbau von IT-Komponenten zu unterstützen, setzt arago in der Abteilung Systembetrieb vermehrt auf zwei Komponenten: • Eine „echte“ Automatisation des Systemund Applikationsbetriebes, die mit individuellen Anforderungen umgehen kann und den menschlichen Administrator wirklich entlastet, statt ihn lediglich zu treiben. • Die Schaffung einer Private Cloud, um durch eine vollständige Virtualisierung der ServerLandschaft Skaleneffekte auch für kurzfristigen Ressourcenbedarf verfügbar zu machen und so über die reine Server-Konsolidierung hinaus zu nutzen. Das dynamische Konzept des Cloud-Computing bildet die Voraussetzung für eine Flexibilisierung der IT und die damit verbundene Verbesserung der Auslastung vorhandener Ressourcen (Abbau von Pufferinvestitionen, Energieeinsparungen, etc.) sowie der Nutzbarkeit hinzu gemieteter Ressourcen für den temporären Bedarf. Allerdings kann der Administrationsaufwand für eine sich solchermaßen dynamisch verändernde IT-Umgebung nicht mehr allein von einem Menschen mit Werkzeugen
Fokus
11
erbracht werden. Um den gewünschten Effekt zu realisieren, ist es daher erforderlich, dass beide Lösungsteile – Cloud-Infrastruktur und Autopilot-IT-Betrieb – nahtlos ineinander greifen.
Private Cloud statt reiner ServerKonsolidierung Im neuen arago-Konzept schafft nun eine Private Cloud Abhilfe. Im Gegensatz zur einfachen Virtualisierung, die mehrere virtuelle Server auf einem physischen Server zusammenlegt, um Hardware einzusparen, werden hier sämtliche Ressourcen vollständig dynamisch zuge-
Strategische Bedeutung
Um individuelle Anwendungen effizient zu betreiben, benötigt man entweder sehr viel Fach-Know-how oder über die übliche Standardisierung und Konsolidierung hinausgehende Verfahren, um Kosten zu senken. Dazu kann die arago-Lösung Autopilot ganz individuell auch solche Störungen (Incidents) in der Systemlandschaft, die nur ganz selten auftreten oder in einer bestimmten Ausprägung noch gar nie aufgetreten sind, weitgehend automatisch bearbeiten und damit sowohl Verfügbarkeit wie auch Compliance verbessern, während die erforderlichen Personalkosten gering gehalten werden und die vorhandenen Experten sich auf den Kunden konzentrieren können. Basis der Lösung ist ein Regel-Pool für die Ablage der Erfahrungen rund um die Bearbeitung von Vorfällen sowie ein IT-Modell, das die Abhängigkeiten zwischen der IT und den Services dokumentiert. An allen Punkten des Betriebsprozesses, an denen im herkömmlichen Betrieb menschliche Interaktionen eingeplant sind, wird nun zunächst der Autopilot angesprochen. Dieser analysiert eingehende Daten und führt alle zur Ausfallvermeidung und Umgebungsveränderung notwendigen Aktionen automatisch durch. Erst wenn die Maschine einen Arbeitsschritt nicht vollenden kann, nimmt sie Kontakt zu den jeweiligen Experten auf und übergibt diesem das Problem mit einem definierten Status und der fertig vorbereiteten Analyse.
Change 30% Budget
Run 70% Budget
Operative Bedeutung
Budgetverteilung wiesen. Man muss also gar nicht mehr wissen, auf welcher physischen Maschine die aktuelle virtuelle Datenbank- oder Applikations-ServerInstanz läuft. Gerade im E-Business-Umfeld, wo oftmals kurzfristig skaliert werden muss oder eine zusätzliche Applikation hinzukommen soll, muss dann kein physisches oder virtuelles System um CPU oder Speicher erweitert werden. Stattdessen wird die zusätzliche Applikation auf dieser Cloud eingerichtet und solange in der Summe noch genügend Ressourcen zur Verfügung stehen, kann die Applikation sofort laufen. Außerdem erlaubt diese Konfiguration auch das kurzfristige Hinzumieten von Rechnerkapazitäten, so dass auch ein kurzfristiger Mehrbedarf etwa für eine Marketing-Kampagne nicht in eigentlich nicht benötigten Hardware-Investitionen mit einer unausweichlichen Steigerung der Fixkosten mündet. Verglichen mit herkömmlichen physischen oder virtuellen Servern erreicht man so eine wesentlich höhere Flexibilität. Neben der automatischen
UpDate! Ausgabe 13 · Juli 2010
Fokus
12 Lastverteilung ergibt sich so zugleich höchste Ausfallsicherheit: Falls nämlich eine physische Maschine ausfällt, laufen die betreffenden virtuellen Maschinen einfach auf einer anderen physischen Maschine in der Cloud weiter. Mögen diese Vorteile auch überzeugend scheinen, war Virtualisierung bislang bei IT-Betreibern nur als punktuelle Lösung im Einsatz, um Systeme kostengünstig bereitzustellen, für die sich eine eigene Hardware-Anschaffung nicht lohnte. Nach wie vor existieren erhebliche Vorbehalte, eine komplette Umgebung zu virtualisieren, gerade bei I/O-kritischen Anwendungen oder zentralen Datenbanken. Mit der neuesten Generation der Virtualisierungs-Produkte lässt sich ein virtueller Server aber mittlerweile genauso an ein SAN anschließen wie ein physischer, so dass keinerlei Engpässe mehr bestehen. Entsprechend positive Erfahrungen mit dem Private-Cloud-Ansatz hat arago auch bereits im eigenen Rechenzentrum gesammelt. Unter dem Strich lohnt sich die Kombination aus Autopilot und Private Cloud für Kunden. Für den Kunden steht hier die deutliche Preissenkung bei Verbesserung der abrufbaren Leistung und völliger Flexibilität im Vordergrund, für den Betreiber entscheidend sind die höhere Ausfallsicherheit, die Unabhängigkeit von physischer Infrastruktur und insbesondere der automatisierte Betriebsablauf bis auf Anwendungsebene, welche den Betrieb ohne Margenverlust in Zeiten sinkender Marktpreise sichern und den Kunden binden kann.
UpDate! Ausgabe 13 · Juli 2010
Für die Zukunft sind weitere Einsparungen bereits programmiert: Statt wie früher mit mehreren Wochen Vorlauf neue Hardware anschaffen zu müssen, kann jederzeit eine neue virtuelle Maschine in der Private Cloud bereitgestellt werden, wenn etwa eine Fachabteilung eines Kunden eine neue Anwendung betreiben will. Das erforderliche Capacity-Management muss lediglich dafür sorgen, dass die Ressourcen in der Summe ausreichen und notfalls irgendwann einen neuen Server hinzustellen. Sollte eines Tages ein Umzug des Rechenzentrums anstehen, ist auch dieser dank Cloud leicht zu bewältigen: Sobald die Cloud um genügend Rechner am neuen Standort ergänzt ist, können die am alten Standort abgeschaltet werden – alles andere geht automatisch. Zusammenfassend lässt sich feststellen, dass in der Kombination mit Automatisierung Cloud-Konzepte auch für solche Anwendungen nutzbar werden, die nicht speziell für eine Cloud entwickelt wurden. Somit erschließen sich die Vorteile von Cloud-Computing erstmals auch für die Legacy-IT und ermöglichen hier erhebliche Einsparungen bei Infrastruktur, Persona und nicht zuletzt auch der immer wichtiger werdenden Energie. Aus diesem Grund zählt das neue Lösungskonzept bei arago mittlerweile zum Standard und wird zukünftig in allen geeigneten Projekten eingesetzt.
Fokus
13
Geschwindigkeit vs. Wissen – Wie Automation die wenigen IT-Gurus nutzbar macht Es ist unbestritten, dass echte IT-Experten in der Betreuung von IT-Landschaften nicht wegzudenken sind. Selbst bei großen Anbietern trifft man bei der Lösung anspruchsvoller Aufgaben immer wieder auf die gleichen wenigen echten IT-Gurus, die die echten Herausforderungen bewältigen. Oft sehen sich diese Experten einem harten Wettkampf gegen die Uhr und damit gegen Pönalzahlungen ausgeliefert und mit steigender Komplexität der ITAnwendungen vermehren sich die Einsätze der Experten exponentiell. Mit der Ausrichtung der IT auf dynamische Architekturen, die derzeit unter dem Begriff Cloud Computing zusammengefasst werden, wird der zeitliche Wettkampf noch verschärft, wenn nicht gar multipliziert. Denn zusätzlich zu den SLAs kommen nun noch die dynamischen Änderungen an der Struktur der Anwendungen und der Struktur der Gesamtinfrastruktur, die eine Cloud ausmachen. Spätestens dann ist dem Problem nicht mehr mit Überstunden beizukommen. Aus diesem Grund stellt sich die Frage, wie heute gearbeitet wird und wie man diesen Geschwindigkeitswettbewerb durch Wissen gewinnen kann? Abgesehen von allen administrativen Prozessen wird ein Problem heute Schritt für Schritt abgearbeitet. Dabei werden verschiedene Experten zu Rate gezogen und wenn die Kommunikationsprozesse gut funktionieren, greifen diese Experten Hand in Hand, um eine Aufgabe zu lösen. Dabei entsteht ein Ablauf, der klar umrissen ist und der – tritt genau dasselbe Problem noch einmal auf – wiederholt werden sollte. Diese Wiederverwendung wird entweder implizit gefördert, indem die Experten dazu angehalten werden eine Knowledge Base in Form eines Wikis oder anderer Dokumentationsme-
Hans-Christian Boos
thoden zu pflegen, oder explizit erledigt, indem die Experten das erworbene Wissen in Skripten ablegen, die dann beim Eintreten derselben Situation wieder angewandt werden können. Diese Skripte entstehen zumeist aus dem Frust heraus, mehrmals den selben Lösungsweg durchgeführt zu haben, wahrscheinlich einigen Kollegen zum dritten Mal erläutert zu haben, was zu tun ist, und dennoch immer wieder bei ähnlichen Fehlersituationen gerufen zu werden. Zur Erstellung solcher Skripte steht heute eine ganze Fabrikhalle voller guter und innovativer Werkzeuge zur Verfügung, die sich entweder auf eine bessere Wiederverwendbarkeit durch Standardisierung oder auf eine komfortable Erstellung der Skripte fokussieren. Aber egal wie bunt oder methodisch das Thema auch angegangen wird, letztendlich entstehen dabei feste Skripte und Prozeduren.
UpDate! Ausgabe 13 · Juli 2010
Fokus
14
Infrastructure Apps
Platforms/OS
Start
End
Application Operation
Automatisierung „Old Style“ Dieses Vorgehen hat zwei gravierende Nachteile, die im Wettkampf gegen die Zeit nicht helfen. 1. Mangelnde Flexibilität oder Wieder verwendung Eine einmal erstellte Automatisierung oder ein einmal erstelltes Skript ist für eine bestimmte Situation vorgesehen. Wenn genau diese Situation vorliegt, kann es ausgeführt werden und wird den gewünschten Erfolg zeigen. Dies kann sogar automatisch erfolgen, wenn die Situation, auf die ein Skript anwendbar ist, genau genug beschrieben ist und überwacht wird. Meistens aber aktiviert ein Mensch die Skripte, nachdem er die Situation untersucht hat. Der Unterschied zum Experten besteht darin, dass das Skript einen direkten Lösungsweg nimmt und nicht, wie der Experte selbst, den Weg bei der initialen Problemlösung sucht und dabei auch überflüssige, aber erkenntnisreiche Schritte durchführt. Dadurch sind Skripte immer nur situationsbedingt anwendbar und auch der Overhead einer guten Überwachung oder eines zentralen Repositories für die Skripte – wie das die Data Center Automation oder Run Book Automation Werkzeuge der aktuellen Generation bieten – kann die Anwendbarkeit
UpDate! Ausgabe 13 · Juli 2010
nicht erweitern. Für eine Umgebung, die permanenten Änderungen unterworfen ist und deren Standardisierung mit Sicherheit niemals 100 % erreicht, ist damit jede Art von Skripten zwar eine gute Erweiterung des Werkzeugkastens und kann das Durchführen eines bestimmten Arbeitsschrittes erheblich beschleunigen, aber für den generellen Kampf gegen die Uhr ist eine Sammlung von „starren Programmen“ nur bedingt geeignet. 2. Mangelnde Pflegbarkeit An der Erstellung eines einmal erfolgreichen Arbeitsablaufes sind mehrere Experten beteiligt. Diese Experten komprimieren ihr Wissen in einem Skript oder in einer Prozedur. Will man diesen Ablauf nun verändern, muss man zunächst wieder eine ähnliche Konstellation von Experten zusammenstellen, die das bestehende Konstrukt verstehen und dieses dann ändern. Außerdem ist es wahrscheinlich, dass bei einer Änderung an einer Stelle des Konstrukts auch andere Stellen oder gar andere Skripte und Prozeduren betroffen sind. Also werden nach dem guten alten Grundsatz „Never change a running System“ solche Änderungen möglichst auf ein Minimum reduziert, um keine unvorhersehbaren Folgeaufwände zu generieren.
Fokus Die Pflege wird also durch die Abhängigkeiten innerhalb von Skripten und zwischen Skripten sowie die benötigte Expertenkombination für entsprechende Pflegeeingriffe erschwert. Das macht aber auch eine kontinuierliche Verbesserung einer solchen Umgebung zu einer Mammutaufgabe, die entsprechende Bürokratie und Overheads nach sich zieht. Tritt man nun einen Schritt zurück, um sich zu fragen, was das Arbeiten der Experten vom Arbeiten der Skripte – die ja von den Experten erstellt wurden – unterscheidet, sieht man den Unterschied im schrittweisen Vorgehen der Experten, die keinem festen Ablauf unterliegen und zu einem beliebigen Zeitpunkt andere Experten hinzuziehen können. Ein Skript hat eine komplexe Bedingung, die eintreten muss, damit es seine Aufgabe erfüllen kann. Ein Experte kann mit relativ wenigen Informationen einen kleinen Baustein aus seinem Gesamtwissen abrufen, der dann mehr Informationen erzeugt, mit denen dann der Experte selbst oder einer seiner Kollegen den nächsten Baustein abrufen kann und bewerten kann, ob er den richtigen Weg eingeschlagen hat oder nicht. Experten gehen also Schritt für Schritt vor, erzeugen bei jedem Schritt neue Informationen und werden das, was sie über die zu bewältigende Aufgabe wissen, nach jedem Schritt neu gegen ihr Erfahrungswissen austauschen. Legt man nun das Erfahrungswissen von Experten in einem Wissenspool in hinreichend kleinen Bausteinen ab, so kann – bei ausreichend Rechenkapazität oder guten Algorithmen – dieses Wissen Schritt für Schritt abgerufen, das Ergebnis nach jedem Schritt neu analysiert und so ein dynamisch auf die Situation passender Ablauf erzeugt werden. Umfasst der beschriebene Wissenspool das Wissen und damit die Erfahrungen mehrerer verschiedener Experten, so kann auch die Zusammenarbeit der Experten maschinell abgebildet werden. Der Unterschied ist, dass die Aktionen Schritt für Schritt herausgesucht werden – ein Skript entsteht also während seiner Ausfüh-
15 rung. Dabei können Schritte durchgeführt werden, die nicht notwendig sind, die aber wertvolle Erkenntnisse darüber geben, welches weitere Wissen abgerufen werden sollte oder welche Erfahrungen in der gegebenen Situation nicht relevant sind. Mit einem Erfahrungsspeicher und einem entsprechenden Algorithmus, der diesen Erfahrungsspeicher abruft, lassen sich gleich mehrere Herausforderungen bewältigen: 1. Geschwindigkeit in der Verarbeitung Offensichtlich kann eine Maschine in einer vertrauten Umgebung schneller arbeiten und mehr Aufgaben entgegennehmen als ein Mensch. Durch die Kombination von unterschiedlichem Expertenwissen im Erfahrungspool fallen aber auch die Overheadaufwände weg, die normalerweise notwendig sind, um zwei Experten an ein und derselben Aufgabe arbeiten zu lassen. Selbst wenn die Maschine nicht schneller arbeiten würde als der Mensch, würden die Ergebnisse durch den Wegfall der Bürokratie 50 % schneller erreicht. 2. Wiederverwendung von Expertenwissen und damit Schaffung neuen Wissens Einmal abgelegtes Wissen wird wieder und wieder verwendet. Auch die aufwändige Pflege fällt weg, denn ein Experte lässt sich
Knowledge Repository with rule modules Application Operation Infrastructure Apps Platforms/OS
Erfahrungspod
UpDate! Ausgabe 13 · Juli 2010
Fokus
16
Decision
Decision
Decision
Analysis
Analysis
Analysis
Start
Analysis
End
Dynamische Automatisierung mit dem arago Autopilot ja auch nicht bei jedem neu erworbenen Wissen das Gedächtnis löschen. Lediglich die Anwendungswahrscheinlichkeit von alten Erfahrungen verändert sich bei der Gewinnung neuer Erfahrungen. Damit wird das Wissen der Experten wiederverwendbar, der Pflegeaufwand für einen einmal etablierten Wissenspool gering gehalten und der Experte durch die gewonnene Zeit in die Lage versetzt, neues Wissen und neue Erfahrungen zu erarbeiten. 3. Parallelität und damit Korrelation und Kombination von Aufgaben Dadurch, dass eine Maschine im Gegensatz zu Experten an vielen Problemen gleichzeitig arbeiten kann, kann eine Maschine auch eine automatische Korrelation der Aufgaben vornehmen. Zum Beispiel wenn zwei Situationen für sich genommen kein neues Wissen im Erfahrungspool erschließen, in
UpDate! Ausgabe 13 · Juli 2010
ihrer Gemeinsamkeit aber den Zugriff auf neue Erfahrungen ermöglichen. So wird nicht nur das gleichzeitige Abarbeiten vieler Aufgaben ermöglicht, sondern auch noch die Verbindung von mehreren Aufgaben gefördert – eine Gegebenheit, die in modernen IT-Architekturen, die so viele versteckte Abhängigkeiten haben, von größtem Vorteil ist. Mit diesem Vorgehen müssen nicht die Experten das Rennen gegen die Uhr gewinnen, sondern sie haben Zeit neues Wissen zu sammeln und neue Erfahrungen in den Pool der Maschine zu überführen, die die tägliche Arbeit erledigt. Damit wird nicht nur die Aufgabe des IT-Experten wieder wesentlich interessanter, sondern seine Fähigkeiten werden tatsächlich zum ersten Male multipliziert und die Seltenheit von Experten wird zum Geschäftsvorteil.
Development
17
Cloud Pilot – Ein Überblick Jede Cloud Plattform, in der man heute aktuelle IT-Systeme einstellen kann, bezieht sich heute auf eine bestimmte Infrastruktur und beinhaltet dann die notwendige Virtualisierung, die mit wichtigen Dynamisierungs- und Managementwerkzeugen angereichert wurde. Da die meisten heutigen IT-Umgebungen aber mehrere Plattformen überspannen, kommen, um eine heutige IT-Anwendung in der Cloud zu betreiben, mehrere Cloud Plattformen zum Einsatz, die übergreifend gesteuert werden müssen. Neben diesen Steuerungsaufgaben stellt sich auch die Frage nach dem In- oder Outsourcing von Ressourcen zum Beispiel im Falle von Spitzenbelastungen, die ebenfalls nur von übergeordneter Stelle beantwortet werden kann. Ein Cloud Pilot ist demnach eine besondere Form des bereits beschriebenen Autopiloten, der sich auf folgende zwei Aufgaben konzentriert: 1. Management von Abhängigkeiten zwischen mehreren Cloud Plattformen 2. Management der Nutzung verschiedener Provider für eine Cloud Plattform Die Behandlung beider Punkte durch ein besonderes Regelwerk im Autopiloten, das sich auf das Management von Cloud Umgebungen spezialisiert, wird im Folgenden beschrieben. Im Hause arago werden verschiedene Cloud-Technologien eingesetzt, so dass das besonders für das Cloud Management entstehende Autopilot Regelwerk – der Cloud Pilot – Expertenwissen abbildet, das sich im täglichen Umgang mit verschiedenen Cloud Ansätzen ergeben hat. Das Regelwerk des Cloud-Piloten befindet sich in stetiger Entwicklung und wird noch im Jahr 2010 als separates Paket verfügbar sein. Zunächst wird der Umgang mit verschiedenen Architekturen beleuchtet, da dieser beim Einsatz von Cloud Technologien ohne Autopiloten zu sehr unerwarteten Ergebnissen führen kann.
Roland Judas
Cloud Technologie bedeutet im ersten Schritt den Einsatz einer Virtualisierungstechnologie, die mit Management- und Skalierungslösungen angereichert wurde. Das bedeutet, dass bei steigendem Ressourcenbedarf von IT-Komponenten diesem Ressourcenbedarf Rechnung getragen werden kann, indem im ersten Schritt am aktuellen Ausführungsort der Komponente noch freie physische Ressourcen der Komponente zugeordnet werden. In einem zweiten Schritt kann die Komponente mit Ressourcenbedarf auf einen anderen, leistungsfähigeren oder mit mehr freien Ressourcen gesegneten physischen Wirt umgeleitet werden. Diese Aktionen werden typischerweise vollautomatisch von der jeweiligen Cloud Management – oder Virtualisierungsmanagement – Lösung übernommen. Läuft eine Anwendung innerhalb einer einzigen IT-Plattform, ist damit die Skalierungsanforderung für diese Anwendung 100 % abgedeckt. Die meisten heutigen IT-Anwendungen und auf jeden Fall alle servicebasierten Anwendungen benötigen entweder von vornherein mehrere verschiedene Plattformen (z. B. Linux, Solaris, Host, Windows) oder setzen in der Architektur zumindest darauf auf, dass einzelne Services auf beliebigen Plattformen zur Verfügung gestellt werden können. Dazu kommen verschiedene Cloud Technologien oder Virtualisierungsplattformen zum Einsatz und dann entstehen bei der Skalierung unvorhersagbare Effekte. Zum Beispiel kann der Engpass in einem Service dazu führen, dass ein abhängiger Service nach unten skaliert wird, weil er nicht mehr so intensiv genutzt wird. Zur gleichen Zeit wird der ursprüngliche Service hoch skaliert, wodurch der gerade herunter skalierte Dienst überlastet wird. Je mehr Komponenten an der Kette beteiligt sind desto größer die Ausschläge der Über- oder Unterlast und desto länger die Oszillation der Skalierungen auf den verschiedenen Plattformen, bis ein Gleichgewicht gefunden ist. Da dieses Gleichgewicht stark von der aktuellen Last abhängt, kann es sogar
UpDate! Ausgabe 13 · Juli 2010
Development
18 Provider 1
Provider 2
Infrastruktur 1: Linux
Infrastruktur 1: Linux
Infrastruktur 2: Windows
Provider 3 Infrastruktur 1: Linux Infrastruktur 2: Windows
Infrastruktur 3: Solaris
Infrastruktur 3: Solaris
Infrastruktur n: …
Infrastruktur n: …
Infrastruktur n: …
Cloud Pilot Distribution Knowledge vorkommen, dass es sich nie einstellt, weil auch die Last Änderungen unterworfen ist. Der Cloud Pilot kennt die Abhängigkeiten zwischen den Plattformen, weil über das IT-Modell die Abhängigkeiten der Nutzung einzelner Komponenten genauso bekannt ist wie die unterschiedlichen eingesetzten Cloud Technologien. So können Skalierungsaktionen von außen verhindert oder beschleunigt werden bzw. die Auswirkungen von Skalierungen (z. B. kurzzeitige Unterlast während eine Komponente umgezogen wird) beim Verhalten der Managementsoftware berücksichtigt werden, so dass eine konsistente Nutzung der Gesamtplattform und damit aller auf den verschiedenen Cloud Technologien laufenden Services gegeben ist. Setzt man diese Technologie nicht ein, steigt der manuelle Betreuungsaufwand für eine über mehre Plattformen verteilte Anwendung übermäßig an oder es muss von vornherein auf die Nutzung von Cloud Technologien für Anwendungen verzichtet werden, die auf verschiedenen Systembasen aufsetzt. Da Letztes auf alle modernen Anwendungen zutrifft, ist dies keine Option oder würde den Nutzen von Cloud- und Virtualisierungstechnik zumindest stark einschränken. Darum sind entsprechende Reaktionen, wie sie manuell vorgenommen würden – zum Beispiel vorübergehend eine Herunterskalierung verhindern – im Regelwerk des Cloud Piloten
UpDate! Ausgabe 13 · Juli 2010
vorgesehen und werden als Erfahrungen abgerufen, wenn Einschwingvorgänge starten oder neue Anwendungen für eine Reorganisation einzelner Plattformen oder der Gesamtarchitektur sorgen. Der zweite Bereich, in dem ein übergeordnetes und auf Erfahrungen basierendes Steuerungssystem den Betrieb von Cloud Plattformen sinnvoll ermöglicht, ist die Bereitstellung eines Systems auf mehreren verschiedenen Plattformen. Da diese Plattformen – ob intern oder extern betrieben ist zunächst irrelevant – über verschiedene Managementverfahren und ggf. auch unterschiedliche Prozesse verfügen, kann ein Verschieben von Ressourcen nicht aus einer Plattform selbst erfolgen, sondern muss von einer außenstehenden Instanz angesteuert werden. Außerdem muss entschieden werden, welche Systeme überhaupt auf welchen Plattformen liegen dürfen. Diese Entscheidung kann auf Basis von Kosten oder Sicherheitskriterien (z. B. ob Datenauslagerung möglich oder nicht möglich ist) aber auch auf Basis von ProzessOverhead oder kommerziellen Langzeitfolgen getroffen werden. Diese könnte man in einem starren Regelwerk ablegen, das bei ausgiebiger Nutzung der Cloud Plattformen immer komplexer würde. Legt man es als Erfahrungswert im Cloud Pilot Regelpaket des Autopiloten ab, so beschränkt sich das eigentliche Wissen dagegen auf einen relativ schmalen Regelsatz,
Development der durch harte Grenzen – Sicherheits- und Kostenrestriktionen – an die eigenen Prozesse angepasst wird und der dann nicht nur das Management von Systemübergängen übernimmt, sondern gleichzeitig auch notwendige Policyänderungen oder Skalierungen in präferierten Plattformen (z. B. Private Clouds) zur Genehmigung vorlegt. Diese beiden Komponenten werden in verschiedenen Regelblöcken erprobt und stellen gemeinsam die Steuerung einer Cloud Plattform dar, die eben nicht auf strikteste Standardisierung angewiesen ist, sondern die heutigen IT-Systeme übernehmen und verwalten und diese ggf. noch zwischen mehreren Providern aufteilen kann. Das Cloud Pilot Regelwerk wird derzeit auf unterschiedlichen Virtualisierungstechniken (VMware, Xen, Solaris 10, Microsoft, …) getestet und zusammengestellt. Anschließend wird dieses Regelwerk auf verschiedene Provider Interfaces (RightScale, Amazon, …) angewendet und so als allgemeiner Cloud Pilot für die Nutzer der arago Autopilot Technologie bereitgestellt. Der Cloud Pilot stellt dabei eine besondere Komponente dar, die
19 nicht nur die Arbeitsweise der Administratoren emuliert, sondern auch direkt mit den verschiedenen APIs der Cloud Technologien und Cloud Provider kommunizieren kann – was ein normaler Administrator ohne Programmieraufwand nicht tun kann – und damit eine extrem schnelle und vor allem sehr flexible Schnittstelle zwischen Technologieanbietern schafft. Aber auch die Schnittstelle zwischen verschiedenen Anbietern der gleichen Technologie (zum Beispiel VMWare vSphere Outsourcing Anbieter) wird so standardisiert, dass deren Angebote zumindest technisch normiert werden und damit nur noch die kommerziellen Rahmenbedingungen für die Nutzung des einen oder des anderen Angebots ausschlaggebend sein können. Der Cloud Pilot ist damit eine Hybrid Technologie, die zwischen der menschlichen Entscheidung, die auf Erfahrungen und Prozessen basiert, und den technischen Möglichkeiten, die auf der Verfügbarkeit großer Datenmengen und verschiedener Schnittstellen beruhen, eine Brücke schlägt und damit das bestmögliche Ergebnis erzielt.
Anzeige
arago
Consulting GmbH mehr als Druck ...
arago Consulting GmbH Eschersheimer Landstraße 526–532 • 60433 Frankfurt am Main Telefon: 0 69 / 405 68-352 • www.arago-consulting.de
Wir drucken für Sie > Schulungsunterlagen > Geschäftsberichte > Prospekte > Broschüren > Flyer > u. v. m.
Alles aus einer Hand
Beratung • Redaktion • Layout • Satz Korrektorat • DRUCK • Konfektion • Logistik
Development
20 Thorsten Hilger
Modell, Master Data Management oder CMDB – Einfache Best Practices Um IT betreiben zu können, muss man wissen, was man überhaupt betreibt. Diese grundlegende Erkenntnis hat bei den Designern des ITIL Standards zum Beispiel dazu geführt, dass die Voraussetzung für alle Betriebsprozesse die sogenannte Configuration Management Data Base (CMDB) ist. Auch aus anderen Blickwinkeln ist die Notwendigkeit wirklich zu wissen, was zu betreuen und zu betrachten ist, essenziell. So ist für einen Architekten zum Beispiel das Modell – die grundlegende architektonische Beziehung zwischen Umgebung und Anwendung) – die Voraussetzung dafür, eine stabile, robuste und skalierbare Architektur aufstellen zu können, und aus Sicht der Verwaltung ist eine möglichst genaue Beschreibung der vorhandenen und eingesetzten Ressourcen (Asset Management oder, etwas breiter aufgestellt, Master Data Management) wichtig. Da in der IT leider nur selten „tapfere Schneiderlein“ pragmatische Ansätze wählen, sondern tatsächlich versucht wird, alle Arten von Herausforderungen mit einem Ansatz zu erschlagen, ist die Konsequenz oft ein sehr abstraktes und modulares System, dass eine oder mehrere Metaebenen zur Abstraktion der eigentlichen Gegebenheiten verwendet. Derartige Systeme können zwar alle Arten von Umgebungen beschreiben, verlangen dafür aber ein tiefes Verständnis und setzen den Willen zur ausgiebigen, ständigen und dauerhaften Pflege durch Personal voraus, das dieses Modell nicht nur inhaltlich, sondern auch konzeptionell versteht. Der logisch bestechende Satz: „Man muss ja wissen was man betreibt, darum braucht man eine CMDB“, hat zu vielen CMDB Projekten geführt, die auf Grund ihrer Komplexität nicht zu
UpDate! Ausgabe 13 · Juli 2010
Ende geführt werden konnten, und löst heute einen größeren Respekt vor CMDBs aus, als sie verdienen. In einschlägigen Ressourcen im Internet kann man inzwischen Experten darüber sprechen hören, ob CMDBs nicht nur für Weltkonzerne geeignet sind, weil ihre Pflege so extensive Ausmaße annimmt und dergleichen. Und solche Aussagen sind verständlich, wenn man sich vor Augen führt, dass in einer CMDB heute alle möglichen Informationen mit IT Bezug (vom Rechenzentrum über die Netzverbindung, von der Netzwerkkarte über das Rack, von der Konfigurationsänderung bis zur Urlaubsvertretung, von der fachlichen Bedeutung bis hin zu den administrativen Befehlen) abgelegt sind. Das führt zu enorm komplexen Datenmodellen und schwer zu verstehenden und komplex zu verwaltenden Strukturen. Die Grundsatzfrage bleibt aber immer noch: Was soll eigentlich betrieben werden? Und jeder, der am Betriebsprozess beteiligt ist, muss sich diese Frage für sich selbst stellen. Das bedeutet, dass es ganz verschiedene Quellen und ganz verschiedene Nutzungsschemata für Informationen gibt, die diese Frage beantworten. Wie in solchen Fällen üblich, bietet sich die KIS Methode an. Keep It Simple ist das einfachste Prinzip, dem jeder folgen sollte, der sich mit der Erfassung von IT-Modellen oder CMDB Daten beschäftigt. Je weniger Daten man als Pflicht definiert und je mehr Daten sich auf Grund der wenigen Pflichtdaten auch im Nachhinein noch dazufügen lassen, desto wahrscheinlicher wird diese Informationsbasis auch gepflegt werden und aktuell sein. So kann beim arago M—ARS Ansatz zum Beispiel jegliche Art von Informationen im Modell hinterlegt und mit anderen CMDB oder Modellansätzen verbunden werden. Diese Informationsdichte ist aber keine Bedingung für
Development das Funktionieren des Autopiloten, denn ein Modell ist ja nur Mittel zum Zweck, es soll dem Administrator – egal ob menschlich oder maschinell – die Möglichkeit geben, einen Ansatzpunkt zur Erfüllung einer ihm übertragenen Aufgabe zu finden. Darum muss im M—ARS Modell lediglich die Zuordnung zu einer der Ebenen (Maschine, Anwendung, Ressource oder Software Service) vorgenommen und eine ungerichtete und nicht näher definierte Verbindung (Abhängigkeit) zu anderen Komponenten abgelegt werden. Zusätzlich wird eine Zuordnung zu M, A, R oder S auch noch eine weitere Typisierung (z. B. Web Service, Intel basiert) gefordert. Mit diesen wenigen Informationen kann man anfangen zu arbeiten. Im Laufe der Arbeit entstehen mehr Informationen, zum Beispiel wo der Web Service installiert ist, wie genau er konfiguriert ist etc., um beim vorangegangenen Beispiel zu bleiben. Diese Informationen kann man entweder mit entsprechender Unterstützung der Pflegeumgebung im Modell von Hand ablegen oder man kann es dem Erfahrungswissen (dem Autopiloten) überlassen, diese Informationen herauszusuchen. Man kann davon ausgehen, dass ein Administrator – zumindest ein guter – die Arbeit nicht einstellt, nur weil er eine nicht ganz hinreichende Startinformation erhält. Ein guter Administrator fängt mit dem an, was man ihm gibt und beschwert sich darüber, dass es viel zu wenig ist. Und findet den Rest dann selbst heraus. Genau so kann ein Autopilot auch arbeiten und damit wird die übermäßige Modellpflege zu einer Sache des entsprechenden Regelwerks und der Freigabe der durch Regeln vorgenommenen Modellergänzungen durch einen entsprechenden Verantwortlichen. Der Pflegeaufwand wird minimiert und das Modell bzw. die CMDB bei Bedarf Stück für Stück gefüllt. Je weniger Grundanforderungen man an das Modell stellt, desto sicherer kann man sich sein, dass man ein aktuelles Modell vorfinden wird. Außerdem ist ein unvollständigeres Modell eventuell dafür verantwortlich, dass eine
21
Fehlerbehebung länger dauert als bei einem vollständigen Modell. Aber ein schlecht gepflegtes Modell verhindert die Fehlerbehebung vollständig, so dass die langsamere Fehlerbehebung – und bei einer automatisierten Lösung wie dem Autopiloten sprechen wir hier von Performanceunterschieden unterhalb 2 Minuten – auf jeden Fall vorzuziehen ist. Der Ansatz ist also eine möglichst gute Modellstruktur zu haben. Im Falle des M—ARS Modells ist diese in einem XML Schema abgelegt. Diese Struktur sollte so wenige Pflichtfelder wie möglich haben. Im Falle des M—ARS Standards sind dies die Grundzuordnung (M, A, R oder S), eine Typisierung und die Verbindungen (Abhängigkeiten) zu anderen Knoten. Für alle weiteren Daten sollten entweder Strukturen im Schema vorgesehen sein oder zumindest der Weg zu den Namensgebungen (Common Language) dieser Strukturen eindeutig und nachvollziehbar sein. Diese Common Language und Strukturanweisungen ermöglichen den einfachen und standardisierten Zugriff auf Informationen und vor allem auch die Kontrolle, ob diese Informationen bereits vorliegen oder erst noch ermittelt werden müssen. In unserem Hause gelang es zum Beispiel, auf diese Weise ein Modell, das nur nach der physikalischen Auto-Discovery durch IBM TADDM mehr als 100.000 Komponenten aufwies, auf unter 500 wesentliche Komponenten zu vereinfachen und diese innerhalb von 2 Tagen mit den Basisinformationen und einer Verbindung zum Monitoringsystem zu versehen.
UpDate! Ausgabe 13 · Juli 2010
Development
22
Den Autopiloten mit Wissen versorgen
Viktor Voss
Um die Autopilottechnologie zu nutzen, die aus einem Erfahrungspool Schritt für Schritt das notwendige Wissen herauszieht und es anwendet, um eine bestimmte Aufgabe im IT-Betrieb zu lösen, muss dieser Erfahrungspool mit Wissen gefüllt sein und konstant erweitert werden. Die dafür notwendigen Arbeitsschritte sollen hier kurz umrissen werden. Um Wissen ablegen zu können, muss man sich zunächst vor Augen führen, was flexibel abrufbares Wissen von direkt anwendbarem Wissen unterscheidet. Als Beispiel bietet sich ein Industrieroboter an. Dieser wird mit einem festen Programm ausgestattet, mit dem er einen bestimmten Arbeitsvorgang hocheffizient durchführen kann. Setzt man ihm einen anderen Arbeitsvorgang vor, so wird er diesen nicht komplettieren können und mit großer Wahrscheinlichkeit das Werkstück zerstören. Das Programm eines Industrieroboters ist direkt abrufbares Wissen und zu vergleichen mit einem Skript im IT-Betrieb. Flexibel abrufbares Wissen wäre bei unserem Roboterbeispiel, wenn der Roboter bei jedem Werkstück, das ihm vorgesetzt wird, zunächst erkundet, was er da vor sich hat, und dann durch erfahrungsbasiertes Ausprobieren herausfindet, wie er das gewünschte Ziel erreichen kann. Ganz offensichtlich ist die letztere Variante wesentlich flexibler, mutet aber ein wenig nach Science Fiction an. Die Schwierigkeit besteht darin, das Wissen im Erfahrungspool bereitzustellen. Das Wissen im Erfahrungspool des arago Autopiloten für den IT-Betrieb wird in Regeln abgelegt. Diese Regeln bestehen grundsätzlich aus fünf Teilen: 1. Beschreibung der Regel 2. Definition des Gültigkeitsbereiches der Regel
UpDate! Ausgabe 13 · Juli 2010
3. Definition der Informationslage, mit der die Regel konfrontiert werden muss, damit sie ausgeführt werden kann 4. Ausführungsteil der Regel 5. Beschreibung der Endsituation nach Durchführung der Regel. Im Gegensatz zur Skripterstellung beziehen sich Regeln nicht auf die Umsetzung einer ganzen abgeschlossenen Aufgabe, sondern beschreiben partikulares Wissen oder partikulare Erfahrungen, die erst zu einem späteren Zeitpunkt für die eine oder andere Aufgabenerfüllung zusammengesetzt werden. Derartiges Wissen zu erstellen ist keine einfache Aufgabe. Deswegen haben wir bei arago einen Arbeitsablauf entwickelt, der an Hand der Erledigung einer ganz bestimmten Aufgabe, die Schritt für Schritt – ähnlich wie die Erstellung eines Skriptes – durchgeführt wird, die Elementarisierung der Bestandteile vornimmt und so ohne großen Aufwand die Elementarisierung und damit die Erreichung von Wiederverwendbarkeit des in der Problemlösung vorhandenen Wissens vornimmt. Dieser Arbeitsablauf ist im folgenden großen Flussdiagramm dargestellt und kann auch als Poster bestellt werden. Der Arbeitsablauf untergliedert sich im Wesentlichen in drei Komponenten: 1. Erstellung der Regel selbst 2. Bearbeitung des Gültigkeitsbereiches 3. Bearbeitung der notwendigen Informationslage Diese drei Bereiche sind jeweils mit einem eigenen Arbeitsablauf dargestellt und werden im Ablauf zur Erstellung der Regel selbst zusammengeführt. Durch eine Art Frage-/Antwortspiel wird die Unterteilung der Gesamtaufgabe in Einzelschritte rekursiv vorgenommen. Dabei werden sowohl Regeln identifiziert, die man zur Erfüllung der Aufgabe wirklich sofort schreiben muss (Merkliste mit Priorität), als auch Regeln,
Development die zur Verbesserung der Qualität oder Wiederverwendbarkeit auch noch (irgendwann einmal oder von Experten mit anderen Schwerpunkten) geschrieben werden sollten (Merkliste). Geht man mit einer bestimmten Aufgabenstellung (Bearbeitung eines bestimmten Incidents, Bearbeitung einer Lastsituation, ChangeDurchführung) an diesen Arbeitsablauf heran, so werden dabei sowohl die neu zu erstellenden Regeln sichtbar, als auch die bereits im Wissenspool vorhandenen und damit für die Durchführung der aktuellen Aufgabe bereits verfügbaren Regeln aufgezeigt. Damit entsteht nicht nur das zusätzlich notwendige Wissen, sondern dem Bearbeiter werden gleichzeitig der enorme Nutzen der Wiederverwendung und die Einfachheit der Wiederverwendung selbst vor Augen geführt. Somit führt die stetige Anwendung dieses Prozesses nicht nur zu einer Erweiterung des Wissenspools an sich, sondern auch dazu, dass die Administratoren, die mit diesem Prozess arbeiten, zur Anwendung des Prozesses und der Automationstechnologie des arago Autopiloten motiviert werden. Sie sehen sozusagen, was sie sich selbst schon an lästiger Kleinarbeit abgenommen haben, und das ist äußerst motivierend. Der untergeordnete Arbeitsablauf der Bestimmung der Gültigkeit bezieht sich dabei auf das vorhandene oder zu pflegende IT-Modell und stellt somit sicher, dass das Modell den Anforderungen der Administratoren entspricht und nicht bloß irgendwelchen abstrusen Modellanforderungen genügt, die mit der praktischen Anwendung nichts zu tun haben. In diesem Teilbereich wird ausschließlich auf Daten des Modells Bezug genommen, die entweder
23 selbst durch Regeln erstellt wurden oder die gepflegt werden müssen (Ersteres ist präferabel). Im untergeordneten Arbeitsablauf zur Bestimmung, mit welchen Informationen eine bestimmte Regel und damit ein bestimmtes Stück Wissen abgerufen werden kann bzw. relevant ist, wird auf die Aufgabe selbst eingegangen. Im Modell des arago Autopiloten trägt eine Aufgabe alle Informationen mit sich, die für ihre Erfüllung notwendig sind. Diese Informationen in Kombination mit Modellinformationen, die dem aktuellen Arbeitsort des Administrators im herkömmlichen IT-Betrieb entsprechen, ergeben die Informationslage, die zur Bewertung einer Regel herangezogen wird. Diese Informationslage ist wesentlich volatiler als die Modelldaten, die im vorangegangenen Prozess herangezogen wurden. Hier ist es also essenziell wichtig, dass nicht auf ganz starre Strukturen aufgesetzt wird, sondern dass durch Vorgaben zur Namensfindung für Variablen und Blöcke, die die Informationen beinhalten, deren Dokumentation einen einheitlichen Zugriff auf diese Elemente auch von verschiedenen Menschen ermöglicht. Dieser einheitliche Zugriff wird einerseits durch das vereinheitlichte Namenssystem (Common Language) als auch durch zu erfassende Beschreibungen der Ein- und Ausgabeparameter einzelner Regeln ermöglicht. Wenn Administratoren mit dieser Systematik arbeiten, lernen sie sehr schnell den Wert aussagekräftiger, kurzer Dokumentationssätze und führen diese bei den von Ihnen erstellten Regeln auch stetig mit. Wendet man diesen Ablauf stringent an, kann ein guter IT-Administrator das Arbeiten mit dem Wissenspool in wenigen Tagen lernen.
UpDate! Ausgabe 13 · Juli 2010
Development
26
AJAX Framework
Patrick Röglin
AJAX ist das Schlagwort der Web 2.0 Bewegung. Eine Abkehr von den statischen und trägen Applikationen der Vergangenheit hin zu einer Synergie zwischen Desktop und Internet.
In dieser Zeitspanne kann der User nichts tun, außer die Auslieferung der Seite abzuwarten. Bei AJAX-Anwendungen hingegen kann er weitere Aktionen auf der Seite ausführen, während die Reaktion auf seinen ersten Befehl läuft. Als technischer Vorteil wäre das reduzierte Als AJAX-Applikation bezeichnet man umLadevolumen und die damit reduzierte Ladegangssprachlich eine Website, die bei einer zeit zu nennen. Es muss vom Server nur das Aktion nicht eine neue Seite lädt, sondern den geliefert werden, was sich verändert, und nicht Inhalt der Seite verändert. So kann ein Teil der die gesamte Seite. Seite oder die ganze Seite verändert werden, Die durch AJAX (und Erweiterungen wie ohne dass die URL gewechselt werden muss. prototype) bereitgestellten Funktionen bilden Hierdurch lassen sich Applikationen schreieinen guten Funktionsumfang für simple Apben, die in ihrem Verhalten eher klassischen plikationen. Um den User von allen MöglichkeiDesktops ähneln als klassischen Webseiten. ten des dynamischen Webs profitieren zu lasDie klassischen Web-Applikationen werden sen muss noch viel Programmierarbeit in jedes häufig als holprig oder stockend wahrgenomProjekt gesteckt werden. Insbesondere hochmen. Der Grund hierfür ist der Zeitabschnitt dynamische Funktionen wie Widgets, dynamizwischen Befehlserteilung (Klick/Enter) und sche Templates oder dynamische Module sind dem Anzeigen der daraus resultierenden Seite. sehr aufwändig in Erstellung und Wartung. An dieser Stelle greift scriptMe ein. Mit dem Ziel, die Entwicklungszeit zu verkürzen und den Entwicklungskomfort zu steigern, Designserver Applikationsserver hat arago scriptMe erarbeitet und bereits erfolgreich eingesetzt. scriptMe ist ein Framework, dass die Entwicklung widgetgeXML XML steuerter und hochdynamischer Applikationen deutlich vereinfacht. Das Framework bietet das komplette Frontend einer solchen HTML Userinteraktion Applikation inklusive Widgetverwaltung in einer leicht verständlichen Form. Die Entwickler der Applikation JavaScript scriptMe können sich vollständig auf das Backend und das Design konzentrieren. Sowohl eine Toolbox als auch CSS und Bilder Ereignissteuerung eine beliebig granulierbare Ablagefläche bilden die Aufenthaltsräume für Widgets. Widgets lasFrontend sen sich durch scriptMe in Größe und Position frei verändern. Auch
UpDate! Ausgabe 13 · Juli 2010
Development Zustände wie: geöffnet, minimiert und geschlossen lassen sich abbilden. scriptMe verhindert eigenständig Überlagerungen von Widgets und kann die Ausdehnungen und Zustände von Widgets erzwingen oder verhindern. Um ein Maximum an Flexibilität zu gewährleisten, behandelt scriptMe Daten und Design vollständig getrennt. Somit können die Designs unabhängig entwickelt und getestet werden. Auch Anpassungen der Designs können zu einem späteren Zeitpunkt vorgenommen werden, ohne das Backend verändern zu müssen. Die Daten werden über eine XML-Schnittstelle übertragen. Dies ermöglicht eine maximale Kompatibilität zu anderen Datenquellen. Das Backend überträgt hierbei zum einen die
27 Konfigurationen der Applikation und zum anderen die Anzeigedaten. In der Konfiguration wird beschrieben, welche Module das Frontend anzeigen soll, welche Templates hierfür genutzt werden sollen und welchen Zustand die Widgets beim Erstaufruf haben. Die Daten werden abhängig von den Aufgaben der Applikation geliefert. scriptMe kann mit beliebigen Daten umgehen. Dies ermöglicht die Anzeige sowohl eines Forums und eines Flashfilms mit der gleichen Bibliothek, ohne dass der scriptMe Code angepasst werden muss. Auch das nachträgliche Laden von JS-Dateien, CSS-Definitionen oder Bilddateien ist problemlos möglich.
Automatisierung im Systembetrieb – Die arago Autopilot Engine aAE
Inside arago
28 Lydia Fratzer
Auftakt zur Roadshow – Automatisierung im Systembetrieb Den Auftakt einer Roadshow durch deutsche Großstädte zum Thema Automatisierung im Systembetrieb – die arago Autopilot Engine aAE bildete das Event am 19. 5. 2010 in den Räumen der arago AG in Frankfurt. Zunehmender Kostendruck einerseits, hohe Ansprüche an Verfügbarkeit und Sicherheit sowie Überlastung der Experten im Systembetrieb andererseits führen zu einem wachsenden Interesse an der arago Autopilot Engine. Um diesem Interesse nachzukommen, bietet die arago noch vor der Sommerpause weitere Fachveranstaltungen in Berlin, Bonn, Stuttgart und München. Um den Teilnehmern der Veranstaltung in Frankfurt das Flair eines Autopilot-Betriebs zu vermitteln, händigten zwei Stewardessen den Gästen beim „Check-In“ Bordkarten aus und wünschten einen guten Flug mit dem Autopiloten. Zu Beginn gab Hans-Christian Boos, Vorstand der arago AG, einen Überblick über Einsatzmöglichkeiten und die Funktionsweise des Autopiloten. Je nach Größe und Komplexität der Serverlandschaft können durch den Einsatz des Autopiloten durchschnittlich 30 % der Personalkosten im Systembetrieb eingespart werden. Zudem reduzieren sich die Downtimes um bis zu 50 %. Nebenbei dokumentiert die Engine jeden Schritt sehr ausführlich und revisionssicher, so dass auch hier Kosten hinsichtlich der Einhaltung von Compliance und gesetzlichen Regularien reduziert werden können. Viktor Voss (arago AG) demonstrierte anschließend die Arbeit des Autopiloten, die im Echtzeitbetrieb nicht sichtbar ist. Mit einer künstlich herbeigeführten zeitlichen Verzöge-
UpDate! Ausgabe 13 · Juli 2010
rung konnten die Teilnehmer verfolgen, wie die Engine verschiedene Knoten des hinterlegten IT-Modells durchläuft, um die Ursache eines Fehlers herauszufinden und notwendige Schritte zur Behebung einzuleiten. In ihrem Vortrag Ordnung ist das halbe Leben präsentierte Jeanette Fürst (OpenAdvice IT Services GmbH) die Business Service Monitoring Lösung (BSM) von OpenAdvice. BSM visualisiert Servicekorrelationen und bietet eine Management-Sicht auf auswählbare Komponenten. Anschauliche Grafiken demonstrierten den Teilnehmern das automatisierte Service Monitoring in der Praxis. Hinter die BSM Lösung fügt sich nahtlos der arago Autopilot an, um Incidents automatisiert zu beheben bzw. pro-aktiv zu vermeiden. Das konkrete Vorgehen bei einem Automatisierungsprojekt erläuterte Veit Blumrodt von der syngenio AG. Während der Reifegrad- und Detail-Analyse-Phase wird ein Pilotprojekt für das Ausrollen der Autopilot Engine beim Kunden identifiziert, meist ein besonders fehleranfälliger Bereich. Phase 3 beinhaltet das Ausrollen der Engine und wird mit der Übergabe an den Kunden inklusive Wissenstransfer abgeschlossen. Sind beim Kunden Prozessmanagement-Tools im Einsatz, werden diese zur Abwicklung eines Automatisierungsprojekts herangezogen, andernfalls arbeitet syngenio nach der Prince2-Methode. Zum Abschluss der Veranstaltung konnten die Teilnehmer mit den anwesenden Experten Detailfragen klären. Beim Flying Buffet kam auch das Networking nicht zu kurz, so dass viele neue Kontakte bis zum „Check-Out“ geknüpft werden konnten. Mehr zur Veranstaltung und zu den Vorträgen: www.arago.de
Inside arago
29
Next 2010 Mit Konferenzen ist es immer schwierig, denn nie kann man es allen recht machen – vor allem nicht, wenn höchst unterschiedliche Erwartungen an die Inhalte aufeinander treffen. Aber um es vorweg zu nehmen: Die Next 2010 war dennoch eine gelungene Konferenz. Die Erwartung einer erhellenden Vorstellung Disruptiver Technologien hat mich am 10. und 11. Mai nach Berlin getrieben, bestärkt darin durch das diesjährige Veranstaltungsmotto Game Changers und die bekannten Bewertungen der Next-Konferenzen aus den vergangenen vier Jahren. Schließlich war fast die ganze Internet-Branche zugegen und traf auf Vertreter aus Medien, Journalismus und Werbung. Referenten aus aller Welt gaben sich ein Stelldichein, vom Frauenhofer Institut – dem Erfinder von mp3 – über die Social Media Women Cindy Gallup bis hin zu einem amerikanischen Unternehmen, das Automobile als Unikate fertigt. Thematisch ging es in diesem Jahr um Game Changers. Schade nur, dass die Next 2010 selbst keine wirklichen Game Changer an den Start brachte. So waren die Themen der Vorträge zum Teil unspektakulär bis langweilig; zu vieles in den zwei Forensträngen hatte man an anderer Stelle bereits schon einmal gehört und gesehen. Für eine so große Anzahl von Teilnehmern, von denen viele sich selbst ja gerne als Vordenker sehen, gab es erstaunlich wenig angeregte Diskussionen direkt in den Panels. Stattdessen wurde endlos von Folien abgelesen. Ja, der Präsentationsenthusiasmus der Speaker ließ wirklich zu wünschen übrig. Lediglich Frau Gallup mit ihrem Vortrag über ihre Seite makelovenotporn.com und der Beitrag des amerikanischen Professors und Tanzlehrers Peter Lovatt aka Dr. Dance How to dance haben wirklich einen Ansatz von Game Changing aufgezeigt.
Annett Boos
Meine Erwartungen indes, disruptive Technologien kennenzulernen und etwas über mögliche Vermarktungsansätze zu erfahren, fielen schon nach dem ersten Tag komplett hinten runter. Stattdessen habe ich mich auf das Netzwerken fokussiert, denn dafür bot die Next 2010 einen exzellenten Nährboden. Bei ausgelassener und entspannter Stimmung konnte man viele Leute aus den unterschiedlichsten Bereichen und Positionen auf überschaubarer Fläche treffen. Diese äußerst ergiebigen Gespräche am Rande der Next 2010 haben mir spannende neue Kontakte gebracht. Ich freue mich schon darauf, die begonnenen Dialoge fortzusetzen und zu intensivieren. Als typisches Erkennungszeichen einer Konferenz im IT-Bereich sei noch angemerkt, dass höchstens zwanzig Prozent der über tausend Gäste Frauen gewesen sind, der Rest war männlich – und mit den vielen, allzu vielen Anzugträgern auch etwas zu förmlich gewandet für einen Haufen professioneller Geeks, aber das nur am Rande.
UpDate! Ausgabe 13 · Juli 2010
Inside arago
30
Cloud Storm Düsseldorf
Roland Judas
Am 4. 5. lud im Rahmen der europäischen Cloudstorm-Events eine Reihe innovativer Anbieter von Produkten im Bereich des Cloud Computings zu einer Informationsveranstaltung in Düsseldorf. Circa 70 Gäste folgten dem Aufruf, um im Meilenwerk zwischen Oldtimern und Sportwagen das Thema intensiv zu diskutieren. Nach einer Keynote mit dem Titel No Cloud without Automation, in der arago-Gründer Hans-Christian Boos aufzeigte, wie eng Cloud Computing und Automatisierung ver-
zahnt sind, präsentierten Firmen wie Racktivity, A-Server, Amplidata und ContactOffice im Rahmen von Kurzpräsentationen verschiedene Lösungen im Bereich des Cloud Computings. Der Abend schloss mit einer angeregten Diskussion zwischen Gästen und präsentierenden Firmen. Die Cloudstorm-Reihe wurde Anfang Juni mit einer Veranstaltung in Amsterdam fortgeführt. Weitere Informationen finden Sie auf www.cloudstorm.org.
Neue Mitarbeiter der arago AG Angela Burgmann
Yusuf Murat Yalin
Angela Burgmann, gelernte Fachkauffrau für Einkauf und Materialwirtschaft, unterstützt seit dem 4. 3. 2010 nach ihrer Familienpause die Abteilung Projekte als Assistentin
Yusuf Murat Yalin testet seit dem 1. 5. 2010 für uns Software im Bereich Projekte. Während er beruflich in die Tücken und Schründe von Programmen eintaucht, geht er in seiner Freizeit lieber die Wände hoch. Eines seiner vielen Hobbys ist nämlich das Klettern.
Kristina Shagan Kristina Schagan ist seit dem 29. 5. 2010 bei arago im Unternehmensbereich Betrieb tätig und unterstützt unsere Systemadministratoren als Team assistentin. Neben der Arbeit studiert sie Wirtschaftsrecht und BWL. Billard betreibt sie als Hobby und ist u. a. DoppelEuropameisterin bei den Juniorinnen.
UpDate! Ausgabe 13 · Juli 2010
Inside arago
31
15 Jahre arago AG Die arago AG wird dieses Jahr 15 Jahre alt! Das möchten die Gründer Hans-Christian Boos, Martin Friedrich und Dr. Bernhard Walther zum Anlass nehmen, mit allen Kunden, Mitarbeitern, Partnern und Freunden zusammen ein rauschendes Fest zu feiern. Auf dem Programm stehen neben 15 Jahren arago AG-Highlights eine Wii-Olympiade sowie ein Basketball-Freiwurfwettbewerb, bei denen es Preise zu gewinnen gibt. Außerdem Barbecue und Livemusik. Und weitere Überraschungen, deren Art aus verständlichen Gründen noch nicht verraten werden soll. Das Ganze findet am 3. September 2010, einem Freitag, im idyllischen Club Longbeach zu Hattersheim statt, direkt an den Gestaden des Mains. Die Einladungen mit dem genauen Veranstaltungsprogramm werden in Kürze auf den Postweg gebracht.
Infos: www.clublongbeach.de
Impressum Herausgeber
Redaktion und Textbeiträge
arago Institut für komplexes Datenmanagement AG
Annett Boos, Hans-Christian Boos, Ulrich Callenberg, Lydia Fratzer, Martin Friedrich, Thorsten Hilger, Roland Judas, Patrick Röglin, Viktor Voss Layout, Grafik & Satz
Vorstände Hans-Christian Boos, Martin Friedrich Eschersheimer Landstraße 526–532 60433 Frankfurt am Main Telefon: 0 69 / 405 68-0 Fax: 0 69 / 405 68-111 info@arago.de www.arago.de
arago Consulting GmbH info@arago-consulting.de www.arago-consulting.de Bildnachweise Titelseite: lambda_X (www.flickr.com/people/lambda_x/), Lizenz: creativecommons. org/licenses/by-nd/2.0/deed.de Seite 33: Eirik Newth (www.flickr.com/people/eiriknewth/), Lizenz: creativecommons. org/licenses/by/2.0/deed.de ISSN 1862-6580
UpDate! Ausgabe 13 · Juli 2010
Comment
32
Boos Comments Hans-Christian Boos
Enterprise 2.0 – Nur Marketing, solange die „alten“ Vorstände nur Marketing darin sehen In allen möglichen Büchern und Zeitungsartikeln wird das Loblied auf Enterprise 2.0 und Ecosysteme gesungen und die Argumente für solche Systeme sind bestechend. Leider tangieren derartige Systeme immer auch das Selbstverständnis eines Unternehmens und sind damit auf Gedeih und Verderb vom Ego der Führungskräfte des Unternehmens beeinflusst. Die Grundaussage von Enterprise 2.0 verkündet, es sei kein riesiges Unternehmen mehr notwendig, um weltweit agieren zu können, sondern kleinere Unternehmen – mit jeweils besseren Margen als ein einziges großes – könnten sich für eine bestimmte Aufgabe zusammenfinden, sie mit vereinten Kräften erledigen und ansonsten ihrer Wege gehen. Bei Erfolg wächst die Wahrscheinlichkeit, dass diese Zusammenarbeit wiederholt wird und auf diese Weise Ecosysteme von Unternehmen entstehen, die jeweils mit ihrer Expertise in Kombination ein großes Ganzes erbringen. Wirtschaftlich wird das heute oft noch durch das Thema Generalunternehmer-
UpDate! Ausgabe 13 · Juli 2010
schaft oder, einfacher ausgedrückt, über die Haftung in Flexibilität und Geschwindigkeit gebremst, aber das kann man leicht ändern. Schwieriger hingegen ist die Organisation der Zusammenarbeit der kleineren Einheiten untereinander, so dass diese sich wirklich wie in einem lebenden Organismus optimal an- und unterordnen. Und das hat insbesondere mit dem Selbstverständnis der Führungsriegen zu tun. Da hört man dann, dass eine Zusammenarbeit nur dann richtig gut ist, wenn der Partner die eigenen Dienstleistungen vertreibt; man selbst übernimmt diesen Dienst für den Partner nur halbherzig. Wird gar offensichtlich, dass die Partnerschaft sich trotz allem lohnt, wird sofort die Frage gestellt, ob man diese Leistung nicht auch selbst erbringen könne, um so die Marge zu erhöhen. Darum geht es nicht, werte Damen und Herren Vorstandskollegen. Es geht darum, gemeinsam eine Aufgabe zu erfüllen und sich nicht im Streit „Wer hat mehr davon“ zu verlieren oder nach dem „Gewinn des anderen zu schielen“. Gemeinsam ist der Kuchen deutlich größer, die Verwaltungskosten deutlich geringer und die Time-to-Market deutlich kürzer. Aber diese Erkenntnis wird durch ein ebenso kurzfristiges wie kurzsichtiges Gewinnstreben auf der Top-Etage oft verdrängt. Also noch einmal deutlich, meine Damen und Herren Vorstandskollegen … Seien Sie modern, verstehen Sie unter einer Partnerschaft, dass jeder seine Aufgabe so gut wie möglich erledigt und dabei die Eigenarten des anderen respektiert.