Technology Evangelist Developer
Research Engineer Strategist
Trainer
Platform Architect
{Mobile, Cloud & Grid}

Amazon.com ist eine riesige Shopping-Anwendung mit hunderten von Webservices, welche nur eine funktionierende Anwendung für den Benutzer darstellen, wenn die einzelnen Webdienste auch miteinander kommunizieren können. Eine skalierbare Webanwendung muss lose gekoppelt sein, damit die Skalierung in beide Richtungen auch funktioniert. Der wichtigste Webdienst, den Amazon.com selbst am meisten nutzt, ist und bleibt Amazon SQS, der Amazon Simple Queue Service. 

Mit SQS bietet bietet Amazon einen Warteschlangen-Kommunikationsdienst an, der es Anwendungen ermöglicht asynchron miteinander zu kommunizieren. Nachrichten können eine maximale Größe von  64 KB in einem beliebigen Textformat besitzen. Diese werden zur Warteschlange hinzugefügt. Jede Warteschlage wird über mehrere Datenzentren verteilt repliziert. Eine Nachricht kann in einer Warteschlange 14 Tage lang verweilen und wird erst dann entfernt. Manuell kann und sollte die Nachricht natürlich nach der erfolgreichen Bearbeitung gelöscht werden. Nachrichten können zu einer Warteschlange gleichzeitig gesendet und gelesen werden. 
Nachrichten werden via HTTP gesendet und die Zustellung erfolgt über eine “At least one” Semantik an mindestens einen Empfänger. Die Nachrichten selbst werden über Polling empfangen. Da die Daten asynchron repliziert werden, ist es möglich, dass ein Empfänger nicht alle Nachrichten bekommt die an eine Warteschlange gesendet werden. Ferner ist es möglich, dass die Nachrichten in einer anderen Reihenfolge ankommen oder mehr als einmal zugestellt werden. Daher muss die Logik der Warteschlange sowohl idempotent als auch unabhängig von der Nachrichtenreihenfolge. Sobald eine Nachricht von einem Empfänger angenommen worden ist, wird die Nachricht für einen kleinen Zeitraum versteckt, damit andere Empfänger diese nicht sehen können. Der Empfänger kann die Nachricht dann verarbeiten und sie im Anschluss von der Warteschlange endgültig entfernen. Wenn das Entfernen jedoch nicht innerhalb der versteckten Nachrichtenzeitspanne erfolgen sollte, so wird die Nachricht für alle wieder sichtbar und wird dann von dem nächsten Empfänger angenommen. Der Dienst ist skalierter bis zu Millionen von Nachrichten pro Tag und realisiert eine FIFO (First In - First Out) Warteschlange. Was ist mit dem Asynchronen Nachrichten Pattern gemeint? Betrachten wir zunächst die zwei Prozesse A und B. Diese sind per se natürlich in irgendeiner Weise miteinander verflochten, wenn der Prozess B nur starten kann, wenn er von Prozess A einen Input bekommt. Dies würde jedoch zur Folge haben, dass weder Prozess A noch Prozess B entsprechend skalieren können, da beide zueinander in Abhängigkeit stehen. Die Prozesse kann man entkoppeln, wenn man eine Warteschlange hinzufügt. 
ABB. 1: ENTKOPPELUNG VON PROZESSEN DURCH ASYNCHRONEN NACHRICHTENAUSTAUSCH.
Ein weiterer Vorteil, den ich dadurch erreiche ist, dass die Skalierung der Prozesse gleich mitgeliefert wird. Ich habe die Möglichkeit nun einen starken und damit rechenintensiven und zeitintensiven Prozess B einfach auf mehrere Maschinen in der Cloud zu verteilen. Prozess B bekommt nun die Daten aus der Warteschlange, damit gilt dies für einen weiteren Prozess ebenfalls. So kann ich nach Bedarf und Last n Maschinen hinzufügen und meinen Nutzern einen entsprechende Performance anbieten.  Wenn ich hingegen einen rechenintensiven Prozess A haben, dann kann auch in diesem Szenario ein weiterer Prozess hinzugefügt werden, da der Prozess nun nicht mehr direkt mit dem Prozess B kommuniziert, sondern die Daten an die Warteschlange sendet. Und wie weitere oben bereits erwähnt, kann Amazon SQS diese Nachrichten parallel in die Warteschlange schreiben und lesen.  Es besteht auch die Möglichkeit die Daten verteilt in zwei oder mehr Warteschlangen zu liefern. Die Folgeprozesse B können dann aus unterschiedlichen Warteschlangen bedient werden. Man könnte z.B. ebenso leicht eine weitere Warteschlange hinzufügen für fehlgeschlagenen Bearbeitungen von Nachrichten.
ABB. 2: DURCH ENTKOPPELUNG ENTSTANDENE SKALIERUNGSMÖGLICHKEITEN VON PROZESSEN

Bei all den Vorteilen gibt es natürlich auch immer ein paar Stolpersteine. Bei Amazon SQS handelt es sich um einen verteilten Warteschlangen-Dienst. Dies bedeutet der Dienst ist auch auf verschiedenen Servern in der Cloud verteilt. Damit ist die Reihenfolge einer Nachricht in der Warteschlange nicht immer beibehalten. Wie oben erwähnt handelt es sich um eine FIFO-Warteschlange, jedoch gibt es durch die Verteiltheit keine Garantien. Eine weitere unschöne Eigenschaft ist, dass die Nachrichten öfter als einmal aus der Warteschlange geliefert werden können. Eine mögliche Lösung wäre an dieser Stelle den Bearbeitungsstatus in einer Datenbank zu speichern. 

Über keine der aktuellen Programmiersprachen ist in der letzten Zeit soviel gesprochen worden, wie über Node.js. Aber warum ist dies der Fall? Dieser Artikel versucht eine Einordnung, einen Überblick und einen Ausblick zu geben.

Die Grundlagen 

Prinzipiell ist es für Programmierer einfach eine neue Programmiersprache zu erlernen, wenn man bereits eine Sprache zur Gänze durchdrungen hat. Professoren nutzen gerne auch eine Aussage, wie “Gute Programmierer können in jeder Sprache programmieren, denn wenn man einmal weiß, wie man programmieren muss, dann ist der Rest nur eine Frage der Syntax”. Bei Node.js ist die Sachlage sogar noch ein wenig komfortabler, da viele Web Programmierer bereits mit Javascript vertraut sind und in den letzen Jahren kaum andere Programmiersprachen nutzen mussten, da die Frameworks und Erweiterungen der Sprache dies nicht notwendig machten. Dies ist ein Grund, warum gerade der Sprung für viele Programmierer von Javascript zu Node.js relativ leicht ist. Die Hürde sich mit einer neuen Syntax beschäftigen zu müssen entfällt nahezu. 

Wir halten fest: +1 für Node.js

Ein Blick auf Node.js 

In letzer Zeit wurden so einige Blogeinträge über Node.js verfasst. Darum soll dieser Abschnitt nur einen nitty-gritty-Überblick geben. Tiefergehendere Artikel und Blogs finden Sie in den Quellenangaben zu diesem Artikel. Node.js basiert auf der Googles V8 Javascript Engine und ermöglicht das Schreiben von server-seitigen, event-basierte und asynchrone Anwendungen mit Hilfe von Javascript. Die V8 Engine von Google wurde in C++, Javascript und Assembler verfasst, welches die Performance der Engine Rechnung trägt. Der in Javascript verfasste Code wird vor der Ausführung in nativen Maschinencode übersetzt. Weitere Feinheiten, wie Inline Caching erhöhen noch die Performance. Man kann also sagen, dass die Geschwindigkeit des Grundgerüsts von Node.js Vorfreude bereitet. 

Eines der erklärten Ziele von Node.js ist es eine Sprache zu komponieren, die das einfache erstellen von skalierbaren netzwerkfähigen Programmen ermöglicht. Dies sind gleich mehrere harte Herausforderungen für eine Programmiersprache. Ein netzwerkfähiges Programm zu erstellen ist per se nicht schwierig und auch in der ein oder anderen Programmiersprache recht einfach und effizient. Und eine einfach zu erlernende Sprache zum Lösen von netzwerkorientierten Problemen auf Serverseite ist sicherlich für jeden Web Programmierer ein Zugewinn. Diesen Anspruch kann und wird Node.js sicherlich erfüllen. 

Doch wie sieht es mit der so wichtigen Skalierung aus? 

Kampf der Nebenläufigkeit

Betrachten wir zunächst ein einfaches Beispiel aus dem Alltag. Stellen wir uns einmal vor, wir möchten einen kleinen Imbiss in einem Fastfood Restaurant zu uns nehmen. Dazu begeben wir uns zunächst i das präferierte Restaurant und stellen und in die Warteschlange. Wie lang diese ist, ist sicherlich je nach Tageszeit und bedingt durch andere Einflüsse, wie etwa Urlaubszeiten unterschiedlich. 

Die Thread-basierte Methode das Restaurant zu betreiben würde bedeuten, dass ein Kunde aus der Warteschlange (FIFO) bedient wird, sobald er an die Theke vorgerückt ist, also die notwendigen System-Ressourcen einmal zugewiesen bekommen hat. Je nach Implementierung des Kunden ( :-) ) kann dieser Vorgang nun wenige Sekunden dauern, oder auch Minuten. Solange jedoch der Kunde die Ressourcen besitzt, gibt er diese auch nicht mehr ab. Das würde zu einem starken Anwachsen der Warteschlange führen, wenn man nicht entsprechende Maßnahmen ergreift. Dies würde bedeuten, dass ich einen weiteren Verkäufer (Thread) hinzufügen müsste, um meine Blockierung etwas zu entschlacken und die Warteschlange möglichst klein zu halten. Dies bedeutet jedoch in unserem Beispiel eine starke finanzielle Aufwendung, die auch nicht an die Dynamik der Anfragen gekoppelt ist und uns somit eine prinzipielles Problem aufwirft. Dies ist besonders deutlich, wenn der Ansturm an Kunden besonders gering ist. Es gibt sicherlich viele Möglichkeiten dieses Problem mit Thread-basierten Lösungsansätzen in den Griff zu bekommen und eine möglichst effiziente, Ressourcen schonende und skalierbare Implementierung zu Implementieren.

In der asynchronen und ereignisbasierten Welt würde der Kunde in das Restaurant gehen, sich in die Warteschlange einreihen. Beim Zuteilen der Ressourcen bekäme der Kunde jedoch eine Liste mit den zu erledigenden Dinge, wie z.B. eine Speisekarte und optionalen Features; wie Verzehr vor Ort oder Auswärts, Ketchup, Mayonnaise, Extra Käse - die üblichen zeitfressenden Fragen bei einer Bestellung. Der Kunde würde daraufhin die Warteschlange verlassen und sich erst wieder einreihen, wenn er eine Bestellung ohne Rückfragen des Kellners abgeben kann. Persönliche Bemerkung an dieser Stelle: Ich versuche dies seit Jahren in die Realität umzusetzen. Es funktioniert jedoch nur, wenn die Prozesse des Unternehmens, bei dem ich eine Bestellung aufgebe wohl definiert sind, die Mitarbeiter bestens geschult sind und ich die Speisekarte und die Features selbst bestens kenne. Denn dann ist es in der Tat möglich den Bestellvorgang auf eine Guten Tag-Ihre Bestellung bitte-Das macht dann-Auf Wiedersehen-Zyklus zu begrenzen, der wenige Sekunden dauert. Dies ist jedoch nicht immer möglich. Doch zurück zu unserer asynchronen Welt. Der Kunde (Prozess) würde also wieder zurück an die Theke kommen, wenn er meint alle Anfragen an die Bedienung korrekt stellen zu können. Wir gehen in diesem vereinfachten Modell von einem sauber implementieren System auf Seiten des Restaurants aus. Wenn der Kunde die Anfrage nicht korrekt formuliert, dann muss er sich wieder zurückziehen und es später erneut versuchen. Dies wiederholt sich, bis der Bestellvorgang abgeschlossen ist. 

Doch wie sieht es in diesem Fall mit der Skalierbarkeit aus? Sicherlich kann man auch in diesem Fall eine weitere Bedingung im Falle eines zu starken Anwachsens der Warteschlange hinzufügen. Jedoch ist es nicht so komfortable, wie die Thread-basierte Lösung. Vorteile dieser asynchronen und nicht blockierenden Methode gibt es viele, einer ist zum Beispiel, dass die Bedienungen nicht durch einen Kunden blockiert werden. 

Welcher der beiden Ansätze ist nun jedoch der bessere? Nun darüber streiten sich die Fachlektüren rauf und runter und dies nicht erst seit gestern. Aus der Prozesstheorie für Arbeitsabläufe in Firmen könnte man zum Beispiel anführen, dass es wesentlich effizienter ist, wenn sich ein Mitarbeiter zu 100% auf eine Tätigkeit konzentriert und diese ohne Störung und Unterbrechung abarbeitet. In der Realität, könnte man aber gegenargumentieren, kommt es aber zu Unterbrechungen, wie ein Telefonanruf. Schön wäre es doch alle Vorteile beider Welten zu kombinieren und einzusetzen. Doch genau da sind wir an der Schwachstelle von Node.js angekommen. Momentan ist das Ziel nur die asynchrone und nichtblockierende Implementierung voranzutreiben. Damit hat man keinerlei Möglichkeit mehr auf Änderungen in dem Workload, der Anwendung oder der Performance durch einen Wechsel oder eine Vermischung von beiden Modellen, wie es in anderen Sprachen wie C++ oder Java möglich ist. 

Neue Software für eine neue Welt?

Die Frage, welche man sich heute stellen muss, ist jedoch, ob es notwendig ist diese Modelle zu mischen. Ist es im Zeiten des Cloud Computing nicht vielmehr notwendig über grundlegende Prinzipien nachzudenken? Was ist Skalierung? Was bedeutet Auto-Skalierung? Wie wird es heutzutage betrieben? Sind die aktuellen Anwendungen überhaupt Cloud-fähig, oder müssen nicht vielmehr viele Anwendungen überarbeitet oder gar neu implementiert werden? Cloud Computing in seiner jetzigen Form unterstützt beide Welten und auf dem Weg zu neuen skalierbaren Applikationen ist es notwendig über die grundlegenden Modell einmal in Ruhe nachzudenken. Betrachten wir doch einmal die aktuellen Infrastruktur als ein Dienst Anbieter. In der Regel bieten sie beginnend von einer kleinen Maschine, welche in Ausstattung und Performanz gerade einmal einem Netbook entspricht. Um nun die vollen Nutzen aus einer solch kleinen Maschine zu ziehen, um Skalierung und Kosten im Griff zu haben, müssen wir uns fragen, wie die Skalierung unseres Systems aussehen könnte und wie wir die beste Performanz erreichen? Im Vergleich dazu haben wir auf der Enterprise IT Seite hochperformante Systeme mit enormen Speicher und Mehrkernsystemen. Auf den ersten Blick dürfte jedem auffallen, das es zwischen den beiden Welten einen Unterschied gibt, der sich sehr wahrscheinlich auch auf das Programmiermodell niederschlagen dürfte. Mit dynamischen Ansätzen kommen wir auf den Enterprise IT Maschinen sehr gut zurecht. Mal benötigt man mehr Thread-basierte Lösungen und mal kippt das Programm mehr zu einer asynchronen und nicht-blockierenden Lösung. Bei unseren kleinen Cloud Computing Maschinen ist dies anders. Wie haben es hier mit einer kleinen Single Core CPU zu tun. Und diese sollte möglichst gut ausgelastet werden. Wenn wir die CPU jedoch auslasten möchten und diese für unsere Paar Cent ideal nutzen wollen, sollten wir dann nicht versuchen die Last so hoch wie möglich zu bekommen? Und ist dies nicht der Fall, wenn die I/O Operationen nicht blockierend sind? Denn nur wenn möglichst viele Prozesse die Chance haben die Ressource zugeteilt zu bekommen, dann kann die CPU auch beschäftigt gehalten werden. Wenn wir noch tiefer hineinschauen, dann stellen wir fest, dass die Architektur von Infrastruktur als ein Dienst Datenzentren so aufgebaut ist, dass viel I/O Kommunikation stattfinden muss, um beispielsweise Prozesse zu synchronisieren. 

Fazit 

Node.js ist ein vielversprechender Kandidat für eine Standardsprache im Cloud Computing. Jedoch ist abzuwarten, wie die Skalierung der kommenden Systeme funktionieren wird. Mit C++ als Grundgerüst ist auf jeden Fall Performanz und Skalierbarkeit gegeben, man denke nur an OpenMP. Mit mehr als 2500 Repositorien, welche bereits von der Gemeinde implementiert worden sind ist auf jeden Fall ein weiterer Grundstein gelegt. Ferner ist die Sprachsynchronität auf der Seite von Client und Server ein nicht zu unterschätzender Vorteil, auch wenn Web Dienste generische Schnittstellen bereitstellen sollten und damit die Sprachabhängigkeiten verschwinden lassen sollten. Jedoch ist die Implementierung der Applikationen in der Realität nicht weit genug darauf abgestimmt und auch Standards wie WSDL 2.0 haben sich noch nicht in den Anwendungen durchgesetzt. Wie immer ist technologisch vieles schöner vorhanden, was sich jedoch durchsetzen wird ist wie immer unklar. Ich denke das die Möglichkeiten, welche Node.js mit sich führt überwiegen dürften. Auch werden in Zukunft die Programme sauberer entwickelt werden, da der Client- bzw. Web Client-Entwickler nun auch die Serverseite implementieren kann. Dies ist insofern entscheidend, als dass sich die Entwickler besser austauschen und verständigen können, der Code in einer anderen Programmiersprache immer nicht so gut ist, wie in der Haussprache eines Entwicklers. Hinzu kommt, dass sich die Art, wie Programme auf Cloud Computing Infrastrukturen entwickelt werden deutlich in Richtung von Technologien wie Node.js verlagern dürfte. Auch ist die momentan betrieben automatische Skalierbarkeit nicht wirklich schön gelöst. Vielleicht hat Node.js auch dafür eine Lösung in Zukunft bereit. Wir dürfen gespannt sein.

 

Quellen:

[1] Node.js (nodejs.org)

[2] Google‘s V8 JavaScript Engine (en.wikipedia.org)

[3] 2500+ repositories for Node.js related code (github.com)     

In den letzten Jahren hat Microsoft oftmals das Feld von hinten versucht wieder aufzuräumen. Das muss per se nichts schlechtes sein, denn viele andere Unternehmen machen es ebenso. Das momentan erfolgreichste Beispiel ist Apple. 
Auch in der Welt von BigData und Hadoop in der Cloud war es von Seiten Microsofts bisher eher etwas still. eine erste veröffentlichte Agenda zeigte das zielstrebige Vorhaben in Punkto Cloud und BigData ordentlich Gas zu geben. Dies ist besonders im BigData Jahr 2012 wichtig. 

Doch wie verhält es sich mit den Daten und der Cloud oder insgesamt? Nun bisher ist es von der geschichtlichen Entwicklung ähnlich, wie mit die von SQL. SQL sollte dem einzelnen Nutzer auch die Möglichkeit geben Daten direkt und ohne technisches Personal nutzen zu können. Bis heute jedoch ist es sicherlich nicht in den Chefetagen der Unternehmen üblich Daten über SQL abzufragen. Der Manager von heute nutzt dann doch lieber Tools, welche auf Knopfdruck funktionieren. Wer kann es ihm auch im Zeitalter von iPhone und Tabletts verübeln. Doch BigData analysieren ist ebenso komplex. Mittlerweile gibt es zwar Tools, wie Hive[2] oder Pig[3], welche zumindest die Komplexität der Datenanalyse auf der Anwenderseite wieder auf den SQL Level zurückgebracht haben, jedoch ist auch hier der normale Nutzerschwer überfordert. Hinzu kommt, dass die Daten auch irgendwie in z.B. Hadoop “hinein” müssen.
Microsoft scheint hier Abhilfe schaffen zu wollen und Hadoop Büro tauglich werden zu lassen. So zumindest die Angekündigten Pläne. Mit Hilfe des Unternehmens Hortonworks[4] soll es möglich werden Apache Hadoop mit Hilfe einer ODBC Schnittstelle direkt an Microsofts Excel anbinden zu können. Damit würden dann Business Intelligence (BI) Tools Zugang zu Hadoop Cluster bekommen und in Excel könnten Pivot-Datenanalsen nutzbar sein.

Ebenso entwickeln beide Hersteller zusammen ein JavaScript Framework für Apache Hadoop[5] zur einfachen Einbindung und Datenexploration in JavaScript. Dies dürfte für die momentan sehr große JavaScript Gemeinde eine gute Nachricht sein und für Microsoft ein Schritt in die richtige Richtung. 
Die eingeschlagen Richtung hin zu nutzerfreundlicherer Datenanalyse dürfte für Anwender, klassische VBA-Entwickler, JavaScript Programmierer, ODBC Freunde und Freelancer aus dem Bereich Datenanalyse eine schöne Bereicherung und Absicherung zukünftiger Aufträge verheißen. Warten wir ab wie sich die Dinge entwickeln.

Quellen:

Eine hochverfügbare Anwendung soll es werden. Nun soweit stimmen die meisten Pläne für neue Softwaresysteme überein. Viele Entwickler und Architekten entwickeln mit dem Ziel, eine hochverfügbare und skalierbare Anwendung zu kreieren. Am bestem mit keiner Downtime, Continuous Integration und weiteren netten Annehmlichkeiten des Entwicklerndaseins. Doch wie beginnt man? Welche Architektur ist die richtige für mein Vorhaben? Wie erreiche ich mein Ziel in diesen wolkigen und immer nebulöser werdenden Zeiten?
Diese Frage lässt sich natürlich nicht einheitlich und generisch beantworten. Denn die Implementierung des Systems hängt immer von einer Reihe von Randbedingungen ab. Es muss und sollte immer genau untersucht werden, welche Systeme und Komponenten für meine Anwendung benötigt werden und überhaupt geeignet sind. Es gibt auf dem “Markt” momentan eine Menge guter OpenSource-Softwareprojekte, die gute Vorraussetzungen haben spezifische Probleme zu adressieren und diese auch zu lösen. Jedoch wie findet man die richtige? Man muss seine Anforderungen gut kennen und jederzeit im Blick haben. Facebook hat z.B. nicht ohne Grund Thrift² entwickelt, obwohl es bereits gute mögliche Kandidaten für multi-plattform Ansätze gab, wie etwa CORBA und SOAP. Doch mit dem festen Focus auf seine Anforderungen, gelangt man das ein oder andere Mal doch an die Grenzen bestehender Systeme. 

Erlang. Der dänischer Mathematiker und Ingenieur? Die Großgemeinde Erlang des Stadtbezirks Hechuan in der chinesischen Stadt Chongqing? Oder soll es hier doch um die Programmiersprache Erlang gehen? Genau. Es geht in diesem Artikel um eben einen dieser alten Hasen der IT, der in Zeiten moderner dynamischer System wieder an das Licht der Programmierwelt vorstößt. Denn verschollen war Erlang nie. Es gab und gibt immer Systeme, die unter der Oberfläche eine breite Masse von anderen System unterstützen und mit Erlang erbaut sind. 
Begeben wir uns in die Vergangenheit von Erlang, um zu erfahren, was Erlang ist und warum es so wertvoll sein kann für die Cloud bzw. moderne Systemarchitekturen. Die Ericsson language oder auch nach dem dänischer Mathematiker und Ingenieur Agner Krarup Erlang benannte Sprache und Laufzeitumgebung erblickte in den Laboren von Ericsson die Welt. Geburtshelfer und Vater war Joe Armstrong im Jahre 1986³. In den Laboren von Ericsson suchte man damals nach einer Möglichkeit die folgenden Anforderungen zu erfüllen.

• Parallelität
• hohe Verfügbarkeit
• Fehlertoleranz
• Effizienz
• Auswechseln von Modulen zur Laufzeit
Wie man bereits in dieser Liste sehen kann, scheint Erlang ein geeigneter Kandidat für viele heutige Systeme zu sein. Doch es hängt sehr davon ab, was man denn eigentlich bauen möchte. Für Number Crunching oder auch graphik-intensive Anwendungen ist Erlang sicherlich nicht die beste Wahl mit diesen Design-Anforderungen. Wenn man hingegen ein verteiltes, robustes, skalierendes, Multi-core fähiges und interoperable Anwendung im Focus hat, dann ist Erlang sicherlich im Kreise der engsten Kandidaten für dieses System.

1993 wurde ein weiterer Meilenstein in der Geschichte von Erlang gesetzt. Verteilung wurde dem System hinzugefügt, was es ermöglicht homogene Programme auf heterogener Hardware laufen zu lassen. 
Doch ist Erlang wirklich den Anforderungen seiner Entwickler gewachsen? Werfen wir doch einmal einen Blick auf die heutigen Systeme und picken uns ein paar Beispiele heraus. Viele Firmen nutzen Erlang in ihren Produktivsystemen ¹ ³

• Amazon nutzt Erlang für die Implementierung von SimpleDB
• Yahoo! nutzte Erlang für ihren Social Bookmarking Dienst Delicious (jetzt AVOS Systems, Inc.), welcher mehr als 5 Millionen Nutzer und mehr als 150 Millionen URLs beheimatet
• Facebook nutzt Erlang für den hauseignenen Chat, hit mehr als 100 Millionen aktiver Nutzer
• T-Mobile nutzt Erlang für sein SMS und Authentifizierungssystem
• CouchDB 
• RabbitMQ
Es lassen sich sicherlich noch viele weitere Beispiele finden, die für Erlang sprechen und die Robustheit und Skalierbarkeit deutlich belegen können. 
Doch was macht Erlang so besonders? Nun Erlang ist in erster Linie nicht nur eine Programmiersprache, sondern auch ein Laufzeitsystem mit umfangreiche Bibliothek. Erlang kommt zudem mit besonders leistungsfähigen VMs daher. Das System Erlang/OTP (The Open Telecom Platform) ist somit geradezu ideal geeignet für verteilte, hochverfügbare Systeme. Die Erlang VM hat auch eine lange Entwicklung hinter sich. Sie machte Stationen bei JAM, VEE (Virding’s Erlang Engine), Strand88 und über TEAM kam man dann endlich bei Bogdan’s Erlang Abstraft Machine (BEAM) an⁴.

BEAM ist implementiert eine Registermaschine und keine Stackmaschine. Es gibt keine Manipulationsmöglichkeiten für Stacks. In BEAM ist es z.B möglich über einfache Instruktionen Speicher zu allokieren oder Tutel zu initialisieren. Dies ist bei anderen VMs, wie beispielsweise die von Java nicht möglich, da hier in Objekten gedacht und operiert wird. Dadurch ist der Zugriff nur über die Erzeugung eines Objektes möglich, welcher die Details der Speicherallokierung verbirgt. Ebenso ist die Erzeugung neuer Prozesse anders aufgebaut, als es bei der JVM der Fall ist. Die Entscheidung, wann ein weiterer Prozess gestartet wird, erfolgt bei der Erlang VM nicht über Synchronisationsinstruktionen. Betrachten wir einmal die wichtigste Vorteile der Erlang VM ein wenig genauer⁵. 
Leicht gewichtige Prozesserzeugung. In nebenläufigen Systemen ein klarer Bonus und Vorteil auch und gerade in Hinblick auf die Komplexität einer Architektur. Man verliert sich während der Entwicklung nicht in Threads. Kurz: Erlang erledigt das System Thread Management. Dies ermöglicht die Fokussierung auf die eigentliche Arbeit, das Entwickeln der Anwendung. Man benutzt während der Entwicklung einfach die Ressourcen, die man benötigt. 
Des Weiteren hätten wir eine ideale Nachrichtenverteilung in Erlang implementiert. Solange eine Prozess ID innerhalb der Plattform bekannt ist, kann 
man direkt Nachrichten durch die Anwendung genau an diesen Prozess schicken. Ich denke ich brauche die Stärke in diesem Bereich nicht weiter auszuführen, wenn man sich in Erinnerung ruft, dass die Erfinder doch bei einem Kommunikationsunternehmen arbeiteten.
Um die Highlights abzurunden, bietet Erlang noch die Möglichkeit eines Codeaustauschs zur Laufzeit. Dies ist ein extrem wichtiges und -entschuldigen Sie den Ausdruck - coole Eigenschaft. Um eine hohe Verfügbarkeit von Systemen zu erreichen, ist dies eine notwendige Eigenschaft eines Systems. Dies bringt nach Untersuchungen 5-9 neunen an Uptime. Hierbei gilt jedoch auch wieder, dass die Anwendung natürlich so entwickelt sein muss, dass dies auch möglich ist. Es ist wie mit allen Dinge: man bekommt nichts umsonst. 

Doch wo es viel Lob gibt, gibt es natürlich auch immer einen Kritikpunkt. In diesem Fall natürlich auch. Erlang ist nun mehr als 20 Jahre alt. Dies ist ein nicht zu unterschätzender Punkt, den man berücksichtigen sollte. Andere Programmiersprachen sind sicherlich auch nicht die jüngsten, haben jedoch im Laufe ihrer Lebenszeit eine starke Entwicklergemeinde hinter sich gehabt und der Sprache so einige Kinderkrankheiten ausgetrieben. Auf der anderen Seite war Erlang immer im behüteten Schoß einer kleinen Entwicklergemeinde. Dies hat auch sein gutes. Da die Sprache dadurch vielleicht genau die gewünschte Robustheit erlangt hat, die sie heute nachweisen kann. Denn nicht umsonst setzen so viele Unternehmen bei der Implementierung genau auf dieses Pferd. Man kann außerdem auch von Kindern viel lernen. Dies zeigen unlängst Managerschulen, in denen Kinder den Erwachsenen beibringen, worauf es im Leben ankommt. 
Hier eine kleine Zusammenfassung vor dem Resümee in Anlehnung an Paul O’Rorke⁶ :

Haupteigenschaften:
• Asynchrone Nachrichtenübermittlung
• Synchrone Nachrichtenübermittlung ist möglich
• Tracking/Monitoring von Prozessen, z.B. mit Hilfe eines Nameservers
• Schnelle Prozesserzeugung
• Code Integration von Java und C möglich

Stärken:
• Geeignet für hoch verteilte, nebenläufige Anwendungen mit Zehntausenden von Transaktionen pro Sekunde
• Ermöglicht eine hohe Anzahl von simultanen Prozessen (Produktivsysteme mit 8-9 Millionen Prozessen sind im Einsatz) 
• Extensive Inter-Prozess Kommunikation
• Verteilung über heterogene Maschinen ist kein Problem, da Erlang keine Unterscheidung macht, wo der Prozess läuft
• Codeaustausch zur Laufzeit

Schwächen:
• Nicht geeignet für Anwendungen wie Number Crunching
• Große VM, daher nicht umbedingt für clientseitige Anwendungen geeignet

Die zu grundliegende Betrachtung von Erlang und seinen Fähigkeiten befürwortet einen Einsatz dieser Sprache oder Systemkomponenten, die in Erlang realisiert worden sind für moderne Projekte in dynamischen und skalierbaren Systemlandschaften wie etwa im Cloud Computing Umfeld. Ob es nun “nur” die Nutzung von beispielsweise CouchDB oder RabbitMQ ist, oder die komplette Anwendung nativ in Erlang entwickelt wird, sei einmal dahingestellt. Es lohnt sich jedenfalls. 

Quellen:
[1] Erlang Programming - A Concurrent Approach to Software Development; Autoren: Francesco Cesarini, Simon Thompson; Verlag: O’Reilly Media; Veröffentlicht: June 2009  http://www.oreilly.de/catalog/9780596518189
[2] Thrift - Scalable Cross-Language Service Implementation; Autoren: Mark Slee, Aditya Agarwal, Marc Kwiatkowski, FACEBOOK - http://thrift.apache.org/static/thrift-20070401.pdf

 

Was die Datensicherheit angeht, war 2011 ein Jahr voller böser Überraschungen: Hacking-Attacken ungeahnten Ausmaßes, Sicherheitslöcher in sicher geglaubten Systemen, hunderttausende gestohlener Account-Daten. Was kommt als Nächstes? Die Experten in den Sicherheitslaboren von Websense habe die Top Cyber Attacken für 2012 herauskristallisiert.

1. Digitale Identität ist für Cyber-Kriminelle wertvoller als Kreditkartendaten
In Foren wird es bald einen regen Handel mit persönlichen Informationen geben. Die sozialen Netzwerke basieren allesamt auf Vertrauen in die eigenen Kontakte. Mit einem gestohlenen Login gelangen die Datendiebe an vertrauliche Daten und können diese missbrauchen.

2. Die größte Gefahr droht von einem Konglomerat aus Social-Media-Bekanntschaften, der Nutzung mobiler Geräte und Cloud-Diensten
In der Regel bestehen Angriffe aus mehreren Komponenten. Die Kombination Internet und E-Mail ist ein Klassiker. Im kommenden Jahr werden sich Angreifer vor allem Soziale Medien, mobile Kommunikation und Cloud-Dienste zu Nutze machen, um ihre Opfer zu finden. Es gab bereits erste Fälle von Cyber-Angriffen über die Chat-Applikation in einem Sozialen Netzwerk. Die Täter hatten sich mit gestohlenen Login-Daten Zugang verschafft und den Account missbraucht, um an den richtigen Adressaten ihres Betrugs zu gelangen.

3. Die Zahl der Angriffe auf Smartphones und Tablets explodiert
Davor warnen die Experten seit Jahren, aber im kommenden Jahr wird es zu einem Massenphänomen: Die Nutzer werden reihenweise Opfer von immer mehr raffinierteren Betrügereien, die ganz gezielt verschickt und eingesetzt werden (Social Engineering Scams). Hier rechnet Websense mit mehr als 1.000 unterschiedlichen Varianten von Schadcode und Attacken auf mobile Geräte.

4. Verschlüsselter Datenverkehr bereitet der Unternehmens-IT
Kopfzerbrechen

Der Datenverkehr im Web wird privater, immer mehr getunnelte Verbindungen schützen vor fremden Blicken. Der Grund dafür liegt zum einen in der exponentiellen Zunahme von Tablets und anderen mobilen Geräten, zum anderen verwenden viele Webseiten wie Google, Facebook oder Twitter standardmäßig verschlüsselte Verbindungen (https) und suggerieren dadurch Sicherheit. Für viele Sicherheitssysteme in Unternehmen bringt das einige Probleme mit sich. Weil die verschlüsselten Daten nicht mehr analysiert werden können, stochert die Abwehr hilflos im Nebel.

5. Eindämmen ist das neue Vorbeugen
Jahrelang bestand die Sicherheitsstrategie von Unternehmen ausschließlich darin, Malware und Cyber-Attacken gar nicht erst eindringen zu lassen. Niemand beschäftigte sich damit, seine eigenen Daten daran zu hindern, das Unternehmen zu verlassen. Mittlerweile denken einige Firmen um. Immer öfter liegt der Fokus auch auf der intelligenten Kontrolle des Datenverkehrs nach draußen. Damit wird der Abfluss von Informationen verhindert und der Schaden begrenzt, wenn es zu einem Angriff gekommen ist.

6. Die Angreifer tarnen sich besser
Die Olympischen Spiele in London, der Präsidentschaftswahlkampf in den USA, Verschwörungstheorien – Menschen interessieren sich für viele Dinge. Das nutzen Cyber-Angreifer aus und springen auf jeden Zug auf, der interessant erscheint. Das ist nichts Neues. Aber in Zukunft werden die Angreifer an Stellen zuschlagen, an denen die Nutzer nicht damit rechnen: Gefälschte Nachrichtenseiten, die von echten kaum zu unterscheiden sind, Facebook-Statusmeldungen und Twitter-Tweets, Xing-Kommentare und YouTube-Links – es gibt nichts, was nicht missbraucht wird. Vor allem bei angeblichen außergewöhnlichen Nachrichen, die auf diesen Wegen verbreitet werden, sollte man besser zwei Mal hinschauen und sich nicht täuschen lassen.

7. Angriffe über Social Engineering und gefälschte Antiviren-Software bleiben ungeschlagen
Sogenannte Scareware, also das Vorgaukeln einer Gefahr verbunden mit dem Angebot einer (kostenpflichtigen) Lösung und gefälschte Antiviren-Software, die angeblich Schadprogramme findet und (gegen Gebühr) entfernt, erlebt 2012 ein neues Hoch. Allerdings nimmt die Bedrohung neue Formen an. Statt eines einfachen „Ihr Computer ist infiziert“-Banners wird es 2012 vor allem diese drei Szenarien geben: Gefälschte Software für die Registry-Bereinigung, für die Systembeschleunigung und für Backup-Lösungen in der Cloud, die vorwiegend bekannte Anbieter imitieren.

Das Sicherheitslabor Websense charakterisiert die fünf wichtigsten Kategorien so:

1. Scriptkiddies
Dieser Gruppe geht es vor allem um Action. Häufig handelt es sich bei den Scriptkiddies um Teenager, die bis spät in die Nacht vor ihren Rechnern sitzen. Mit ihren eingeschränkten Programmierkenntnissen nutzen sie Sicherheitslücken in Betriebssystemen und Applikationen aus und zielen vor allem darauf ab, beispielsweise Webseiten zu manipulieren oder Teile davon zu zerstören. Das erinnert an den Film „Wargames – Kriegsspiele“, der 1983 in den Kinos lief. Wargames enthielt einige, für Scriptkiddies typische Aktivitäten. Der Teenager David dringt in ein Flugbuchungssystem ein und reserviert einen Flug nach Paris. Ferner betätigt er sich auch als Cracker, der seine Schulnoten ändert. An die Passwörter gelangt er über Social-Engineering-Techniken.

2. Hacktivisten
Gemeint sind damit Hacker, die ihre Tätigkeit mit sozialen, politischen, religiösen oder anderen weltanschaulichen Motiven begründen. Sie rekrutieren sich aus der Gruppe handgestrickte Pullover tragender Demonstranten, die aus Protest Bäume besetzen und die ihre Sprühdose für Parolen jetzt mit der Tastatur eingetauscht haben, um über das Web für ihre Anliegen zu werben. Hier erreichen sie ein weit größeres Publikum, als es ihnen jemals mit herkömmlichen Mitteln gelingen würde. Hacktivisten schrecken auch nicht davor zurück, fremde Webseiten zumindest zeitweise zu kapern, um auf ihre Anliegen aufmerksam zu machen.

3. Digitale Straßenräuber
Dies ist die größte Hacker-Gruppe. In früheren Zeiten wäre dies die Kategorie der Kleinkriminellen gewesen: Taschen- und Trickdiebe, die ihre ahnungslosen Opfer ablenken und Kleinbeträge oder gar die gesamte Geldbörse stehlen oder auf Märkten und an Straßenecken mit Produktpiraterie ihr Geld verdienen. Im Laufe der Zeit haben sich lediglich deren Methoden, nicht aber ihr generelles Vorgehen gewandelt. Einfache Trojaner, Adware, Spam, Phishing oder Social-Engineering-Techniken reichen aus, um das schnelle Geld zu machen. Manchmal werden potenzielle Opfer mit gefälschten Nachrichten zu Naturkatastrophen oder anderen Aufsehen erregenden aktuellen Ereignissen geködert und ihnen dann beispielsweise Passwörter und andere persönliche Informationen entlockt.

4. Organisierte Cyber-Kriminelle
Gezielte, gut getarnte Angriffe auf Unternehmen und Industriespionage sind ein effizient organisiertes Geschäft, das von Profis ausgeübt wird. Die eigentlichen Aktivisten sind mit modernstem Equipment ausgerüstet und verstehen es in bester Spionagemanier, ihr Tun zu verschleiern. Ihre Auftraggeber sind in der Regel bestens in der Geschäftswelt vernetzt und können so, ohne großes Aufsehen zu erregen, lukrative Ziele auskundschaften. Gemeinsam bilden die Häuptlinge und Indianer ein starkes Team, das es auf das
große Geld abgesehen hat und das Ziel sehr oft, ohne Aufsehen zu erregen, erreicht. Während es eine Gruppe auf kurzfristig zu erzielende Vorteile abgesehen hat, geht es im anderen Fall um so genannte Advanced Persistent Threats (APTs), die sich über eine lange Zeit erstrecken können. Dabei handelt es sich um Fälle von Spionage und Sabotage, bei der Produktunterlagen, Konstruktionszeichnungen und Patentdatenbanken das Ziel sind.

5. Cyber-Agenten
Beispielhaft für diese Kategorie sind generalstabsmäßig geplante und durchgeführte Attacken wie der Stuxnet-Virus, der im Sommer 2010 erstmals auftauchte. Er hatte es auf Industrieeinrichtungen und iranische Atomanlagen abgesehen. Hinter Malware wie dem Stuxnet-Virus steht die Arbeit von fünf bis sechs Entwicklern über einen Zeitraum von mindestens sechs Monaten. Viele vermuten, dass ein solches Projekt nur durch staatliche Unterstützung möglich war. Das würde bedeuten, dass wirtschaftliche oder auch politische Interessen mit modernsten Mitteln aus dem Arsenal des Cyber-Krieges geführt werden. Viele halten diese kriegerische Rhetorik für nicht übertrieben. So hat beispielsweise das Pentagon den Cyberspace neben Land, Wasser, Luft und Weltraum vor einiger Zeit zur fünften Domäne militärischer Einsätze erklärt. Andere Staaten werden da sicherlich kaum zurückstehen.

Die SecTXL startet 2012 in ihr zweites Jahr. Haben sich die Inhalte im vergangenen Jahr noch an einem Tag ausschließlich auf das Thema Cloud Computing konzentriert, findet die SecTXL ‘12 (http://sectxl.com) in Hamburg an zwei Tagen (22. und 23. Februar) statt und wird zusätzlich die Bereiche Mobile Computing, Social Media und weitere Themen wie bspw. Consumerization (of IT) aus dem juristischen und technischen Blickwinkel betrachten.

Neue Technologien und Konzepte stellen Unternehmen heutzutage vor immer größere und vor allem vor mehr Herausforderungen gleichzeitig. Zum einen muss sichergestellt werden, dass die eingesetzten Systeme auf der technischen Seite mindestens ausreichend abgesichert sind. Zum anderen ergeben sich auf Grund der Globalisierung und dem verstärkten Einsatz von weltweit verteilten Systemen auch juristische Fragen, die den Einsatz „auf dem Papier“ bereits erschweren können.

Die SecTXL ‘12 nimmt sich diesen Thematiken an und präsentiert neben fachlichen Vorträgen von Rechtsanwälten und Experten aus den Bereichen des Datenschutzes und der Datensicherheit ebenfalls technische Probleme und deren Lösungen von IT-Architekten. Damit werden Möglichkeiten aufgezeigt, wie sich Unternehmen in Zeiten moderner Kommunikation und Arbeitsweisen aus dem Blickwinkel der Sicherheit verhalten müssen.

Auf der SecTXL ‘12 in Hamburg präsentieren wir einen gut durchdachten und in sich stimmigen Themenmix aus dem Bereich der IT-Security (Technisch/ Juristisch) mit dem Fokus auf Cloud Computing, Social Media, Consumerization (BYOD) und mehr. Dafür haben sich viele herausragende national sowie international bekannte Referenten angekündigt, darunter:

1. Dr. Johannes Mainusch | Vice President Operations, XING AG und freier Berater

2. Nina Diercks, Rechtsanwältin | http://www.socialmediarecht.de

3. Jan Schneider, Rechtsanwalt: SKW Schwarz Rechtsanwälte

4. Tim Cappelmann, Leiter Managed Service: AirITSystems GmbH

5. Udo Schneider, Architect EMEA: Trend Micro

6. Florian Ebert, IT-Security Consultant: Siemens Enterprise Communications

7. Eva Schlehahn, Legal Researcher + Consultant: Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

8. Dr. Christopher Kunz, Geschäftsführer: filoo GmbH

9. Sebastian Rohr, CTO (CISSP/CISM) | accessec GmbH

10. Peter Griesbeck, Leiter Consulting & Design – Network, Infrastructure and Security: Siemens Enterprise Communications

11. Sven Thomsen, Referatsleiter / Referent | Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

12. Steffen Heyde, Principal Portfolio Manager | secunet Security Networks AG

13. Sven Schlüter, Senior Security Consultant“ | Context Information Security

14. Julija Got, Absolventin der Wirtschaftsinformatik | TU München (Studenten Wildcard)

Die Vortragsthemen der SecTXL ‘12 in Hamburg sind

• Security in Social Networks – ein Erfahrungsbericht

• Social Media – Das No Man’s Land des Rechts?

• Die Cloud-Strategie 2012 – endlich rechtssicher in die Cloud!

• Cl(Out)dsourcing – Sicherheitsanforderungen im Vertragswerk richtig abbilden

• BYOD: Kontrollierter Kontrollverlust?

• Virtualisierung von IT Security – Anforderungen an die Organisation

• Virtualisierungs- und Cloud-Security: Alte Sicherheit in neuen Schläuchen?

• Absicherung von Unternehmen vor Gefährdungen aus den sozialen Medien und Netzwerken

• Cloud Computing und Datenschutz – Chancen, Risiken und Perspektiven

• IT-Sicherheit und Datenschutz im Smart Grid

• SSL, quo vadis?

• Überleben In der Cloud – Die echten Gefahren

• Trendwende ICT-Security? » Worüber Unternehmen heute wirklich nachdenken…

• Risikoanalyse und Risikosteuerung im Cloud Computing

Alle Vortragsthemen sowie deren Abstracts sind über http://12.sectxl.com/hamburg/agenda-hamburg zu erreichen.

[Termin, Veranstaltungsort und Anmeldung]

Die SecTXL ‘12 findet am 22. und 23. Februar 2012 in der Bucerius Law School Hamburg statt.

Die Teilnehmerzahl der SecTXL ‘12 in Hamburg ist auf 100 Personen streng limitiert. Eine vergünstigte Anmeldung ist zurzeit mit dem Early Bird noch bis zum 01.02.2012 möglich. Die Registierung befindet sich unter http://12.sectxl.com/hamburg/registrierung-hamburg

[Stimmen zur SecTXL ‘11]

"Im Gegensatz zu den meisten kommerziellen Kongressen, die überwiegend aus Werbevorträgen der Sponsoren bestehen, 

wurden die Vortragenden im Vorfeld per Code of Conduct auf die Werbefreiheit ihre Vorträge verpflicht.”

"Dieses Konzept war der Grundstein für eine rundum gelungene Veranstaltung, deren Agenda die wichtigsten Aspekte des Thema Technische und Juristische Sicherheit des Cloud Computings abdeckte."

“Die gestrige SecTXL ’11 in Frankfurt war ein voller Erfolg. Zumindest war ich nicht der einzige Teilnehmer, der das Symposium “Security in the Cloud” mehr als nur interessant fand.”

“Es sollte meines Erachtens häufiger solcher Treffen von Entscheidern, Unternehmen und IT-Rechtsanwälten geben. Die SecTXL ’11 hat mir zumindest gezeigt, dass gerade in Deutschland noch eines fehlt…”

“Es war eine wirklich interessante Veranstaltung, im Verlauf derer viele gute Einblicke von unterschiedlichen Perspektiven vermittelt wurden.”

Beachten Sie auch den „Code of Conduct“ (http://12.sectxl.com/uber-die-sectxl/code-of-conduct).

>

Matlab und Mathematica machen den Schritt in die Cloud. Matlab bietet die technischen und vor allem auch die lizenzrechtlichen Möglichkeiten, die benötigt werden, um in der Cloud seine Berechnungen durchführen zu können. Dies ist mit EC2 gut implementierbar. Matlab und EC2 ermöglichen damit einem Forscher und oder auch einem Ingenieur die Möglichkeit Berechnungen parallel und verteilt auf verschiedenen EC2 Instanzen laufen zu lassen. Dadurch verkürzen sich nicht nur die Laufzeiten der einzelnen Jobs, sondern es werden auch Probleme gelöst, die man vielleicht aus eigener Erfahrung gut kennt: Ressourcenknappheit! Wer hat es nicht schon einmal erlebt, dass ein Job, den man auf einem Cluster ausführen wollte schon erst einmal ewig (gefühlt) anstehen muss, bis er überhaupt gestartet wird. Dies ist eine wunderbare Sache für Wissenschaftler, Forschungsabteilungen, Ingenieurbüros etc. Auch ist man nicht mehr an die beschränkten Ressourcen gebunden. Man muss nicht länger warten, weil z.B. nur 10 Computer Nodes zur Verfügung stehen, denn man kann nun einfach noch 10 weitere hochfahren, wenn man Sie benötigt. Was für Matlab gilt, ist auch der Weg den Wolfram Research mit Mathematica genommen hat. Es ist das erklärte Ziel Mathematica in der Cloud für jeden zur Verfügung zu stellen. Dies geschieht momentan unter der Federführung von Nimbus Services. Nimbus Services ermöglicht es Mathematica auf unterschiedlichen Plattformen auszuführen, von Supercomputing Umgebungen bis zu EC2 Maschinen. Und dann wären da noch Anbieter die eher einen SaaS (Software as a Service) Ansatz verfolgen, wie etwa Monkey Analytics. Dieses Web basierte Mathematik Tool versteht Matlab, Python und R Befehle und bietet damit auch einen guten Zugang zu wissenschaftlichem Rechnen.

Amazon bietet mit SQS einen Warteschlangen-Kommunikationsdienst an, der es Anwendungen ermöglicht asynchron miteinander zu kommunizieren. Nachrichten können eine maximale Größe von 64 KB besitzen. Diese werden zur Warteschlange hinzugefügt. Jede Warteschlage wird über mehrere Datenzentren verteilt repliziert. Nachrichten werden via HTTP gesendet und die Zustellung erfolgt über eine “At least one” Semantik an mindestens einen Empfänger. Die Nachrichten selbst werden über Polling empfangen. Da die Daten asynchron repliziert werden, ist es möglich, dass ein Empfänger nicht alle Nachrichten bekommt die an eine Warteschlange gesendet werden. Ferner ist es möglich, dass die Nachrichten in einer anderen Reihenfolge ankommen oder mehr als einmal zugestellt werden. Daher muss die Logik der Warteschlange sowohl idempotent als auch unabhängig von der Nachrichtenreihenfolge. Sobald eine Nachricht von einem Empfänger angenommen worden ist, wird die Nachricht für einen kleinen Zeitraum versteckt, damit andere Empfänger diese nicht sehen können. Der Empfänger kann die Nachricht dann verarbeiten und sie im Anschluss von der Warteschlange endgültig entfernen. Wenn das Entfernen jedoch nicht innerhalb der versteckten Nachrichtenzeitspanne erfolgen sollte, so wird die Nachricht für alle wieder sichtbar und wird dann von dem nächsten Empfänger angenommen. Der Dienst ist skalierter bis zu Millionen von Nachrichten pro Tag und realisiert eine FIFO (First In - First Out) Warteschlange.

Happy Birthday IBM 5150

Happy Birthday IBM 5150