Thoughts. Ideas. Photography.

Posts tagged “Cloud Computing

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: 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: 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.