Kategorien
News

Moodle Plugin ermöglicht Zugriff auf Dokumente in Microsoft SkyDrive

Microsoft erweitert stetig die Integration seiner Anwendungen mit seinem Cloud Storage Service SkyDrive. Allerdings wurden vor längerer Zeit die SkyDrive APIs geöffnet, was Entwickler dazu motivieren sollte SkyDrive für sich zu entdecken. Moodle ist das jüngste Projekt, was auf diesen Zug aufgesprungen ist. Seit der Version Moodle 2.3 können Nutzer nun direkt auf Dokumente in Microsoft SkyDrive zugreifen.

Moodle Plugin ermöglicht Zugriff auf Dokumente in Microsoft SkyDrive

Moodle und SkyDrive

Bei Moodle handelt es sich um ein Open Source Kursmanagementsystem sowie eine Lernplattform und wird bevorzugt von Bildungseinrichtungen eingesetzt. Moodlestellt online „Kursräume“ zur Verfügung. In diesen werden Arbeitsmaterialien und Lernaktivitäten bereitgestellt. Jeder Kurs kann so konfiguriert werden, dass nur angemeldete Teilnehmer diesen besuchen können, Gäste zugelassen sind oder zur Teilnahme ein Passwort erforderlich ist.

Das Plugin für die Integration von Moodle mit SkyDrive wurde vom Moodle Entwickler Dan Poltawski veröffentlicht und ermöglicht den Zugriff von Moodle auf Dokumente die in Microsoft SkyDrive abgelegt wurden. Voraussetzung dafür ist die Moodle Version 2.3.

Moodle und Cloud Storage Services

Moodle 2 unterstützt die Verbindung zu vielen Datei Repositories und Cloud Storage Services, darunter Dropbox, Box.net, Google Docs. Mit dem neuen Plugin kann nun auch auf die Daten aus dem eigenen Microsoft SkyDrive Account zugegriffen werden.

Das Plugin wurde ursprünglich von dem Telekommunikationsanbieter LUNS als Client für die Universidad Teconológica de Chile (INACAP) entwickelt und als Open Source veröffentlicht. Dan Poltawski führte die Entwicklung des Plugins fort und stellte es für Moodle 2.3 bereit.

Kategorien
News

Collide: Google präsentiert Collaborative Cloud IDE

Google präsentiert unter dem Namen „Collide“ eine neue Cloud basierte Collaborative IDE, mit der gemeinsam, verteilt und ortsunabhängig an Java Quellcode entwickelt werden kann. Das schreibt (noch) Google Software Engineer Scott Blum auf seinem Google+ Account.

Collide: Google präsentiert Collaborative Cloud IDE

Hintergrund

Scott kündigt in dem Beitrag seinen Abschied von Google an, da Google die Entwicklungsabteilung in Atlanta auflöst. Eines der Projekte an dem Scott beteiligt war, wurde parallel mit der Schließung des Google Büros in Atlanta ebenfalls beendet. Allerdings werden Teile von diesem Projekt nun in ein neues Open Source Projekt überführt.

Das Projekt hat den Namen „Collide“ (collaborative IDE). Dabei handelt es sich um ein Web-basierter Code-Editor, mit dem gemeinsam an Software-Projekten gearbeitet werden kann und richtet sich an Java Entwickler.

Voraussetzungen

  • Java 7
  • Ant 1.8.4+
  • Alle weiteren Abhängigkeiten sind im Projekt hinterlegt

Screencast

Peter Cooper von CooperPress hat dazu bereits einen kurzen Screencast veröffentlicht, der zeigt, wie man collide konfiguriert und die ersten Schritte macht.

httpv://www.youtube.com/watch?v=8Gq12bLbm54

Kategorien
Analysen

Der Amazon Web Services (AWS) Ausfall: Letzte Chance – So etwas darf nicht noch einmal passieren!

Nach dem letzten Ausfall der Amazon Web Services (AWS) am 29.06/30.06 habe ich – zurecht – die schlechte Systemarchitektur von Instagram kritisiert. Man sollte niemals alle seine Eier in ein Nest legen. Allerdings habe ich mir noch einmal in Ruhe die Fehler innerhalb der Amazon Cloud während des Ausfalls angeschaut. Amazon muss unbedingt seine Hausaufgaben erledigen, es geht hier schließlich um knallhartes Business und die Kunden zählen auf die Verfügbarkeit der Cloud Infastruktur.

Der Geduldsfaden wird immer dünner

Eines ist klar und das predige ich in jeder Situation. Amazon bzw. jeder IaaS Anbieter stellt „nur“ die nötigen Infrastrukturressourcen in Form von virtuellen Instanzen inkl. Konfigurationstools bereit, um damit sein eigenes virtuelles Rechenzentrum aufzubauen. Die Verfügbarkeit des auf der Cloud betriebenen Systems muss selbst sichergestellt werden. Aber wie, wenn das „Werkzeug“ dafür nicht funktioniert?

David Linthicum schreibt, dass er in der Nähe der Cloud Rechenzentren an der Ost Küste der USA wohnt. Und er bestätigt, dass die Gewitter wirklich sehr stark gewesen sind und die Stromversorgung und das Mobilfunknetz flächendecken lahmgelegt haben. Er schreibt zudem, dass solche Unwetter in dieser Region nicht ungewöhnlich sind und die meisten Cloud Anbieter keine Probleme damit hatten.

Komplexität kann man nicht beherrschen

Amazon ist mit Abstand Marktführer im Cloud Infrastruktur Markt und dieser Ausfall zeigt deutlich, wie schwierig es für Cloud Computing Anbieter (uneingeschränkt) ist, diese massiven Systeme zu betreiben und robust gegen Fehler auszulegen. Immerhin besteht alleine die Amazon Cloud in der Region US-EAST, nach eigenen Angaben, aus 10 Rechenzentren, die in vier Availability Zones aufgeteilt ist.

Die Probleme im Detail

Es handelte sich mal wieder um eine Kaskade von unerwarteten Fehlern, die zu diesem langen Ausfall führten. So konnte in einem Rechenzentrum die Notstromversorgung nicht aktiviert werden. Die USVs konnte die Systeme nicht lange genug mit Strom versorgen, wodurch diese in der Region heruntergefahren werden mussten. Dadurch standen keine virtuellen Instanzen mehr zur Verfügung. Was die Situation jedoch verschlimmerte, waren Probleme mit den Konfigurationstools, Software mit denen Kunden die Ressourcen innerhalb der Region erstellen, verschieben und anpassen können. Dadurch waren die Kunden nicht in der Lage auf den Ausfall zu reagieren.

Engpass

Ein weiteres Problem war ein Engpass während des Bootvorgangs der Amazon Server. Das führte dazu, dass es länger dauerte als erwartet, um wichtige AWS Services wie EC2 und EBS wieder hochzufahren. Das sorgte für ein Folgeproblem, als EBS wieder online war, da hier technische Eingriffe notwendig waren, um sicherzustellen, dass alle auf EBS gespeicherten Daten weiterhin vorhanden sind. Laut Amazon hat es mehrere Stunden benötigt, um diesen Fehler zu beheben.

Ein unbekanntes Problem

Das aber vielleicht schwerwiegendste Problem bestand in einem unvorhergesehen Fehler im Elastic Load Balancer (ELB), der dafür zuständig ist, den Traffic zu den Servern mit ausreichend Kapazität zu leiten. Als EC2 plötzlich nicht mehr verfügbar war, versuchte der ELB weiterhin Workloads auf die Server zu verteilen. Als die Amazon Cloud dann neu gestartet wurde, fuhren ebenfalls eine große Anzahl an ELBs in einem Status hoch der zu einem Fehler führte, den Amazon zuvor noch nicht gesehen hatte. Dieser überflutete die Amazon Cloud mit Anfragen, was wiederum zu einer Verzögerung führte. Dieser Fehler, in Kombination mit einer großen Anzahl neuer Server, die in von dem Ausfall nicht betroffenen Availability Zones durch Kunden ausgerollt wurden, erzeugte weitere Anfragen, die in der Summe die Fehlerbehebung verzögerte.

Gewitter + Viele eigene Fehler

Zwar war die eigentliche Ursache für den Ausfall der Amazon Cloud ein Gewitter. Die Wahrheit ist jedoch, dass sich die Cloud Infrastruktur durch eigene versteckte Fehler wieder selbst außer Gefecht gesetzt hat.

Kunden verlieren Daten

Neben Anbietern wie Instagram, Pinterest und Heroku waren ebenfalls Foursquare, Quran, Moby und Reddit von dem Ausfall betroffen. Dabei sollen mehrere große EC2 Kunden wertvolle Daten verloren haben. Darunter Chartbeat, die von einem Verlust von 11 Stunden an historischen Datenmaterial sprechen. Diese seien laut dem Unternehmen nicht wiederherstellbar.

Alternativen evaluieren

Ich habe mich bisher immer schützend vor die Amazon Web Services gestellt, da sie wirklich einen sehr guten Job machen und für das Cloud Computing stehen. Allerdings muss ich gestehen, dass ich langsam ein wenig irritiert bin was die Vorsichtsmaßnahmen gegenüber „unvorhersagbare“ Ereignisse wie Gewitter und Stromausfälle sind. Das erneut die Notstromversorgung nicht funktioniert, die schlussendlich zu dem Ausfall geführt hat, ist doch sehr merkwürdig und muss hinterfragt werden. Zumal es sich dabei schon um das zweite Mal handelt, wo „ein Schalter“ defekt war. Bis vor einer Woche habe ich meine Hand dafür ins Feuer gelegt, dass Amazon regelmäßig Fail-Over Szenarien durchführt, um sicherzustellen, dass Stromausfälle oder Unwetter routinemäßig „abgearbeitet“ werden und „ein Schalter“ im richtigen Moment mal nicht klemmt. Wo gerade der Strom doch als das analoge Paradebeispiel für das Pay-as-you-go Modell des Cloud Computing steht. Mittlerweile muss ich meine Hand – für die Amazon Web Services – für diesen Fall leider erst einmal zurückziehen.

Die Amazon Web Services haben dem Cloud Computing mit dieser Ausfallserie zwar nicht stark geschadet, aber erneut Diskussionen ausgelöst, die vor Monaten Ad acta gelegt wurden. Es kann einfach nicht sein, dass ein Stromausfall solche Probleme verursacht und schon gar nicht ein zweites Mal.

Es ist daher an der Zeit seine Eier nicht mehr nur in eine Availability Zone oder Region zu legen, sondern sich ebenfalls Gedanken über Alternativen und andere Clouds zu machen, um das eigene Risiko zu minimieren. Ein gutes Beispiel ist die Web TV Agentur Schnee von Morgen von Nikolai Longolius. Das Unternehmen setzt primär auf die Amazon Web Services und hat parallel eine Version für die Google App Engine entwickelt. Risikomanagement halt!

Ich sehe hier für Amazon allerdings noch ein zweites Problem. Nachdem sich das Unternehmen anfangs verstärkt auf die Startups dieser Welt konzentriert hat und weiterhin konzentrieren wird, versuchen sie auch vehement in den Bereich für etablierte Unternehmen einzusteigen. In einem Markt, wo sich bereits erfahrene Anbieter wie HP, IBM und Microsoft tummeln, die Wissen wie man auf die Bedürfnisse von großen Kunden eingeht. Diese Ausfälle werden es Amazon erschweren, Argumente für den Weg in die AWS Cloud zu finden.


Bildquelle: http://thearmadagroup.com

Kategorien
News

Microsoft Dynamics CRM wächst mit der Cloud. Microsoft Dynamics NAV 2013 kommt im Herbst.

Unter dem Namen Dynamics vertreibt Microsoft seine CRM (Customer Relationship Management) und ERP (Enterprise Resource Planning) Lösungen. Was on-Premise trotz großem Mitbewerb aus Deutschland (SAP) und den USA (Siebel, Salesforce) erfolgreich funktioniert, wird bzw. soll auch in Kürze aus der Cloud kommen. Im Gespräch erzählte mir Jochen Wießler, Director Microsoft Business Solution, wie Dynamics CRM Online auf Grund der Cloud wächst und gedeiht und wann wir mit Microsoft Dynamics NAV 2013 rechnen dürfen.

Microsoft Dynamics CRM wächst mit der Cloud. Microsoft Dynamics NAV 2013 kommt im Herbst.

Microsoft Dynamics CRM Online

Mit Microsoft Dynamics CRM Online liefert Microsoft seine bekannte CRM-Lösung seit Januar 2011 als Cloud Service aus. Damit kann auf alle Kundendaten zu jederzeit und von jedem beliebigen Ort aus darauf zugegriffen werden. Darüber hinaus erfolgt die Abrechnung nach dem Pay per use Modell und bietet ein fest vereinbartes Service Level Agreement (SLA).

Wachstum durch die Cloud

Zielmarkt von Dynamics CRM sind kleine- und mittelständische Unternehmen. Dabei hatte Microsoft das Problem, dass den Kunden zunächst gar nicht bewusst war, dass sie Dynamics CRM ebenfalls als Cloud Lösung erhalten können. Sie fragten in erster Linie nach der on-Premise Variante. Bei Microsoft gilt seit der Einführung von Dynamics CRM Online im Jahr 2011 jedoch „Online first!“ und das scheint sich zu bewähren. Die Cloud Lösung hat bei den Kunden mittlerweile eine hohe Akzeptanz erreicht, wodurch Microsoft 30% mehr Kunden für Dynamics CRM gewinnen konnte. Dabei setzen 60% aller Neukunden auf die Cloud Lösung.

Auch die Integration mit bereits bestehenden Microsoft Cloud Produkten wie Office 365 stehe oben auf der Prioritätenliste und sei ein integraler Bestandteil der Microsoft Cloud Strategie im Bereich Business Solutions.

Deutschland mein Datenschutz

Dem Thema Cloud und Datenschutz steht Microsoft täglich gegenübergestellt. So fragt jeder 2te Kunde nach Compliance- und Datenschutzanforderungen und ob diese erfüllt werden. Insbesondere in Deutschland sei dieses ein sehr brisantes Thema. Um die ersten Fragen zu klären und Grundlagenwissen zu vermitteln hat Microsoft mit seinem Trust Center eine Plattform geschaffen, um den Kunden die Bereiche Datenschutz und Cloud näher zu bringen. Zudem erfüllt Microsoft seit Mitte Juni ebenfalls die EU Standardvertragsklauseln.

Allerdings sei der Datenschutz nur ein Thema während der Gespräche mit Kunden und niemals die Hauptanforderungen, die ein Kunde stellt. Viel wichtiger seien die Performance und die Funktionalität, welche die Akzeptanz und Entscheidung für Cloud Lösungen wie Dynamics CRM Online liefern. Allerdings sei die Bandbreite generell noch ein Problem.

Microsoft Dynamics NAV 2013

Microsoft ERP Lösung Dynamics NAV wurde speziell für mittelständische Firmen mit branchenspezifischen Anforderungen entwickelt. Dabei wurde besonders auf die Bedienung geachtet, weshalb die Benutzeroberfläche stark an Microsoft Outlook angelehnt wurde. Eine offene Architektur soll für eine schnelle Anpassung und Implementierung neuer Funktionen sorgen. Ein Partnernetzwerk von durch Microsoft zertifizierte Unternehmen liefern zudem weitere Zusatz- und Branchenlösungen.

Auf in die Cloud im Herbst 2012

Derzeit steht Dynamics NAV nur als on-Premise Lösung zur Verfügung. Aber das wird sich ändern. Unter dem Namen Microsoft Dynamics NAV 2013 erwartet Microsoft, die ERP Lösung im Herbst 2012 als Cloud Lösung veröffentlichen zu können.

Ob die Implementierungen als reine Cloud Lösungen umgesetzt werden, kann zu diesem Zeitpunkt noch nicht genau gesagt werden. Wahrscheinlich wird es sich vermehrt um hybride Szenarien handeln. Das liegt u.a. an den unterschiedlichen Gesetzgebungen in den verschiedenen Ländern weltweit. Dabei könnten die länderspezifischen Themen als on-Premise Lösung bereit gestellt werden und die allgemeinen, nicht kritischen Themen, direkt aus der Microsoft Cloud kommen.

Da jede ERP Software immer sehr individuell gestrickt ist, erwartet Microsoft zudem, dass es spezielle „Standard“ ERP-Konfigurationen aus der Cloud geben wird, die dann noch granularer von Partnern angepasst werden können. Ein Beispiel wäre ein Maschinenbauer, der sich auf die Entwicklung und Herstellung von Getränkeautomaten spezialisiert hat. Hier wäre es dann die Aufgabe des Microsoft Partners eine „Standard Konfiguration“ zu liefern und diese kostengünstig anzupassen.

Kategorien
Analysen

Amazon Web Services (AWS) Ausfall: Erklärungen | Erster Kunde geht | Netflix hält die Treue | Okta versteht die Cloud-Architektur

Nach dem erneuten Ausfall von Teilen der Amazon Web Services (AWS) am vergangenen Freitag und Samstag, von denen große Webseiten und Services wie Netflix und Instagram betroffen waren, gab es in dieser Woche neben einer Stellungnahme von Amazon, ebenfalls Reaktionen von Kunden, die zeigen, dass der Geduldsfaden langsam reißt. Allerdings sind auch selbstkritische Töne zu hören.

Amazon erläutert das Problem

Während einer Stellungnahme am Montag erklärte Amazon, dass seine Rechenzentren an der Ostküste der USA von einem Gewitter am Freitag (29.06.12) betroffen waren. Während die Notstromversorgung bei den meisten wie erwartet funktionierte, kam es bei einem einzigen erneut zu einer Fehlfunktion bei der redundanten Stromversorgung. Der daraus resultierte Stromausfall beeinflusste „eine einstellige Prozentzahl an Kunden“. Darunter Instagram, Netflix, Pinterest, Quora, Heroku und Hootsuite.

Erster Kunde verlässt die Amazon Cloud

Wie die InformationWeek berichtet, hat mit Whatsyourprice.com, einem Online Dating Service, der erste AWS Kunde die Konsequenzen aus dem Ausfall am 29.06/ 30.06 gezogen und seine 10 virtuellen Server in eine Co-Location in Las Vegas umgezogen. Neben dem kürzlichen Ausfall war Whatsyourprice.com bereits vom zwei Stündigen Ausfall am 14.06.12 betroffen. Hinzu kam, dass der letzte Ausfall gerade zu einer Zeit eintrat, während nach Angaben des Unternehmens typischerweise viele Singles online sind.

Laut Whatsyourprice.com basierte die Systemarchitektur auf zwei Availability Zones. Dennoch war das Unternehmen nicht in der Lage neue Instanzen in der nicht von dem Ausfall betroffenen Availability Zone zu starten. Whatsyourprice.com kann sich diesen Umstand nicht erklären, da sie ihrer Meinung nach alles richtig gemacht haben und werden auf Grund dieser Situation nicht mehr auf Amazon EC2 setzen.

Netflix hält die Treue

Netflix, die auch von dem Ausfall betroffen waren, werden der Amazon Cloud hingegen nicht den Rücken kehren. Wie das Unternehmen auf seinem Blog schreibt, hat der Ausfall ein paar Schwächen in seiner Architektur aufgezeigt, die ebenfalls den Chaos Monkey überlistet haben. So habe die eigene Load-Balancing Architektur das gesamte Problem während des Ausfalls noch verstärkt.

Dennoch wird Netflix weiterhin auf die (Amazon) Cloud setzen, da der Service seit dem Wechsel in die Cloud eine bessere Uptime hat als zuvor. Zudem sei die eigene Architektur so ausgelegt, dass ein Ausfall von AWS davon nicht beeinflusst wird. Dafür achtet Netflix darauf, die Services weltweit zu verteilen. Während des Ausfalls in der Region US-EAST, konnten europäische Kunden den Services trotzdem nutzen. Darüber hinaus setzt Netflix auf Cassandra, einem Distributed Cloud Storage, der über alle AWS Zonen und Regionen verteilt ist. Cassandra sorgt dafür, dass der Verlust von einem Drittel aller Nodes innerhalb einer Region aufgefangen wird, ohne Daten zu verlieren oder die Verfügbarkeit zu beeinflussen.

Bitte: Nicht den Fehler von Instagram machen

Netflix selbstkritische Analyse sollte sich auch Instagram oder besser Facebook zu Herzen nehmen. Mich wundert, warum die schlechte Systemarchitektur von Instagram während der Due-Diligence-Prüfung durch Facebook bei der 1,5 Milliarden Dollar hohen Übernahme nicht aufgefallen ist.

Okta, ein Cloud basierter Identity Management Service, setzt ebenfalls auf die Cloud Infrastruktur der Amazon Web Services und war für seine Kunden weltweit zu 100% verfügbar. Das schreibt Okta VP Eric Berg auf dem Unternehmensblog. Demnach sei die Systemarchitektur so konzipiert, dass einzelne Komponenten ohne Weiteres zu jeder Zeit ausfallen können. In diesem Fall werden die Anfrage zu einem funktionsfähigen System „irgendwo auf der Welt“ weitergeleitet. An dieser Stelle sehen wir wieder einmal, dass Cloud Computing nicht bedeutet, einfach nur einen virtuellen Server hochzufahren!


Bildquelle: http://apod.nasa.gov

Kategorien
News

Rapidshare Cloud Storage: Seriosität vs. Preis vs. Performance

Rapidshare, bekannter Anbieter für Onlinespeicherplatz, auf dem bevorzugt Warez und Schmuddelfilmchen illegal gespeichert werden, versucht über eine Cloud Storage Lösung den Weg in die Seriosität. Mit RapidDrive wird das Unternehmen aus der Schweiz gegen Ende des Jahres für RapidPro Nutzer einen Client veröffentlichen, mit dem Rapidshare in die Betriebssysteme Windows 7, Windows Vista und Windows XP eingebunden werden kann.

Rapidshare Cloud Storage: Seriosität vs. Preis vs. Performance

Der Preis: Unschlagbar

Betrachtet man lediglich die Kosten, ist die Entscheidung relativ einfach. Ein RapidPro Account mit einer Laufzeit von 2 Jahren kostet 99,90 EUR, das entspricht 4,11 EUR pro Monat. Dafür bekommt man unbegrenzten Speicherplatz, Traffic usw. Das ist im Vergleich zum aktuellen Markt ein absoluter Spitzenwert.

RapidDrive ist langsam und bietet keine Synchronisation

Nach eigenen Angaben soll die Performance von RapidDrive sehr schwach sein. Das hängt damit zusammen, da sich die Dateien, anders als bei Cloud Storage Services wie Dropbox oder SkyDrive, nur im RapidShare Storage befinden. Es existiert keine lokale Kopie der Datei. Somit muss die Datei erst vollständig heruntergeladen werden, bevor diese geöffnet werden kann. Auch eine Synchronisation, die ein Echtzeit-Backup ermöglicht, wird von RapidDrive nicht unterstützt.

Vertrauen steht an erster Stelle

Insbesondere die Probleme um MegaUpload, bei der auch RapidShare in den Fokus geraten ist, lassen Zweifel aufkommen, ob man, selbst seine vielleicht völlig unwichtigen Daten, dort speichern möchte. Natürlich kann jeder Anbieter wie Dropbox oder Box ins Visier der Staatsanwälte geraten. Jedoch haben sich die bisherigen Cloud Storage Anbieter noch nichts zu Schulden kommen lassen. Anders als die klassischen Filehoster, allen voran RapidShare.

Lieber auf seriöse Anbieter wie Dropbox, Box, SkyDrive, TeamDrive, CloudSafe usw. setzen.

Wer dennoch Interesse hat, muss noch bis September warten. Dann soll RapidDrive für alle Nutzer mit RapidPro-Accounts zur Verfügung stehen. Zudem sind Versionen für andere Betriebssysteme ebenfalls in Planung.

Kategorien
Kommentar

Zurück in die Cloud: Terminals und Mainframes bekommen ihr Update 2.0

Seitdem die ersten Cloud Lösungen auf dem Markt erschienen sind, hat sich bis heute vieles weiterentwickelt. Viele Anbieter versorgen uns mittlerweile täglich mit neuen Services. Auch Unternehmen, die traditionell nicht aus dem Cloud Computing Umfeld kommen, konzentrieren ihre Geschäftsmodelle verstärkt auf Lösungen aus der Cloud und bauen ihre Angebote darauf auf. Ebenso verhält es sich mit der Art wie wir in Zukunft bzw. bereits arbeiten oder im privaten Umfeld mit neuen mobilen Technologien umgehen. Wo die älteren Semester vereinzelnd bestimmt noch mit Terminals und Mainframes gearbeitet haben, wird die jüngere Generation diese Technologien nur aus dem Museum kennen. Aber aufgepasst wir erleben eine Revolution. Es geht nämlich „Zurück in die Cloud“.

Terminals und Mainframes für die Masse

Blicken wir auf die Vergangenheit zurück, hatte immer nur eine ausgewählte Gruppe an Unternehmen und Menschen Zugriff auf Rechenleistung usw., die durch Mainframes bereitgestellt und auf die per Terminals zugegriffen wurde. Dabei handelte es sich zum einen um große Unternehmen, zum anderen um Universitäten und Forschungseinrichtungen. Allerdings musste die Nutzung der Mainframes teuer bezahlt werden, denn Rechenleistung war Luxus.

Seit 2006 ist Rechenleistung und der Zugriff auf Speicherplatz, Anwendungen und IT-Ressourcen im Allgemeinen für die breite Masse zugänglich. Selbst wenn die Zielgruppe anfangs eher klein war, gehörte diese nicht mehr zu einer Gruppe von Auserwählten. Jeder der möchte darf heute auch – wenn er dazu in der Lage ist und das zu moderaten Preisen.

Terminals 2.0

Nicht zuletzt durch die Chromebooks und Chromebox von Google erleben die Terminals eine Revolution. Mit Googles ChromeOS verschwindet das lokale Betriebssystem und wandert in Googles Cloud, von wo sämtliche Anwendungen und Daten bereitgestellt werden. Das Chromebook bzw. die Chromebox sind lediglich nur noch ein Stück „dumme“ Hardware mit einem Monitor sowie einer Tastatur/ Maus. Das Betriebssystem selbst wird über die Cloud geliefert. Schlussendlich ist Googles Chromebook Ansatz eine Weiterentwicklung der Terminal Services, die in den 90ern und z.T. bis heute noch gerne in Unternehmen eingesetzt werden, um den Mitarbeitern eine vollständige und vorkonfigurierte Arbeitsumgebung schnell bereitzustellen. Allerdings beschränkte sich dieses Konzept bisher nur auf das eigene Unternehmensnetz. Google geht einen Schritt weiter und macht die Terminals zu 100% mobil. Möglich machen es die heutzutage mobilen Datenverbindungen und WLAN Netze.

Neben Google gibt es natürlich weitere Anbieter, die Cloud Desktops bzw. Desktop-as-a-Service Lösungen anbieten, um darüber komplette Arbeitsumgebungen aus einer Cloud bereitzustellen.

Aber auch ohne Chromebooks oder explizite Cloud Desktops/ Desktop-as-a-Service Angebote sind wir nicht mehr auf unser lokales Betriebssystem angewiesen. Heutzutage reicht ein Browser, um Anwendungen (Software-as-a-Service, SaaS) zu nutzen, Daten zu speichern oder darauf zuzugreifen.

Mainframes 2.0

Die Amazon Web Services (AWS) wiederum haben die Mainframes revolutioniert. Was noch vor ein paar Jahren unvorstellbar war ist nun Wirklichkeit. Kreditkarte raus und her mit der Rechenleistung (Infrastructure-as-a-Service, IaaS). So einfach ist es wirklich. Bei der Umsetzung sollte man jedoch behutsam vorgehen.

Neben Rechenleistung können mittlerweile natürlich viele weitere Services über die Cloud genutzt werden. Speicherplatz, Geschäftsprozesse, Anwendungslogik bis hin zu ganzen Anwendungen (Platform-as-a-Service, PaaS) lassen sich in die Cloud auslagern. Neben Amazon gibt es mit Microsoft Windows Azure, Rackspace oder Google natürlich noch viele weitere Cloud Anbieter.

Was viele zudem nicht wissen. Jeder nutzt heute in irgendeiner Form die Cloud bzw. Cloud Anwendungen. So setzen beliebte Angebote wie Pinterest, SoundCloud, Instagram oder mobile Apps auf Cloud Infrastrukturen, um damit auf mögliche Besucheranstürme vorbereitet zu sein, bzw. hohe Investitionskosten in IT-Infrastruktur zu vermeiden.

Zurück in die Cloud

Die technologische Entwicklung die uns das Cloud Computing beschert, zeigt einen Trend der Informationstechnologie hin zu dem Motto „back to the roots“ oder viel besser „back to the cloud“. Wie ich Eingangs beschrieben habe, wurde in den Anfängen der „vernetzten“ Informationstechnologie die IT-Infrastruktur um einen Mainframe aufgebaut an dem Terminals angeschlossen waren. Terminals zeichneten sich dadurch aus, dass diese über lediglich einen Monitor und Eingabegeräte verfügten – aber über keinen lokalen Speicher oder eine nennenswerte Intelligenz. Diesem alten Ansatz steht im Grunde der einzige Unterschied gegenüber, dass der Mainframe i.d.R. im eigenen Rechenzentrum stand, da Bandbreiten mit heutigen Maßstäben nicht vergleichbar bzw. nicht finanzierbar waren. Mit der Revolution durch das Cloud Computing und den schnellen und allgemein stabilen Datenverbindungen kann die Hardware als auch Software heute überall stehen.


Bildquelle: http://bengene.blogspot.de

Kategorien
Analysen

Der Ausfall der Amazon Web Services (AWS) zeigt die schlechte Systemarchitektur von Instagram

Auf Grund eines erneuten Ausfalls der Amazon Web Services (AWS) vom 29.06.12 bis 30.06.12 hatten viele Services, darunter populäre Seiten wie Pinterest, Netflix, Instagram und Heroku mit Problemen zu kämpfen. Wohingegen auf Netflix und Pinterest, zumindest hier aus Europa, zugegriffen werden konnte, war Instagram vollständig down. Auf Twitter begann währenddessen eine Wut-Welle gegen die Amazon Web Services, weil das geliebte Instagram nicht genutzt werden konnte. Von Cloud Computing und Marketing Bullshit war die Rede. Was die Nutzer natürlich nicht wissen konnten, es war die schlechte Systemarchitektur von Instagram selbst, die dafür gesorgt hat, dass der Bilderservice nicht erreichbar war.

Schwere Stürme führten zu dem Ausfall

Grund für den Stromausfall waren laut dem Stromversorger Dominion Virginia Power schwere Stürme mit 80 Meilen pro Stunde, die zu massiven Schäden geführt haben. Dominion Virginia Power versorgt mehrere Rechenzentren in der Region Virginia. In­fol­ge­des­sen viel die Stromversorgung für das Amazon Rechenzentrum aus, was erneut zu einer Kaskade von Problemen innerhalb der einzelnen Services der Amazon Cloud führte.

A line of severe storms packing winds of up to 80 mph has caused extensive damage and power outages in Virginia. Dominion Virginia Power crews are assessing damages and will be restoring power where safe to do so. We appreciate your patience during this restoration process. Additional details will be provided as they become available.

Zahlreiche Amazon Services betroffen

Der Ausfall betraf dieses Mal deutlich mehr Services, als noch bei dem Ausfall vor zwei Wochen. Darunter Amazon CloudSearch, Amazon CloudWatch, Amazon Elastic Compute Cloud, Amazon Elastic MapReduce, Amazon ElastiCache, Amazon Relational Database Service und AWS Elastic Beanstalk.

Instagram nutzt nur eine Region

Von dem Ausfall war nur die Availability Zone US-EAST-1 betroffen, die sich in North Virginia befindet. Alle anderen weltweit verteilten Amazon Regionen zeigten keine Fehler und liefen weiterhin stabil. Anders als von dem Ausfall betroffene Anbieter wie Netflix oder Pinterest, war Instagram weltweit überhaupt nicht erreichbar. Das führt eindeutig zu dem Ergebnis, dass Instagram seine Systeme ausschließlich in dieser einen Amazon Region, der US-EAST-1, laufen lässt. Die Entscheider und Systemarchitekten müssen sich daher die Frage gefallen lassen, warum ein mittlerweile so populärer Dienst, der für 1 Milliarde US-Dollar an Facebook verkauft wurde, nicht hochverfügbar ausgelegt ist, indem die Systeme über mehrere Regionen bzw. Availability Zones in der Amazon Cloud verteilt sind. Scheinbar hat Instagram aus den Fehlern anderer Amazon Kunden nicht gelernt, die von den bisherigen Ausfällen betroffen waren.

Für den Fehlerfall vorbereitet sein

Selbstverständlich darf man Amazon von diesem erneuten Ausfall auf keinen Fall freisprechen. Die Region US-EAST-1 in North Virginia scheint zum Problemkind zu werden. Dennoch weißt Amazon regelmäßig und vehement darauf hin: „Design for failure!“

Hierfür hat das Unternehmen eine Webseite geschaffen, auf der Whitepapers zum Download bereitstehen, die dabei helfen, fehlertolerante Anwendungen zu entwickeln und Cloud Architekturen zu verstehen. Dazu gehören u.a. die Folgenden.

AWS Cloud Architecture Best Practices Whitepaper

Dieses Whitepaper gibt einen technischen Überblick aller AWS Services und verschiedener Best Practice Ansätze für die architektonische Gestaltung, um damit effiziente und skalierbare Architekturen zu entwerfen.
Link

Building Fault-Tolerant Applications on AWS Whitepaper

In diesem Whitepaper werden Funktionen für die Erhöhung der Fehlertoleranz vorgestellt, die dazu dienen, um hoch zuverlässige und hochverfügbare Anwendungen innerhalb der AWS Cloud zu entwickeln.
Link

Web Hosting Best Practices Whitepaper

Dieses Whitepaper überprüft detailliert Lösungen für das Web Application Hosting. Dazu gehört unter anderem, wie jeder AWS Service genutzt werden kann, um eine hochverfügbare und skalierbare Webanwendung zu entwerfen.
Link

Leveraging Different Storage Options in the AWS Cloud Whitepaper

Dieses Whitepaper dient dazu, einen Überblick über die Speichermöglichkeiten in der AWS Cloud zu geben und darüber hinaus Szenarien vorzustellen, um eine effektive Nutzung zu erzielen.
Link

AWS Security Best Practices Whitepaper

In diesem Whitepaper werden bestimmte Tools, Funktionen und Richtlinien beschrieben, um zu verstehen, wie Cloud Anwendungen innerhalb der AWS Infrastruktur von Grund auf geschützt werden können.
Link

Netflix und sein Chaos Monkey

Ein Grund warum Netflix ein so robustes und hochverfügbares System auf der Amazon Cloud betreibt, ist der selbst entwickelte und sogenannte Chaos Monkey. Der Chaos Monkey hilft Netflix dabei sicherzustellen, dass alle einzelnen Komponenten unabhängig voneinander arbeiten. Dazu zerstört der Chaos Monkey wahllos Instanzen und Services innerhalb der Netflix AWS Infrastruktur, um seinen Entwicklern dabei zu helfen, zu gewährleisten, dass jede einzelne Komponente antwortet, auch wenn die System-Abhängigkeiten nicht einwandfrei funktionieren.

Kategorien
News

Amazon Web Services (AWS) erneut mit Ausfall. Wieder ein Stromausfall. Wieder in North Virginia. Schwere Stürme sind die Ursache.

Es scheint sich langsam zu einer never ending story zu entwicklen. Die Amazon Web Services (AWS) haben erneut mit einem Ausfall in der Region US-EAST-1 in North Virginia zu kämpfen. Dabei handelt es sich, wie erst kürzlich, um einen Stromausfall. Dieses Mal auf Grund schwerer Stürme.

Schwere Stürme sind für den Ausfall verantwortlich

Grund für den Stromausfall sind laut dem Stromversorger Dominion Virginia Power schwere Stürme mit 80 Meilen pro Stunde, welche die Netzteile zerstört haben die zu massiven Schäden geführt haben. Dominion Virginia Power versorgt mehrere Rechenzentren in der Region Virginia.

A line of severe storms packing winds of up to 80 mph has caused extensive damage and power outages in Virginia. Dominion Virginia Power crews are assessing damages and will be restoring power where safe to do so. We appreciate your patience during this restoration process. Additional details will be provided as they become available.

Viele Amazon Services betroffen

Von dem Ausfall sind dieses Mal deutlich mehr Services betroffen, als noch bei dem Ausfall vor zwei Wochen. Darunter Amazon CloudSearch, Amazon CloudWatch, Amazon Elastic Compute Cloud, Amazon Elastic MapReduce, Amazon ElastiCache, Amazon Relational Database Service und AWS Elastic Beanstalk.

Hier das Protokoll des Ausfalls.

Amazon CloudSearch (N. Virginia)

10:16 PM PDT We are investigating elevated error rates impacting a limited number customers. The high error rates appear related to a recent loss of power in a single US-EAST-1 Availability Zone. We are working to recover the impacted search domains and reduce the error rates which they are experiencing.

Amazon CloudWatch (N. Virginia)

8:48 PM PDT CloudWatch metrics for EC2, ELB, RDS, and EBS are delayed due to lost power due to electrical storms in the area. CloudWatch alarms set on delayed metrics may transition into INSUFFICIENT DATA state. Please see EC2 status for the latest information.
10:19 PM PDT CloudWatch metrics and alarms are now operating normally.

Amazon Elastic Compute Cloud (N. Virginia)

8:21 PM PDT We are investigating connectivity issues for a number of instances in the US-EAST-1 Region.
8:31 PM PDT We are investigating elevated errors rates for APIs in the US-EAST-1 (Northern Virginia) region, as well as connectivity issues to instances in a single availability zone.
8:40 PM PDT We can confirm that a large number of instances in a single Availability Zone have lost power due to electrical storms in the area. We are actively working to restore power.
8:49 PM PDT Power has been restored to the impacted Availability Zone and we are working to bring impacted instances and volumes back online.
9:20 PM PDT We are continuing to work to bring the instances and volumes back online. In addition, EC2 and EBS APIs are currently experiencing elevated error rates.
9:54 PM PDT EC2 and EBS APIs are once again operating normally. We are continuing to recover impacted instances and volumes.
10:36 PM PDT We continue to bring impacted instances and volumes back online. As a result of the power outage, some EBS volumes may have inconsistent data. As we bring volumes back online, any affected volumes will have their status in the „Status Checks“ column in the Volume list in the AWS console listed as „Impaired.“ If your instances or volumes are not available, please login to the AWS Management Console and perform the following steps: 1) Navigate to your EBS volumes. If your volume was affected and has been brought back online, the „Status Checks“ column in the Volume list in the console will be listed as „Impaired.“ 2) You can use the console to re-enable IO by clicking on „Enable Volume IO“ in the volume detail section. 3) We recommend you verify the consistency of your data by using a tool such as fsck or chkdsk. 4) If your instance is unresponsive, depending on your operating system, resuming IO may return the instance to service. 5) If your instance still remains unresponsive after resuming IO, we recommend you reboot the instance from within the Management Console. More information is available at: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html

Amazon ElastiCache (N. Virginia)

8:43 PM PDT This service is currently affected by a power event. Please see the EC2 status for further information.
9:25 PM PDT We can confirm that a large number of cache clusters are impaired. We are actively working on recovering them.
10:21 PM PDT We are continuing to recover impacted Cache Nodes. Our APIs are operating normally.

Amazon Relational Database Service (N. Virginia)

8:33 PM PDT We are investigating connectivity issues for a number of RDS Database Instances in the US-EAST-1 region.
9:24 PM PDT We can confirm that a large number of RDS instances are impaired. We are actively working on recovering them.
10:43 PM PDT RDS APIs are operating normally. We are continuing to recover impacted RDS instances and volumes.

AWS Elastic Beanstalk (N. Virginia)

9:00 PM PDT This service is currently affected by a power event. Please see the EC2 status for further information.

Erneut bekannte Webseiten und Services betroffen

Der Ausfall hat mit Instagram, Pinterest und Netflix wieder viele bekannte Webseiten und Services betroffen. Ebenfalls der PaaS Anbieter Heroku, der viele Startups und mobile Anwendungen zu seinen Kunden zählt ist betroffen. Wohingegen Pinterest und Netflix erreichbar sind, ist Instagram vollständig down. Erst am 14. Juni 2012 gab es in North Virginia einen Stromausfall im Amazon Rechenzentrum.

Kategorien
News

Jury Mitglied: Cloud Computing World Series Awards

René Büst war Jurymitglied der 2012er Cloud Computing World Series Awards.