Symposia Journal Edition 03/2011 by Symposia 360° GbR

// Informativ // Qualitativ // Unabh채ngig

Edition 02/2011 Cloud Computing

Mobile Computing

Events

Technologien

www.symposiajournal.de

Cloud Computing vs. Datacenter Automation

Denmark is edging closer to the cloud Die Notwendigkeit einer Cloud Multivendor Strategie Anwendungsgebiete der Near Field Communication

Informativ | Qualitativ | Unabhängig Liebe Leser, es war der Aufreger des diesjährigen Osterfestes: Der Ausfall von Teilen der Amazon Web Services hat die gesamte Szene bewegt und wieder einmal gezeigt, dass sich Cloud Computing Nutzer nicht aus der Verantwortung ziehen dürfen und schon gar nicht mit dem Finger auf die Anbieter zeigen sollten, wenn das eigene Design mangelhaft geplant und umgesetzt wurde. Wir schauen hinter die Kulissen des AWS Ausfalls und zeigen, wie für solche Situationen Präventivmaßnahmen ergriffen werden sollten. Passend dazu bewegen wir uns in die Welt der Superhelden und lernen, dass jedem von uns eine große Verantwortung obliegt, wenn wir Cloud Computing nutzen. In den Cloud Computing Basics werden dieses Mal der SQL Azure Data Sync Service von Microsoft vorgestellt sowie das Konzept der Amazon Elastic Block Store und der AWS Regionen und Availability Zones erläutert. Etwas forscher wird es bei unserer Diskussion über den Kampf um die echte Cloud und die Frage ob Cloud Computing tatsächlich grün ist. Darüber hinaus erhalten wir einen Cloud Computing Statusbericht von unseren Freunden aus Dänemark und lernen auf Basis eines realen Fallbeispiels wie dort eine Migration in die Cloud durchgeführt wurde. In unserer Rubrik “Cloud Computing Science” betrachten wir den Bereich der Cloud Computing Security und wie sich Security Administratoren im Falle von Infrastructure-as-a-Service verhalten sollten. Und auch das Mobile Computing kommt in dieser Ausgabe nicht zu kurz. Erfahren Sie die Hintergründe und mögliche Anwendungsgebiete der Near Field Communication. Viel Spaß beim Bilden wünschen Björn Böttcher & René Büst

Inhalt

02/2011

SymposiaJournal

Inhalt

02/2011

SymposiaJournal

02/2011

Veranstaltungen

AWS User Group Hamburg Ein Rückblick auf den 01 .06.2011

Am 01 .06 fand das zweite Treffen der AWS User Group Hamburg im Jahr 2011 statt. Als Host stellte sich dieses Mal die Hamburger Niederlassung der Adobe Systems GmbH zur Verfügung und versorgte alle Teilnehmer darüber hinaus mit kühlen Erfrischungen. Das Essen in Form von Bagels stellte dieses Mal Symposia 360° bereit. Vielen Dank für die Unterstützung! Das erste Highlight erlebten alle Teilnehmer aber bereits vor dem Treffen. Die Queen Mary 2 gab sich die Ehre, wodurch sich das Adobe Büro, direkt am Hafen gelegen, als vermutlich strategisch bester Aussichtsplatz herausstellte. Im Anschluß folgte, wie bereits beim letzten Treffen, Ralph Rebske mit seinem Vortrag. Dieses Mal mit dem Thema “AWS: Under The Hood – Understanding the Technology behind AWS“. Ein überaus informativer Vortrag, bei dem die Konzepte und Ideen von EC2 sowie EBS gelehrt wurden! Darüber hinaus stellte er die Probleme des AWS Outage nochmals ausführlich dar und erläuterte Best Practise Ansätze, um als Nutzer solchen Situationen zu begegnen. Der Business Case zur Nutzung der Amazon VPC musste leider berufsbedingt ausfallen, wird aber bei dem kommenden Treffen gehalten. Stattdessen stellte sich spontan Markus Knofe bereit, einen Vortrag über sein Projekt “elasticbeam – Releasing Erlang Applications into the Cloud” zu halten, dessen Folien er glücklicherweise dabei hatte. Dabei ging es um die Anwendungsentwicklung mit der Programmiersprache Erlang in der Cloud. Ein sehr interessantes Projekt, bei dem als Infrastruktur die Eucalyptus Cloud diente. Die Bilder des Treffens können, wie üblich, auf unserer Flickr Seite betrachtet werden. Alles in allem blicken wir erneut auf ein erfolgreiches User Group Treffen zurück und freuen uns auf 03/2011 . 6

SymposiaJournal

Veranstaltungen

SymposiaJournal

02/2011

Geek and Poke

SymposiaJournal

Cloud Computing Basics

02/2011

Spiderman und die Cloud von Björn Böttcher

„Aus großer Kraft folgt große Verantwortung“ heißt es bei Spiderman [1 ]. Doch was hat das ganze mit Cloud Computing zu tun? Cloud Computing ermöglicht einen vollkommen neuen Zugang und Umgang mit IT Ressourcen. Ob nun Entwickler, Architekt oder Manager, prinzipiell kann jeder Infrastructure-as-a-Service (IaaS) Ressourcen nutzen. Doch was bedeutet dies für ein Unternehmen? Ist es für eine Firma erstrebenswert, dass jeder Mitarbeiter Zugriff auf scheinbar unendliche IT Ressourcen hat? Nein, sicherlich nicht. Es ist sicherlich der Albtraum eines jeden CEO. Hierzu ein aktuelles Beispiel: An einem Sonntagmorgen war ein System Administrator mit seiner Routine, der Wartung seiner Cloud Server beschäftigt, als er plötzlich feststellte, dass er eine Datenbank mit 800.000 Benutzeraccounts von einer anderen Firma sehen konnte. Wie konnte es dazu kommen? Nun die Benutzer von Cloud Computing Angeboten sind wie schon gesagt nicht zwangsläufig nur Systemadministratoren, sondern auch Entwickler. Und eben ein solcher Entwickler hat in diese Fall als ein Systemadministrator gearbeitet und seine Datenbank selbst verwaltet, wie er es vielleicht von seiner lokalen Testumgebung stets gewohnt war. Doch im einem Produktionssystem gelten andere Anforderungen und andere Restriktionen. Lassen Sie mich an dieser Stelle noch ein anderes mögliches Szenario beleuchten. Ein Entwickler eines angesehen Softwareentwicklungshauses arbeitet an einer Software, die einen enormen Wert für das Entwicklungshaus darstellt. Der Entwickler testet diese in einem selbstkonfigurierten Cloud Computing Setup. Er vergisst jedoch nach dem Testen die Systeme wieder herunterzufahren. Dummerweise hat er ferner alle Standardports offen gelassen und der Server mit dem Quellcode steht nun im Internet jedem als willkommenes Ziel zur Verfügung. Dadurch könnte dem Unternehmen ein enormer wirtschaftlicher Schaden entstehen.

SymposiaJournal

02/2011

Cloud Computing Basics

Sind diese Fälle neu? Ist dies ein neues Risiko für die Unternehmen, die Cloud Computing im Unternehmen einsetzen wollen? Nun, ob alle Beispiele, welches theoretisch möglich wäre, auch tatsächlich in Erscheinung treten ist fragwürdig. Und Risiken haben Unternehmen auch schon immer getragen, wenn es um Daten und IT ging. Erinnern wir uns nur an den Fall eines verlorenen USB Sticks auf einer Messe mit wichtigen Konstruktionsplänen. Wichtig ist, dass die Mitarbeiter für Sicherheit sensibilisisert werden. Es muss eine Verantwortung und eine Identifikation mit dem Unternehmen erfolgen. Denn schließlich ist der wirtschaftliche Schaden des Unternehmens auch gleichbedeutend mit der Arbeitsplatzsicherung des Angestellten. Auf der Seite des Unternehmens ist es ferner entscheidend, Richtlinien, Standards und Prozesse zu definieren, zu kontrollieren und einzuhalten. Nur wenn es weiterhin eine IT Abteilung mit Systemadministratoren gibt, die die Server, Firewalls etc. konfigurieren und warten, dann kann dies auch der Weg zu einer verantwortungsvollen Nutzung von Cloud Ressourcen führen. Und auch nur auf diese Weise kann eine Bildung von Schatten IT verhindert werden. Wichtig ist also die eigene IT nicht zu umgehen bei der Migration in die Cloud, sondern effektiv und konsequent einzubeziehen. Denn der einzelne Entwickler sollte trotz der modernen Möglichkeiten, keinen direkten Zugriff auf “unbegrenzte” Unterenehmsressourcen haben. Die Bereitstellungszeit einer Ressource sinkt dennoch von Monaten, Wochen oder Tagen auf Minuten. Wie kann ich das ganze technisch umsetzen? Wichtig im ersten Schritt ist es die bisherigen Strukturen der Bereitstellung der IT-Abteilung auch auf Cloudstrukturen abzubilden. Dies beginnt mit der Implementierung eines Identitätsmanagements. Dies kann mittlerweile direkt mit Tools der Anbieter erfolgen. Beispielsweise gibt es bei den Amazon Web Services dafür das Identity and Access Management (IAM) [2]. Dieses ermöglicht es mehrere Benutzer zu erstellen, die dann über ein zentrales Konto administrierbar sind. Jedem Account werden spezifische Sicherheitsbefugnisse erteilt und können auch wieder entzogen werden. Diese Accounts beziehen sich jedoch nicht nur auf Benutzer, sondern können ebenso Ressourcen adressieren, wie z.B. andere Systeme oder Anwendungen. Für eine einfachere Verwaltung können zudem Gruppen angelegt werden. Damit fällt es dann leichter die Administration im Auge zu behalten. So ist die Rotation von Zugangsschlüssel eine Kleinigkeit. Ein weiteres Highlight dieser Dienste ist es, dass man einem Benutzer den Zugang unter Nebenbedingungen erteilen kann. Dies könnte z.B. die Uhrzeit, die IP-Adresse oder ein ähnliches geeignetes Regularium sein. Mit Hilfe eines Identitätsmanagements ist die Bereitstellung von Ressourcen, auch unter Restriktionen möglich und ergibt einen kontrollierten Umgang mit der Ressource Cloud. Die Abrechnung der genutzten Cloud Kapazitäten erfolgt weiterhin über ein Konto. Damit hat die interne IT Abteilung auch weiterhin ein Budget, über welches Sie entsprechende Ressourcen verwalten und zur Verfügung stellen kann. Zusammengefasst ist ein sinnvoller und organisierter Umgang bei der Nutzung von Cloud Ressourcen entscheidend für eine erfolgreiche Migration. Die bestehende interne ITAbteilung sollte auch weiterhin in den Bereitstellungszyklus für Ressourcen integriert sein vielmehr muss. 10

SymposiaJournal

Cloud Computing Basics

02/2011

Über Björn Böttcher Björn Böttcher war als Microsoft Student Partner an der Technischen Universität Hamburg-Harburg tätig und hat sich schon während seines Studiums als Freelancer in vielen Projekten aktiv in der Wirtschaft um informationstechnologische Umsetzungen gekümmert. Nach seinem Abschluss als Diplom Informatik-Ingenieuer promoviert er bei der Parallel Computing Group an der TUHH im Cloud und Grid Umfeld. Das Interesse an der Wissensvermittlung hat er schon früh während seiner Ausbildung zum Reserveoffizier entwickelt und bis nach dem Studium erhalten und intensiviert.

Quellenangaben [1 ] http://de.wikipedia.org/wiki/Spider-Man [2] http://aws.amazon.com/de/iam SymposiaJournal

02/2011

Cloud Computing Basics

Die Notwendigkeit einer Cloud Multivendor Strategie von René Büst

Es war der Aufreger über Ostern diesen Jahres. Der Outage der Amazon Web Services in der Region US-EAST-1 . Das Problem machte sich zunächst mit Latenzen und Fehlerraten innerhalb der EBS Volumes und Verbindungsproblemen zu den EC2 Instanzen bemerkbar. Die Folge waren Verbindungsprobleme zu einigen Webseiten und Anbietern, die EC2 nutzen, um ihre Services anzubieten, wie Hootsuite, Mobypicture, Reddit oder Foursquare. Es stelle sich heraus, dass ein Routingfehler in der Folge eines manuellen Netzwerkupgrades für den Amazon Elastic Block Store (EBS) zu dem Ausfall führte.

Hintergrund Der Amazon Elastic Block Store besteht aus zwei Netzwerken, einem Primären für die Verarbeitung von hohen Lasten und einem Sekundären für niedrigere Lasten. Über diese Netzwerke findet die Kommunikation der jeweiligen Cluster innerhalb einer EBS-Zone statt. Um das Update vorzunehmen musste zunächst der Netzwerkverkehr umgeleitet werden. Anstatt diesen jedoch auf einen anderen Router innerhalb des primären Netzwerkes umzuleiten, wurde der Verkehr der Nodes des Cluster in das sekundäre Netz geleitet, das dadurch völlig überlastet wurde. Die Folge war eine Verkettung von Problemen, die durch die Methoden zur redundanten Datenhaltung (um einen Datenverlust zu verhindern) vervielfacht wurden. Auf Grund dieses Routingproblems waren einige EBS Nodes nicht mehr in der Lage auf das primäre sowie auf das sekundäre Netzwerk zuzugreifen und waren damit von den restlichen Nodes isoliert. Jeder Node repliziert im Normalfall seine Daten auf die anderen Nodes, wodurch eine hohe Verfügbarkeit der Daten erzielt wird. Durch den Verbindungsabbruch verloren die voneinander isolierten Nodes jedoch ihre Replizierungspartner. Nachdem das Routingproblem behoben war, begonnen die Nodes wieder damit, sich einen Replikationspartner mit ausreichend freiem Speicherplatz zu suchen. Dieser Vorgang dauert in einem funktionsfähigem Cluster gewöhnlich nur ein 12

SymposiaJournal

Cloud Computing Basics

02/2011

paar Millisekunden. Durch die Masse an Anfragen war jedoch nicht mehr ausreichend Speicherplatz innerhalb des Cluster vorhanden, was dazu führte, dass die Replikation deutlich länger dauerte. Auf Grund dieser Konstellation waren 1 3 Prozent der EBS Nodes nicht mehr in der Lage Schreib- bzw. Leseanfragen zu beantworten. Zudem war das EBS Kontrollsystem nicht mehr zu 1 00% funktionsfähig, wodurch innerhalb des Cluster keine neuen Volumes mehr erstellt werden konnten. Durch zwei weitere Missstände wurde die Situation noch verschäft. Zum einen suchten die nicht mehr funktionsfähigen Nodes weiterhin nach freiem Speicherplatz und zum anderen führte eine Race-Condition innerhalb des EBS Programmcodes dazu, dass weitere EBS Nodes ausfielen. Da die Amazon EC2 Instanzen die EBS Volumes nutzen, um darauf ihre Daten persistent zu speichern, wurden sie dadurch ebenfalls in Mitleidenschaft gezogen. Der Wechseln eines Replikationspartners muss der zugeordneten EC2 Instanz mitgeteilt werden. Das ist im Normalfall in Ordnung. Während des Problems führte diese Methodik jedoch dazu, dass der Kontrolldienst für diese Replikation ebenfalls überlastet wurde, wodurch sich die gesamte Überlast auf die anderen Availability Zones auswirkte. Ebenfalls von dem Ausfall betroffen war der Amazons Relational Database Service (RDS), der EBS verwendet, um darauf Datenbanken und Logdateien abzulegen. Hier besteht das Problem darin, dass der Ausfall eines EBS Volumes dazu führt, dass die komplette RDS Instanz stehen bleibt. Normalerweise greift eine RDS Instanz parallel auf mehrere EBS Volumes zu. Daher waren innerhalb der Availability Zone davon um die 45 RDS Instanzen betroffen.

Design For Failure Unternehmen sollten sich nicht auf die Nutzung einer einzigen Availability Zone konzentrieren, sondern ihre Anwendung über mehrere Zonen hinweg betreiben. Im Idealfall sogar über mehrere Regionen hinweg. Amazon ist sich mittlerweile jedoch bewusst, dass die Nutzung mehrerer Availability Zones die Komplexität der Anwendung erhöht und will daran in Zukunft nachbessern. Darüber hinaus soll das Monitoring von Änderungen innerhalb der Infrastruktur verbessert und die Fehlertoleranz von EBS erhöht werden. Zudem wird die Gesamtkapazität freier Ressourcen erhöht, um damit ähnlichen Problemen entgegenzuwirken, sowie das Fehlerverhalten der EBS Nodes angepasst. Zunächst muss eines jedoch klar sein. Amazon stellt “nur” virtuelle Ressourcen zum Aufbau einer eigenen virtuellen Infrastruktur bereit. Amazon ist nicht für die Anwendung und deren Funktionalität zuständig, sondern stellt nur die Infrastruktur bereit, auf der die Anwendungen ausgeführt werden. Design for failure! Ist im Prinzip nichts Neues. Im Grunde sollte das ebenfalls bei jedem anderen nicht Cloud Anbieter und im eigenen Rechenzentrum beachtet werden. Der Entwickler sollte immer in der Pflicht stehen, seine Anwendung gegen Hardware oder sonstige Ausfälle abzusichern und die Verfügbarkeit sicherzustellen.

SymposiaJournal

02/2011

Cloud Computing Basics

Hootsuite, Mobypicture, Reddit und Foursuqare bspw. haben den Fehler gemacht, sich nur auf eine AWS Region zu konzentrieren, anstatt ihren Service über die gesamte Amazon Cloud hinweg zu verteilen. Speziell bei Mobypicture, als einen europäischen Anbieter mit Sitz in Holland, ist genau dies ein wenig verwunderlich. Die deutsche Seite von Foursquare hingegen war bspw. erreichbar und lief stabil, ebenso die von Reddit.

Nicht alles auf eine Karte setzen Für jedes Unternehmen, das seinen Service über die Cloud anbietet, gilt es daher: “Nutze die gesamte Cloud eines Anbieters und verlasse Dich nicht nur auf einen einzigen Anbieter!” Durch die Verteilung einer Anwendung über mehrere Regionen und Availability Zones bei einem Anbieter wird die Verfügbarkeit der Anwendung drastisch erhöht. Zudem ist eine MultiVendor Strategie zwingend erforderlich. Außerdem müssen bereits von Beginn an Fallback Szenarien entwickelt werden, um gegen einen plötzlichen Ausfall vorbereitet zu sein. Es geht also bspw. darum, Systeme aufzubauen, die im Fehlerfall automatisch eine gespiegelte Infrastruktur bei einem anderen Anbieter aufbauen. Besser wäre es, mehrere Anbieter parallel zu nutzen und die Services über mehrere Anbieter hinweg zu verteilen. Dazu gehört z.B.: Instanzen von unterschiedlichen Anbietern parallel produktiv einzusetzen, um damit das Risiko zu streuen.

Für die Zukunft Amazon darf auf keinen Fall von einer Schuld freigesprochen werden, dazu werben sie viel zu deutlich mit der eigenen Verfügbarkeit. Dennoch, beim Cloud Computing handelt es sich um bedeutend mehr als nur das Nutzen von ein paar virtuellen Ressourcen und jeder Nutzer der Cloud ist für die Verfügbarkeit seiner Anwendung selber verantwortlich. Dafür stehen ihm ausreichend Mittel und Wege auf Grund der Cloud zur Verfügung!

Über René Büst René Büst ist Cloud Computing Evangelist, IT-Analyst, -Advisor und -Autor, Managing Director von Symposia 360° und Gründer & Autor von CloudUser | Ξxpert. Er hat ein Informatik Diplom der Hochschule Bremen und ist Cand. M.Sc. in IT-Management and Information Systems an der FHDW Paderborn.

SymposiaJournal

Cloud Computing Basics

02/2011

SQL Azure Data Sync Service von Holger Sirtl

SQL Azure stellt ein echtes relationales Datenbankmanagementsystem als Cloud Service bereit. Enthalten sind ein Subset der Datenbank-Engine aus SQL Server, die SQL Azure Reporting Services sowie der SQL Azure Sync Service.

Der SQL Azure Sync Service erlaubt es, eine lokale Datenbank mit einer SQL Azure Datenbank zu synchronisieren. D.h. Änderungen, die in einer der beiden beteiligten Datenbanken vorgenommen werden, können bei Bedarf in die jeweils andere Datenbank übertragen werden. Damit wird es sehr einfach möglich, Offline-Szenarien zu realisieren, in denen beim Ausfall der Internet-Verbindung mit einer lokalen Datenbank weitergearbeitet werden kann. Änderungen, die in dieser Zeit lokal vorgenommen werden, können dann sehr leicht nach SQL Azure übertragen werden, wenn die Verbindung wieder steht. Für die folgenden Ausführungsschritte legen Sie zunächst eine neue Datenbank unter SQL Azure an. Führen Sie auf dieser Datenbank (z.B. mit Hilfe des SQL Server Management Studios) das in Listing 1 gezeigte SQL-Skript aus.

SymposiaJournal

02/2011

Cloud Computing Basics

CREATE TABLE [Kunden]( [KundenID] [int] IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, [Anrede] [nvarchar](6) NOT NULL, [Vorname] [nvarchar](50) NOT NULL, [Nachname] [nvarchar](50) NOT NULL, [Email] [nvarchar](50) NOT NULL, [Website] [nvarchar](50) NULL, [Telefon] [nvarchar](30) NULL, [Timestamp] [timestamp] NOT NULL ) CREATE INDEX IX_Kunden_Email ON Kunden (Email) INSERT INTO [Kunden] ([Anrede], [Vorname], [Nachname], [Email], [Website], [Telefon]) VALUES ('Herr', 'Holger', 'Sirtl', 'hsirtl@microsoft.com', 'http://blogs.msdn.com/hsirtl', '089/123-456') Listing 1 : Anlegen von Tabelle und Tabelleneintrag in SQL Azure

Damit wird die Tabelle Kunden angelegt und in dieser Tabelle ein einzelner Tabelleneintrag geschrieben. Tabelle und Inhalt sollen später mit Hilfe des Microsoft Sync Frameworks in eine lokale Datenbank übertragen werden.

Das Microsoft Sync Framework Synchronisation zwischen SQL Azure und einer lokalen Datenbank wird mit Hilfe des Microsoft Sync Frameworks implementiert. In den folgenden Abschnitten soll eine kleine Konsolenanwendung entwickelt werden, die eine Synchronisationsbeziehung zwischen einer lokalen SQL Express Datenbank und einer SQL Azure Datenbank herstellt. Die Architektur ist in Abbildung 2 zu sehen.

Abbildung 2: Architektur einer Sync Framework basierten Lösung

SymposiaJournal

Cloud Computing Basics

02/2011

Eine auf dem Sync Framework aufsetzende Lösung enthält in der Regel folgende Komponenten, die in der Architekturabbildung zu sehen sind:

Sync Provider

Dies ist eine Art Datenbank-Treiber, der die Funktionen des Sync Frameworks für die beteiligten Datenbanken in die jeweiligen Datenbank-Aufrufe übersetzt. Hier muss also für die betreffende Datenbank ein passender Sync Provider eingesetzt werden. Für SQL Server und SQL Azure stellt Microsoft passende Provider bereit. Für andere Datenbanksysteme sind von den jeweiligen Herstellern ebenfalls Provider verfügbar.

Sync Orchestrator

Diese Komponente konfiguriert die beteiligten Datenbanken, initiiert die Synchronisation und wertet die Ergebnisse aus. Für die Kommunikation mit den Datenbanken bedient er sich der Sync Provider Starten Sie nun Visual Studio und legen über den Menüpunkt File / New / Project ein neues Projekt an. Wählen sie als Projektvorlage eine Konsolenanwendung (Visual C# / Windows / Console Application). Da die Anwendung das Sync Framework nutzen soll, werden vier DLLs benötigt, die in Tabelle 1 aufgelistet sind.

Tabelle 1 : Für das Sync Framework benötigte Dateien und Namespaces

Nach Hinzufügen der DLLs sollte der Solution Explorer die entsprechenden Namespaces wie in Abbildung 3 zu sehen auflisten.

Abbildung 3: Referenzen zum Sync Framework

SymposiaJournal

02/2011

Cloud Computing Basics

Die Konsolenanwendung soll die folgenden zwei Funktionalitäten bieten: • Initialisierung der Synchronisationsbeziehung (Methode Setup()) • Durchführung einer Synchronisation (Methode Sync()) Die beiden hierzu benötigten Methoden sind in Listing 2 zu sehen. Sie werden je nach Aufrufparameter aufgerufen. Fehlt der Aufrufparameter, wird eine entsprechende Information auf der Konsole angezeigt. using System; using System.Data.SqlClient; using Microsoft.Synchronization.Data.SqlServer; using Microsoft.Synchronization.Data; using Microsoft.Synchronization;

namespace SyncTest{ class Program{ public static string sqlazureConnectionString = @"Server=<MEIN_SERVER>.database.windows.net; Database=<MEINE_DATENBANK>; User ID=<MEIN_SERVER_ADMIN_USER>@<MEIN_SERVER>; Password=<MEIN_SERVER_ADMIN_PASSWORT>; Trusted_Connection=False; Encrypt=True;"; public static string sqllocalConnectionString = @"Server=.\SQLEXPRESS; Database=<MEINE_LOKALE_DATENBANK>; Trusted_Connection=True"; public static readonly string scopeName = "alltablesyncgroup"; static void Main(string[] args){ // Test if input arguments were supplied: if (args.Length == 0){ System.Console.WriteLine("Please enter an argument."); System.Console.WriteLine("Usage: SyncTest.exe -setup"); System.Console.WriteLine(" SyncTest.exe -sync"); } else if (args[0] == "-setup") Setup(); else if (args[0] == "-sync") Sync(); } public static void Setup() { ... } public static void Sync() { ... } } } } Listing 2: Code-Gerüst für die Sync Anwendung

SymposiaJournal

Cloud Computing Basics

02/2011

Konfiguration der beteiligten Datenbanken Bevor eine Synchronisation der Datenbanken durchgeführt werden kann, müssen diese entsprechend vorbereitet werden. Dabei werden in den Datenbanken Hilfstabellen angelegt, in denen Synchronisationsinformationen gespeichert werden. Das Schema der zu synchronisierenden Tabellen bleibt dabei unverändert. Für die initiale Konfiguration der Datenbanken implementieren Sie die Setup()-Methode nun wie in Listing 3 gezeigt. Die dort durchgeführte Konfiguration setzt voraus, dass Sie die SQL Azure Datenbank wie zuvor beschrieben aufgesetzt haben, d.h. eine Kunden-Tabelle existiert. public static void Setup(){ try{ SqlConnection sqlServerConn = new SqlConnection(sqllocalConnectionString); SqlConnection sqlAzureConn = new SqlConnection(sqlazureConnectionString); DbSyncScopeDescription myScope = new DbSyncScopeDescription(scopeName); DbSyncTableDescription Customer = SqlSyncDescriptionBuilder.GetDescriptionForTable("Kunden", sqlAzureConn); // Add the tables from above to the scope myScope.Tables.Add(Customer); // Setup SQL Server for sync SqlSyncScopeProvisioning sqlServerProv = new SqlSyncScopeProvisioning(sqlServerConn, myScope); if (!sqlServerProv.ScopeExists(scopeName)){ // Apply the scope provisioning. Console.WriteLine("Provisioning SQL Server for sync " + DateTime.Now); sqlServerProv.Apply(); Console.WriteLine("Done Provisioning SQL Server for sync " + DateTime.Now); } else Console.WriteLine("SQL Server Database server already provisioned for sync " + DateTime.Now);

SymposiaJournal

02/2011

Cloud Computing Basics

// Setup SQL Azure for sync SqlSyncScopeProvisioning sqlAzureProv = new SqlSyncScopeProvisioning(sqlAzureConn, myScope); if (!sqlAzureProv.ScopeExists(scopeName)){ // Apply the scope provisioning. Console.WriteLine("Provisioning SQL Azure for sync " + DateTime.Now); sqlAzureProv.Apply(); Console.WriteLine("Done Provisioning SQL Azure for sync " + DateTime.Now); } else Console.WriteLine("SQL Azure Database server already provisioned for sync " + DateTime.Now); sqlAzureConn.Close(); sqlServerConn.Close(); } catch (Exception ex){ Console.WriteLine(ex); } } Listing 3: Methode zum Initialisieren der Synchronisationsbeziehung

Die Methode baut zunächst Verbindungen zu den beiden Datenbanken (wie über die Connection-Strings konfiguriert) auf und initialisiert einen sogenannten Sync-Scope. Dieser legt den Bereich, d.h. die Tabellen, fest, der synchronisiert werden soll. Danach wird die Schema-Information der Kunden-Tabelle ermittelt und dem Sync-Scope hinzugefügt. Anschließend wird der Sync-Scope zunächst auf der lokalen Datenbank und dann in SQL Azure provisioniert. Abschließend werden die Verbindungen zu den Datenbanken wieder geschlossen. Bauen Sie die Solution durch Auswahl des Menüpunkts Build / Build Solution. Öffnen sie anschließend ein Konsolenfenster und wechseln dort in das Verzeichnis, in das Visual Studio die exe-Datei geschrieben hat. Abbildung 4 zeigt die Konsolenausgabe bei Ausführung der Anwendung (zuerst Aufruf ohne Parameter, dann mit Parameter -setup).

Abbildung 4: Initialisierung des Sync Frameworks

SymposiaJournal

Cloud Computing Basics

02/2011

Damit ist die Initialisierung der Datenbanken abgeschlossen. Das Sync Framework hat in beiden Datenbanken Hilfstabellen angelegt, in denen Änderungen bis zur nächsten Synchronisation zwischengespeichert werden. Abbildung 5 zeigt die Tabellenansicht aus dem SQL Server Management Studio vor und nach der Initialisierung.

Abbildung 5: Tabellen vor und nach Initialisierung des Sync Frameworks

Vor der Initialisierung ist nur in SQL Azure eine Kunden-Tabelle vorhanden. Nach der Initialisierung wurde zum einen die Tabelle auch in der lokalen Datenbank angelegt (ja, dies erledigt das Sync Framework automatisch), zum anderen wurden in beiden Datenbanken die Hilfstabellen angelegt. Noch wurden allerdings keine Daten übertragen. Die Änderungen beziehen sich noch ausschließlich auf die Schemata.

Synchronisation mit einer lokalen Datenbank Nun soll die Sync()-Methode implementiert werden, mit deren Hilfe eine Synchronisation der beiden Datenbanken, d.h. ein Datenabgleich, erfolgen kann. Implementieren Sie die Methode wie in Listing 4 gezeigt. Die Methode baut Verbindungen zu den beiden Datenbanken auf und instanziiert einen neuen Sync-Orchestrator. Im Orchestrator werden zwei passende Sync-Provider und die gewünschte Synchronisationsrichtung definiert. Im Beispiel soll die Synchronisation in beide Richtungen erfolgen.

SymposiaJournal

Cloud Computing Basics

02/2011

public static void Sync(){ try{ SqlConnection sqlServerConn = new SqlConnection(sqllocalConnectionString); SqlConnection sqlAzureConn = new SqlConnection(sqlazureConnectionString); SyncOrchestrator orch = new SyncOrchestrator{ LocalProvider = new SqlSyncProvider(scopeName, sqlServerConn), RemoteProvider = new SqlSyncProvider(scopeName, sqlAzureConn), Direction = SyncDirectionOrder.UploadAndDownload }; Console.WriteLine("ScopeName={0} ", scopeName); Console.WriteLine("Starting Sync " + DateTime.Now); ShowStatistics(orch.Synchronize()); sqlAzureConn.Close(); sqlServerConn.Close();

}

} catch (Exception ex){ Console.WriteLine(ex); }

public static void ShowStatistics(SyncOperationStatistics syncStats){ Console.WriteLine("General Sync Statistics"); Console.WriteLine("======================="); Console.WriteLine("\tSync Start Time : " + syncStats.SyncStartTime.ToString()); Console.WriteLine("\tSync End Time : " + syncStats.SyncEndTime.ToString()); Console.WriteLine(""); Console.WriteLine("Upload Statistics (local SQL -> SQL Azure)"); Console.WriteLine("============================================"); Console.WriteLine("\tChanges Applied : " + syncStats.UploadChangesApplied.ToString()); Console.WriteLine("\tChanges Failed : " + syncStats.UploadChangesFailed.ToString()); Console.WriteLine("\tChanges Total : " + syncStats.UploadChangesTotal.ToString()); Console.WriteLine(""); Console.WriteLine("Download Statistics (SQL Azure -> local SQL)"); Console.WriteLine("============================================"); Console.WriteLine("\tChanges Applied : " + syncStats.DownloadChangesApplied.ToString()); Console.WriteLine("\tChanges Failed : " + syncStats.DownloadChangesFailed.ToString()); Console.WriteLine("\tChanges Total : " + syncStats.DownloadChangesTotal.ToString()); } Listing 4: Methode zum Synchronisieren der Inhalte der Datenbanken

SymposiaJournal

Cloud Computing Basics

02/2011

Nach erfolgreicher Synchronisation wird das Ergebnis über die Hilfsmethode ShowStatistics() angezeigt. Bauen Sie die Solution und wechseln Sie anschließend in das Konsolenfenster. Rufen Sie dort die Anwendung mit dem Aufrufparameter -sync auf. Abbildung 6 zeigt das Ergebnis.

Abbildung 6: Synchronisation der Inhalte aus SQL Azure

Da in der SQL Azure Datenbank nur ein Eintrag vorhanden war, zeigt die Ausgabe an, dass eine Änderung von der SQL Azure Datenbank in die lokale Datenbank übertragen wurde. Prüfen Sie (z.B. im SQL Server Management Studio), ob der Eintrag nun korrekt in der lokalen Datenbank liegt. Ändern Sie nun den Eintrag in der lokalen Datenbank. Hierzu können Sie das SQL Skript verwenden, das in Listing 5 abgebildet ist, und führen Sie dieses im SQL Server Management Studio aus. UPDATE [LokalDB].[dbo].[Kunden] SET [Vorname] = 'Max' ,[Nachname] = 'Mustermann' WHERE [KundenID] = 1 GO Listing 5: Änderung eines Eintrags in der lokalen Datenbank

SymposiaJournal

02/2011

Cloud Computing Basics

Starten Sie nun einen neuen Synchronisationslauf, indem Sie wieder in das Konsolenfenster wechseln und dort durch Aufruf der Anwendung mittels SyncTest -sync eine Synchronisation der Datenbanken durchfürhen. Das Ergebnis ist in Abbildung 7 zu sehen.

Abbildung 7: Synchronisation der Änderung der lokalen Datenbank

In diesem zweiten Synchronisationslauf wurde nun ein Eintrag (der geänderte Eintrag) von der lokalen Datenbank nach SQL Azure übertragen. Abbildung 8 zeigt, wie sich das Ergebnis im SQL Server Management Studio darstellt. Dort ist der geänderte Eintrag in SQL Azure abgebildet.

Abbildung 8: Ergebnis der Synchronisation

SymposiaJournal

Cloud Computing Basics

02/2011

Über Holger Sirtl Holger Sirtl ist seit 2006 als Architect Evangelist bei Microsoft in München tätig und berät in dieser Rolle Unternehmen im Aufbau .NET-basierter Anwendungsarchitekturen. Schwerpunktthemen seiner Arbeit sind Cloud Computing mit der Windows Azure Platform, Office Business Applikationen (OBA) sowie Microsofts "Software+Services"-Strategie. Vor seinem Einstieg bei Microsoft arbeitete Holger Sirtl sechs Jahre lang als Technologieberater für eine international führende Unternehmensberatung sowie zwei Jahre lang als Senior-IT-Projektmanager für einen großen deutschen Energieversorger.

Ressourcen zur SQL Azure Database Engine SQL Azure im Überblick

http://www.microsoft.com/windowsazure/sqlazure

SQL Azure in der MSDN Library

http://msdn.microsoft.com/en-us/library/ee336279.aspx

Ressourcen zum SQL Azure Sync Service Microsoft Sync Framework Developer Center

http://msdn.microsoft.com/en-us/sync/default.aspx

Download: Microsoft Sync Framework 2.1 Software Development Kit (SDK)

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ee6af1 41 -79d0-4351 a4a0-ea89bb29dcf5&displaylang=en SymposiaJournal

02/2011

Geek and Poke

SymposiaJournal

Cloud Computing Basics

02/2011

Das Konzept der AWS Regionen und Availability Zones von René Büst

Amazon EC2 bietet die Möglichkeit, Instanzen über mehrere Standorte zu verteilen. Dabei sind die Standorte in Availability Zones und Regionen aufgeteilt. Die Regionen sind verstreut und befinden sich in getrennten geographischen Gebieten wie den USA und Europa. Availability Zones sind verschiedene Standorte innerhalb einer Region, die so konstruiert sind, dass sie isoliert betrieben werden und von Fehlern in anderen Availability Zones nicht betroffen sind. Dazu bieten sie eine kostengünstige Konnektivität mit einer geringen Netzwerklatenz zu anderen Availability Zones in der gleichen Region. Durch das Starten von Instanzen in separaten Regionen, können Web Anwendungen so konstruiert werden, dass sich diese geographisch in der Nähe von bestimmten Kunden befinden und rechtlichen oder anderen Anforderungen gerecht werden. Weiterhin werden Anwendungen vor dem Ausfall eines einzelnen Standorts geschützt, indem Instanzen in separaten Availability Zones ausgeführt werden. Die folgende Graphik zeigt eine Darstellung der Amazon EC2 Regionen und Availability Zones. Jede Region ist völlig unabhängig. Jede Availability Zone ist vollständig isoliert, aber durch Netzwerkverbindungen mit einer geringen Latenz mit anderen Availability Zones verbunden.

SymposiaJournal

02/2011

Cloud Computing Basics

Regionen Amazon EC2 verfügt über mehrere Regionen, wodurch EC2 Instanzen an den Standorten ausgeführt werden können, die den eigenen Anforderungen entsprechen. Um z.B. als nicht europäisches Unternehmen Kunden in Europa Dienstleistungen anzubieten und zudem den dort gesetzlichen Anforderungen gerecht zu werden, können die EC2 Instanzen in einer Availability Zone der Region Europa ausgeführt werden. Jede Amazon EC2 Region ist so konstruiert, dass sie vollständig isoliert von allen anderen Amazon EC2 Regionen betrieben wird. Damit wird die größtmögliche Unabhängigkeit und Stabilität erzielt und macht den Ort einer jeden EC2 Ressource eindeutig. Um Instanzen zu starten oder mit diesen zu arbeiten, muss zunächst die korrekte URL eines Endpunkts einer Region definiert werden. Soll z.B. eine Instanz in der Region USEast (Standard Region) betrieben werden, wird als Endpunkt URL ec2.us-east1 .amazonaws.com verwendet. In der folgenden Tabelle sind alle Regionen mit ihren zugehörigen Endpunkten dargestellt.

Availability Zones Fehler können auftreten, die Auswirkungen auf die Verfügbarkeit von Instanzen haben, die sich an dem gleichen Standort befinden. Auch wenn das ziemlich selten vorkommt – wenn alle Amazon EC2 Instanzen an einem einzigen Standort gehostet werden, der von einer Störung betroffen ist, sind diese Instanzen nicht mehr verfügbar. Sind z.B. Instanzen über drei Availability Zones verteilt und eine dieser Instanzen fällt aus, kann eine Anwendung zu konzipiert werden, dass die Instanzen in den übrigen Availability Zones die Anfragen automatisch entgegennehmen und verarbeiten.

SymposiaJournal

Cloud Computing Basics

02/2011

Das Konzept des Amazon Elastic Block Store von René Büst

Der Amazon Elastic Block Store (Amazon EBS) ist eine spezielle Speicherart, die speziell für Amazon EC2 Instanzen konstruiert wurde. Mit Amazon EBS können Volumes erstellt werden, die von Amazon EC2 Instanzen wie externe Geräte eingebunden (gemounted) werden können. Amazon EBS Volumes verhalten sich wie unformatierte externe Block-Devices. Sie können durch den Benutzer benamt werden und stellen eine Block-Device-Schnittstelle bereit. EBS Volumes können mit einem Dateisystem ausgestattet oder wie ein gewöhnliches Block-Device genutzt werden. Ein AWS Account ist auf 1 00 EBS Volumes oder in der Summe auf eine Volume Gesamtspeichergröße von 20 Terrabyte begrenzt. Dabei beträgt die maximale Größe eines Volumes 1 Terrabyte. Jedes EBS Volume kann jeder EC2 Instanz innerhalb derselben Verfügbarkeitszone hinzugefügt werden. Mit Amazon EBS können Snapshots (Backups) der EBS Volumes erstellt und auf Amazon S3 gespeichert werden. Diese Snapshots können als Ausgangspunkt für neue EBS Volumes genutzt werden und schützen die Daten langfristig. Weiterhin können Snapshots mit bestimmten Benutzern geteilt oder öffentlich verfügbar gemacht werden. Amazon EBS Volumes verfügen über folgende Eigenschaften: • Speichern ausserhalb der Instanz • Persistenz jenseits der Lebensdauer von Instanzen • Hohe Verfügbarkeit und Zuverlässigkeit • Hinzufügen und Entfernen der Volumes für bereits ausgeführte Instanzen • Darstellung als ein eigenes Gerät innerhalb der Instanz • Amazon EBS Snapshots verfügen über folgende Eigenschaften: • Erfassung des aktuellen Zustands eines Volumes • Datensicherung • Instanziierung neuer Volumes, die den exakten Inhalt eines Snapshots beinhalten SymposiaJournal

02/2011

Cloud Computing Basics

Amazon EBS Anwendungsfälle Fehlertoleranz Amazon EBS ist so konstruiert, dass jede Instanz zu einem Speichervolumen hinzugefügt werden kann. Fällt eine Instanz auf Grund eines Fehlers aus, löst sich das EBS Volume automatisch mit den intakten Daten von der Instanz. Anschließend kann das Volume zu einer neuen Instanz hinzugefügt werden und der Wiederherstellungprozess beginnen.

Erklärung 1 . Eine Amazon EC2 Instanz ist mit einem EBS Volume verbunden. Die Instanz fällt aus, bzw. Probleme treten auf. 2. Zur Wiederherstellung muss das EBS Volume nun von der Instanz gelöst werden. Das kann auch automatisch durch das EBS Volume erfolgen. Anschließend wird eine neue Instanz gestartet und das Volume dieser neuen Instanz hinzugefügt. 3. Für denn Fall das ein Amazon EBS Volume ausfällt, kann eines neues EBS Volume auf Basis des jüngsten Snapshots des Volumes erstellen, dass ausgefallen ist.

SymposiaJournal

Cloud Computing Basics

02/2011

Neue Volumes auf Basis von Snapshots erstellen Amazon EBS Snapshots ermöglichen den schnellen Einsatz neuer Volumes, indem ein bereits vorhandener Snapshot als Ausgangspunkt für diese neuen Volumes dient.

Erklärung 1 . Es wird ein Web-Service mit einer großen Datenmenge verwendet. 2. Wenn die Daten fertig sind, kann ein Snapshot des Volumes in Amazon S3 zur langfristigen Datensicherung gespeichert werden. 3. Wenn der Datenverkehr und Ressourcenverbrauch ansteigt, kann aus dem Snapshot ein neues Volume erstellt, eine neue Instanz gestartet und anschließend dieser neuen Instanz das neue Volume hinzugefügt werden. 4. Wenn sich der Datenverkehr wieder verringert, können eine oder mehrere Amazon EC2 Instanzen heruntergefahren und ihre EBS Volumes gelöscht werden.

SymposiaJournal

02/2011

Cloud Computing Basics

Datenpersistenz EBS Volumes existieren unabhängig von den aktuell vorhandenen Instanzen und bleiben solange vorhanden, bis sie explizit gelöscht werden. Das ermöglicht das Speichern von Daten, ohne dass eine Instanz gestartet sein muss.

Erklärung 1 . In regelmäßigen Abständen wird eine Instanz zur Batchverarbeitung von großen und wachsenden Datenmengen ausgeführt. 2. Am Ende der Verarbeitung wird die EC2 Instanz beendet. Das EBS Volume wird aber weiterhin ausgeführt. 3. Werden die Daten das nächste Mal verarbeitet, wird eine neue EC2 Instanz gestartet und dem bereits vorhandenen EBS Volume hinzugefügt. Auf Basis dieses Vorgehens können die Daten nur mit den Ressourcen auf unbestimmte Zeit verarbeitet und gespeichert werden, die auch tatsächlich benötigt werden.

Root Partition EBS Volumes können als Root Device (Partition) für Linux und Windows Instanzen verwendet werden. Dadurch besteht die Möglichkeit Root Partitionen mit der Größe von bis zu 1 Terrabyte zu nutzen. Weiterhin kann das EBS Volume (als Root Partition) von einer anderen Instanz gemounted werden, falls eine Instanz ausfällt. Die Größe der Partition kann während des Startvorgangs mittels Block Device Mapping geändert werden.

Erklärung 1 . Ein vorhandenes AMI ist in Amazon EBS gespeichert. Es Änderungen daran vorgenommen und ein neues AMI erstellt. 2. Falls die Größe der Root Partition nicht mehr ausreicht, wird die Instanz gestoppt und mit einem größeren EBS Volume neu gestartet. 3. Falls eine Instanz ausfallen sollte, wird eine neue Instanz gestartet und die Root Partition (EBS Volume) der ausgefallenen Instanz gemounted.

Große Datenmengen Amazon EBS bietet größere Volumes als Amazon EC2 Instanzen. Jedes EBS Volume kann bis zu einem Terrabyte groß sein.

SymposiaJournal

Cloud Computing Meinung

02/2011

Grün oder nicht grün – das ist hier die Frage von Dr. Michael Pauly

Vor einigen Jahren wäre noch niemand auf die Idee gekommen, grüne Wolken als angenehm zu bezeichnen, höchstens noch als reizvoll – erinnert die Kombination doch mehr an die Verbrennung von Dingen, für die ein saftiges Strafgeld fällig ist. Aber mit Cloud Computing soll IT ja „green“ werden, wird kolportiert. Was ist dran am Gedanken der grünen Wolke? Green IT durch die Cloud oder vielleicht sogar Green IT in der Cloud? Alles reizvolle Gedanken. Aber wie sieht es denn nun aus? Eine der Ideen, die hinter Cloud Computing steckt, ist es, Rechnersysteme möglichst effizient zu betreiben und dabei optimal auszunutzen. Dieses Prinzip ist seit Jahrzehnten bekannt und beliebt. Nur dass damals die Triebfeder in den hohen Kosten der Rechenressourcen lag, so dass sich das Teilen lohnte. Niemand kam dabei auf die Idee, dass ein Konkurrent etwas zu Augen bekam, das nicht für dieselben bestimmt war. Die äußeren Zwänge waren einfach so, dass sich ein „Sharing“ teurer Ressourcen nicht vermeiden ließ. Heute sind wir an einem ähnlichen Punkt. Astronomische Preise für Speicher- und Rechenressourcen sind aber längst passé. Die allermeisten Unternehmen können sich leistungsfähige Hardware leisten. Es sind vielmehr andere für den Betrieb notwendige Bestandteile, die die Kosten in die Höhe treiben. Zum Beispiel, um die gewünschte Hochverfügbarkeit, Ausfallsicherheit, Datensicherheit etc. zu realisieren. Auch steigende Energiekosten durch Kostenexplosionen bei fossilen Brennstoffen oder durch den eifrig diskutierten Ausstieg aus der Kernenergie lassen sich nicht ohne weiteres wegdiskutieren. Wie an vielen anderen Stellen beansprucht das Cloud Computing auch hier sein Claim und offeriert sich als Nothelfer für den energiekostengeplagten IT-Treibenden. Und zwar sowohl für die Anbieter- als auch für die Nutzerseite.

SymposiaJournal

02/2011

Cloud Computing Meinung

Weniger Energieverbrauch durch mehr Cloud Computing? Unabhängig davon, wo IT-Services produziert werden, benötigen diese zum einen Strom für die IT selbst, zum anderen Strom für das „Außenrum“, beispielsweise die Kühlung der Systeme. Die anfallenden Energiekosten sind bereits heute ein nicht mehr zu vernachlässigender Faktor der Gesamtkosten eines Cloud-Service. In großen ITOrganisationen kommen so jährlich zweistellige Millionenbeträge an Energiekosten zusammen. Aktuelle Schätzungen sprechen von 1 0-20 Prozent – bei steigender Tendenz. Manche Auguren sehen diesen Anteil in den nächsten Jahren bis auf 50 Prozent anwachsen. Kein Wunder wird Cloud Computing auch hiergegen zur Wunderwaffe stilisiert. Dabei ist der Stromverbrauch eines Servers nicht linear zur jeweiligen IT-Leistung. Selbst bei einer geringen Auslastung eines Serversystems, existiert ein gewisser „Energiebodensatz“, ein Minimum an Energie, ohne dass der Server nicht läuft. Das führt dazu, dass es sich nicht lohnt, ein System mit einem geringen „Wirkungsgrad“ zu betreiben. Die Lösung hierfür heißt Virtualisierung. Damit lässt sich die Gesamtauslastung für ein physikalisches Serversystem in einen Bereich mit einem interessanten Auslastungsgrad bringen – wenn genügend Arbeit da ist ;-) Die Voraussetzungen sind natürlich, dass zum einen jederzeit genügend virtuelle Systeme benötigt werden, um die physikalischen Server optimal auszulasten, zum anderen, dass Server, die aktuell nicht mehr benötigt werden, abgeschaltet werden können. Beide Voraussetzungen stellen die Betreiber heutiger Rechenzentren vor große Herausforderungen. Und durch Cloud Computing werden diese nicht kleiner.

Wenn man´s nur vorher wüsste S Ein wesentlicher Bestandteil der Cloud-Philosophie ist die Flexibilität und Dynamik beim Bezug von IT-Services. Dies impliziert gleichzeitig, dass der Provider die zukünftige Auslastung seiner Systeme nur abschätzen kann, aber eben im Vorfeld nicht genau weiß. Er muss also schon aus Sicherheitsgründen etwas großzügiger kalkulieren, um auf Eventualitäten reagieren zu können. Dazu kommt: Die dynamisch wechselnde Belegung mit (logischen) virtuellen Servern lässt „Lücken“ entstehen, die kontinuierlich aufgeräumt werden müssen – weil ja die Nutzungszeiträume der virtuellen Maschinen unterschiedlicher Größe auch unterschiedlich lang sind. Ohne konsequentes und kontinuierliches Aufräumen entsteht auch im virtuellen Universum Chaos, und bekanntlich nimmt die Entropie immer weiter zu. Die Argumentation, Virtualisierung = grün geht also nicht in jedem Fall auf. Bei einem „schlechten“, d.h. ineffizienten Management der Cloud und einer unzureichenden Ressourcenabschätzung wird man dem Ziel einer grünen IT nicht unbedingt näher kommen. Eine grüne Cloud setzt somit neben einer optimierten Kapazitätsplanung eine entsprechend ausgereifte Automatisierung voraus. Diese muss die Anzahl der 34

SymposiaJournal

Cloud Computing Meinung

02/2011

notwendigen (physikalischen) Server kontinuierlich minimieren und aktuell nicht benötigte Serversysteme abschalten. Im Bedarfsfall müssen diese in möglichst kurzer Zeit wieder in einen adäquaten Betriebsmodus gebracht werden. Dies setzt voraus, dass die vorhandene bzw. benutzte Infrastruktur einen derartigen „energetischen“ Betrieb unterstützt. Wenn diese „inneren Werte“ durch eine „energieeffiziente Verpackung“ ergänzt werden, gelangt man zu einem grünen Cloud-Rechenzentrum. Aktuell laufen unter dem Stichwort Datacenter 2020 beispielsweise entsprechende Untersuchungen für eine Optimierung der Klimatisierung. Und im Paket von inneren und äußeren Energieoptimierungsmaßnahmen gelingt den Anbietern nicht nur eine effiziente, d.h. kostengünstige und intelligente IT-Produktion, sondern darüber hinaus auch ein Stück Verantwortungsübernahme in einer Ära, die nachhaltiges Wirtschaften zur Maxime erhebt. Denn – soviel ist klar – ein Ende der ungebremsten IT-Produktion ist nicht abzusehen, allzumal Länder wie Indien bislang nur einen Bruchteil des potenziellen Nutzerpotenzials erschlossen haben. Erst sieben Prozent des Milliardenvolkes haben einen Internetanschluss.

Grüne Aspekte aus Nutzersicht Bislang haben wir den Blick auf die Anbieterseite geworfen. Aber auch die Nutzerseite kann durch Cloud Services die CO2-Produktion reduzieren. Und zwar dort, wo IT Geschäftsprozesse effizienter macht oder physikalische Dinge ersetzt (Dematerialisation). Dabei muss der Nutzer aber immer darauf achten, dass die aufgewendete Energie für die IT-Produktion und Bereitstellung nicht höher liegt als für den bisherigen Prozess. Kommunikation und Kollaboration aus der Cloud werden zunehmend ergänzt durch Lösungen für die Logistik und beispielsweise auch Smart Metering. Einsichtig ist: Über Kollaborationslösungen können Fahrt- und Flugstrecken abgelöst werden, was einer direkten Reduktion des Carbon footprint entspricht. Hintersinniger ist der Einsatz cloudbasierter Services zur Optimierung von Warenströmen. Die Maxime muss daher lauten, dass Cloud Computing Prozesse spürbar effizienter machen muss. Es muss ein zählbares Ergebnis als Einsparung von natürlichen Ressourcen verbucht werden.

Grüne IT – wer´s glaubt Auf der anderen Seite zeigt die Erfahrung, dass einfach verfügbare Dienstleistungen, die einen „Umsonst“-Charakter haben, dazu neigen, auch exzessiv genutzt zu werden. Dieser „Flatrate“-Effekt ist auch unter dem Namen Jevons’ Paradox bekannt. Sobald Technologien effizienter und damit billiger werden, greifen auch (potenzielle) Nachfrager zu, die die Leistung bislang nicht in Anspruch nahmen. Es gibt genug unbefriedigte Nachfrage, die vor dem Hintergrund einer besseren Erschwinglichkeit und Verfügbarkeit befriedigt wird.

SymposiaJournal

02/2011

Cloud Computing Meinung

Dies gilt umso mehr, da ja – auch einigen älteren Clouddefinition zufolge – IT-Ressourcen in unbegrenzter Menge zur Verfügung stehen. Somit steht und fällt der Aspekt einer grünen IT durch Cloud Computing letzten Endes mit dem vernünftigen Umgang mit ITRessourcen – trotz der geringen Kosten. Niedrige Kosten für IT-Dienste dürfen in diesem Sinne daher durchaus als Hemmschuh für eine grüne IT gesehen werden. Weitere zu berücksichtigende Effekte hinsichtlich einer ganzheitlichen Energiebilanz sind beispielweise auch die Verwaltung der notwendigen Netz-Infrastrukturen und zusätzliche Aufwände für die Sicherheit der über Netze transportierten Daten.

Fazit: nicht immer grün, aber immer öfter Fazit: Cloud Computing bietet eine Reihe von grünen Ansätzen, die bereits heute genutzt werden bzw. werden können. Jedoch automatisch ist Cloud Computing an sich nicht grün. Es gilt, das Thema ganzheitlich zu betrachten – sowohl von Anbieter- als auch von Nutzerseite. Bei den gegenwärtigen Problemen, aussagekräftige und reelle Ökobilanzen anzufertigen, kein einfaches Unterfangen.

Über Dr. Michael Pauly Dr. Michael Pauly ist promovierter Elektroingenieur und Wirtschaftsingenieur. Er arbeitet bei T-Systems als Consultant mit Fokus auf Dynamic Services und Cloud Computing. Michael Pauly agiert als einer der Sprecher für Cloud Computing von T-Systems und vertritt das Thema auf diversen Veranstaltungen und Konferenzen.

SymposiaJournal

Cloud Computing Meinung

02/2011

Standpunkt: Der Kampf um die echte Cloud von Dr. Martin Reti

Die Zeiten sind vorbei, da wir uns mit einer Kollektion von gerade mal vier Clouds zufrieden gaben. Und da wir uns damit begnügen mussten, uns darüber zu amüsieren, dass die Private Cloud gar nicht für Privatleute ist und die Institutionen des Publicbereichs gar nichts von Public Clouds halten. Geradezu inflationär steigt die Zahl der Cloud-Arten: die Logistik Cloud, die Deutsche Cloud, die Automotive Cloud, die Business Cloud, die G-Cloud, die Kasumigaseki Cloud; Clouds haben mittlwerweile auch Eigenschaften, sie sind dedicated (!), shared, blau oder grün und erst kürzlich begegnete uns eine Zuckerrüben-Cloud. Die Fülle menschlichen Erfindungsreichtums ist größer als die grenzenlosen Möglichkeiten, die die ICT bietet. Zu all diesen mehr oder weniger kuriosen Cloudformen gesellt sich nun die „echte Cloud“. Die Glaubenskrieger der unverfälschten Cloudidee haben ihr Rüstzeug angelegt und sind bereit in die Schlacht zu ziehen. Den ritterlichen Tugenden von Mut, Hilfsbereitschaft und Wahrheit sehen sie sich verpflichtet und natürlich der Sache der Cloud. Denn „es kann nur eine geben“ skandieren sie, die Public Cloud. Also zunächst mal: nichts gegen die Public Cloud! Das Phänomen Cloud Computing hat seinen Ursprung im Internet. Und Public Cloud ist auch eine gute Sache – überall dort, wo es mehr Nutzen bringt, als es Schaden anrichtet oder Folgekosten verursacht. Das muss jedes Unternehmen im Einzelfall entscheiden. Aber Public Cloud zum Nonplusultra zu erklären und gleichzeitig die Mär von der höheren Sicherheit in der Public Cloud zu pflegen, das klingt doch ein bisschen b utopisch. Unbestritten: Public Cloud ist Cloud Computing in seiner (bisherigen) Extremform, vielleicht in seiner reinsten Form. Kein Widerspruch. Und auch die Tatsache, dass niemand darüber diskutiert, was eine Public Cloud ist, während die wachsende Anzahl verschiedener Sonst-Clouds exponentiell steigt, spricht für die These. SymposiaJournal

02/2011

Cloud Computing Meinung

Aber ist eine Argumentation nicht eigenartig, die postuliert, die Public Cloud sei eine echte Cloud, weil sie demokratischer ist? Eher entspricht nämlich eine Public Cloud einer Diktatur. Der Cloud Provider entscheidet nämlich für seine Kunden, wie das einzig verbindliche Produkt aussieht. Was dem Kunden bleibt, ist die Wahlfreiheit: Nimm´s oder lass es bleiben. Basta! Die Kosten- und Effizienzvorteile einer Public Cloud ergeben sich nämlich, wie wir alle wissen, aus einem rigorosen Standardisierungsansatz. Da bleibt wenig Freiraum für individuelle Lösungen. Das hat seine Richtigkeit. Doch die Geschwindigkeit neuer Releases, ein durchgängig hohes und gleiches Managementniveau, das gelingt halt nur dann, wenn eben nicht alle mitreden, sondern wenn der Cloudprovider bestimmt – und keiner widersprechen darf. Den wirtschaftlichen Erfolg als Maßstab für eine „echte“ Cloud einzuführen und die schiere Größe, bedeutet nichts anderes als jeden kleineren Cloudanbieter zum Nicht-Cloudler abzustempeln – und zwar unabhängig davon, wie technisch ausgereift sein Angebot und sein betriebswirtschaftliches Modell ist. Die Private Cloud bleibt ein umkämpftes Feld: Den einen kann die Cloud gar nicht privat genug sein, den anderen kann sie nicht öffentlich genug sein. Selbst wenn ein Provider für jeden seiner Kunde eine eigene Cloud aufbaute, selbst dann könnte er noch Effizienzvorteile aus der kopierten Bauanleitung generieren, mal ganz abgesehen davon, dass auch das automatisierte einheitliche Management aus Sicht des Providers und des Kunden den Cloud-Industrialisierungs- und damit Kostensenkungsansatz erzielt. Und wenn womöglich mehrere Kunden die Plattform des Providers teilten – owei, das kann doch keine Cloud sein ;-) Die „echte“ Cloud zum Wert in der Businesswelt zu erheben, das hat was DonQuichotteskes. Die Kunden wissen, worauf sie sich einlassen, wenn sie in die Cloud gehen und sie treffen eine Entscheidung, die ihren Notwendigkeiten inklusive eines spezifischen Risikobewusstseins entspricht. Das Ergebnis kann dann mal zur Public mal zur Private Cloud führen oder zu einer Mischung. Allein drei Kriterien für das Vorliegen einer echten Cloud zu postulieren (für alle über Internet erreichbar, mindestens 250 Millionen Transaktionen pro Tag und selbe Leistung für alle Nutzer) scheint doch ein wenig eng gefasst. Mancher träumt ja beispielweise auch den Traum einer unbegrenzten Verfügbarkeit oder eines unproblematischen Anbieterwechsels oder der grenzenlosen Integration weiterer Cloud Services. Warum ein Unternehmen in die „echte“ Cloud gehen sollte, wo doch eine „unechte“ Cloud ein adäquates Pack an Vorteilen bringt, erschließt sich nicht unbedingt. Letzten Endes bleibt jedoch die Frage, wo denn der spezifische Mehrwert einer Cloud liegt, die „echt“ oder public ist? Will ich als Nutzer Kosten sparen, Effizienz gewinnen, Geschwindigkeit generieren oder will ich mich aus Imagegründen mit dem Etikett der Echtheit schmücken?

SymposiaJournal

Cloud Computing Meinung

02/2011

Die Diskussion um die echte Cloud erinnert ein klein wenig an den Schulhof, auf dem die eine „echte“ Markenkleidung hat und der andere nur „normale“ Kleidung. Echtheit kann ein Wert sein, insbesondere wenn es um Diamanten oder alte Meister geht, aber wenn man ehrlich ist, kommt es bei Cloud Computing auf die inneren Werte an: Welchen Nutzen bietet mir der Service? Welche Vorteile kann ich für mein Geschäft daraus generieren? Und welches Risiko bin ich bereit zu tragen? Möchte ich im Zweifelsfall dem US Patriot Act unterliegen? Die Entscheidung liegt – wie immer – beim Nutzer. Ob das Prädikat „echt“ den Ausschlag der Waagschale pro public beeinflussen mag, darf bezweifelt werden. Stichhaltiger und überzeugender wäre doch wohl eine Argumentation über die Vorteile eines Dienstes und nicht über das coole Image. Yo, Man!

Über Dr. Martin Reti Dr. Martin Reti, ein digitaler Imigrant, arbeitet im Solution Marketing von T-Systems und verfolgt das Thema Cloud Computing intensiv. Der Kommunikationsmann ist einer der Autoren des BitkomLeitfadens "Cloud Computing – Evolution in der Technik, Revolution im Business".

SymposiaJournal

02/2011

Geek and Poke

SymposiaJournal

Cloud Computing Meinung

02/2011

Cloud Computing vs. Datacenter Automation von Matthias Rechenburg

In diesem Artikel möchte ich analysieren wie Cloud Computing dazu beitragen kann Rechenzentren effizienter zu betreiben. Ich möchte speziell erläutern welche Aspekte der IT-Infrastruktur sich sinnvoll mittels öffentlichem, privatem und Hybrid Cloud Computing automatisieren lassen, gleichzeitig aber auch die Limitationen der „Wolke“ beleuchten. Bestandsanalyse – was sind Rechenzentren?

Um es kurz zu sagen: „Rechenzentren sind komplexe Monster“. Um Rechenzentren effizient zu betreiben ist es notwendig genau zu analysieren was ein „Rechenzentrum“ alles beinhaltet. Hierzu einigen einfache Fakten, die wir aus langjähriger Erfahrung im Aufbau, der Administration und Automatisierung von Rechenzentren, „gelernt“ haben.

Rechenzentren sind verschieden!

Jeder Betreiber von Rechenzentren hat verschiedenste Anforderungen, Bedürfnisse und auch (Technologie-) Vorlieben. Ein jedes Rechenzentrum wird dementsprechend geplant, aufgebaut und betrieben. Die Schlussfolgerung die sich daraus ergibt ist das alle Rechenzentren unterschiedlich sind und das es keine zwei genau gleichen Rechenzentren auf dieser Welt gibt.

Alle Rechenzentren implementieren dieselben Subsysteme

Trotz der unterschiedlichen Anforderungen der Rechenzentrumsbetreiber findet man in jedem Rechenzentrum dieselben „Subsystem“ wie z.B. Server-Deployment, NetzwerkManagement, IP-Adressen DNS Verwaltung, System- und Service-Überwachung, Backup/Restore, Virtual Machine- und Storage-Management usw. Nahezu jedes Rechenzentrum auf dieser Welt verfügt über diese Subsysteme.

SymposiaJournal

02/2011

Cloud Computing Meinung

Die Technologien, die in den Subsysteme eingesetzt werden, sind verschieden!

Alle Rechenzentren benutzen dieselben Subsystem, jedoch implementieren sie diese Subsysteme mit einer Vielzahl an unterschiedlichen Technologien. Hier ein Beispiel für das „Virtualization“ Subsystem: • der eine schwört auf Xen • der nächste bevorzugt KVM • wieder ein anderer setzt nur VMware ein • für den nächsten gibt es nur OpenVZ Dasselbe Beispiel für das „System- und Service Überwachung“ Subsystem: • der erste mag Nagios • der zweite bevorzugt Icinga • der dritte möchte lieber Zabbix • und der vierte setzt Collectd ein Die Auswahl der Technologien für ein jedes Subsystem in einem Rechenzentrum ist wiederum abhängig von den Anforderungen, Bedürfnissen und Vorlieben des Systemadministrators, der IT Infrastruktur-Designer und dem Firmen Grundsatz.

Erhöhung der Komplexität Hochverfügbarkeit

ist

umgekehrt

proportional

Ein recht einfaches Prinzip. Je komplexer ein System ist, je schwieriger ist es, es hochverfügbar zu betreiben. „KIS“ (Keep It Simple) hilft oftmals den Grad der Robustheit drastisch zu erhöhen.

Erhöhung der Komplexität ist umgekehrt proportional zu Möglichkeit der Automatisierung

Angelehnt an die vorherige Erkenntnis hier auch wieder eine simple, umgekehrt proportionale Abhängigkeit bezüglich dem Grad der Möglichen Automatisierung und der Komplexität eines Systems. Ist jeder Server in einem Rechenzentrum eine „einzigartige Spezialkonstruktion“ ist es schwierig dieses System in die gesamt AutomatisierungsStrategie der IT Infrastruktur einzupassen.

Virtuelle Maschinen laufen auf physikalischen Server Systemen

Virtuelle Maschinen erlauben Services „Hardware unabhängig“ zu betreiben. Die Abstraktion des eigentlichen Services in einer Virtuellen Maschine bringt den gewaltigen Vorteil mit sich, das der eigentliche Dienst nun eine (virtuelle Maschine) „Datei“ ist und das man diese „Datei“ dann recht einfach von einer Hardware auf die andere migrieren kann. Die „Hardware-Unabhängigkeit“ ist aber auch nur zum Teil richtig da einen Virtuelle Maschine immer ein physikalisches Host System benötigt auf dem sie betrieben wird. Die einfache Schlussfolgerung daraus ist das Virtuelle Maschinen physikalische Systeme benötigen, auf denen sie laufen. 42

SymposiaJournal

Cloud Computing Meinung

02/2011

Physikalische System gehen „kaputt“

Ähnlich wie bei „Murphy's Law“, wo wenn es schon schlimm ist noch schlimmer kommt, ist die Hauptabhängigkeit der Services die in einem Rechenzentrum betrieben werden leider nicht wirklich robust. Physikalische System gehen, ohne Ausnahme, irgendwann kaputt. Kaputt heißt z.B. Festplatten oder Lüfter fallen aus, Speicher korrumpiert, Netzwerkkarten fallen aus usw. Dies beeinträchtigt natürlich ungewollt den Betrieb der Dienste.

Gerade der Aspekt das physikalische System tendieren kaputt zu gehen ist sehr wichtig!

Eine große Bestrebung für Betreiber von Rechenzentren sollte also sein zu versuchen den „schwachen“ Teil der betriebenen Dienste, nämlich die physikalische Hardware, unabhängig zu machen von dem eigentlichen Dienst, der nur aus „Software“ besteht. Die Software selber, die den Dienst ausmacht, kann eigentlich nicht wirklich kaputt gehen, denn die Bits und Bytes der Software verändern sich normalerweise nicht eigenständig (unter der Voraussetzung das sie auf einem sicheren, hochverfügbaren Storage-System gespeichert wird).

Was ist wichtig für den End-Benutzer?

Aus der Sicht eines End-Benutzers von Services eines Rechenzentrums sieht das ganze viel einfacher aus. Für den Benutzer ist es nur wichtig das der gewünschte Service „verfügbar“ ist. Das heißt im Detail das der Hostname (oder die IP-Adresse) des Serversystems, das den Service auf einem der IP-Ports anbietet, läuft und die ServerApplikation selber auch läuft und erreichbar ist. Einfachstes Beispiel dafür ist eine simple Webseite die auf einem Server mit einem speziellen Hostnamen unter TCP/IP Port 80 zu Verfügung steht. Wie kann uns nun unter den oben angesprochenen Aspekten und Fakten Cloud Computing helfen unsere Rechenzentren effizienter zu betreiben?

Alles in die Cloud migrieren – das wird schon helfen S Manch ein Cloud Anbieter verspricht Kunden gern:

“Einfach alles in die Cloud migrieren, das löst all Ihre Probleme“. Dies ist auch zum Teil richtig da die vereinfachte und voll automatisierte Bereitstellung von vorkonfigurierten virtuellen Maschinen in bestimmten Bereichen wie z.B. in der Entwicklungs- und Qualtitätsicherungs-Abteilung, ohne großen Aufwand eingeführt werden können und dann zur Steigerung der Effizienz beitragen. Ein weiteres Beispiel sind Firmen deren Produktions-Systeme extrem schwankenden „Workload-Peaks“ ausgesetzt sind wie z.B. E-Commerce- und Shop-Systeme im Internet zur Weihnachtszeit. Gerade die Möglichkeit des Ausbalancieren solcher Services mittels zusätzlicher ServerRessourcen von öffentliche Cloud Providern während „Workload-Peaks“ bietet hohe Flexibilität und erlaubt es auch einen „Massenansturm“ von Kunden gut zu überstehen. SymposiaJournal

02/2011

Cloud Computing Meinung

Je nach Geschäftsmodell und Fokus einer Firma kann Cloud Computing so in 50 – 60% der Abteilungen sinnvoll betrieben werden. Nicht desto trotz gibt es immer ein Teil von Systemen die man, aus verschiedensten Gründen (z.B. rechtliche), nicht unbedingt in der Cloud (öffentlich oder auch private) betreiben möchte.

Und wer verwaltet und administriert die Cloud?

Ein weiterer wichtiger Aspekt ist das die „Wolke“ ein meist relativ abgeschlossener Teil der gesamten IT-Infrastruktur ist. Cloud Computing kann also nur zu einem begrenzten Teil dazu beitragen die komplette Verwaltung des Rechenzentrums zu automatisieren. Des weiteren bedarf die Cloud, als ein Teil des Rechenzentrums, natürlich auch Verwaltungs- und Administration-Aufwand d.h. faktisch befinden uns immer noch in genau demselben Bereich wie am Anfang, nämlich die Bereitstellung und der Administration von physikalischen Server Systemen, b die irgendwann kaputt gehen.

Fazit: Cloud Computing vs. Datacenter Automation

Eine Cloud, die in einem Rechenzentrum betrieben wird, ist wiederum nur ein weiterer Dienst der unter denselben Aspekten der jeweiligen Subsystem behandelt und betrieben wird z.B. Die Cloud Dienste müssen überwacht werden, Virtuelle Maschinen und speziell deren physikalische Hosts System müssen bereitgestellt und administriert werden, die Cloud Systeme müssen ins Backup/Restore Subsystem eingebracht werden, IP-Adressen sowie DNS Hostnamen müssen konfiguriert werden usw. Um genau jenen Bereich in einem Rechenzentrum zu automatisieren benötigt man eine

„Middleware“ zur kompletten Automatisierung von Rechenzentren

Für die Automatisierung von kompletten Rechenzentren ist eine übergreifende Abstraktionsschicht notwendig, die die automatisch Verwaltung aller beteiligten Subsystem eines Rechenzentrums erlaubt und deren Technologie-Schicht (unterhalb der Subsysteme) extrem modular gestaltet ist um jeglichen Technologie- Anforderungen und Bedürfnissen gerecht zu werden. Des weiteren muss diese Abstraktionsschicht („Middleware“) die Rechenzentrums-Logik implementieren, die z.B. dafür notwendig ist um einen neuen Dienst bereitzustellen. Diese Logik beschreibt den Lebens-Zyklus eines Dienstes in einem Rechenzentrum von der Initialen Konfiguration und Bereitstellung bis zur De-provisionierung. Der abgebildete Lebens-Zyklus hat zudem die Aufgabe den einzelnen Subsystem Informationen über den Dienst und dessen Status mitzuteilen, damit diese automatisiert ihre Arbeit verrichten können. Es ist dann weiterhin erforderlich, das die eigentliche Aufgabe, z.B. das starten einer Virtuellen Maschine, wiederum in den verschiedenen möglichen Technologien, mittels unterschiedlicher Module für jede Technology (Plugins), abstrahiert wird.

SymposiaJournal

Cloud Computing Meinung

02/2011

Um den größtmöglichen Grad der Automatisierung von Rechenzentren zu erreichen ist also ein Modell nötig, das möglichst viele Informationen über einen zu betreibenden Dienst in einem „Master Objekt“ konzentriert um so möglichst viele der verschieden Aufgaben und Aktionen selbständig zu übernehmen. Ein gutes Beispiel für ein solches, sehr erfolgreiches Modell ist der Fernseher.

Ein Fernseher ist ein hoch komplexes technisches System das dem End-Benutzer einen Dienst zu Verfügung stellt und „fernseh- gucken“ ermöglicht. Dieses komplexe System wird für den Benutzer mittels einer einfachen Steuerung abstrahiert, der Fernbedienung. Das Fernsehgerät selbst enthält alle Informationen wie die einzelnen Subsysteme anzusprechen sind z.B. was zu tun ist wenn der Benutzer den Kanal wechseln möchte.

Vielmehr als nur Cloud Computing ...

Eine, wie hier beschriebene „Middleware“, die den oben angesprochenen Fakten und deren Schlussfolgerungen gerecht wird, ist die Open-Source Datacenter Management und Cloud Computing Plattform openQRM. openQRM wird zur übergreifenden Automatisierung von IT-Infrastrukturen eingesetzt und bietet zusätzlich auch Funktionalitäten zum Öffentlichem, Privatem,- und auch dem Hybrid Cloud Computing. openQRM abstrahiert Dienste in einem „Appliance“ Master-Objekt das alle Informationen beinhaltet, wie ein Service zu verwalten ist z.B. Typ der Virtuellen Maschine oder welches Physikalische System, Hardware-Anforderungen, Typ und Version des Betriebssystems, Details über zu startenden Applikationen und auch Service-Level-Agreements (SLA) wie z.B. der Dienst benötigt mindestens 2 CPUs, 4GB Speicher und muss Hochverfügbar sein.

Das „Appliance Modell“ von openQRM

SymposiaJournal

02/2011

Cloud Computing Meinung

Unterhalb der Komponenten des „Appliance“ Master-Objekts sind die verschiedenen Subsystem angesiedelt, die die eigentlichen Aktionen dann mittels unterschiedlicher Plugins in den verschiedenen Technologien umsetzen und ausführen. Als eines der wenigen Lösungen, die auf der Idee von Cloud Computing basieren, bietet openQRM die Möglichkeit die komplette IT-Infrastruktur zu automatisieren und nicht nur einen Teil davon, der mit der automatisierten Bereitstellung von Virtuellen Maschinen (Cloud Computing) abgedeckt werden kann. Mit openQRM lässt sich die gesamten Aufgaben in Rechenzentren effizient automatisieren ohne sich auf bestimmte Technologien festlegen zu müssen. Da openQRM auch die automatisierte Bereitstellung von physikalische Systemen voll unterstützt kann man es sogar benutzen um, innerhalb der openQRM Cloud, „Wolken“ andere Cloud Anbieter voll automatisch seinen Benutzern zur Verfügung zu stellen. Um den „Cloud Vendor Locking“ auszuschließen stellt openQRM zudem Schnittstellen zu den bekannten Öffentlichen Cloud Anbietern wie z.B. Amazon EC2, Eucalyptus und der Ubuntu Enterprise Cloud zur Verfügung.

openQRM, much more than just a Cloud ...

Über Matthias Rechenburg Matthias Rechenburg ist Projektmanager des openQRM Projekts und Geschäftsführer der openQRM Enterprise GmbH. Stellen Sie ihm eine beliebige Frage zu den tiefsten openQRM-Interna Matthias wird sich freuen Ihnen die technisch fundierteste Antwort geben zu können. Seit vielen Jahren ist er in eine Vielzahl OpenSource-Projekte involviert, die sich mit hochverfügbaren ClusterLösungen, Serverkonsolidierung, Netzwerk- und StorageManagement beschäftigen. Sein Hauptinteresse liegt in den verschiedenen Virtualisierungs-Technologien, deren Funktionalität und deren Integration in eine generische Virtualisationsschicht für moderne Datacenter. Matthias lebt mit seiner Frau in Bonn, liebt es selbst zu entwickeln, reist gern und genießt es sich an OpenSource-Veranstaltungen und Kongressen zu beteiligen.

SymposiaJournal

Cloud Computing Meinung

02/2011

Denmark is edging closer to the cloud

by Søren Peter Nielsen and Camilla Grynnerup Fisker In the wake of the global financial crisis, the Danish public sector finds itself in a position where it needs to become more efficient and innovative to maintain its high level of service and remain competitive. Cloud computing could be the key. Danish media attention has been drawn to cloud computing for some time. Especially the benefits of scalability, flexibility, and financial savings, have branded cloud computing as the inevitable component of the future Danish IT infrastructure. Traditionally, data is located within the organisation or in the machine room by a classic operation supplier. Safeguarding data in a static location has to a certain extent been blocking evolvement of the Danish IT sector. But cloud computing is a new way of thinking IT. Instead of a static product, by cloud computing you get a service. This perception is revolutionary to the Danish IT sector and public authorities can benefit vastly from it. However, in order to fully exploit the potential of the cloud, migrating IT systems to the cloud must not be done recklessly – it should be done only if it adds value and makes sense. Representing the Danish public IT sector, the National IT and Telecom Agency (NITA), therefore, accepted the challenge and migrated one of its biggest projects, NemHandel, to the cloud.

NemHandel – a white cloud in the blue sky NemHandel is a national Danish infrastructure for exchanging of business documents (e.g. invoices and orders) in the public and private sector as well as between sectors. In the early summer of 2009 NITA decided to evaluate the central services operations in the NemHandel infrastructure. The choice was between either to invest further in the existing operations infrastructure or to reconsider the operations entirely. The latter was chosen, as cloud computing was able to fulfil the project’s three central requirements: scalability, flexibility, and financial savings. SymposiaJournal

02/2011

Cloud Computing Meinung

The figure illustrates the activity of NemHandel over a period of 24 hours and over a month, which indicates the clear advantages of scalability and flexibility by the cloud-solution

The migration of NemHandel onto the cloud became reality in June 201 0. Cloud computing facilitated a dynamic scalable infrastructure for the NemHandel production environment through a purely consumption-based price model. It also provided the opportunity of creating integrated development environments and testing environments, being clones of the production environment, but fully controlled by the development team â&#x20AC;&#x201C; and all this at a substantially lower price. The business case dealt exclusively with the operational environment. And the case showed that substantial financial savings could also be made within integrated development environments, testing environments and the staging environment. In terms of non-financial aspirations, attaining an operational environment, which effectively scales proportional to the inconsistent consumption pattern of NemHandel, was a success. Migration costs were estimated to amount to DKK 725,000, but hit a total cost of DKK 1 ,650,000. In spite of this vast budget overrun, which primarily was due to investments in production maturity, return of investment would be achieved in only 1 4 months.

The table sums up the business case as estimated before implementation versus the realised cost of the migration.

SymposiaJournal

Cloud Computing Meinung

02/2011

Denmark is ready for the challenge The NemHandel case illustrates that Denmark’s public IT sector is ready to accept the challenge and explore cloud computing in full scale. Cloud computing is indeed a new business-model to the Danish IT sector. It provides the possibility of creating an environment for innovation. Because cloud computing is cheaper and more flexible, the process from idea to reality is much shorter than before. Cloud computing allows for words being put into practice. The Danish population is very IT-ready and the infrastructure is already attuned. The opportunity for the Danish IT-industry to create a cloud-market with great export-potential, and thereby maintain its high level of service and remain competitive, definitely exists. The impending task is to seize the opportunity.

About Camilla Grynnerup Fisker Head of Section and project manager of the cloud computing initiatives at the National IT and Telecom Agency under the Ministry of Science, Technology and Innovation.

About Søren Peter Nielsen Søren Peter Nielsen is Chief Architect in the Danish National IT and Telecom Agency. He is working to get the most out of cloud, mobile, open data, social, sensors and big data. Mr. Nielsen also focus on the opportunities in the meeting of the internet and the energy sector in a Smart Grid. Earlier work for the Danish government include establishing public sector IT infrastructure solutions and international standardization initiatives.

SymposiaJournal

02/2011

Cloud Computing Science

How to tackle the top threats to cloud computing infrastructures? by Sergio Loureiro, Ph.D. and Matthias Jung, Ph.D. On the cloud infrastructures model or Infrastructure as a Service (IaaS), security administrators focus on managing virtual machines, the network and security zones. Their goal is to put controls in place regarding how virtual machines are deployed, used and terminated thus avoiding uncontrolled access and additional costs. The Cloud Security Alliance that has published the best practices to cloud computing security [1 ], has enumerated the top threats to cloud computing [2] as well: ● Threat #1 : Abuse and Nefarious Use of Cloud Computing ● Threat #2: Insecure Interfaces and APIs ● Threat #3: Malicious Insiders ● Threat #4: Shared Technology Issues ● Threat #5: Data Loss or Leakage ● Threat #6: Account or Service Hijacking ● Threat #7: Unknown Risk Profile In this article, we focus completely on what these threats mean in the IaaS model and we offer recommendations to IaaS administrators in order to tackle these threats.

Threat #1 : Abuse and Nefarious Use of Cloud Computing IaaS brought very powerful

compute power and almost unlimited storage to the reach of users. IaaS administrators need to detect abuse and nefarious use by enterprise users. For example, the presence of email botnets, rogue web servers and password cracking activities within the enterprise infrastructure.

Threat #2: Insecure Interfaces and APIs

IaaS providers publish a set of APIs for users and administrators to manage and interact with cloud services. There are several aspects to consider: the security analysis of these 50

SymposiaJournal

Cloud Computing Science

02/2011

APIs, the authentication and authorization mechanisms. Once the security processes are in place to reduce the risks of the APIs, such as renew and revocation of credentials, IaaS administrators still need to detect anomalies on the usage of these APIs.

Threat #3: Malicious Insiders

The threat of malicious insiders needs to be treated by a security process of screening and then by a strict implementation of separation of duties. IaaS administrators need to analyse the IaaS providers’ processes in place to deal with insiders, and in addition to implement the processes to deal with their own insiders. Finally, IaaS administrators need to monitor the runtime operations of insiders and specially privileged ones.

Threat #4: Shared Technology Issues

IaaS providers should seclude the shared infrastructure (in case of multi-tenancy) between customers. IaaS administrators, as suggested by the top threats document for remediation, should implement security best practices for installation/configuration and monitor environment for unauthorized changes/activity.

Threat #5: Data Loss or Leakage

Modification, deletion and transmission of sensitive data off premises should be prevented. IaaS administrators may deploy DLP products to achieve this goal although these are somewhat complex to deploy and configure.

Threat #6: Account or Service Hijacking

Account hijacking is not new, however the fact of an attacker gains access to your API credentials represents a very serious threat to IaaS customers. IaaS administrators must prohibit the sharing of credentials between users and deploy proactive monitoring to detect unauthorized activity as suggested by the top threats document.

Threat #7: Unknown Risk Profile

The unknown risk comes from the lack of transparency of IaaS providers. IaaS administrators should build and disclose logs and infrastructure details in order to increase transparency.

Runtime Solutions Threat #1 : Abuse and Nefarious Use of Cloud Computin g

During virtual machines’ runtime, IaaS administrators must use tools to monitor CPU, memory, network and disk usage in order to detect abusive usage. Doing so, cloud administrators can identify the following threats: ● An email botnet that is installed on their infrastructure by high SMTP traffic ● Rogue web server by high HTTP traffic ● Password cracking by launching of several machines with high CPU loads

SymposiaJournal

02/2011

Cloud Computing Science

Threat #2: Insecure Interfaces and APIs

IaaS providers do not usually offer a log of the API calls that allow IaaS administrators to perform further analysis. The first step is to use tools that build a log of modifications on the infrastructure and to keep it at the exterior and with integrity protection. On the other hand, APIs are critical to the infrastructure, IaaS administrators should monitor the availability and the response time of the APIs. Doing so, cloud administrators can identify the following threats: ● An API that is compromised and is being exploited to performs unwanted changes on their infrastructures. ● APIs that are not responding quickly enough and may impact the administration tools in place.

Threat #3: Malicious Insiders

IaaS administrators should use tools to do the following: ● Analyse the usage behavior of their users ● Rely on a third party service that checks and builds an independent audit trail Doing so, cloud administrators can identify the following threats: ● Identify and prove wrong behaviour by analysing an audit trail that is safely kept off premises

Threat #4: Shared Technology Issues

IaaS administrators must work with the IaaS providers to analyse the measures put in place to seclude the environments of each customer. In addition, IaaS administrators should use tools to reduce the attack surface by reducing the number of services, the number of open ports and protect sensitive information, such as credentials.

Threat #5: Data Loss or Leakage

DLP tools should be used by IaaS administrators in order to detect data loss. IaaS and virtualization brought the possibility of copying a complete virtual image very easily and on the other hand snapshots and backups must be protected.

Threat #6: Account or Service Hijacking

IaaS administrators must manage users’ credentials and implement a least privilege policy to manage access rights in order to contain the surface of attack when the credentials are compromised. IaaS administrators must deploy tools to implement a secure lifecycle of credentials and in addition they should use tools to detect abnormal behaviour on the usage patterns of their users in order to detect credentials compromise.

Threat #7: Unknown Risk Profile

The unknown risk comes from the lack of transparency of IaaS providers. IaaS administrators must put in place tools to build and analyse logs and infrastructure details in order to increase visibility and accountability. 52

SymposiaJournal

Cloud Computing Science

02/2011

Conclusion In summary, the challenges facing IaaS administrators are significant. They need tools tohelp them in their day to day battle against the top security threats to cloud computing. Full automation of the security deployment is needed to maintain the administration costs low in dynamic infrastructures. Moreover, we reviewed potential attack vectors that are specific to IaaS and need new solutions.

About Sergio Loureiro Sergio Loureiro, CEO, has worked in network security for more than 1 5 years. He has occupied top management positions in 2 startups where he was responsible for email security products and services, and security gateways. Before he was the lead architect for a number of security products such as SSL VPNs, log management, web security and SSL crypto accelerators. His career started in several research labs, where he participated in European projects focusing on security. Sergio holds a Ph.D. in computer science from the ENST Paris and MSc and BSc degrees from the University of Porto (Portugal). He is the holder of 3 patents.

About Matthias Jung CTO, has over 1 2 years of hands-on experience in the networking and communications domain. As researcher, software architect, and product manager, he contributed to such different products as Content Delivery Networks, Multicasting Protocols, WAN and HTTP Acceleration, SOA and Web-Applications. Matthias holds a Ph.D. in Information Systems from the University of Nice (France), a Master of Computer Science and Networking from E.S.S.I., Sophia Antipolis (France), and a Master of Business-ComputerScience from the University of Mannheim (Germany)

Sources [1 ] https://cloudsecurityalliance.org/guidance/csaguide.v2.1 .pdf [2] https://cloudsecurityalliance.org/research/projects/top-threats-to-cloud-computing SymposiaJournal

02/2011

Cloud Computing Science

About SecludIT SecludIT is a security SaaS company fully dedicated to cloud infrastructure security. Our vision is that only a fully automated approach to security can cope with the elastic nature of new cloud infrastructures.

About Elastic Detector Elastic Detector for Amazon EC2 is the first product that materializes the patent pending Elastic Security technology, which allows to dynamically adapt the security perimeter to changing cloud infrastructures. Elastic Detector is the first step to tackle the top threats to IaaS and automatically brings security related information to IaaS administrators, helping them to deal with the 7 threats described above, as follows: 1 . Elastic Detector builds an audit trail by logging all the virtual machines launches and terminations. Email alerts are sent for real time detection if required. This is done by using the IaaS APIs, thus no need to install, configure and update agents, and no extra-CPU load and cost is required for such monitoring. 2. Elastic Detector detects modifications on the infrastructure that can come from a malicious usage of the APIs. Additionally, Elastic detector performs continuous tests of availability and responsiveness of API endpoints, since management of the infrastructure rely completely on the APIs. 3. Elastic detector builds an audit trail that is kept outside of the premises, so making it much harder to erase the trace of malicious operations from an insider. 4. Elastic Detector helps to tighten down the number of open ports at the firewall layer, which is a best practice. 5. Elastic Detector helps security administrators to perform an initial level of detection by identifying high rates of outbound traffic on virtual machines. In the future, Elastic Detector will extend its coverage by monitoring and detection of virtual image snapshots, that is a raising threat on the context of DLP. 6. Elastic detector highlights the modifications performed on the infrastructure (running instances and firewall rules) so it helps security administrators to detect compromised accounts by showing an high rate of modifications when compared with a normal operation period. 7. Elastic detector builds an audit trail of infrastructure modifications and logs monitoring information that may be published in order to foster transparency. Website: https://elastic-detector.secludit.com 54

SymposiaJournal

Geek and Poke

SymposiaJournal

02/2011

Mobile Computing

Anwendungsgebiete der Near Field Communication von Fabien Röhlinger

Als vor gut zehn Jahren das Internet salonfähig wurde, wurde es frenetisch als der große Heilsbringer und als DIE Revolution der Businesswelt gefeiert. Plötzlich wurden die Unternehmen von gestern langweilig. Und alles, was ein “.com” im Namen hatte, war von Haus aus mit “Erfolg” gleichzusetzen. Dass viele Menschen dachten, die große Internet-Revolution sei ausgeblieben, ist hinreichend bekannt. Das Internet hat ganze Industrien hinreichend verändert

Die Nachwehen der Internet-Blase sind weniger auf das Scheitern des Internets zurückzuführen, als vielmehr auf die überzogenen Erwartungen der Menschen. Viele dachten, mit dem Internet würde über Nacht ein neues Zeitalter beginnen und aus jedem Einzelhändler, der eine Internetseite hat, gleichzeitig ein Millionär werden. Man hätte es ahnen können. Wenige Jahre vorher erhielt das Faxgerät Einzug in die Büros - und veränderte die Effizienz von Büroprozessen ebenfalls. Es wäre undenkbar gewesen, hätte man plötzlich nur noch von “Fax Companies” gesprochen, nur weil eine Firma ein solches Gerät besaß - und es auch benutzte. Eine Webseite macht ein Unternehmen natürlich noch nicht zu einem Internet-Unternehmen. Nach dem Platzen der Internet-Blase wandten sich die Unternehmen wieder ihrem Alltag zu. Und viele, sehr viele Manager hakten die privat eingefahrenen Aktienverluste als “bitteres Lehrgeld”, sowie das Abenteuer “Internet” als Lehrgeld und “wir-haben-es-jaschon-vorher-gewusst” ab. Dabei hat das Internet vielen Unternehmen die Chance geboten Wertschöpfungsketten nachhaltig zu optimieren und aus den Kostenoptimierungen Profit zu schlagen. Man kann fast jede Branche als Beispiel heranziehen, in denen neue, durch das Internet verbesserte Prozessketten die Branchenlandschaft verändert haben. Am Beispiel der Musikindustrie kann man es wohl am Besten nachverfolgen. Die großen Musikverlage haben viel zu lange an ihren bestehenden Geschäftsmodellen und Wertschöpfungen festgehalten, im festen Glauben, sie könnten so ihre Umsätze schützen. Dabei haben sie übersehen, dass das Internet nicht die Preise kaputt macht, sondern komplett neue, schnellere und bessere 56

SymposiaJournal

Mobile Computing

02/2011

Vertriebswege entstehen lässt. Steve Jobs hat dies schon sehr früh erkannt. Heute beherrscht er mit Apple die Musikverlage - und nicht mehr umgekehrt.

Smartphones und das “mobile Internet” werden diese Entwicklung noch beschleunigen - und radikalisieren

Einhergehend mit dem immer weiter verbreiteten „mobilen Internet“ in Form von Smartphones, die ja heutzutage fast immer “on“ sind, tun sich natürlich auch neue innovative Technologien in Bezug auf „mobile computing“ auf. Man kann jetzt schon mit Smartphones am Flughafen „boarden“, Barcodes einscannen, um den günstigsten Preis zu einem Produkt finden oder mit einem Klick bei Ebay und Amazon einkaufen. Im Klartext bedeutet das, dass sich die Prozesskette weiter deutlich verkürzen wird. Musste man vor einigen Jahren - oder vielmehr: vor Kurzem - noch mit Dingen, die man online verrichten wollte, warten, bis man wieder vor einem Rechner mit Internetzugang sitzt, kann man heute schon von (fast) überall direkt online gehen. Die Folgen dürften, zumindest mittelfristig, deutlich gravierender sein als beim ersten Internetboom. Das mobile Internet, bzw. Smartphones, haben gerade im Bereich “Navigationssysteme” gezeigt, dass man hier sehr schnell über neue Geschäftsmodelle nachdenken sollte. Seit Smartphones mit Google Maps immer erfolgreicher werden, und damit teure Navigationssysteme zunehmend obsolet machen, hat sich der Börsenwert der führenden Hersteller drastisch reduziert. Dieser Prozess dürfte sehr bald auch auf andere Branchen übergreifen. Einzelhändler fühlen sich durch ihre Kunden bedroht, die direkt im Laden via Smartphone Preise vergleichen, gleichzeitig erschließt die Spieleindustrie neue Chancen und Geschäftsfelder mit Online- bzw. Cloud Gaming. Es stehen also auf verschiedenen Ebenen große Veränderungen an. Mit Smartphones haben Menschen das Internet und den Computer immer in der Tasche. Das verkürzt Prozesse und schmälert Prozesskosten. Die Frage ist nun, ob Unternehmen die Chancen, aber auch die Risiken frühzeitig erkennen und Innovationen aus den neuen Technologien schaffen können. Mit NFC ist eine solche Technologie “im Kommen”, die viel Platz für Innovationen bietet. Und es sieht ganz so aus, als würden nicht nur einige “große Fische” diese Chance nutzen wollen. Dies verwundert aber auch nicht, wenn man einen genaueren Blick auf “Near Field Communication” und die damit verbundenen Möglichkeiten wirft. Um das ganze Thema NFC könnte tatsächlich ein ähnlicher Hype enstehen, wie es heute schon bei den Apps im Smartphonebereich der Fall ist.

NFC - das Tüpfelchen auf dem bekannten “i”

Schaut man sich NFC und das, was diese Technologie bietet, genauer an, wirken manche durchaus sehr nützliche und aktuelle “Features” fast steinzeitlich. NFC könnte das „mobile Computing“ auf eine ganz neue Stufe heben, das „mobile Internet“ inklusive. Wer sich bisher nur oberflächlich mit NFC auseinandergesetzt hat, mag der Technologie nicht mehr als die Vereinfachung der bargeldlosen Zahlung zutrauen. Hier lohnt sich ein Blick über den Tellerrand. Denn NFC bietet mehr. SymposiaJournal

02/2011

Mobile Computing

Was genau ist NFC?

NFC (Near Field Communication) ist ein Übertragungsstandard zum kontaktlosen Austausch von Daten. Diese Form der Datenkommunikation funktioniert nur über kurze Strecken. Erste Entwürfe dieser Technik wurden 2002 von Sony und NXP Semiconductors präsentiert. Man könnte also sagen, NFC ist schon „ein alter Hut“. Jedoch scheint jetzt erst die Zeit für diese Technologie reif zu sein, bzw. reif zu werden, denn bis sich diese Technik durchsetzen wird, dürfte immer noch einige Zeit vergehen. Wenn man sich diese Technologie, und was verschiedene Hardwarehersteller und Internetunternehmen mit ihr vorhaben und entwickeln, anschaut, wirft man eventuell einen Blick auf die nächste größere Evolutionsstufe in Bezug auf Mobile Computing. Der große Vorteil von NFC gegenüber anderen Technologien zum Datenaustausch, zum Beispiel Bluetooth oder RFID, ist die Tatsache, dass ein schneller Verbindungsaufbau von Peer-to-Peer-Netzwerken möglich ist. RFID-Chips finden sich beispielsweise in Lebensmitteln, Büchern, aber auch sogenannten Magnetkarten, wie man sie in Hotelzimmern nutzt. Um möglichst kompatibel mit aktueller RFID-Technologie zu sein, bietet NFC mehrere Arten der Kommunikation. In einem dieser „Modi“ (Card Emulation Mode) verhält sich das Smartphone beispielsweise als passive RFID Karte, mit entsprechender Software kann das Gerät dann unter anderem als Hotelzimmer-Schlüssel genutzt werden. So muss man keine extra Karte mit sich herumtragen, der Zimmerschlüssel ist dank NFC “immer am Mann”. Von der technischen Seite her muss also nicht zwangsläufig auch eine komplett neue Infrastruktur erschaffen werden - bei manchen Einsatzzwecken ist dies allerdings schon nötig -,auf RFID basierende Systeme könnten auch mit NFC genutzt werden.

Anwendungsgebiete Auch wenn NFC momentan in erster Linie durch die Tatsache auf sich aufmerksam macht, dass Googles neues Bezahlsystem „Wallet“ – vorerst nur für die USA angekündigt – sich der NFC-Technik bedient, sind die Möglichkeiten, die Near Field Communication bietet, um einiges vielfältiger. Ein interessantes Szenario ist beispielsweise die Möglichkeit mit einem NFC fähigen Smartphone, wie oben schon beschrieben, Hoteltüren zu öffnen, aber auch andere Zugangssysteme zu nutzen. Das Handy konnte also mit NFC-Chip, außer als Zimmerschlüssel, beispielsweise auch als Autoschlüssel herhalten. In diesem Zusammenhang wäre es weiterhin möglich, per NFC Voreinstellungen bezüglich der Sitzund Spiegelpositionen innerhalb eines Automobils automatisch anwenden lassen zu können. Eine zwar einfachere Möglichkeit, die jedoch auch sehr nützlich sein kann, ist ganz simpel Informationen über NFC zu empfangen. Dazu muss das entsprechende Gerät einfach in der Nähe eines NFC-Tags hinterlegt werden. Diese Informationen können alles mögliche sein – ein Link, der dann im Webbrowser aufgerufen wird oder Fahrpläne am Bahnhof, die auf das mobile Gerät übertragen werden um dann dort aufgerufen werden zu können. Dies alles geschieht in Sekundenschnelle, kein mühseliges Koppeln zwischen zwei Geräten wie z.B. bei Bluetooth ist von Nöten. So könnten auch Fahrscheine zukünftig 58

SymposiaJournal

Mobile Computing

02/2011

dank NFC durch einfaches Berühren eines entsprechenden Terminals mit dem NFCfähigen Geräte gekauft werden. Auf diese Art und Weise wäre es auch möglich am Flughafen einzuchecken, oder aber auch Hotels und Mietwägen zu buchen. Aber auch in Bezug auf Remote Computing könnte man NFC theoretisch nutzen. So machen im Internet Gerüchte die Runde, Apple würde daran arbeiten, NFC einzusetzen, um beispielsweise ein iPhone gewisse Rechte an einen Mac übertragen zu lassen. Auf diese Art und Weise wäre es dann möglich, ein Programm auf einem fremden Rechner so zu nutzen, wie man es gewohnt ist. Nach dem Abbrechen der Verbindung – spätestens wenn man sich mit dem iPhone von dem Rechner weit genug entfernt – würde das Programm dann auf dem fremden Mac wieder gelöscht. NFC wird auch in Bereichen Einzug erhalten, in denen man die neue Technologie heute noch gar nicht vermuten mag. So arbeitet ein Team der TU Berlin an einer Lösung (Werbe)Flyer direkt per NFC zu verteilen - eine Idee, die vielleicht auf den ersten Blick abwegig klingen mag (“will ich wirklich Werbung auf meinem Telefon?”) - bei längerer Betrachtung aber durchaus interessant erscheint. Würde sich ein solches Modell durchsetzen, hätte das weitreichende Veränderungen für die Papier- und Druckereibetriebe.

Die Infrastruktur

Auch wenn es möglich ist schon vorhandene Technologie (z.B. wie schon erwähnt RFID) zu nutzen, muss die nötige flächendeckende Infrastruktur für NFC und das, was diese Technologie uns zukünftig bieten kann, erst noch geschaffen werden. So hat aber beispielsweise Nokia schon 2007 ein Modell (das Nokia 61 31 ) mit NFC ausgerüstet, mittlerweile weitere Geräte aus dem Sortiment, will aber auch nach und nach alle kommenden Smartphone Modelle mit dieser Technologie bestücken. Weiterhin setzen Google (Bezahlsystem „Wallet“) und Samsung bei ihren Android Geräten immer mehr auf NFC (Samsung auch beim eigenen Betriebssystem Bada), aber auch Apple will sein iPhone zukünftig NFC-fähig machen. Hierbei steht allerdings noch nicht fest, ob das schon beim nächsten iPhone, oder erst in späteren Generationen der Fall sein wird.

Ausblick Die Chancen stehen gut, dass NFC zukünftig - auch wenn dies noch einige Jahre dauern mag - in jedem “mobile device”, wie heute beispielsweise Bluetooth, zu finden sein wird. Wo es heute noch eine tolle Sache ist, auf dem Smartphone nach einer Zugverbindung zu schauen, könnten wir mit einem NFC-fähigen Gerät zukünftig am Bahnhof die Fahrkarte lösen, bei der Kontrolle durch den Schaffner die gültige Fahrkarte durch kurze Berührung mit dem entsprechenden Gerät entwerten lassen, die Speisekarte des Bordrestaurants durch das Auflegen des Handys auf eine entsprechende Stelle auf dem Tisch auf das Smartphone laden, von dort aus über das Internet eine Bestellung aufgeben und dann natürlich wieder per NFC bezahlen. Leider werden wir erst einmal neidisch in die USA schielen, wo Google noch dieses Jahr “Wallet” einführen wird. Ob Googles neues Bezahlsystem ein Erfolg wird, könnte auch ein Indikator dafür sein, ob sich NFC dann auch wirklich immer weiter verbreiten und zu einer SymposiaJournal

02/2011

Mobile Computing

Technik werden wird, die uns viele Bereiche des täglichen Lebens erleichtert. Mit Google, Apple, Samsung, aber auch dem Handyhersteller Nokia, der zwar die letzten Innovationen verpasst hat, aber vielleicht auch wieder Anschluss finden wird, gibt es einige große “Fürsprecher” hinter NFC. In Bezug auf “Google Wallet” könnte man auch noch Mastercard und die Citigroup erwähnen, die in den USA die ersten großen Partner für das neue Bezahlsystem sind. Allerdings ist dieses ja nur eine Möglichkeit, die NFC zu bieten hat. Es wird Zeit, dass sich alle Branchen mit diesem Thema auseinandersetzen. Die Chancen und Risiken sind groß. Unternehmen sollten sowohl die Auswirkungen, als auch die Geschwindigkeit, in der ganze Branchen von tief einschneidenden Änderungen stehen, nicht unterschätzen. Peter Chou, CEO von HTC, glaubt, dass wir bis 201 5 weltweit rund 500 Millionen NFC-fähige Handys haben werden. Es ist nur eine Frage der Zeit, dass die ersten Geschäftsmodelle auf den Markt kommen, die alles verändern - mal wieder!

Über Fabien Röhlinger Fabien Röhlinger ist Gründer und Blogger von AndroidPIT. Die Webseite hat sich in den vergangenen zweieinhalb Jahren zu einer der wichtigsten Datenbanken für Android Apps weltweit entwickelt und wird jeden Monat von vielen hunderttausend Lesern besucht. Fabien absolvierte nach seinem Abitur eine Ausbildung zum Eurokaufmann. Sein BWLStudium an der Universität Regensburg brach er nach dem dritten Semester ab, um sich seiner Laufbahn als Unternehmer zu widmen. Seit dieser Zeit hat Fabien mehrere Unternehmen im Internet- und Telekommunikationsbereich gegründet.

SymposiaJournal

Editorial

02/2011

Impressum

Symposia 360° GbR Schützenstr. 11 21 266 Jesteburg Tel.: 041 83 / 94 89 40 Fax: 041 83 / 77 39 30 E-Mail: verlag@symposia360.com Internet: http://www.symposia360.com

Fabien Röhlinger, Dr. Matthias Jung, Dr. Sergio Loureiro, Søren Peter Nielsen, Camilla Grynnerup Fisker, Matthias Rechenburg, Dr. Martin Reti, Dr. Michael Pauly, Björn Böttcher, René Büst, Holger Sirtl

Anzeigenleitung

Björn Böttcher & René Büst

Dipl.-Ing. Björn Böttcher E-Mail: bjoern@symposia360.com Dipl.-Informatiker (FH) René Büst E-Mail: rene@symposia360.com

Photos AWS User Group HH

Herausgeber & Verlag

Redaktion Björn Böttcher, René Büst

Autoren dieser Ausgabe

Cover & Design

Symposia 360° GbR

Karikaturen Oliver Widder Internet: http://geekandpoke.typepad.com

Symposia Journal 03/2011 erscheint am 1 2.09.2011 Redaktionsschluss: 29.08.2011 Anzeigenschluss: 05.09.2011

SymposiaJournal