Cloud- und Utilitycomputing

Vortrag auf dem 26. DV-Treffen der Max-Planck-Institute am 23. September 2009

• Ich beschränke mich im Wesentlichen auf die Dienste von Amazon und Google, da ich sie einmal für prototypisch genug halte (Google: Utility, Amazon: Cloud), sie zum anderen sehr populär sind und preisgünstig bis kostenlos zur Verfügung stehen und ich sie drittens am Besten kenne.
• Die Definition ist meine Definition – ich besitze aber nicht die Definitionshoheit.

• Ich wiederhole nicht meinen Vortrag zum Technologietag 2009 der MPIs.
• Der ist hier zu finden: Die Wissenschaft auf Wolke Google

• Die Bereitstellung von Diensten (Services) via HTTP
• Diese Dienste lassen sich zu eigenen Applikationen koppeln (Mashups, Situational Applications)
• Direkt via Browser abrufbar, verfügen aber auch über eine API
• Protokolle: (meistens) JSON, REST, JavaScript, aber auch XML-RPC und andere Scriptsprachen, seltener Java, WSDL und SOAP (mehr im Enterprise-Bereich)

• Die Bereitstellung von skalierbarer Rechenleistung über HTTP (und REST)
• In der Regel in der Form von virtuellen Maschinen
• Abrechnung erfolgt nach verbrauchter Leistung (nicht pauschal)
• Kein Grid!

Die Google App Engine ist eine Plattform zum Entwickeln und Hosten von Webanwendungen auf den Servern von Google. Der Service ist unter bestimmten Limitationen (siehe Link) kostenlos.

Anwendungen auf der App Engine werden in Python oder (seit kurzem) Java programmiert.

• Core Applications
• Utility Applications

• Amazon EC2 (Applikations-Ebene)
• Amazon S3 (Daten-Ebene)
• Amazon SimpleDB (Metadaten-Ebene)

Diese drei Dienste (und einige Utility-Applikationen) sind (seit gestern) auch auf Servern innerhalb der EU verfügbar)

• Amazon CloudFront
• Amazon SQS
• Elastic MapReduce
• Amazon S3stat

Der Daten-Transfer zwischen den Amazon-Diensten ist grundsätzlich kostenfrei.

• Aufgaben und Workflows, die von den Mitarbeitern selber bei Bedarf (situationsbedingt) aus kleinen Utilities »zusammengestrickt« werden
• Voraussetzung dafür ist, daß die Utilities »mischfertig« vorliegen und
• daß es eine einfache Filter- und Verbindungsmöglichkeit gibt (z.B. Yahoo! Pipes)

»Quick and Easy Done Wiki« (QEDWiki)

• ist ein Mashup-Werkzeug
• ist ein Wiki
• funktioniert im Browser

• Die an sich faszinierende Idee wurde von IBM zugunsten von IBM Lotus-Mashups aufgegeben.

Doch dafür erwarten wir nun Google Wave

• Google Wave (Open Source) ist ein neues Kommunikations- und Kollaborationswerkzeug des Suchmaschinengiganten, das die Arbeit im Netz völlig umkrempeln soll.
• Es ist eine zentrale Kommunikationsplattform, die E-Mail, Instant-Messaging, Chat, Photos, Videos, Karten und Dokumente verbindet.
• Wave erlaubt unter anderem die gemeinsame Arbeit an Texten und anderen Dokumenten und die Änderungen können in Echtzeit verfolgt werden.

• Über APIs soll sich Wave in andere Internetseiten einbetten oder mit Anwendungen anderer Entwickler kombinieren lassen.
• Google Wave soll im Herbst 2009 der Öffentlichkeit zur Verfügung stehen. Später soll der komplette Wave zugrundeliegende Code freigegeben werden, so daß jeder einen Wave-Dienst auf seinen Servern anbieten können soll.

• Talend Open Studio
• tarpipe

funktionieren ähnlich wie Yahoo! Pipes (mit unterschiedlichen Schwerpunkten).

• Große Cloud-Computing Rechenzentrum, wie Nicolas Carr sie beschreibt
• Oder: Dezentrale Anwendungen (Ping, Community-Server, rssCloud, PubSubHubbub, Virtualisierung, »selbstorganisierende Qualität«)

»Like Google, Twitter and the other leading commercial Internet sites have made tremendous contributions to the functionality of the Internet and have earned both their popularity and (where it exists) their revenue. But the end-to-end principle and the reliability of distributed processing must have their day again, whenever some use of the Internet becomes too important to leave up to any single entity.« (Andy Oram: Why social networks need to be decentralized)

• Google hat versprochen, Google Wave als Anwendung unter einer Open Source-Lizenz freizugeben.
• Damit ist a) die Kritik des BSI an Google Wave hinfällig.
• Und b) eine dezentrale Wave-Umgebung denkbar.
• denn Wave basiert auf einer Erweiterung des XMPP-Protokolls (Jabber)

• Monolithische Applikationen, Dinosaurier und eierlegende Wollmilchsäue, die eine Rundum-Glücklich-Versorgung garantieren sollen
• Ziel war das »Glück« der MPIs/MPG, nicht das »Glück« der beteiligten Wissenschaftler

Die eierlegenden Wollmilchsäue, wie z.B. Digilib, eSciDoc, die Scholary Workbench müssen Mashup-fähig (SaaS) gemacht werden, d.h.

• »generische Werkzeuge« entwickeln
• als Widgets/Gadgets embeddable sein
• Pipe-fähig gemacht werden (REST in, RSS, Atom, JSON … out)

• REST-/AJAX-Schnittstellen entwickeln
• MPG-Pipes (RSS/Atom …) – wenn man die Applikationen nicht auf fremden Servern laufen lassen will

• Den Wissenschaftlern weniger vorschreiben, denn
• weder die DV-/IT-Abteilungen noch die Bibliotheken wissen wirklich, was den Wissenschaftler »glücklich« macht. (Glauben Sie mir, wenn ich etwas in meinen Jahren als DV-Leiter am MPIWG gelernt habe, dann das.)

• Wikis als persönliche Wissensrepositorien
• Wikis als Werkzeug der Gruppenkommunikation und Dokumentation
• (Doku-) Wikifarmen
• Vernetzung (d.h. Bereitstellung eines oder mehrerer Community-Server)
• Test von Google Wave (???)

• Virtualisierung als »Server-Konsolidierung«
• Virtualisierung als Grundlage zur Bereitstellung des Clouds
• Verschiedene vorgefertigte Images zur Verfügung stellen (Wiki, Drupal, GNU R, Octave etc.)
• Die Vorschläge müssen von den Wissenschaftlern aus den Instituten kommen!
• Skalierbarkeit ermöglichen!

• Virtualisierung als Dienstleistung der Rechenzentren der MPG
• eigene »App Engine«?
• Noch einmal: (Doku-) Wiki-Farmen
• OpenStreetMap-Server

• Danke für Ihre Aufmerksamkeit!
• URL: www.cognitiones.de/doku.php/cloud-_und_utilitycomputing

• Zurück

Kategorie: Arbeitsmaterial Webworking → Cloud Computing → Utility Computing → Situational Computing

Werbung