Seite wählen

NETWAYS Blog

Da geh ich einfach zu Amazon – Bachelor of AWS

aws_cloudCloud-Dienste erfreuen sich bei vielen Anwendergruppen zunehmender Beliebtheit. Die hohe Flexibilität, der günstige Einstiegspreis und die scheinbar grenzenlose Skalierbarkeit machen einfach Lust, seine komplette IT-Infrastruktur in die Cloud zu migrieren. Viele Anwender unterliegen hier einfach dem Reiz der “Gratis-Compute-Power” und kostenlosem Storage für alle.
Damit der Einstieg leichter fällt, hat Branchenprimus Amazon den AWS Simple Monthly Calculator auf den Markt gebracht. Die Motivation dahinter ist denkbar einfach; IT-Infrastruktur als Commodity-Produkt soll für Jedermann leicht nutzbar und preislich transparent sein. Hat man sich dann also erfolgreich bei Amazon angemeldet und die letzten Artikel des Lebensabschnittpartners aus dem Warenkorb entfernt gibt es oft ein böses Erwachen. Der Simple-Calculatur ist nämlich nicht simple sondern complex wie Sau. So versucht der verwirrte IT-Leiter von Schrauben-Kunze dann schnell jemanden zu finden, der ihm ungefähr sagen kann wie viel Intra-Region-Data-Transfer er einbuchen muss und ob die IOPS für den lokalen Druckserver ausreichend sind. Final verwirrt, reserviert sich der Kunde dann noch eine für ihn stromerzeugende DynamoDB und stellt erst später fest, dass die ganze Kacke auch noch Kohle kostet.
Gemeinsam mit dem Bildungsministerium haben einige regionale Hochschulen diese Herausforderung am Markt erkannt und bieten, beginnend mit dem Sommersemester 2015, den Studiengang “Bachelor of AWS” an. Neben dem Umgang mit Rosen lernt man in dem fünfjährigen Grundstudium die Grundlagen des Simple-Calculators und bekommt halbjährlich eine Einführung in das sich wöchentlich ändernde Preismodell. Nach dem Studium ist der Studierende in der Lage die Software zu bedienen, Dritten bis zum nächsten Update zu erklären und die AWS-Status mit Hilfe von PhantomJS zu manipulieren.
Neben den mathematischen Herausforderungen des Studiums steht vor allem die Preisdifferenzierung im Vergleich zur “klassischen” IT-Infrastruktur im Vordergrund. Die damit verbundene Desillusionierung, dass irgendjemand etwas zu verschenken hat, wird in Kleingruppen und unter psychologischer Betreuung gemeinsam verarbeitet. “No Peak, No Cloud” ist hierbei von ebenso verbindlicher Bedeutung wie “Wer später bremst, fährt länger schnell”.
Wer sich noch dieses Jahr für die Anmeldung zum Fernstudium entscheidet, kann kostenlos an den angebotenen Vendor lock-in Workshops teilnehmen. Hier wird von anerkannten Industriespezialisten der Unterschied zwischen Commodity wie Strom und Internet und Commodity wie Cloud und Cloud erklärt. In kostspieligen Selbstversuchen werden komplette Unternehmensanwendungen APIfiziert und in die Cloud migriert. Nach einigen Wochen in Produktion soll die Plattform dann zurück ins eigene Rechenzentrum oder zu einem anderen Public-Cloud-Provider verschoben werden. Auch hier werden die Teilnehmer bei garantierten Schwierigkeiten nicht alleine gelassen, sondern rund um die Uhr von einem DevOps-Seelsorger-Team betreut.
Wer jetzt nicht dabei ist, macht definitiv einen Fehler. Alle anderen sind ja auch dabei!

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

SLA in der Cloud – Es ist nicht alles Gold was glänzt

Es ist eher Zufall das ich an Sebastians Cloud-Post vom letzten Dienstag anknüpfe, aber ich hatte es mir bereits am Montag vorgenommen. Vor einigen Tagen war bei Heise zu lesen, dass Amazon ein paar Schwierigkeiten mit einem Teil, Amazon nennt es AWS-Verfügbarkeitszone, des Datacenters in Virginia hatte. Amazon selbst beschreibt die Details auch ausführlich im entsprechenden RSS-Feed der Teil des Status-Monitors ist.
Der ein oder andere wird mit dem Status-Monitor und den zugrunde liegenden Informationen schon überfordert sein, aber die Transparenz möchte ich Amazon nicht vorwerfen. Hinzu kommt das die Kollegen ihren Laden mit Sicherheit im Griff haben und der ein oder andere Vortrag zum Thema hat mich schon von Amazons Können überzeugt. Vielmehr finde ich spannend wie Service aber auch Verfügbarkeit nach Außen definiert werden. Der Begriff Cloud-Services, die bei Amazon übrigens Web-Services heissen, muss im Moment ja nahezu für jeden IP-basierten Dienst herhalten, dessen Pakete beim Routing das eigene Firmengebäude verlassen. Ob Spotify, Dropbox oder iCloud, nahezu alles ist immer und überall erreichbar und ich muss mich um nichts mehr kümmern. Was ist aber wenn ich mich dafür entschieden habe meine Services in die „Cloud“ zu verlagern? Wie funktioniert das? Kann meine Anwendung das überhaupt?
Genau das ist nämlich die spannende Frage in der sich Vorstellung und Realität oft nicht die Hand geben. Gerade bei Amazon besteht das Angebot aus verschiedenen Diensten wie EC2, S3, Cloud Watch und allem möglichen anderen. Cloud-Services verwenden heisst nämlich eine Applikation aus verschiedenen Service-Komponenten zusammenzubauen und Internet-Dienste für DB, Routing oder Loadbalancing zu verwenden. Mit Services wie CloudWatch kann man die gebuchten Ressourcen dann auch überwachen und bei Bedarf Ressourcen hinzufügen.
Was aber passiert wenn Hardware im Rechenzentrum ausfällt? Die Antwort ist einfach. Nix!
Ich möchte niemanden desillusionieren, aber auch Cloud-Dienste laufen auf echter Hardware, die von Zeit zu Zeit mal den Geist aufgibt. Wenn das passiert kann ich mich informieren lassen und ggf. per Hand einen Ec2 Snapshot neu starten, von selbst jedoch passiert dort reichlich wenig. Die Kunden können sich durch die Online-Hilfe wühlen und schauen wie sie die entsprechenden Volumens wieder aus einem Snapshot recovern und die gebuchten Ressourcen online bringen. Ist ja eigentlich auch logisch dass man dort nicht alles für den Kunden machen kann, da man die Applikation ja nicht kennt und keine Ahnung hat, was wie zusammengehört.
Besonders spannend finde ich zwei Punkte aus der SLA-Definition zur Beschreibung der Verfügbarkeit und der daraus resultierenden Gutschriftsregelung:

  • Jeder Ausfall unter fünf Minuten ist nicht SLA-Relevant
  • Unavailable ist das System nur dann, wenn mind. zwei Availability Zones in denen man Systeme eingestellt hat nicht verfügbar sind

Was das bedeutet kann sich jeder selbst ausrechnen und aus meiner Sicht ist der SLA auch nicht verwerflich. Ob ich mich jedoch hinter dem Paperwork herauswagen und meine Gutschriftsregelung durchsetzen kann, wage ich zu bezweifeln. Einfach dargestellt bedeutet das für den Kleinanwender aus meiner Sicht einfach nur, dass man nix bekommt und auch keine Verfügbarkeitseinbusse besteht.
Wir messen uns täglich an den Herausforderungen im eigenen Rechenzentrum und es passieren auch Fehler. Sei es nun verursacht durch uns, den Kunden oder durch beide Seiten. Die besonderes spannende Mehrwert den wir aber den Kunden hier bieten ist das Wissen über Ihre Geschäftsmodell, Abhängigkeiten, Ansprechpartner und alldem was einen Kunden speziell macht, wenn man IP, Strom und Rackspace als Voraussetzung annimmt. Da kann ich mich nicht mit dem Angebot in der Wolke messen, sondern bin einfach besser!

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

High Performance in der Cloud kann teuer werden

Amazon bietet neuerdings in ihrer Cloud auch ein High Performance (HPC) Angebot, den sogenannten „EC2 Cluster Compute“. Es besteht aus hardware-virtualisierten Maschinen mit 2 Nehalem-CPUs und 23 GB Hauptspeicher, vernetzt durch 10 Gbit/s-Ethernet. Um das Angebot zu vermarkten, hat Amazon einen medienwirksamen Testlauf mit 880 Clusternodes durchgeführt, dabei fast 42 TFlop/s ermittelt und hätte damit theoretisch Platz 146 in der aktuellen Liste der Supercomputer erreicht.
Die Kollegen von science + computing haben nun in ihrem HPC Blog nachgerechnet, was das am Ende kostet und wie viel Geld man durch dieses Cloud Angebot einsparen kann. Das Ergebnis: Man spart gar nichts, man zahlt sogar deutlich drauf. Ein Beispielcluster aus 8 Nodes, der zu 70% ausgelastet ist, kostet je nach Abrechnungsmodel bei Amazon zwischen 62.400 USD und 79.000 USD jährlich. Würde man die gleiche Hardware im eigenen RZ aufbauen, kommt man auf jährliche Kosten von etwa 15.500 USD, also kostet die Amazon Lösung ungefähr 46.000 USD mehr als der Eigenbetrieb.
Natürlich ist das nur eine Beispielrechnung, die lediglich auf die Hardware und den Strompreis abstellt. Viele Zusatzkosten wie Storage, Deployment oder zusätzliche Dienstleistungen dürften aber in beiden Szenarien anfallen, so dass man sie letztendlich ausser acht lassen kann. Bei aller Vereinfachung sieht man trotzdem deutlich, dass die Cloud nicht per se günstiger ist und man schon mit sehr spitzem Bleistift nachrechnen muss. Nur bei einer Auslastung unter 20% wird die Amazon Lösung günstiger. Die Cloud rechnet sich also nur, wenn man lediglich hin und wieder mal einen HPC Cluster braucht.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.