Cloudcomputing / Cloud Computing Blog

Kurzmeldung:

Hatte Amazon bisher einen nicht besonders übersichtlichen Kalkulator für die Kostenberechnung, so darf man sich nun über eine verbesserte und bedienbare Version namens “AWS Simple Monthly Calculator” freuen.

Ohne grundlegende Kenntnisse des Abrechnungsystems und natürlich ohne möglichst genaue Informationen über den zu erwartenden Traffic wird man jedoch keine sinnvollen Ergebnisse erhalten können – “Endkundentauglich” ist das vielleicht nicht, aber in der Planung eines Projektes ein guter Anhaltspunkt für die Kostenprognose.

via AWS Blog

Wir sind gerade dabei, ein größeres Portal “in die Cloud”, d.h. zu Amazon AWS / EC2 umzuziehen. Dabei galt es heute zu klären, ob wir das System bei Amazon US oder EU (d.h. in den USA oder in Europa) hosten.

Reflexartig will man natürlich die Region hier vor der eigenen Haustür nehmen – dies bedeutet aber sofort einen ca. 10%igen Aufpreis auf die Zonen in den USA. Also will man genauer schauen:

Test 1: Ping Zeiten

Dies ergab hier aus Köln im mittel 40 ms für die Server in Europa und ca. 100 ms für die Server in den USA. Da es bei dem Projekt nicht um eine Realtime-Anwendung geht, kann man das sicher verschmerzen.

Test 2: Praxistest

Wir haben dann jeweils ein Testsystem an beiden Standorten eingerichtet, um einen halbwegs realistischen Test durchführen zu können.

Hierfür haben wir die kleinsten Server verwendet, alle Cachingsysteme ausgeschaltet (client- wie serverseitig) und möglichst komplexe Testseiten mit vielen Datenbankabfragen, vielen eingebundenen Files (mehrere CSS-Files, viele Grafiken), grossen Dateien (Videos zwischen 15 und 45 MB) etc. verwendet – die Server sollten also trotz der Testsituation zumindest ein wenig zu tun haben. Wir haben jeweils 5x je Seite gemessen und hieraus Mittelwerte berechnet.

All das ist beileibe keine hochwissenschaftliche Untersuchung, dennoch fand ich das Ergebnis bemerkenswert:

Eine grafische Aufbereitung macht das Verhältnis noch deutlicher klar:

Fazit: Trotz des ca. 10%igen Mehrpreises werden wir die erste Ausbaustufe wohl in Europa (d.h. Amsterdam) launchen, weil aktuell der größte Teil des Traffics aus Europa kommt.

Was im Artikel eigentlich noch fehlte: Woran die deutlich unterschiedliche Seitenauslieferungzeit nun schlussendlich lag, könnte natürlich nur ein Test zusammen mit den Amazon Technikern klären. Die Amazon AWS sind ja virtuelle Maschinen (auf XEN Basis) in einem grossen Rechenzentrum, wo verschiedene potentiell verzögernde Einflüsse untersucht werden müssten, so z.B. Auslastung (CPU, RAM, Festplatten, Netzwerk), Aussenanbindung etc. pp.

Ein Hinweis noch zu den gemessenen Zeiten: Erstaunlicherweise konnten die EU-Server ihren größten Vorteil 60,38% Geschwindigkeitsunterschied) bei derjenigen Testseite ausspielen, welche die größten Dateien eingebunden hatte. Wir hatten vor dem Test erwartet, dass die Unterschiede aufgrund der höheren Latenzen (s.o.; Pingzeiten) vor allem bei vielen kleinen Files auftreten würden und dass sich dies bei größeren Dateien egalisieren würde – was sich nicht bewahrheitet hat…

Wer vorhat, grosse Mengen von E-Mails (Newsletter, Mailinglisten, E-Mailings oder Notify-Mails für Communities) über AWS (Amazon Webservices / EC2) zu versenden, der sollte sich folgende Seite ansehen:

Warum, erklärt die Info von der o.g. Seite:

In order to maintain the quality of Amazon EC2 addresses for sending email, we enforce default limits on the amount of email that can be sent from EC2 accounts. If you wish to send larger amounts of email from EC2, you can apply to have these limits removed from your account by filling out this form.

Additionally, if you intend to send email from EC2, we suggest you provision one or more Elastic IP addresses (EIPs) and provide those addresses to us as part of this form. Amazon Web Services works with ISPs and Internet anti-SPAM organizations (like Spamhaus) to identify these validated EIPs to reduce the chance of your email being flagged as SPAM.

via

Nur eine kurze Meldung in eigener Sache:

Die papaya Software GmbH ist seit Anfang Oktober von Amazon bestätigter Amazon Webservices Solution Provider. papaya war bereits sehr früh in die Planungen eingebunden und ist somit gleich mit dem Beginn des Partnerprogramms mit dabei – zusammen mit europaweit ca. 25 Unternehmen insgesamt, darunter natürlich auch die Branchengrößen Oracle/Sun, IBM etc. pp.

Wir bei papaya bieten im Rahmen der AWS (Amazon Webservices) im wesentlichen 2 Leistungen an:

1. papaya Hosting in der Cloud – SAAS (Software as a service)
2. Consulting und Unterstützung bei der Migration bereits bestehender Webanwendungen “in die Cloud” bzw. in die Hostinginfrastruktur von Amazon – ganz gleich, ob es sich bei den Anwendungen um das papaya CMS handelt oder nicht.

Ich bin gerade über einen älteren Artikel auf netzpolitik.org gestolpert, der Bezug nimmt auf einen Beitrag im britischen Guardian.

Hierin wird Stallmann, der Kopf und Gründer der FSF (free software foundation) u.a. wie folgt zitiert:

(…) Stallman, founder of the Free Software Foundation and creator of the computer operating system GNU, said that cloud computing was simply a trap aimed at forcing more people to buy into locked, proprietary systems that would cost them more and more over time.

So aus dem Zusammenhang gerissen fragt man sich, was die Motivation von Stallman ist – muss man ihm doch bescheinigen, in den letzten Jahrzehnten stets eine Vordenkerrolle eingenommen zu haben. Eine grundsätzliche Verweigerungshaltung gegenüber neuen Entwicklungen ist ihm also keineswegs vorzuwerfen…

Was genau also liegt der Kritik zu Grunde?

Mehr…

Vergleicht man die Kosten für Amazon EC2 Maschinen (siehe hier) mit den Kosten für angemietete Webserver bei beliebigen Hostern, so muss man genau vergleichen: Die “on demand” an- und abschaltbaren EC2 Maschinen können dem Vergleich mit “normalen” Serverangeboten (gleich, ob es gute vserver oder Rootserver sind) kaum standhalten.

Da man im Normalfalle ja für ein Webangebot zumindest eine, oft mehrere Maschinen stets aktiviert haben wird,kann man für diese Server sogenannte “Reserved Instances” nutzen. Dies entspricht technisch und auch preislich eher dem bisher üblichen Modell: Man mietet Server nicht nach Stunden, sondern mit einer längeren Vertragslaufzeit. Lediglich die variabel verwendeten Server (z.B. weitere Webserver oder Datenbankserver werden ja nach Last hinzugeschaltet) werden dann zum normalen EC2 Tarif abgerechnet.

(Diese Information war zwar stets auf der o.g. Amazon Website verfügbar, wurde allerdings oftmals übersehen, was zu einigen Missverständnissen hinsichtlich des Preisvorteils beim EC2 Angebot führte.)

Nun hat Amazon die Preise für die “Reserved Instances” abermals gesenkt:

We wanted to let you know that, starting today, we have lowered the one-time fee for all Amazon EC2 Reserved Instances by 30%. We continuously strive to be more efficient, and to pass cost savings on to you in the form of lower prices. With Linux Amazon EC2 Reserved Instances, you could reduce the cost of your instance usage by up to 56% compared to an On-Demand instance. When using Reserved Instances, you pay a low, one-time fee to guarantee capacity for each instance during a 1 or 3 years period. You then have the option to run that instance whenever you want, at a greatly reduced hourly rate.

Somit ergibt sich folgendes Bild für die günstigste Maschine namens “Small (Default)”:

Man liegt also im Bereich von 39 $ pro Monat (gerechnet für eine Maschine als “reserved instance” mit dreijähriger Laufzeit), entsprechend ca. 27,40 EUR. Verglichen mit dem Angebot eines hochwertigeren Anbieters für “normale vserver” (z.B. Hosteurope, wo man bei rund 13 EUR / Monat liegt) ist das kein geringer, aber auch kein astronomischer Unterschied.

Bei der Betrachung müssen aber neben den reinen Kosten eben auch die Features einbezogen werden – und diese sind bei Amazon durchaus einzigartig und werden von keinem normalen Hoster offeriert: Angefangen bei der Verfügbarkeit und der dank EC2 vorhandenen Flexibilität und nutzungsabhängigen Abrechnung über S3, Elastic Block Storage, availability zones, elastic IP etc. pp. – all dies einbezogen, lautet mein Fazit: Mit den reserved Instances spricht eigentlich nichts dagegen, die Amazon Webservices auch für statische Maschinen (d.h. solche, die stets angeschaltet sind) zu nutzen. Der Kostennachteil wird durch die umliegenden Services m.E. aufgewogen.

All dies gilt aber wohl nur im Business-Umfeld – für eine kleine private Website ist der Dienst weder ausgelegt noch kalkuliert.