Thoughts. Ideas. Photography.

Posts tagged “ICC

ICC: Alles nur ein Marketing-Gag?

Vor ein paar Wochen saß ich im Industriearbeitskreis Cloud Computing an der RWTH Aachen – eine interessante Runde von Wissenschaftlern und Praktikern, die mit Cloud Computing arbeiten. „Arbeiten“ kann dabei total unterschiedliche Ausprägungen haben.

So hörte ich einen sehr interessanten Vortrag von Prof. Sattler von der TU Illmenau zum Thema verteilte, cloudfähige Datenbanken, und wieso ACID-Bedingungen hier manchmal nicht allzu ernst zu nehmen sind. Für jemanden wie mich, für den die ACID-Bedingungen bei Datenbanken mit das zentralste Merkmal einer Datenbank sind, war das ein mehr als nur ein interesssantes Gedankenexeriment.

Ein anderer Vortragender brachte dann eine These auf, auf die ich zunächst erbost reagieren wolllte. Ich nahm mich dann aber zurück, weil ich seine Antwort und seine Überlegugnen dahinter nachvollziehen wollte.

Auf der Heimfahrt aus Aachen tat mir das dann Leid: Ich hätte emotional reagieren und erbost die Überlegung zurückweisen sollen. Dann wäre es mir besser gegangen und ich hätte nicht soviel gegrübelt.

Aber zurück zur Ausgangslage: Der Vortragene war Business Analyst, eine besondere Form des Beraters. Ein Business Analyst untersucht Prozesse und deren Abläufe in Unternehmen um Schwierigkeiten, Deadlocks, Engpässe oder schlicht und einfach unsinnige Prozesse zu identifizieren und sofern möglich zu beseitigen oder zumindest zu verbessern. Die meisten Business-Prozesse sind heute IT-unterstützt, daher hat ein Business Analyst im Normalfall auch viel mit IT zu tun, insbesondere mit den IT-Abteilungen der analysierten Unternehmen.

Das Credo des Business Analysten war nun: Wenn ein Prozess harkt und die interne IT nicht sofort eine brauchbare Lösung liefert, nimm Cloud Computing von einem externen Anbieter. Man merkte seinem Vortrag an, dass er häufiger schlechte Erfahrungen mit internen IT-Abteilungen gemacht hatte. Viele schienen langsam und in internen Prozessen gefangen zu sein.

Meiner Ansicht gibt es hier einige Fehlerquellen:

  • Wenn ein Prozess mit Beteiligung der internen IT-Abteilung nicht anständig arbeitet, sollte man sich fragen, woran das liegt. Es bringt rein gar nichts, der internen IT-Abteilung pauschal den Rücken zu kehren. Wenn der Prozess zwar IT-Unterstützt ist, das Problem aber nicht IT-ursächlich ist, bringt eine Wolke nix.
  • Wenn das Unternehmen nur noch externe IT-Dienste nutzt, und diese seitens einer internen IT-Abteilung nicht mal mehr überwacht werden, wird die interne IT-Abteilung zur Wartungsabteilung für Desktop-PCs. Wissen geht verloren, man begibt sich in Abhängigkeit von externen Anbietern. Man besitzt dann zwar größere Mengen Daten, doch hat man keine Ahnung, wie man diese ggf. vom externen Anbieter „zurückholt“.
  • Statt einer internen IT-Abteilung braucht man über kurz oder lang eine interne IT-Rechts-Abteilung. Diese überprüft ständig die SLAs und Verträge mti den diversen Anbietern, von denen man abhängig ist. Sorry, liebe mitlesende Anwälte, aber ich denke nicht, dass dies ein anzustrebender Zustand ist.
  • Etwas vermisst habe ich eine Definition von Cloud Computing, gerne auch aus Prozess-Analysten-Perspektive. Doch hatte ich permanent den Eindruck, es ginge um  ASP – Application Service Providing. Gerade als er sein Lieblings-Beispiel, die DATEV, nannte, wurde das seht deutlich. Die bekannten NIST-Kriterien (mittlerweile in Version 15) legte er nicht an. Hier kann aber auch ein Verständnisproblem meinerseits liegen. Vielleicht ist nur ASP aus Prozess-Analysten-Perspektive die einzig sinnvolle Art von Cloud Computing. Nur wenn dem so ist: Warum hat sich ASP bis heute nicht durchgesetzt?

Als ich ihn in der Diskussion darauf ansprach, ob Formen des Private Cloud Computing unter Umständen bei der Lösung der Probleme helfen könnten, kam der nächste Schlag ins Gesicht für manchen IT-Verantwortlichen: Er meinte, Private Cloud sei keine Lösung, geschweige denn ein Betriebskonzept. Private Cloud Computing sei nicht mehr als ein Marketing-Gag der Hersteller, auf die RZ-Betreiber hereinfallen würden.

Also mal ehrlich: Cloud Computing ist kein Marketing-Gag, egal ob private oder public. Es ist eine mittlerweile recht sauber definierte Form, den Betrieb eines Rechenzentrums, einer IT-Abteilung oder eines einzelnen RZ-Dienstes zu organisieren. Merkmale wie standardisierte Dienste, klare zugesagte Leistungen, klare Abrechnungsmodelle. Da gibt es keinen Marketing-Gag.

Was versucht heute jemand, der ein Rechenzentrum betreibt? Die Analysten von Gartner und Co. würden sofort Buzzwords wie „Reduce Time To Market“, „Cost Consolidation“ oder „Lean IT“ bringen. Dahinter verbirgt sich meiner Ansicht nach ein ganz einfaches Verhalten: Der IT-Leiter versucht, Komplexität aus seinem Betrieb herauszunehmen. Er versucht, möglichst einfach seine Dienste zu erbringen. Er versucht, Fehlerquellen aufgrund komplizierter Architekturen und Systeme zu vermeiden.

Das klingt gewohnt, hat was von Henry Ford. Der versuchte, Autos statt in handwerklicher Einzelfertigung in Serienfertigung herzustellen. Sowas tut auch der IT-Verantwortliche heute: Er versucht, seinen Betrieb weg vom „handwerklichen“ Ansatz hin zu einem mehr industriealisierten zu verlagern: Statt für jedes System oder jeden Dienst das Rad neu zu erfinden, versucht man auf „vorproduzierte Fertigteile“ zurückzugreifen. (Danke an die Bahn, PWC und Ralf für diesen Denkanstoß!)

Vor einigen Jahren waren solche vorproduzierte Komponenten noch sehr granular: Ein Betriebssystem, ein Server, eine paar Gigabyte Festplattenkapazität, eine Datenbank, eine Skriptsprache, ein Forumssystem, ein Content-Management-System, ein Mailserver, eine geschlagene Woche an Konfigurationsarbeiten und… fertig war das Blog – noch ohne Inhalt und ohne eigenes Layout.

Heute besorgt man sich eine vorkonfigurierte virtuelle Maschine, lässt ein Konfig-Skript durchlaufen und nach 10 Minuten Arbeit läuft die Grundkonfiguration. Solche Maschinen gibt es nicht nur für Blogs, sondern auch für CRM-Systeme, für ERP-Systeme, für…. die Liste ist lang. Das Ausliefern als standardisierte VM ist zwar noch nicht die häufigst genutzte Variante, aber sie erfreut sich steigender Beliebtheit.

Ist dies jetzt schon Cloud-Computing? Nein. Es ist nur ein Beispiel für den Aspekt der Standardisierung.

Jetzt stelle man sich vor, dass eine interne IT-Abteilnung eines Unternehmens solche Fertig-Systeme nutzt anstelle von den oben genannten atomaren Bausteinen: Die Reaktionszeit wird schneller, und sofern die Basis-VMs gut gepflegt sind, wird auch die Qualität nicht darunter leiden, sondern eher steigen. Vor allem aber sieht der interne Kunde schneller ein Resultat: Statt auf die Lieferung und Grundinstallation des Servers zu warten, vergehen bei entsprechender Automatisierung nur noch Minuten bis zum Welcome-Screen seines neuen Servers.

Nun ein wenig Weiterdenken: Statt eines reaktiven IT-Betriebes (Kunde droht mit Auftrag, IT-Abteilung erfindet für den Kunden das Rad neu und bastelt eine individuelle Lösung) wird es ein proaktiverer Betrieb (IT-Abteilung besorgt sich eine Menge vorkonfigurierter VMs aus vertrauenswürdiger Quelle, nutzt diese wenn Kunde mit Auftrag droht). Wenn das bisherige Problem eine langsam reagierende IT-Abteilung war, ist das Problem nun zum Teil gelöst.

Gut, Standardisierung scheint eine Lösungsmöglichkeit zu bieten. Doch haben viele instinktiv Angst vor Standardisierung, vor Gleichmacherei (Hier ein Dank an Prof. Böhle und seine Mitarbeiterin Frau Neumer, die auf diese Argumentationschiene aufmerksam machten und mir interessanten Lesestoff schickten). Wenn man die Auswahl hat zwischen einer Salami vom Bio-Bauern, der mit viel Liebe und Herzblut seine Tiere großzieht, und der im Bliester verpackten gleichförmigen 8,5cm Salami mit viel E621 und dem Besten aus den Vitaminen B, A, S und F, so werden viele die Bio-Salami vorziehen. Standardisierung bedeutet häufig nämlich sowas die „Kleinster Gemeinsamer Nenner“, und das kann unangenehm sein. Also Standardisierung als Gefahr?

In der Tat kann, sofern man auf der falschen Ebene standardisiert, viel gesunde Individualität verloren gehen. Das Customizing von SAP war jahrelang ein entsprechendes Beispiel: Statt SAP an das eigene Unternehmen anzupassen, empfanden es manche Unternehmer mehr als eine Anpassung des eigenen Unternehmens an die Walldorfer Standardsoftware. Standardisierung auf Geschäftsprozess-Ebene ist also keine gute Idee. Mit einer Standardisierung auf Ebene der Werkzeuge scheint aber niemand Probleme zu haben. Windows auf dem Desktop wird als Standard geschluckt, und wenn STRG+C nicht Copy bedeutet, liegen die Nerven blank…

Aber zurück zu meinem Ausgangsaufreger: Private Cloud Computing im Sinne von Adaption der von der NIST genannten Merkmale des Cloud Computing auf eine abgeschlossene IT-Landschaft, ist meiner Ansicht nach kein Marketing-Gag. Insbesondere die Standardisierung – sofern auf der richtigen Ebene durchgeführt – bietet Möglichkeiten. Kombiniert man diese mit Virtualisierung, Self-Service und ggf. weiteren Verfahren zur Abrechnung nach Nutzungsverhalten, kann man sich weg von der handwerklichen IT hin zu einer moderneren beegen. Casus knacktus bleibt dabei die Ebene der Standardisierung. Hier den  Königsweg zu finden, bleibt spannend.


ICC: Datentransfer als Engpass

Ein weiterer Angriffspunkt für Cloud-Bedenkenträger ist der Datentransfer. Der Transfer großer Datenmengen kann in der Tat ein unangenehmer Engpass sein. Wer das mal ausprobieren möchte, kann ja mal seine Ethernetverbindung auf 10MBit drosseln und dann 10GB Daten verschieben. Auf einmal entwickelt man unglaubliches Verständnis für die Entwickler von Kompressionsalgorithmen, und für die von 10GBIT Ethernet.
Doch der Datentransfer kann sich in mehreren Dimensionen zum Engpass entwickeln: Neben dem offensichtlichen zeitlichen Engpass, mehrere 100 Gigabyte über eine DSL-Leitung in die Cloud zu verschieben, gibt es da noch monetäre Restriktionen, die den Datentransfer verhältnismäßig teuer machen.

Eine kurze Übersicht über die Einflussfaktoren:

  • Grundpreis pro übertragenes Bit: Volumen kostet, üblicherweise wird pro Bit (oder ganzzahlige Vielfache davon) ein gewisses Entgeld fällig.
  • Grundpreis pro gespeichertes Bit: Pro abgelegtes Bit (teileweise auch pro Bit und Speicherdauer) wird ein weiteres Entgeld fällig.
  • Put/Get-Befehle werden separat berechnet: Amazon beispielsweise möchte nicht nur pro bewegtem Bit bezahlt werden, es gibt auch eine Art Pauschale pro abgestztem Put oder Get. Nun stelle man sich vor, wie der Kostenzähler rotiert, wenn man viele kleine Dateien schreibt, und aus irgendwelchen Gründen jede Datei mit einem einzelnen Put geschrieben wird. Teilweise wird auch ein Entgeld fällig, wenn aus der Cloud auf die Daten zugegriffen wird.
  • Backup on demand: Manche Cloudanbieter für Storage fangen an, Backupdienste anzubieten – natürlich gegen gesonderte Berechnung.

Was soll man also tun? Es kommt auf die Preisgestaltung an: Daten, die ständig im Zugriff sind, die sehr groß sind oder die sich ständig verändern, sind denkbar schlecht in der Cloud aufgehoben. Selten veränderliche Daten, die nur kurz aufbewahrt werden müssen und auf die nur selten zugegriffen werden, bieten sich für die Cloud an.

Im Blog von Ralf Zenses gibt’s eine schöne Darstellung des Zusammenhangs – willkommen im Pareto-Space!


ICC: Das Problem mit dem schlechten Ruf

Douglas Adams hat in seiner Triologie in fünf Bänden „Per Anhalter durch die Galaxis“ einen Vorschlag für ein revolutionäres Antriebssystem: Man verwendet „schlechte Nachrichten“. Die Vorteile liegen auf der Hand: Praktisch in beliebiger Menge verfügbar, bewegen sich mit (mindestens) Lichtgeschwindigkeit vorwärts, und kein Umweltschützer ist böse, wenn man sie verheizt. Allerdings hatte das Antriebskonzept auch einen entscheidenden Nachteil: Die Nutzer des Antriebs waren überall unbeliebt, weil der Antrieb auf die Nutzer abgefärbt hat – der Ruf der Nutzer war dank der vielen schlechten Nachrichten ruiniert.(Außerdem weiss man nie, wo Gerüchte und schlechte Nachrichten überall ankommen, was die navigation erschwert.)

„Schlechter Ruf“ manifestiert sich im Internet beispielsweise in Form von Blacklists (zum Blocken von Spam, zum Blocken von pornografischen oder anderen unliebsamen Inhalten etc.). Dabei werden, je nach Backlist, einzelne Hosts auf die Liste gesetzt, oder auch ganze Subnetze. Verbreitet sind auch Scoring-Verfahren. Spammt der Rechner selbst, bekommt er eine hohe Score, spammt ein Rechner im gleichen Subnet, bekommen alle Rechner im Subnet eine niedrigere Score etc. Somit erreicht man recht gut große Teile von Botnetzen, wenn diese beispielsweise aus Rechnern im gleichen Subnet einer Firma bestehen, die sich alle gegenseitig infiziert haben.

Ist man erst einmal auf einer solchen Liste vereten, kann man schnell auf andere Listen wandern, und der Ruf ist ruiniert. Das System der Blacklist ist bewährt, und wird gerne genutzt.

Der Effekt kann beim Cloud Computing auch eintreten – im englischen spricht man von „reputation fate sharing“. Man stelle sich folgende Situationen vor:

  • Man setzt einen neuen Mail-Server in der Cloud auf. Aufgrund des extrem hohen Reuse-Faktor erhält dieser Rechner eine öffentliche IP, die kurze Zeit vorher noch einem der größten Spam-Bots aller Zeiten gehört hat. Viel Vergnügen.
  • Einer der Cloud-Rechner wird zum Versenden von größeren Mengen Spam missbraucht. Das System Blacklist schlägt zu und setzt diesen Rechner auf die Liste, und dank eines bewährten Scoring-Verfahrens bekommen die übrigen Rechner im Subnet auch einen Malus. Somit wurde der schlechte Ruf, den eigentlich nur einer der Rechner erhalten sollte, auf alle andern verteilt.

Das Verfahren, das sich bei Subnetzen, die den gleichen Betreiber haben, bewährt hat, wird so zum unkalkulierbaren Risiko für alle Cloud-Kunden.

Lösungen gibt es für dieses Problem nur wenige: Zum einen könnte man das Blacklist-Verfahren modifizieren, um Cloud-Rechner auszunehmen. Allerdings würde dies einen extremen Anstieg des Spams nach sich ziehen. Zum anderen könnte man natürlich endlich Verfahren zur Spamvermeidung auf den Weg bringen, sodass Blacklists überflüssig würden. Zertifikate für SMTP und Greylists wären ein möglicher Anfang.


ICC: Unkalkulierbare Antwortzeiten

Aus der Serie: Wie kann man sich Cloud Computing mieß reden?

Oder positiver formuliert: Welche Risiken gibt es beim Cloud Computing zu bewerten?

Eines dieser Risiken sind unkalkulierbare Antwortzeiten. Ich stelle es hier mal am Beispiel IaaS dar. SaaS und PaaS sind ähnlich, dort sind die Verfahren und Schlussfolgerungen leicht abweichend.

In virtualisierten Umgebungen hat man generell das Problem, dass man einen Mittelweg finden muss zwischen verdammt flott antwortenden, aber total unterbeschäftigten Rechnern, und so weit überbelegten Rechnern, dass nichts mehr geht.

Es ist klar, dass ein Cloud-Betreiber eine möglichst hohe durchschnittliche Auslastung seiner Rechner wünscht, bei gleichzeitig möglichst wenigen Last-Peaks, welche man mit entsprechenden Leistungsreserven abfedern muss. Diese Aufgabe nennt man neudeutsch „Capacity Management“, vereinfacht ausgedrückt ist es das überwachen, dass genügend Last auf den Kisten ist, und trotzdem keine abraucht.

Doch wozu gibt es Methoden, mit denen man mal schnell eine VM von einer auf eine andere physische Maschine schieben kann? Dann sollte das Kapazitätsmanagement doch kein Problem sein.

Das Problem dabei sind aber die Merkmale dieser Methoden, die einem zum Verlagern von Last zwischen Maschinen zu Verfügung stehen. Da gibt es kräftig beworbene Verfahren, die eine Maschine im laufenden Betrieb umziehen. Davon gibt’s auch schicke Demovideos, und da merkt nie jemand was.

<Satiere>Ist ja auch klar. Oder würden Sie einen Leistungseinbruch bemerken, wenn ein Kamerateam Sie vor einem ausgeschalteten Monitor oder einem Standbild filmt und der Kerl mit den Textkarten auch keinen Leistungseinbruch vermerkt hat? Wie auch, als Schauspieler…<Satiere>

Alle diese hot-migration-Methoden arbeiten nach einem ähnlichen Grundverfahren: Die virtuellen Maschinen liegen auf shared storage, zwischen zwei Hosts werden zunächst der Inhalt der Arbeitsspeicher der VM ‚rüberkopiert. Dann werden inkrementell Updates des Arbeitsspeichers gemacht, bis es nur noch wenige Pages gibt, die sehr häufig geändert werden. Dann wird geschwenkt, die VM wird auf dem zweiten Host ab jetzt betrieben, die wenigen übrigen Pages werden umgezogen. Der User merkt davon bestenfalls ein Ruckeln der Maus.

Es ist klar – solch eine Migration ist technisch aufwändig: Viel IO auf beiden Maschinen, Mehrbelastung durch Kopiervorgänge. Nicht gerade das, was man machen sollte, wenn die Maschine eh schon am Anschlag läuft. Also kann man mit diesen Verfahren zwar Kapazitätsmanagement betreiben, aber nur lange bevor man in den Engpass läuft. Proaktives Management ist gefragt.

(Bei Monty Python würde jetzt ein Rudel nordfinnischer Unternehmensberater auf die Bühne hüpfen,  was von APO brüllen und dann von einer urplötzlich auftauchenden Herde Bisons plattgemacht werden. Leider habe ich kein derartiges Video gefunden, welches ich hier hätte einbauen können.)

„Proaktivität“ und „Leistungsbedarf“ sind eine wünschenswerte Kombination, und in virtualisierten Umgebungen, bei denen man jede VM als Betreiber gut kennt, ist Proaktivität sogar bequem zu erreichen. Man weiss einfach, dass Container A (ERP-Dialoginstanz für die Leute im indischen Callcenter, im Gebrauch von 6:00 bis 16:00 Uhr) und Container B (Webshop-Instanz für Nordamerika, in Gebrauch v.A. von 14:00 bis 5:00 Uhr) gut zusammen passen, weil man Erfahrungswerte, Lastprofile und Applikationskenntnis hat.

Bei Cloud-Umgebungen ist das nicht so: Die VMs kommen und gehen ständig, manche sind kurz aufpoppende einmalige Riesenlasten, andere machen praktisch nie was, dritte widerum sind absolut nicht vorhersagbar, weil dort ein Programmierer seinen privaten Ideen fröhnt, immer wenn er irgendwo am Flughafen Zeit hat und auf seinen Flug warten muss. Man hat also unter Umständen weder verlässliche Vergangensheitdaten  noch prognostizierbare Muster. Und zu allem Überfluss hat man extreme Elastizität versprochen.

Was soll man als Cloud Provider machen? Gleich den Strick holen?

Nee, die Lösung ist viel einfacher: Es darf den Kunden einfach nicht stören, wenn die Maschine halt man auf einmal ein wenig stockt, kurz durch die Gegend geschwenkt werden muss und deswegen mal – weil hot migration so aufwändig – nur warm migirert wird (also alle Operationen im Hypervisor anhalten, Speicher verschieben, weitermachen). Das resultiert in zwei Dingen:

  1. Man verspricht dem Kunden besser nicht zu viel Verfügbarkeit. 98% klingt nicht schlecht, und wenn man die Messmethode modifiziert, ist das auch mit wenig Aufwand zu erreichen.
  2. Man verspricht dem Kunden keine festen Antwortzeiten, am besten nicht mal Grenzwerte.

Daraus ergibt sich für den Endkunden ein Problem: Wenn man sich auf eine Antwort aus der Cloud verlässt, ist man verlassen.

Oder positiv formuliert: Betreiben Sie keine zeitkritischen Applikationen in der Cloud, wenn der Betreiber ihnen keine feste Antwortzeit zusichert. Bei IaaS stehen Ihre Chance dafür zur Zeit nicht gut, bei SaaS aber schon sehr viel besser!


ICC: Lizenzmodell für Software

Nachdem es mittlerweile klar ist, dass viele Infrastructure as a Service als das Synonym für das „eigentliche“ Cloud Computing ansehen (und dabei die interessanten Varianten SaaS und PaaS ignorieren), muss man sich mit einigen Besonderheiten dieses Modells vertraut machen.

Zunächst vereinfacht ausgedrückt: Man hat einen virtuellen Rechner mit bestimmten zugesicherten Eigentschaften. Man hat nicht die geringste Ahnung, was für einen CPU-Typ man unter der Virtualisierungsschicht findet, ja man weiss nicht mal, was für eine Virtualisierungsschicht da als Basis für die eigene Maschine dient. Je nach „Verbrauch“ wird abgerechnet, fertig.

Gut, auf solch einer virtuellen Kiste setzt man seien Webshop auf und stellt sich dann die Frage:

„Wie viele Oracle-10g-Enterprise-Edition- oder Standard-Edition-Lizenzen braucht diese Maschine (1) und ist das ganze supportet(2)?“

Zu Frage 1: Keine Ahnung. Fragen Sie Ihren Oracle-Software-Vertriebsbeauftragten. Dessen normales Berechnungsmodell mit CPUs, Sockeln und Cores samt zugehörigen Core-Faktoren läuft ins Leere.  Wenn er keine Lösung findet, können sie den virtuellen Rechner nicht mit einer Lizenz ausstatten.

Zu Frage 2: Aller Wahrscheinlichkeit ist das Ganze unsupported: Oracle lässt nur seine eigene OracleVM sowie Solaris Container als Virtualisierungstechnologie zu. Bei anderen Virtualisierungslösungen gibt’s keinen Support oder man behält sich das Recht vor, dass der Fehler auf nicht-virtualisierter Hardware reproduziert werden muss.

Vor solchen Problemen steht man nicht nur, wenn man die Datenbank von Oracle nutzen möchte. Auf Software wie Mathematik-Programme oder manche Betriebssysteme werden pro CPU oder pro Core lizenziert. Was soll man mit solcher Software in der Cloud machen? Vorsichtshalber für eine 8-Prozessoren-Quadcore-Maschine wie die M4600M2 eine Lizenz erwerben, und hoffen dass der Cloud-Anbieter nicht irgendwo eine 16-CPU-x86-Maschine auftreibt? Oder doch auf eigener Hardware rechnen?

Oder andere Software verwenden, die Cloud-tauglich ist? Aus rechtlicher Perspektive mag dies eine Option sein, doch aus applikatorischer nicht immer.

Zusammenfassend wird es letztlich drei Alternativen geben:

1. Die Softwarehersteller bewegen sich – eine durchaus wahrscheinliche Alternative: Mit speziellen Lizenzangeboten für Cloud Computing, eventuell mit Freigaben für bestimmte IaaS-Produkte, werden sich die Hersteller diesen Markt erschließen können. Vor allem bieten sich dann neue Lizenzmodelle, die sich an den verbrauchsabhängigen Modellen der IaaS-Anbieter orientieren. Eine Datenbank könnte pro Transaktion oder pro verwaltetem Gigabyte berechnet werden, Betriebssysteme nach produktiver Uptime.

2. Die IaaS-Anbieter bewegen sich: Mit zugesicherten maximal zu verfügungstehenden CPUs und Cores, unter zu Hilfenahme von supporteter Virtualisierungstechnologie. Man macht somit die Cloud ein wenig unelastischer, doch lässt man so auch „alte“ Lizenzmodelle zu.

3. IaaS bleibt solchen Anwendungen verschlossen, man bezieht sie als SaaS: Warum selbst die Datenbank betreiben, wenn man sie als Service zukaufen kann? Sofern der Preis in Orndung ist und die Bandbreite ausreicht, wäre auch dieser Schritt denkbar.

Somit bleibt der Markt für Softwarelizenzen im Cloud Computing interessant. Neue Lizenzmodelle werden Software Cloud-tauglich machen und SaaS wird heute noch lokale Software auslagern. Kurzfristig könnte auch die zweite Alternative zum Tragen kommen, langfristig werden Kopplungen an Kerne oder CPUs verschwinden, auch weil Anwender irgendwann gar nicht mehr wahrnehmen können, auf welcher Sorte CPU sie gerade unterwegs sind.


ICC: Cloud Computing in plain english

Ist nicht ganz meine Definition von Cloud Computing, aber ein erster Ansatz und außerdem echt witzig gemacht:


ICC: XaaS

Im Zusammenhang mit Cloud Computing werden immer wieder diverse „as a Service“-Begriffe genannt, um das Cloud-Computing-Angebot näher zu charakterisieren. Wichtig dabei ist: Nicht jedes XaaS-Angebot ist gleich ein Cloud-Computing-Angebot, doch lassen sich die gängien Cloud-Computing-Angebote in diese Kategorien einteilen. Gängig sind IaaS, PaaS, AaaS, SaaS, manchmal auch noch DaaS. Zu diesen vier Varianten wage ich ein paar Prognosen – mal schauen, ob sie zutreffen…

  • IaaS – Infrastructure as a Service. Zu Deutsch: Der Kunde erhält einen standardisierten Virtuellen Rechner, auf dem er machen kann, was er will. Er darf auf der Infrastrukur machen, was er möchte – was genau seine Infrastruktur jetzt aber bildet, ist Problem des Cloud-Anbieters. Das Angebot ist das technisch vielseitigste, gleichzeitig das für den Anbieter vermutlich einfachste. Generell ist hier mit geringen Preisen, aus Anbieterperspektive geringen Margen zu rechnen. Dafür muss der Kunde aber auch eine ganze Menge an Administration selbst übernehmen. Kurzfristig ist dies ein Wachstummarkt, in dem sich viele Player tummeln werden. Mittelfristig gibt es hier Konsolidierungen, und nur Anbieter, die mit geringen Margen und extremer Standardisierung arbeiten, werden überleben können. Langfristig rechne ich in diesem Segment mit einer extremen Standardisierung auch über Anbietergrenzen hinweg, die Anbieter werden austauschbar, einzige Alleinstellungsmerkmale werden Preis und Verfügbarkeit sein.
  • PaaS – Platform as a Service. Eher ein Angebot für Entwickler. Man bekommt eine Softwareplattform zum Entwickeln einer eigenen Software. Teil des Angebots sind also ein geeigneter Compiler und/oder Interpreter, geeignete Middleware, eventuell eine Datenbank und was man sonst so benötigt. Verborgen bleiben Hardware und OS. Der Betreiber erzeugt gegenüber IaaS einen gewissen Mehrwert, der allerdings nur für eine bestimmte Zielgruppe, in diesem Fall Entwickler, interessant ist. Diese Zielgruppe ist bereit, für den erbrachten Dienst mehr zu zahlen als die IaaS-Kunden, sind aber – was Verfügbarkeit und Sicherheit betrifft – anspruchsvoller. Kurzfristig rechne ich in diesem Bereich mit vielen, spezialisierten Anbietern. Mittelfristig werden diese sich konsolidieren, die Produkte werden aber weiterhin vielfältig sein. Langfristig werden sich mehr Anbieter als im IaaS-Segment halten, die aber Spezialisiten für einzelne Teilsegmente sind.
  • AaaS und SaaS –  Application as a Service und Software as a Service. Diese Anbieter gibt es bereits in größerer Stückzahl. Es sind Dienste wie Flickr, GoogleMail oder Adobe Online Photoshop, aber auch größere Sachen wie BusinessOne von SAP oder Salesforce.com. All diese Anbieter verkaufen eine Anwendung, die sie auf unbekannter Hardware, unbekanntem OS etc. betreiben. Der Kunde kann also die gesamte Systemadministration, meist auch Teile der Anwendungsadministration abtreten. Er muss sich nur noch um das Bedienen der Software kümmern. Mit diesem höheren Servicegrad durch den Anbieter wird meist auch die Abrechnung transparenter, da anstatt CPU-Sekunden beispielsweise für Kunden greifbarere Dinge wie Anzahl der Anwender etc. als Grundlage für die Preisfindung herangezogen werden. Kurzfristig sehe ich in diesem Marktsegment eine geradezu explosionsartige Vermehrung von solchen Angeboten, wobei sowohl private Anwender als auch große Unternehmen die Zielgruppe sein werden. Die Akzeptanz dieser Angebote am Markt wird sich schwierig gestalten: Kunden sollen plötzlich für Dinge regelmäßig zahlen, die sie bislang nur einmal bezahlen mussten (oder gar nur raubkopiert haben). Zudem wird es in verschiedenen Bereichen extreme Vorbehalte wegen Sicherheit und Privatsphäre geben. Bei einigen Anbietern wird es solche Vorfälle geben, was mittelfristig zu einer Konsolidierung, aber auch zum Verschwinden von Angeboten in diesem Markt führen wird. Langfristig werden sich meiner Ansicht nach nur Angebote halten, deren Betrieb auf eigener Hardware extreme Kosten verursachen würde, und die zugleich langfristig überzeugende Konzepte zum Schutz der Daten geliefert haben. Auch wird ein eventueller Vendor-Lock – wie er bei einigen heutigen Anbietern zu finden ist – sich langfristig negativ auswirken. Während man mittelfristig erreicht, dass Kunden an ihre Anbieter gebunden sind, werden langfristig Mittel und Wege gefunden, solche Vendor-Locks zu umgehen. Dies wird dann aber nicht zu einem „Wettrüsten“ führen, sondern hoffentlich zu standardisierten Austauschformaten für ähnliche Anwendungen.
  • DaaS – Desktop as a Service. Diese Variante ist auf mobile Endanwender ausgerichtet, seien es Einzelpersonen oder die Endanwender in einem Unternehmen. Diesmal wird die Benutzeroberfläche und Laufzeitumgebung für die Software, welche auf dem Endgerät betrieben wird, ausgelagert. Sun VDI wäre ein Beispiel für eine Software, mit der solch ein Service einfach zu realisieren ist. Man greift über einen Browser oder ein recht einfaches Endgerät auf eine irgendwie geartete Infrastruktur zu, und dort liegt der persönliche Desktop-Rechner, auf dem man dann arbeitet. Falls jemand das mal ausprobieren möchte: Im Sun Solution Center in München steht eine ähliche Infrastruktur bereit, über die man selbst einen Open Solaris Desktop ausprobieren kann. Solch ein Service würde auch mit anderen Betriebssystemen funktionieren – bei Windows wären aber komplexe Softwarelizenzbestimmungen zu beachten. Die Verwandtschaft zu IaaS ist deutlich, doch liegt ein Mehrwert in der zugrundeliegenden Zugriffsinfrastruktur und der hohen und omnipräsenten Verfügbarkeit. Neben Produkten wie Sun VDI gibt es diverse unvollständige Ansätze für DaaS, welche nur Teile abbilden, beispielsweise zentrale Homeverzeichnisse oder Dateiablageorte, welche dann von überall genutzt werden können. Der Markt für DaaS ist erst im Entstehen, erste Unternehmen verschieben Ihre Desktops in Private Clouds. Für DaaS in Public Clouds gibt es noch keinen wirklichen Markt. Mittelfristig wird DaaS in Private Clouds für Unternehmen wichtig und gängig werden. Langfristig werden sie laute Arbeitsplatz-PC verdrängen – auch weil einfache Desktopgeräte wartungsärmer sind. Im privaten Umfeld rechne ich eher nicht damit – dort werden sich mehr öffentlich zugängliche Speicher durchsetzen, welche man dann von fremden Desktops nutzen kann. Mittel- und Langfristige Prognosen wage ich für die private Nutzung noch nicht.

Es gibt noch mehr XaaS: DaaS steht auch noch für „Database as a Service“, SaaS auch für „Storage as a Service“ oder „Security as a Service, hin und wieder taucht IaaS als „IT as a Service“ auf.

Wichtig ist meine Ansicht nach hierbei:

  • IaaS wird ein heißes Pflaster, sollte jemand in diesem Bereich eine Firma gründen wollen: Vergessen Sie es – außer sie können Rechenleistung zum Nulltarif herstellen.
  • PaaS wird ein kleiner, aber feiner Nieschenmarkt: Wenn man hier eine geniale Idee hat, welche genau auf die Bedürfnisse der Entwickler ausgerichtet ist, kann man damit Erfolg haben. Wichtig ist aber, seine Idee bald auf die Straße zu bringen und schnell Entwickler davon zu überzeugen.
  • AaaS & SaaS für Unternehmen: Dieser Markt wird für große Softwaresysteme üblich – hier können die Anbieter auf wirklichen Mehrwert bieten. Alteingessenne Markteilnehmer können hier ihre Produkte an neue Zielgruppen bringen, oder vorhandene Kunden mit neuen Angeboten bei der Stange halten. Neue Marktteilnehmer werden es schwer haben, außer in Kooperation mit alteingesessenen Softwarehäusern, die SaaS gerne jemand anderem überlassen wollen. Wenn man solch einen Partner hat, und dessen Kunden lassen sich auf SaaS ein: Das könnte was werden.
  • AaaS & SaaS für Endanwender: Das wird ein schwieriges Pflaster – vorstellbar sind meiner Meinung nach nur zwei Szenarien: Software, die man sehr selten braucht und per Use kaufen kann (beispielsweise Steuererklärungs-Software), oder Software, die man gerne immer und überall nutzen möchte.
  • DaaS: Dieser letzte Markt ist bereits gut mit Anbietern für Unternehmen bestückt – neue Markteilnehmer werden es schwer haben. Für die privaten Anwender existiert hier noch nicht das Killer-Feature, mit dem sich das Produkt durchsetzen wird. Falls jemand hier eine geniale Idee hat – ausprobieren!

ICC: Warum keine Flatrates?

Flatrates sind in Deutschland unheimlich beliebt. Zuletzt war nur Flatrate-Saufen in’s Gerede gekommen, die meisten anderen Flatrates freuen sich wachsender Beliebtheit.

Auffällig dabei ist der hohe Anteil an Flatrates, bei denen Bandbreiten bzw. Datenübertragungsmengen ohne nennenswerte Begrenzung angeboten werden. Seien es DSL-Flatrates, seien es UMTS-Tarife oder Telefontarife – die Datenmenge ist meist nicht beschränkt. Okay – da gibt es jede Menge Fallstricke und „Fair-Flat-Regeln“, aber bei einigermaßen normaler Nutzung sind die Tarife in Ordnung und erscheinen jedem Nutzer transparent: DSL und Telefon kosten pro Monat X Euro. Exakt vorhersagbar.

Eine andere Art der Flatrate sind die Angebote für VServer und ähnliche Prä-Cloud-Hosting-Angebote. Hier erhält man einen virtuellen Server mit bestimmten Eigenschaften (langsam, stets zu wenig Speicher, langsame Netzwerkanbindung) und zahlt dafür eine Pauschale. Wenn man andere Eigenschaften will (schnell, ausreichend Speicher, flotte Netzwerkanbindung) wählt man einen teureren Tarif und bekommt auch dieses.

Die Berechnung einer Flatrate ist relativ einfach aus Anbieterperspektive:

  • Fixkosten des Service (im Falle des VServers die anteiligen Kosten für den Server, auf dem der VServer läuft, beispielsweise 1/8 Opteron),
  • + anteilige Kosten für Strom, Kühlung etc. (vorsichtshalber 24*7*31*Volllast, also 24 kWh/Monat),
  • + Kosten für Datenvolumen (also anteilige Kosten an einem SAN)
  • + Kosten für Datenübertragung (also anteilige Kosten an der Internetverbindung)
  • * Sicherheitsfaktor (irgendwas größer 1, bei manchen Angeboten wahrscheinlich auch größer PI)

Streng genommen bezahlt man bei einer Flatrate also nicht einen Verbrauch an Bandbreite, an CPU-Sekunden oder an Speicherbedarf, sondern eine bereitstehende Kapazität, die man dann aufbraucht (oder nicht). Man zahlt nicht 1254 MB auf der Platte, sondern man zahlt dafür, dass eine virtuelle 40-GB-Platte für einen einen Monat lang da ist, egal wieviel man davon nutzt. Man zahlt nicht für 13292 CPU-Sekunden, die man auf einem Opteron verbraucht hat, man zahlt für eine zu Verfügung stehende CPU-Sekunde pro realer Sekunde und pro bezahlter CPU. Man zahlt nicht für 12010 MB übertragene Daten, man zahlt dafür, dass eine 2-MBIT-Verbindung in’s Internet 24/7 bereitssteht.

Aus Anbieterperspektive sind Flatrates aus mehreren Gründen attraktiv:

  • Fixer Geldzufluss: Nie war es so einfach, eine Umsatzprognose abzugebeben. Wenn alle Kunden die gleiche Pauschale zahlen, kann man mit simpler Multiplikation sehr einfach den Geldfluss vorhersagen.
  • Kapazitäten sind einfacher zu planen als unvorhersagbare Bedarfe. Mit der Zeit wird auch ein „Matching“ zwischen Bedarfen und gebuchten Kapazitäten sichtbar, sodass man ein besseres Kapazitätsmanagement machen kann.
  • Weniger Kosten für die Abrechnung: Es ist schlicht und einfach recht aufwändig, genau den Verbrauch mitzuschreiben und dann ihn abzurechnen. Ein Teil der Kosten für einen Dienst sind die Kosten für dessen Abrechnung. Bei preiswerten Diensten kann – bei entsprechend komplexer Erfassung – die Abrechnung teurer sein als der Dienst selbst.

Im Cloud Computing gibt’s praktisch keine Kapazitäten, die der Kunde bucht. Flatrates und Cloud Computing schließen sich daher momentan noch aus: Wenn man flexible, elastische Merkmale möchte, kann man keine Kapazitäten pro Zeiteinheit buchen. Wenn ich kurzfristig 100 CPU-Sekunden pro Sekunde verheize und dann wochenlang nicht eine, dann nutzt mir eine zugesicherte CPU-Sekunde pro reale Sekunde recht wenig.

Eines der Merkmale des Cloud Computing ist nun einmal die Elsatizität des Services. Man legt sich nicht auf einen monatlichen Verbrauch im vorhinein fest, also wird es keine zeitlich konstante Flatrate geben. Was es aber geben kann, sind Paketangebote: 100 CPU-Sekunden zum Preis von 90, 1000 Put-Datenzugriffe im Paket billiger, wenn man Vorkasse leistet…


ICC: Messen und Gemessen werden

Ist die Abrechnung von Cloud Computing eigentlich überhaupt fair?

Der Mensch – insbesondere der Deutsche – neigt anscheinend dazu, die Fairness von Abrechnungen extrem zu hinterfragen, um anschließend eine nur auf den ersten Blick faire und einfache Verteilung der Kosten aus dem Boden zu heben. Diese Abrechnung zeichnet sich meist dadurch aus, dass es einen linaren Zusammenhang zwischen irgendetwas durch einfach gestrickte Leute zählbarem und Geld gibt. Beispiel gefällig: Das Bezahlen von gedruckten/kopierten Seiten nach deren Anzahl.

Aus jahrelanger Erfahrung habe ich gelernt, dass die Kosten für eine gedruckte Seite von vielen Faktoren abhängen:

  • Stromverbrauch: Muss der Drucker extra für diese eine Seite aufgewärmt werden, oder druckt er die Seite zusammen mit einer Million anderer Seiten im Dauerbetrieb.
  • Tonermenge: Ist es der berühmte 5%-Dr.-Gauer-Brief, oder ist es ein vollflächiges Schwarz?
  • Papierart: Standard-Papier, Hochglanzpapier, Ökopapier…
  • Anteilige Instandhaltungskosten: Je nach Modell, verwendetem Papier, verwendeter Tonerart, verbrauchter Tonermenge etc. unterschiedlich.
  • Wer druckt die Seite? Bestimmte Personen neigen dazu, ungeeignete Folien in Drucker einzulegen. Bei denen kostet jede 10. Seite etwa 150 Euro an Reparaturkosten.

Man könnte all diese Faktoren einzeln abrechnen und erfassen – das wäre richtig fair. Das war auch mein erster Ansatz für einen Abrechnungsmodus zur Berechnung der Druckkosten. Ich fand’s nur fair, wenn jemand, der viel Toner verheizt, mehr bezahlt.

Das Verfahren hat funktioniert – aber es fand keine Akzeptanz. Die Nutzer wollten in der Lage sein, ihren Verbrauch selbst zu messen –  durch ein fremdes Verfahren gemessen zu werden, war nicht in akzeptabel. Das Verfahren war für die Nutzer intransparent, ohne genaues Studium der Tonerpreise und der Wartungsintervalle unterschiedlicher Druckertypen war im vorhinein nicht zu sagen, wie teuer eine gedruckte Seite jetzt nun werden würde. Also kam der Schwenk auf eine Pauschale pro Seite. Bitte nicht nachfragen, wie diese entstanden ist – das Verfahren zu Preisfindung war total instrasparent und hatte den Einsatzu von PI und Würfeln eingeschlossen. Rein theoretisch hätte man übrigens den Verbrauch auch nach dem Gewicht des Papiers berechnen können…

Im Cloud Computing möchte und muss man auf einmal den Verbrauch an CPU, Speicher und Datenübertragung mit Kosten belegen. CPU-Verbrauch wird dazu in Zeit-auf-einer-CPU gemessen (wobei unterschiedliche CPU-Typen durch eine entsprechende Normierung berücksichtigt werden sollen), Speicher wird nach Megabyte berechnet, Datenübertragung auch. Zusätzlich fallen Pauschalen für den Zugriff auf Daten an.

All diese Größen könne einfach gemessen werden – CPU-Sekunden spuckt die Virtualisierung aus, Datenmengen und deren Übertragung der Filer. Multiplikation beherrscht das ERP-System, und fertig ist die Rechnung.  Irgendwie scheint die Abrechnung sogar fair zu sein – wenngleich eine Überprüfung praktisch nicht möglich ist: Das Verfahren ist extrem intransparent.

Woher soll ein Kunde denn wissen, wie viele CPU-Sekunden beim Booten seines Servers real angefallen sind? Er konnte den Server in der Zeit nicht überwachen, er muss sich auf irgendwelche Angaben aus einem Virtualisierungslayer verlassen. Selbst messen geht praktisch nicht – gemessen werden schon. Woher soll ein Kunde wissen, wie viele PUT/GET oder ähnliche Anfragen an den Filer kamen, wenn Millionen von Usern darauf zugreifen? Wieder geht nur gemessen werden, selbst messen ist praktisch unmöglich. Intransparenz wo man auch hinschaut. Cloud-Computing-Anbieter können praktisch abrechnen, wie sie wollen – könnte man meinen.

Die Transparenz des Abrechnungsverfahrens ist langfristig ein entscheidendes Merkmal, um Cloud-Computing-Anbieter auszuwählen. Kein Anbieter wird es sich erlauben können, intransparente Verfahren ewig anzubieten – statt dessen werden wahrscheinlich zunächst exakte Belege und Einzelverbindungsnachweise üblich sein, langfristig Pakete oder gar partielle Flatrates üblich werden.


ICC: Was ist eigentlich Cloud Computing und was ist daran neu?

Definitionen zu Cloud Computing gibt es wie Sand am Meer, und mindestens ebenso viele Begründungen, warum man schon ewig Cloud Computing macht und warum das jetzt nichts neues sei. Auch gibt es viele Ankündigungen, dass sich der Markt verdoppeln würde – je nach Quelle bis spätestens 2012. Andere wiederum mögen es nicht.

Aus Betreiber-Perspektive mag Cloud Computing auch nur Alter Wein in neuen Schläuchen sein. Häufig fallende Stichworte sind standardisierte Produkte, Virtualisierung, Abrechnung nach irgendwelchen Verbräuchen. Das klingt nach dem guten alten VServer bei Strato & Co.: Standardisiertes Produkt (Virtueller Server mit Linux vom Typ xyz), Virtualisiert, sodass der Benutzer nicht weiss, wo er gerade mit der Kiste unterwegs ist.  Die Abrechnung erfolgt nach Zeit, die die Virtuelle Kiste vermietet wurde, und nicht nach Verbrauch. Die ersten Merkmale von Cloud Computing ähneln also denen des alten Hostings:

Cloud Computing Merkmal 1: Standardisiertes Produkt. Nimm es oder vergiss es. Es gibt nur den Standard. Den kannst Du bekommen und Deinen Bedürfnissen anpassen. Wenn der Standard dafür nicht taugt, bist Du als Kunde uninteressant.

Cloud Computing Merkmal 2: Virtualisierung. Um das Standardisierte Produkt herzustellen, wird Hardware genutzt, was der Endbenutzer nicht sieht. Dazwischen ist eine Virtualisierungsschicht. Es kann dem Benutzer egal sein, der Betreiber sichert ihm zu, dass sein Produkt funktioniert. Es muss dem Benutzer sogar egal sein, wenn er die besonderen Freiheiten des Cloud Computing nutzen möchte.

Aber Cloud Computing ist da schon etwas feiner, granularer sozusagen. Während der alte VServer für 24 Monate wie ein Handyvertrag lief, kann man den Virtuellen Cloud Server für kürzere Fristen buchen. Genau genommen wird nicht mal nach Zeit abgerechnet, sondern nach verbrauchter Rechenleistung, verbrauchtem Speicherplatz und verbrauchter Bandbreite für Datenübertragungen. Womit wir beim dritten Merkmal für Cloud Computing wären:

Cloud Computing Merkmal 3: Abrechnung nach Verbrauch von Rechenleistung, Speicherplatz und Bandbreite. Auf den ersten Blick fair, auf den zweiten Blick nicht transparent: Wie werden diese Werte ermittelt? Kann der Benutzer sicher sein, wirklich nur seinen Verbrauch zu zahlen? Oder bezahlt er vielleicht irgendwelche Phantasiewerte? Gibt es hier keine Flatrates? (Hierzu gibt’s auf jeden Fall noch einen Beitrag)

Auffällig ist bei den Angeboten von Amazon und anderen Cloud Anbietern, eine extreme Abweichung von bisherigen Verträgen im IT-Umfeld: Keine Laufzeiten. Keine Festlegung auf bestimmte Rahmenbeschränkungen. Dies wird häufig unter dem Begriff „Elastizität“ zusammengefasst. Man kann sich den Service so zurechtbiegen, wie man ihn gerade braucht. Eben noch ein Mini-Server, jetzt ein ausgewachsener Riese, gleich wieder ein Mini. Für Handyverträge währe das revolutionär: Mindestvertragslaufzeit null, jederzeit Wechsel zwischen verschiedenen Optionen (heute mal mit UMTS und viel Datenübertragung, dafür morgen nur Telefonie ohne SMS…). Wäre das ein Geschäftsmodell?

Cloud Computing Merkmal 4: Flexibilität/Elastizität.  Weder die Vertragslaufzeit noch die genaue Ausgestaltung der Leistungsbeschreibung ist lange festgeschrieben. Eine komplette Kehrtwende gegenüber bisherigen Hostinganbietern.

Doch weichen die aktuellen Leistungsbeschreibungen von Cloud Computing Diensten noch in anderen Bereichen von den gängigen Hosting-Verträgen ab. „Bloss keine Angriffsfläche bieten“, scheint das Motto einiger Anbieter zu sein. Ein Beispiel ist bei Ralf zu finden, der die Verfügbarkeitsangabe von Amazon zerpflückt.

Danksagungen / Quellenangaben:

  • Ralf Zenses hat mit seiner Systematisierung der Eigenschaften/Merkmalen von Cloud Computing die Grundlagen für meine gelegt. Seine Definition erscheint mir aktuell eine der wenigen technologie-unabhängigen zu sein, welche die Ideen hinter Cloud Computing beschreibt, wie es aktuell beispielsweise von Amazon S3 vermarktet wird. Seine beiden Merkmale „Self Provisioning“ und „Stable and durable offerings“ habe ich nicht übernommen, da sie meiner Ansicht nach zwar für öffentliche Clouds gelten mögen, nicht aber zwingend für private Clouds.
  • Constantin Gonzales, dessen mehr technischer Blick auf Cloud Computing die wenigen technischen Besonderheiten hervorkehrt.
  • Die Autoren der Englischsprachigen Wikipedia – so viele Aspekte in so unzusammenhängendem Text bringt nur verteiltes Arbeiten unabhängiger Autoren hin.
  • Ein „besonderer Dank“ gebührt all den Autoren von Online-Lexika oder Zeitschriften, die die Definitionen der Dell-Werbung abschreiben. So bringt ihr das Thema weiter!

Ideen zu Cloud Computing: Wieso jetzt das?

Hallo Ralf,

mit Deinem konsequenten Bombardement zum Thema Cloud Computing hast Du etwas erreicht. Ich mache mir Gedanken darüber – und das ist meistens gefährlich. Entweder für mich oder für das Ding, über das ich nachdenke.

So, jetzt wieder für alle:

Ralf Zenses schreibt seine Gedanken zu Cloud Computing in seinem Blog IFR in the Clouds nieder. In den letzten Wochen haben wir mehrfach über das Thema diskutiert, und haben einige gemeinsame Punkte entwickelt. Meine Ideen zum Cloud Computing werde ich hier auch niederschreiben – das Thema ist einfach zu verführerisch.

Allerdings widme ich nicht gleich das ganze Blog um – das wird nur eine weitere Unterkategorie: ICC. Ideen zu Cloud Computing. Oder „Ideas about Cloud Computing“. Ich hoffe, diese Serie wird mehr Inhalt bekommen als „Schöner Flughafen“.

Warum ich diese Serie aufsetzte: Ich hielt, wie so viele andere auch Cloud Computing zunächst für alten Wein in neuen Schläuchen.  Cloud Computing ist auf den ersten Blick nur ein weiteres Hype-Thema, das unter Umständen demnächst wieder in der Versenkung verschwindet. Die Ideen dahinter beschäftigen mich schon länger, vor allem als eine Teilmenge der Ideen noch unter dem Namen Grid Computing bekannt waren.

Mittlerweile teile ich diese Meinung nicht mehr, unter anderem wegen den langen Diskussionen mit Ralf. Cloud Computing ist technisch zwar nichts neues, wohl aber von den Prozessen und betriebswirtschaftlichen Ideen dahinter. Mit Software Product Lines oder standardisierten Betriebsabläufen gibt es schon länger Bestrebungen, den Betrieb von IT-Landschaften in standardisierte Bahnen zu lenken. Ziel dabei ist eigentlich immer, die Kosten zu senken – IT ist teuer.

Cloud Computing stellt nun einen neuen, extremen Standard dar, IT-Kosten durch Standardisierung in den Griff zu bekommen, und gleichzeitig neue Konzepte im Betrieb und in der Verrechnung von IT-Leistung zu etablieren. Natürlich schafft das Ideen, wie Cloud Computing zu verstehen ist.

Dir, Ralf,  und meinen anderen Lesern: Viel Vergnügen mit meinen Ideen zu Cloud Computing.