Mit JiffyBox hat domainFACTORY, eines der Schwergewichte im deutschen Hostingmarkt, sich ebenfalls dem Thema angenommen und verdient bereits vorweg ein großes Lob. JiffyBox erfüllt alle Anforderungen eines echten IaaS-Angebots.

• Freie Wahl der OS-Images inklusive der Möglichkeit eigene Images zu verwenden
• Freie Wahl zwischen 2.6.26er oder 2.6.18er Kernel und sogar die Möglichkeit eigene Kernel zu verwenden
• Steuerung per API (Webinterface ebenfalls möglich)
• Komplett nutzungsbasierte Abrechnung
• Keine Mindestvertragslaufzeiten

Was will man mehr?

Da für uns die API und die Möglichkeit eigene Images und Kernel zu nutzen besonders wichtig ist, habe ich mir die API mal etwas genauer angesehen (PDF). Bei der JiffyBox handelt es sich laut der guten Dokumentation um eine RESTFul-API die per JSON kommuniziert. Sieht schonmal sehr gut aus.

Doch gleich auf einer der ersten Seite lese ich folgendes:

https://api.jiffybox.de/<API-Token>/v1.0/<modul>[/<bereich>][/<bereich N>]

Eines der Grundprinzipien, wenn nicht sogar das Grundprinzip von REST ist es für mich, dass jede Ressource über eine eigene URL angesprochen wird. Wenn jetzt allerdings wie hier, als Teil der URL ein API-Token übergeben wird, dann haben die Ressourcen keine eindeutigen URLs, denn diese ändert sich ja mit jedem Login. Das ganze ist jetzt zwar kein Beinbruch und sicher gibts es genug Entwickler in der weiten Welt des Internets, die das ganz anders sehen als ich. Aber es gibt meiner Meinung nach bessere Methoden um Authentifizierungstokens zu übertragen. Z.B. im Header.

Positiv anzumerken ist aber definitiv, dass die API sehr sauber auf die Verwendung der Verben achtet und eine eindeutige Versionierung bietet. Etwas, dass wir bei unserer API bisher noch nicht umgesetzt haben.

Alles in allem bin ich aber von JiffyBox durchaus begeistert und kann es nur begrüßen, dass es damit eine brauchbare alternative zu EC2 aus deutschen Landen gibt. Einzig bei den Instanzengrößen könnte man noch etwas nach oben nachbessern. Aber das kommt sicher mit der Zeit.

Aber das ist noch nicht alles, zusätzlich zu den beiden Schwergewichten Rackspace und NASA haben sich noch 100 weitere Entwickler dem Projekt angeschlossen. Eins ist klar, man will hier eindeutig das dominante Open Source Cloud Projekt werden.

Ich kann das nur begrüßen. Zwar gibt es mit Eucalyptus bereits eine vergleichbare Lösung die ebenfalls Open Source ist. Aber gerade die Open Source Gemeinschaft stellt schon seit Jahren unter Beweiss, dass immer Platz für verschiedene Projekte und Ansätze ist. Und der Innovation und Qualität der Projekte schadet es sicher nicht. Ganz im Gegenteil. Es bleibt also abzuwarten und OpenStack ist auf jedenfall ein sehr spannender Ansatz.

Insbesondere für Rackspace ist das natürlich kein Selbstzweck. Höchstwahrscheinlich sieht man in diesem Schritt die große Chance endlich technologisch zu Amazon aufzuschliessen, die völlig zurecht der Quasi-Standard sind.

Ich werde mich demnächst mal genauer mit den einzelnen Komponenten beschäftigen und dann ggf. berichten.

Insbesondere weil Amazon ja keinerlei Informationen nach aussen gibt, ist dies eine wichtige und gute Sache.

Neu hinzu kommen jetzt Informationen zum internen Aufbau von EC2. D.h. Verzeichnisstrukturen und vieles mehr. Die neuen Informationen gehen auf eine Untersuchung von Sören Bleikertz zurück, der plant für eine Studienarbeit noch weitere Informationen zu sammeln. Wir dürfen also gespannt sein, was da noch in Erfahrung zu bringen ist.

Revisiting EC2 Instance IDs

Mit diesem Preismodell kann man in verschiedensten Situationen sicher gut arbeiten. Insbesondere eine Kombination aus den damit drei verschiedenen Preismodellen (On-demand, Reserved und Spot) könnte enormes Einsparungspotential bieten.

Eine graphische Übersicht über die Preisentwicklung der Spotinstanzen gibt es hier. (via @Schollm)

Deshalb kann man sich durchaus berechtigt die Frage stellen, ob man nicht auch mit den US Instanzen arbeiten kann. Wie wirkt sich die höhere Latenz wirklich aus. Genau dies hat das Cloud Computing Blog untersucht.

Wie sich herausstellt sind die Unterschiede durchaus signifikant und die Auswirkungen dementsprechend auch. Es scheint also ratsam zu sein, den Aufpreis für die EU-Zone zu zahlen, wenn man EC2 Instanzen einsetzt. Zusätzlich, hier kommt es natürlich auf das Projekt an, sollte man auch immer daran denken, dass es datenschutzrechtlich nicht ohne weiteres möglich ist, persönliche Daten auf Servern ausserhalb der EU zu speichern.

Damit ist zwar das Problem beschrieben, aber nicht die Ursache.

Ganz besonders hervorzuheben ist dabei ein Unterschied. Amazon Instanzen werden jedesmal frisch aus einen Image gestartet. Wenn die Instanz beendet wird, gehen alle Änderungen verloren. Was für den ein oder anderen auf den ersten Blick erschreckend wirken mag, ging mir vor einem Jahr auch noch so, ist wenn man ehrlich ist die einzige brauchbare Lösung wenn man eine größere Anzahl an Instanzen verwalten will oder muss.

Nur durch diese Images hat man 1. jederzeit einen definierten Zustand und kann 2. überhaupt wirklich kontrolliert Softwareupdates fahren. Natürlich gibt es da verschiedene Lösungen zum Update- bzw. Patch-Management. Aber eigentlich weiss jeder, kommt es damit in der Praxis immer wieder zu Problemen.

Durch die Images hat man jederzeit einen frisch Installierten Server wenn man eine EC2 Instanz startet. Die Images selbst kann man updaten, testen und dann problemlos neue Instanzen damit starten und die alten beenden. Diese Tatsache zwingt einen natürlich dazu nach dem Start automatisiert verschiedene Anpassungen vorzunehmen, die die Instanz auf ihren eigentlichen Einsatzbereich vorbereiten. Genau damit bereitet man sich aber auch darauf vor die Anzahl der Instanzen jederzeit erhöhen oder verringern zu können. Zumindest in der Theorie. In der Praxis wird die ein oder andere Anwendung wohl noch Probleme machen.

Hier ist der Punkt an dem die meisten anderen Anbieter einen Kompromiss eingehen und damit auch den meiner Meinung nach größten Fehler, wenn es um Cloud Computing geht. Man startet eine bestimmte virtuelle Instanz und nicht einfach irgendeine. Damit ist es aber auch nur das. Virtualisierung. Echtes Cloud Computing (Infrastructure as a Service) wird daraus erst wenn die einzelnen Instanzen völlig austauschbar werden. Und das werden sie eben nur, wenn sie jederzeit mit genau dem selben definierten Zustand per API erstellt werden können.

Gerade die API ist dabei aber auch Pflicht. Wer als IaaS Anbieter nicht zumindest geplant hat eine solche Schnittstelle zeitnah anzubieten sollte ganz schnell nochmal sein Angebot überdenken. Wer jetzt lediglich mit einem Virtualisierungsangebot startet und das ganze dann Cloud Computing nennt wird es meiner Meinung nach am Markt nicht lange verkaufen können. Noch ist es nicht zu spät.

Grundsätzlich ist die Software ähnlich wie Eucalyptus Open Source, es gibt aber jetzt neu die Service Provider Edition. Wer sich dafür interessiert findet die Infos sicher auf der Enomaly Webseite. Einige der Neuerungen hier kurz im Überblick:

- KVM is now directly supported as a hypervisor at install time.
- Sample data is installed during initial installation, so there is no need to create a customer/group/permissions before testing the system. See INSTALL for default user/pass.
- VNC window in customer UI is now identical to the Admin UI. Passwords for the VNC console are now found under Info button at VM level.
- Info window now shows how to connect with an external VNC client as well as the existing Java applet.
- VNC window can be disabled entirely on a per VM basis.
- App Center can now be searched/filtered. This is useful if you offer a large number of appliances.
- Admin Dashboard now shows graphical whole cluster resource usage.
- Network Manager has been removed. All deployments are recommended to use DHCP for IP assignment going forward.
- Various performance improvements have been added at customer UI level.
- Various performance improvements have been added to infrastructure code.

Wer mehr Details aus erster Hand benötigt bekommt diese von Reuven Cohen dem Gründer und CTO von Enomaly auf seinem Blog.

Demnach resultierte eine Denial of Service Attacke bei einem auf EC2 gehosteten Dienst in extrem langsamen Zugriffen auf die EBS Volumes. Was die Vermutung nahe legt, dass die gleiche Netzwerkverbindung für externe Verbindungen und für den Zugriff auf die EBS Volumes genutzt wird. Ob dies nun wirklich so ist, oder nicht, weiss ich allerdings auch nicht…

Wie der Artikel aber schon sagt, kann man nur hoffen, dass die Vermutung sich nicht bewahreitet oder zumindest dieser Designfehler hoffentlich bald behoben wird.

Mit dem Relational Database Service bietet Amazon jetzt ganz neu MySQL als Datenbank an. Dabei kann man die größe der Datenbankinstanz auswählen. Diese wird dann automatisch hochgefahren. Darüber hinaus kümmert sich Amazon auch um die wichtigsten Wartungsarbeiten und um Backups.

Instanzen mit mehr Arbeitsspeicher

Zusätzlich zu den High-CPU Instanzen führt Amazon jetzt auch High-Memory Instanzen ein. Die Instanzen hören auf die lustigen Namen Double Extra Large und Quadrupe Extra Large. Am Rande bemerkt, klingt das für mich irgendwie nach Fastfood…

Gesenkte Preise

Ab dem 1. November senkt Amazon darüber hinaus die Preise für die EC2 Instanzen um 15%. Für die EU-Instanzen bedeutet dies folgende neue Preise pro Stunde.

Standard

• Small: $ 0,095
• Large: $ 0,38
• Extra Large: $ 0,76

High-Memory

• Double Extra Large: $ 1,34
• Quadruple Extra Large: $ 2,68

High-CPU

• Medium: $ 0,19
• Extra Large: $ 0,76

15.5 Millionen Instanzen insgesamt: Amazon Usage Estimates