Skip to content

Warum geht Wissen verloren

In einem geschlossenen System geht keine Energie verloren. Schade dass Unternehmen kein geschlossenes System sind, denn es ist erschreckend wie viel Wissen und Erfahrung in einem Unternehmen verloren gehen kann. Einer meiner Aufgaben ist die Beratung von Key Account Kunden bei komplexeren Projekten, um sicherzustellen dass Sie von unserer Erfahrung profitieren und natürlich um unsere Roadmap besser auf die Kundenbedürfnisse abzustimmen. Die Installation von Middleware ist meistens verknüpft mit Konsolidierungs- und Migrationsprojekten (in denen bestehende Anwendungen unterschiedlicher Hersteller auf eine neue Plattform zusammengefasst werden, ganz beliebt sind SAP Einführungen). Deswegen bekomme ich oft (am Rande) mit, wie schmerzhaft es sein kann in einem Unternehmen eine genaue Analyse der (Legacy) IST-Prozesse zu erstellen, oder für ein geplantes neues System die Mindestanforderungen zu definieren. Ich treffe immer wieder auf die selben Muster:
  • Es werden andere (neue) Mitarbeiter mit der Umsetzung der neuen Projekte betraut. Entweder weil man den alten Hasen die neue Technologie nicht zutraut, weil die bestehende Mannschaft nicht aus dem Tagesgeschäft entlassen werden solll, oder weil die Verantwortlichkeiten schleichend neu verteilt werden sollen. Egal welchen Grund es gibt die neuen Mitarbeiter haben keine Erfahrung mit dem Gesamtproblem, und die erfahrenen Mitarbeiter haben entweder keine Motivation oder Gelegenheit mehr zu helfen.
  • Die Vordenker die das alte System entworfen und vor allem weiterentwickelt haben sind nicht mehr im Unternehmen. Kleine Änderungen und Pflege wird vom Stammpersonal vorgenommen, aber keiner kann die Prozesse komplett überblicken.
  • Selbst die detaillierteste Systemdokumentation kann ein System (vor allem die Überlegungen bei der Umsetzung) voll beschreiben. Und selbst wenn sie es könnte, so ist sie nicht mehr vollständig erfassbar.
  • Der Teufel steckt im Detail: die Projekte sind meistens so angelegt dass keine Zeit für Fehler oder Verbesserungen eingeplant werden. Das Second System muss gleich perfekt sein, auch wenn die bestehende Anwendung über Jahrzehnte gewachsen ist. Das sind unrealistische Anforderungen, im besten Fall werden im Laufe des Projektes der Umfang der Pilotprojekte immer kleiner - und damit irgendwann machbar.
  • Mitarbeiter die für die Umsetzung Hauptverantwortlich sind werden so mit Fakten und Entscheidungen überschüttet, dass Verdrängungs- und Überschätzungsmechanismen einsetzen. Das Gesamtsystem aus einer anderen Sichtweise (z.B. aus Sicht des Controllings oder des Operatings, oder des Supports, oder oder) zu betrachten wird als unnötig oder zu aufwändig angesehen. Daraus ergeben sich oft Entscheidungen die sich im späteren Betrieb als sehr ineffektiv herausstellen. Oftmals werden einfach zu wenige zentrale Rollen besetzt. Keyuser und Stakeholder aus unterschiedlichen Bereichen gibt es nicht, oder werden nicht gefördert.
  • Ein weiteres Problem sind knappe Deadlines und neue Technologien. Beide führen dazu dass Unternehmen externe Berater in allen Ebenen beauftragen. Das führt zu dem Effekt, dass die Überlegungen zur Umsetzung nicht immer im Besten Interesse der Firma sind, und die gemachten Erfahrungen auch mit dem Ende des Migrationsprojektes das Unternehmen wieder verlassen. Mehrere hundert Business und Technologie Consultants sind keine Seltenheit.
  • Ein Problem mit dem man fertig werden muss, ist auch die Tatsache dass die funktionierenden Prozesse nicht notwendigerweise effizient sind. Bei einer genauen Analyse werden die Schwachstellen entdeckt. Oftmals wird die Entscheidung zum Re-Engeneering aber zu leichtfertig getroffen. Der Projekt-Scope weitet sich somit aus.
  • Pilotprojekte werden oft auch falsch ausgesucht: zwar ist es Sinnvoll nicht mit dem Core Business als erstes auf eine neue Plattform umzuziehen, jedoch ist das bisher manuell betriebene Business einer ausländischen Zweigstelle nicht unbedingt repräsentativ. Von den Problemen wie Zeitverschiebung, kulturelle und Sprachlichen Barrieren oder fehlende Erfahrung der Stammbelegschaft ganz zu schweigen.
Vermutlich lassen sich all diese Probleme nur bedingt vermeiden. Aber wenn man immer wieder obige Punkte vor Augen hält kann man frühzeitig gegensteuern. Zum Glück verliefen alle Projekte die ich so kenne mehr oder weniger erfolgreich. Hilfreiche waren dabei folgende Faktoren:
  • Heroes die Verantwortung und Kommunikation übernehmen. Immer wieder alle Parteien an einen Tisch holen.
  • Manager die Dank Sachverstand Abschätzungen hinterfragen können.
  • Starke Einbindung von internen Ressourcen in allen Phasen.
  • Iterative Umsetzung in kleinen Schritten.
  • Die Auswahl eines Leistungsstarken und flexiblen Softwarepartners mit herausragenden Mitarbeitern (*grins*)

Amazon senkt die Preise für garantierte EC2 Nutzung

Amazon's Utility Computing Platform EC2 zeichnet sich durch eine einfache Skalierbarkeit aus. Für Anwender die allerdings nicht kurzfristig mehrere hundert Compute Instanzen benötigen war das Pricing nicht so attraktiv. Amazon hat nun Reserved Instances angekündigt. Kann man sich auf eine gleichmäßige Nutzung einer Instanz committen, so sinken die Nutzungspreise erheblich. Ich habe das mal (bei einer Monatsnutzng von 30*24h) hochgerechnet:
InstanzStundenpreisNorm MonatMonat 1yMonat 3y
Small$0,10/$0,05$72$48,68$35,49
XL$0,80/$0,24$576$390$284
Das Modell scheint bisher noch nicht für die Windows Server verfügbar zu sein. Details unter EC2 Pricing. Was ich bei Amazon immer wieder gut finde ist es wie durch einfache Bezahlmodelle Anreize für ein bestimmtes Userverhalten geschaffen wird, und dies dank der Anzahl der Benutzer skaliert. Z.b. die Möglichkeit IP Addressen zu reservieren, und solange man diese nutzt sind sie kostenlos. So langsam kommt Amazon mit diesem Pricing in die Regionen von normalen V-Servern (mit dem zusätzlichen Benefit dass man jederzeit mehr Ressourcen auf Stundenbasis dazuschalten kann). Ganz konkurenzfähig sind die Server allerdings immer noch nicht - trotz Dollar Kurs.

SANs

Meiner Erfahrung nach werden im Enterprise Umfeld technische Infrastruktur Entscheidungen oftmals via Policy geregelt. Wenn dann neue Anwendungen installiert werden, so müssen diese sich in die vorhandene Landschaft einfügen - ohne gross eine Risikobewertung durchgeführt zu haben. Typische Kandidaten für diese Vorgaben sind OS (unkritisch solange Erfahrungen damit vorliegen), Cluster, Netzwerk/Firewalls und Storage. Gerade beim Storage ist das Vertrauen in ein Enterprise SAN grenzenlos (muss es auch sein, war ja teuer). Performance Engpässe werden nie auf der SAN Seite gesucht und Ausfälle werden nicht erwartet (als SPoF darf das SAN einfach nicht ausfallen). Dabei gibt es ja auch alternative Ansätze. Lokales Storage (mit Sharding, Replikation), NAS oder auch die Auslagerung gewisser Daten in eine Storage Cloud. Auf jeden Fall sollte man sich überlegen: was passiert wenn mein SAN ausfällt, und wie schnell kann ich es wieder ans Laufen bringen. In einem Artikel den ich auf Highscalability.com gefunden habe bespricht David Marks die Risiken eines SAN Infrastruktur für Web 2.0 Installationen, bei denen Skalierbarkeit und Verfügbarkeit natürlich oberste Prio haben: Should I get a SAN to scale my site architecture (You Can Change It Later Blog).

AWS Cloud SLAs

Amazon wurde gefeiert als sie SLAs für Ihre Cloud Offerings angeboten haben. Das bezieht sich insbesondere auf die Amazon Web Services Dienste S3 (Storage Cloud), EC2 (Compute Cloud), ECB (Elastic Block Storage) und die Host Lösungen für Queueing (SQS) und Datenbank (SimpleDB). Betrachtet man sich allerdings die SLAs, so muss man sagen diese sind ziemlich nutzlos in einem kommerziellen Umfeld (um traditionalle Bedenken zu zerstreuen): Die neuen EC2 SLA definieren, dass ein Kunde 10% der Gebühren für die letzten 365 Tage zurückerstattet bekommt, wenn die Verfügbarkeit unter 99.5% fällt. Dabei wird die Zurückerstattung nur für zukünftige Gebühren gut geschrieben. Die Zurückerstattung ist auf 10% gedeckelt. Strafen/Schadensersatz werden keine zugestanden. Und zu allem Übel ist die Definition der Verfügbarkeit noch so, dass der Kunde sich selbst darum kümmern muss ausgefallene Instanzen neu zu starten, und nur wenn dies nicht gelingt gilt der Service als ausgefallen. D.h. wenn eine Amazon Instanz alle Stunde ausfällt und der Startup einer neuen Instanz 5mins dauert, so gelten diese 5 Minuten nicht als Ausfall. Bei den S3 SLA werden Gutschriften für erfolglose Requests gezählt. 10% bei unter 99.9% und 25% bei unter 99%. Dabei kann Amazon aber weder Requests zählen die nicht angekommen sind, noch steht Amazon mit Strafen/Schadensersatz für Datenverlust ein. Gleiches gilt für EBS, hier gibt es keine SLA, die typische jährliche Fehlerrate (AFR - Anual Failure Rate) wird mit 0.1% - 0.5% angegeben (Lokale Harddisks haben angeblich 4%). Natürlich wird AWS durch diese SLA unter Druck gesetzt einen guten Service zu erbringen. Von daher haben diese schon einen Effekt. Der Kunde muss darauf aber vertrauen und das Risiko eines Schadens komplett selbst tragen. Eine reduzierte Amazon Rechnung wird Ihn da kaum trösten. Cloud Computing definiert nicht nur die Technologie neu, sondern auch die Ökonomie des Outsourcings: statt ewig Langer Vertragsverhandlungen, umfangreichen SLA Monitorings, Schuldzuweisungen und umfangreiche Konventionalstrafen (die zu Aufschlägen beim Betreiber führen um sein Risiko abzusichern) wird auf ein Kooperatives Vorgehen gesetzt, das von Vertrauen geprägt ist. Deswegen haben es auch die Großen Anbieter in dem Markt einfacher akzeptiert zu werden. Die technischen Vorkehrungen die ein Betreiber trifft werden stärker betrachtet als seine Vertraglichen Zusagen. Zusätzlich ist die Lösung durch den Kunden schon stärker auf Ausfall ausgelegt. (Diesen Artikel nehme ich zum Anlass eine neue Cloud Kategorie hier im Blog einzuführen)

SLES11b3: XEN does not work [a huge number of bug reports]

Der Titel dieses Artikels ist eine Zeile aus den SLES11 Beta3 Release Notes. Dieser Artikel soll aber kein Suse bashing sein, sondern vielmehr will ich etwas Frust über den desolaten Zustand der Xen Unterstützung im Linux Kernel herauslassen. Dabei ist der Hypervisor (erwartungsgemäß wegen der Simplizität) nicht das Problem, sondern die Paravirtualisierung der Guests und Support von aktuellen Linux Kernels für die Dom0 Host Domain. Sogar Microsoft Hyper-V (Windows 2008 Server) und Sun xVM Server (Solaris) haben bessere Xen-komptible Hosts zu bieten als mit einem aktuellen mainstream Linux Kernel erreichbar ist. Fedora/Redhat die bisher viele Forward-Port Arbeiten an den Xen Patches in aktuelle Kernels gemacht haben planen ein Fedora 10 Release mit einem Hauptkernel (Linux 2.6.27 / Xen 3.3.0) der sowohl Bare-Metal als auch DomU Installationen unterstützt (durch die Verwendung des paravirt_ops Frameworks). Also ein sogenannter Unified Kernel. Das klingt zwar gut, aber gleichzeitig wird es keinen Kernel geben der als Dom0 (Host) eingesetzt werden kann. Hier verweist das Fedora Projekt auf F8 oder KVM mit dem Xen-in-KVM Emulator Xenner. Dieser setzt aber Hardware Unterstützung voraus. Bei Debian gibt es einen vergleichbaren Unified Kernel, und recht aktuell (Bug#495895) gibt es jetzt in Debian unstable dank Sebastian Blank wieder einen Dom0 Kernel auf Basis der Suse Patches. Suse selbst hat aber in der SLES11 Beta (wie man am Titel sehen kann) noch einige Probleme in diesem Bereich. Ich denke auch bei Debian hat das noch niemand wirklich ausgiebig getestet. Bleiben die kommerziellen Xen Server 5 (Citrix) Installationen wenn man einen Bastel-freien Linux basierenden Hypervisor betreiben möchte. Bei Oracle gibt es die Xen 3.1 basierte OracleVM die aber eine zentrale Management Console empfiehlt und Redhat liebäugelt nach RHEL 5 mit einer eigenen Virtualisierungslösung auf Basis von KVM (verständlich nach dem Kauf von Qumranet). Ich bin ganz Froh zu sehen dass Suse hier den Dom0 Support wieder nutzbar macht, und Debian ist ganz unerwartet einer der fast-followers.

Hyper-V Server

Beim Virtual PC Guy Blog gibt es Screenshots der Installation und "Gui" des neusten "Betriebsystems" von Microsoft: Screenshot CLI Hyper-C Config Tool Aber Spass beiseite, der Hyper-V Server 2008 ist die kostenlos von Microsoft bereitgestellt Hypervisor Platform auf Basis von Windows Server 2008. Hyper-V Server wird mit einem minimalen Environment geliefert (genannt Server Core: ohne Explorer GUI oder Startleiste). Es ist auch nicht möglich Anwendungen zu installieren. Eine vergleichbare Installation kann auch mit einem Windows Server 2008 gemacht werden: Hyper-V sitzt auch dort unter dem Betriebssystem. Allerdings sind in der Server Version Lizenzen für 1 (Standard), 4 (Enterprise) oder unbegrenzt (Datacenter) viele virtualisierte Windows Server 2008 Instanzen enthalten. Auf einem Hyper-V Server (der nur auf 64bit Hardware (max 4 Sockets, 32GB) mit Hardware Virtualisierung läuft) können diverse (Microsoft) Betriebssysteme betrieben werden. Die Emulation der Legacy Devices ist (im Gegensatz zum MS Virtual Server) nicht optimiert, Guests sollten also Device Treiber in einsetzen die von der Virtualisierung wissen ("erleuchted sind"). Für Linux bietet Microsoft die Linux Integration Components for Hyper-V (Beta) als Paket an, SLES 10 (32bit oder x64) ist damit auf Hyper-V Server zertifiziert (allerdings nur mit einer virtuellen CPU). Dabei werden Xen enabled Kernels eingesetzt.

Oracle@EC2

Oracle und Amazon arbeiten zusammen um Oracle Anwendungen im Amazon Grid anzubieten. Es gibt jetzt einige Images die von Oracle kostenlos bereitgestellt werden. Oracle erlaubt sogar den Betrieb von Produktiven lizenzierten Anwendungen im EC2 Grid. Die Konfiguration ist sogar für offiziellen Support zertifiziert. Besonders interessant sind aber auch die Möglichkeiten die vorinstallierten Anwendungen wie Application Express oder Enterprise Manager Grid einfach mal ausprobieren zu können.