Die Wissenschaft auf Wolke Google

Vortrag zum Technologie-Tag der MPIs am 19. Mai 2009 in Dresden

• Diese Ausführungen geben alleine meine Meinung wieder und nicht die Meinung des Max-Planck-Instituts für Wissenschaftgeschichte oder gar die der MPG …

• eher im Gegenteil ;o)

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

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

• 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

• Diskutiere ich hier nicht (da gibt es kompetentere Ansprechpartner in der MPG), aber in der derzeitigen politischen Situation halte ich meine Daten auf einem amerikanischen kommerziellen Server für sicherer als auf einem Server, der dem Zugriff der deutschen/europäischen Strafverfolgungsbehörden unterliegt
• Außerdem bin ich mir sicher, daß Herr Gerling meine Äußerungen nicht unkommentiert stehen läßt ;o)

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

(Photo: Gabriele Kantel)

• 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 der MPIs und der MPG?

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 MPG
• Ziel ist das »Glück« der MPIs/MPG, nicht das »Glück« der beteiligten Wissenschaftler

• Die Dienstleistungen der MPG stehen dem Wissenschaftler in der Regel nur während seines (meist kurzen) Aufenthalts an einem Institut der MPG 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 Institute schrumpft
• Der Wissenschaftler hat auch nach seinem Ausscheiden aus einem MPI 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 Institute

• In Zeiten, in denen jeder Nutzer an jeder Straßenecke (kostenlose) Email-Accounts nachgeschmissen bekommt, halte ich eine MPG-eigene Email-Adresse für einen Anachronismus
• Sie bereichert nur noch den Jahrmarkt der Eitelkeiten
• Und dafür frißt sie zuviele Ressourcen und verschlingt zuviele Kosten

• 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? Alle deutschen oder gar alle europäischen Wissenschaftsinstitutionen?)

• Auch wenn mir persönlich das Szenario 2 sympathischer ist, halte ich wegen der Komplexität, der vielen ungelösten Probleme und der damit verbundenen Kosten diese Lösung für eher unwahrscheinlich
• Daraus folgt, daß das Szenario 1 wahrscheinlicher ist (und zwar unabhängig davon, ob wir es wollen oder nicht)
• Aber wir sollten wenigsten einige Applikationen auf »unsere« Maschinen holen
• Wir müssen uns daher darauf vorbereiten!

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

• Zurück

Werbung