Zum MPDL-Meeting am 7. Dezember 2009 in Berlin

Beruf: EDV-Leiter am Max-Planck-Institut für Wissenschaftsgeschichte (MPIWG)

Jörg Kantel ist auch der Schockwellenreiter

• Ein Tag im Leben eines (computeraffinen) (Geistes-) Wissenschaftlers
• Cloud- und Utility-Computing – eine Einführung
• Kritik an Carr
• Folgerungen für die MPIs (im Besonderen und wiss. Institute im Allgemeinen)

• Google Mail-Check
• Prüft, ob wichtige Termine anstehen (Google Kalender)
• Schreibt einen Artikel (zusammen mit zwei Kollegen) in Texte und Tabellen

• Stellt zur Vorbereitung einer Konferenz eine Site auf Google Sites zusammen
• Lädt dafür auch ein paar Photos bei Flickr hoch
• Zusammenstellung und Auswertung von ein paar statistischen Daten (Texte und Tabellen)
• Arbeit an einer Materialsammlung (Zeichnungen, Photos und Videos), die er sich bei Sevenload angelegt hat

• Essen mit einigen Kollegen (Real Life ;o))
• Hält dabei einige Ideen, die bei dem Gespräch entstanden sind, mit seinem iPhone in Googles Notizbuch fest

• Danach Arbeit an einem Vortrag mit Folien bei Google Presentations
• Hochladen eines Aufsatzes bei Scribd
• Hochladen eines Konferenzvideos:
• Ein Ausschnitt (< 10 Minuten) für die Konferenzsite bei YouTube
• Den gesamten Vortrag (30 Minuten) bei Vimeo

• Chat mit ein paar Kollegen über das Thema seiner nächsten Arbeit
• Reisevorbereitungen mit Google Maps und Google Earth
• Fahrkarten für die Reise auf bahn.de bestellen

• Kino (Real Live)
• Abendessen mit Freunden beim Griechen (Real Life)
• Vereinbarung für ein weiteres Treffen, Termincheck mit dem iPhone und Googles Kalender
• Wieder zuhause: Diskussion in einer Mailingliste (Google Groups)
• Letzter Mailcheck mit dem Handy (Google Mail)

• Es kommt in ihm keine DV- oder IT-Abteilung vor
• Alle diese Tätigkeiten ließen sich:
• (zur Not) mit einem Handy oder
• (mehr komfortabel) mit einem Netbook erledigen

• (fast) alle diese Dienste werden (zur Zeit) kostenlos zur Verfügung gestellt
• sind nicht an eine bestimmte Institution gebunden (stehen dem Nutzer lebenslang zur Verfügung)

Das sind die Vorzüge von Utility-Computing!

Was ist Cloud-Computing und was ist Utility-Computing?

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

• 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)
• Normalerweise kein Grid (dazu später mehr)

• 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)

• Aufgaben und Workflows, die von den Mitarbeitern selber bei Bedarf (sittuationsbedingt) 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)

• Wiki als Basis für eine Arbeitsumgebung
• Zusätzliche Funktionen per Plugins realisieren
• Mein derzeitiger Favorit: DokuWiki

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

• Stream
• nachträglich »Collections« oder »Groups«
• nachträglich Metadaten (ein paar werden automatisch aus den EXIT-Daten der Bilder geholt)
• nachträglich »Anmerkungen« (Notes)
• … und alles DAU-sicher und einfach

• Amazon S3
• Amazon EC2
• Amazon SimpleDB
• Amazon CloudFront
• Alle Transfers innerhalb Amazons Cloud sind kostenfrei

• Massenspeicher zum Discounter-Preis
• REST-Interface statt (S)FTP
• Daten via HTTP abrufbar, daher auch als Lieferant statischer Webseiten oder Assets geeignet

• Hochskalierbare Computing Power
• Nicht ganz so preiswert, da nicht nur der Datentransfer, sondern auch die CPU-Zeit abgerechnet wird (bei einem ständig durchlaufenden Webserver kommt man daher leicht auf ca. 200 Euro/Monat)
• basiert auf virtuellen Maschinen

• Persistence im Text-Format
• Trotzdem die gewohnten SQL-Befehle
• Und trotz allem schnell

• Frontend für Amazons Cloud
• Ermöglicht dynamische Verteilung der Ressourcen
• daher auch (einfache) Grids möglich

Google verfolgt einen anderen Ansatz, die App Engine

• stellt ein Framework für eigene Applikationen zur Verfügung
• Sprache: Python (und seit neuestem auch Java)
• (noch) kostenlos
• spezielle Kommandos für die Einbidung von Googles (und anderen) Webservices (daher speziell für Situational Applications geeignet)

Mögliche Cloud-Computing-Anwendungen (in den Geistes- und Sozialwissenschaften)

• Gelegentlich anfallende, größere statistische Berechnungen
• Hier kann zum Beispiel eine Amazon VM mit GNU R aufgesetzt werden, die Daten liegen auf S3 und die CloudFront sorgt für ein verteiltes Rechnen

• Größere Mengen von OCR, die schubweise anfallen.
• In solchen Fällen ist das Vorhalten eigener Computing-Kapazitäten unwirtschaftlich, da eine (Aus-) Nutzung nur gelegentlich erfolgt

• Situational Applications (vgl. IBMs QEDWiki)
• Das alte UNIX-Konzept kleiner, spezialisierter Anwendungen, die via Pipes miteinander verbunden werden, kommt wieder zum Vorschein, nur daß die Anwendungen nicht mehr auf der Maschine des Anwenders liegen, sondern im Netz verteilt sind
• Bei der Auswahl der Anwendungen und der Verbindung mittels Glue-Skripten erscheint die IT-Abteilung doch wieder durch die Hintertür ;o)

• spezielle Services wie zum Beispiel Yahoos! Pipe ermöglichen es auch dem Endanwender, sich eigene Mashups »zusammenzuklicken«
• Das würde eine alte Idee verwirklichen, die (mit HyperCard) schon vor Jahren von Peter Damerow bei uns am Institut angeregt wurde

• oder »Hat Nicholas Carr das alles schon vorhergesehen«?

• Carr vergleicht die Entwicklung der IT mit der Entwicklung der Energieversorgung
• Ähnlich wie die Energieindustrie einen »Switch« vom Verkäufer von Turbinen zum Verkäufer von Energie durchmachte, wird die IT-Industrie einen Switch vom Verkäufer von Rechnern zum Verkäufer von Rechenleistung durchmachen

• Große, zentralisierte Serverfarmen werden nicht nur die PCs ablösen, sondern auch die IT-Abteilungen der Unternehmen überflüssig machen
• Rechenleistung wird eine Dienstleistung, ähnlich wie die Versorgung mit Energie, die von außerhalb in die Unternehmen kommen wird

• Wissen Sie noch, was ein Growian ist?
• Erinnern Sie sich noch an den Cargo-Lifter?

• Der Wandel vom Turbinenproduzenten zum Energieversorger und die darauf folgende Zentralisierung enstand aus gesellschaftlicher Notwendigkeit ((Nationale) Vereinheitlichung des Stromnetzes auf 110 resp. 220 Volt)
• Diese gesellschaftliche Notwendigkeit ist bei der IT-Versorgung nicht vorhanden, da das Netz schon heute auf Standards basiert (basieren muß)

• Carr übersieht, daß schon heute wieder ein Umschwung auf dezentrale Energieversorgung zu beobachten ist
• denn »small is beautyfull« und machbar, Frau Nachbar

• aus dem zweifelslos zu beobachtenden Trend hin zu Cloud- und Utility-Computing ist nicht notwendigerweise ein Trend hin zur (globalen) Zentralisierung abzuleiten
• das bedeutet aber nicht, daß dieser Trend nicht existiert
• Und egal wohin die Richtung geht, Cloud- und Utility-Computing wird die IT-Landschaft verändern

Was bedeutet dies für die IT wissenschaftlicher Institutionen?

Zwei (mögliche (Szenarien):

• Szenario 1: Wir entlassen die Wissenschaftler in den Cloud
• Szenario 2: Wir sind der Cloud

Beide Szenarien haben durchaus ihren Charme ;o)

• Monolithische Applikationen, Dinosaurier und eierlegende Wollmilchsäue, die eine Rundum-Glücklich-Versorgung garantieren sollen, beherrschen die IT der wissenschaftlichen Organisationen
• Ziel ist das »Glück« der Institutionen, nicht das »Glück« der beteiligten Wissenschaftler

• Die Dienstleistungen der Institutionen stehen dem Wissenschaftler in der Regel nur während seines (meist kurzen) Aufenthalts an einer wissenschaftlichen Institution zur Verfügung
• Danach hat er u.U. sogar massive Schwierigkeiten, auf seine während seines Aufenthaltes angelegten Daten zuzugreifen
• Folge: Die Bereitschaft sinkt, sich an (Groß-) Projekten zu beteiligen, stattdessen legt er seine Sammlungen und Repositorien lieber außerhalb (eben bei »Google«) an, wo er hofft, daß er »lebenslangen« Zugriff auf seine Daten und Sammlungen hat

Wir entlassen die Wissenschaftler in den Cloud

• Die Anzahl der benötigten Server in den EDV-Abteilungen der Institutionen schrumpft
• Der Wissenschaftler hat auch nach seinem Ausscheiden aus einer Institution vollen Zugriff auf die Daten
• Mit der Beratung der Wissenschaftler, der Auswahl der Tools, der Bereitstellung und Konfiguration der (A)VMs, der Programmierung der APIs und der Glue-Skripte etc. enstehen neue (reizvolle) Aufgaben für die IT-Abteilungen der Institutionen

• Da ich der Auffassung bin, daß die Aufgaben der Supercomputing-Rechenzentren von dem Trend zum Cloud- und Utility-Computing weniger betroffen sind, müßten neue Dienstleistungs-Rechenzentren entstehen
• Erfordert die Bereitstellung von Know How, Rechen- und Manpower
• Weg von den Dinosauriern und eierlegenden Wollmilchsäuen und hin zu kleinen, einfachen Applikationen
• APIs!!!

• Mehr Dienstleistung (SLAs etc.)
• Das Problem des »lebenslangen Accounts« ist zu lösen
• Wer ist »wir«? (MPG? Fraunhofer? Alle deutschen oder gar alle europäischen Wissenschaftsinstitutionen?)

»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)

Wenn wir die Wissenschaftler nicht in den Cloud entlassen wollen, müssen wir

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

• Virtualisierung als Dienstleistung der Rechenzentren der Institutionen
• eigene »App Engine«?
• Wiki-Farmen
• OpenStreetMap-Server

• 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 am MPIWG gelernt habe, dann das.)

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

• Zurück