Amazon's Utility Computing Platform EC2 zeichnet sich durch eine einfache Skalierbarkeit aus. Für Anwender die allerdings nicht kurzfristig mehrere hundert Compute Instanzen benötigen war das Pricing nicht so attraktiv. Amazon hat nun Reserved Instances angekündigt. Kann man sich auf eine gleichmäßige Nutzung einer Instanz committen, so sinken die Nutzungspreise erheblich. Ich habe das mal (bei einer Monatsnutzng von 30*24h) hochgerechnet:
Das Modell scheint bisher noch nicht für die Windows Server verfügbar zu sein. Details unter EC2 Pricing.
Was ich bei Amazon immer wieder gut finde ist es wie durch einfache Bezahlmodelle Anreize für ein bestimmtes Userverhalten geschaffen wird, und dies dank der Anzahl der Benutzer skaliert. Z.b. die Möglichkeit IP Addressen zu reservieren, und solange man diese nutzt sind sie kostenlos. So langsam kommt Amazon mit diesem Pricing in die Regionen von normalen V-Servern (mit dem zusätzlichen Benefit dass man jederzeit mehr Ressourcen auf Stundenbasis dazuschalten kann). Ganz konkurenzfähig sind die Server allerdings immer noch nicht - trotz Dollar Kurs.
| Instanz | Stundenpreis | Norm Monat | Monat 1y | Monat 3y |
|---|---|---|---|---|
| Small | $0,10/$0,05 | $72 | $48,68 | $35,49 |
| XL | $0,80/$0,24 | $576 | $390 | $284 |
Das Modell scheint bisher noch nicht für die Windows Server verfügbar zu sein. Details unter EC2 Pricing.
Was ich bei Amazon immer wieder gut finde ist es wie durch einfache Bezahlmodelle Anreize für ein bestimmtes Userverhalten geschaffen wird, und dies dank der Anzahl der Benutzer skaliert. Z.b. die Möglichkeit IP Addressen zu reservieren, und solange man diese nutzt sind sie kostenlos. So langsam kommt Amazon mit diesem Pricing in die Regionen von normalen V-Servern (mit dem zusätzlichen Benefit dass man jederzeit mehr Ressourcen auf Stundenbasis dazuschalten kann). Ganz konkurenzfähig sind die Server allerdings immer noch nicht - trotz Dollar Kurs.
Schon bisher haben Firmen die Amazon S3 Storage Cloud für die Auslieferung von Bildern und Downloads genutzt. Allerdings hatte S3 im vergleich zu den anderen kommerziellen Content Delivery/Distribution Networks einen Performance Nachteil: wenn man ein CDN in die Web Site einbindet, so erhofft man sich Performance Vorteile insbesondere im Bereich Latenz. Das bedingt Caches die in die Nähe der User repliziert werden.
Amazon hat reagiert, mit der Public Beta zu Cloudfront kann man jetzt eine solche automatische Replikation und globales (DNS) load balancing aktivieren. Preise bewegen sich zwischen 17 und 22 USD cent je GB (je nach Abrufort). Dazu kommen noch 1,2-1,3 cent pro 10.000 GET Requests und die normalen S3 Gebühren für Storage und der Replikation des Content zu den Caches. Dieses einfach Preismodell könnte den Anbietern wie Akamai ziemlich nahe gehen - zumindest solange es um statischen Content geht.
Die folgenden 14 Standorte bietet Amazon für die Verteilung an: United States (Ashburn, VA; Dallas/Fort Worth, TX; Los Angeles, CA; Miami, FL; Newark, NJ; Palo Alto, CA; Seattle, WA; St. Louis, MO); Europe (Amsterdam; Dublin; Frankfurt; London), Asia (Hong Kong; Tokyo).
Bekannte Einschränkungen (laut RightScale blog): kein HTTPS, keine detaillierten Usage Reports, kein Streaming, nur Public S3 Content und kein Fine-Tuning der Caches möglich.
Zum Weiterlesen
Werner Vogels' Ankündigung (Amazon CTO).
Jeff Barr's Ankündgung auf dem AWS Blog
Amazon hat reagiert, mit der Public Beta zu Cloudfront kann man jetzt eine solche automatische Replikation und globales (DNS) load balancing aktivieren. Preise bewegen sich zwischen 17 und 22 USD cent je GB (je nach Abrufort). Dazu kommen noch 1,2-1,3 cent pro 10.000 GET Requests und die normalen S3 Gebühren für Storage und der Replikation des Content zu den Caches. Dieses einfach Preismodell könnte den Anbietern wie Akamai ziemlich nahe gehen - zumindest solange es um statischen Content geht.
Die folgenden 14 Standorte bietet Amazon für die Verteilung an: United States (Ashburn, VA; Dallas/Fort Worth, TX; Los Angeles, CA; Miami, FL; Newark, NJ; Palo Alto, CA; Seattle, WA; St. Louis, MO); Europe (Amsterdam; Dublin; Frankfurt; London), Asia (Hong Kong; Tokyo).
Bekannte Einschränkungen (laut RightScale blog): kein HTTPS, keine detaillierten Usage Reports, kein Streaming, nur Public S3 Content und kein Fine-Tuning der Caches möglich.
Zum Weiterlesen
Werner Vogels' Ankündigung (Amazon CTO).
Jeff Barr's Ankündgung auf dem AWS Blog
Amazon wurde gefeiert als sie SLAs für Ihre Cloud Offerings angeboten haben. Das bezieht sich insbesondere auf die Amazon Web Services Dienste S3 (Storage Cloud), EC2 (Compute Cloud), ECB (Elastic Block Storage) und die Host Lösungen für Queueing (SQS) und Datenbank (SimpleDB).
Betrachtet man sich allerdings die SLAs, so muss man sagen diese sind ziemlich nutzlos in einem kommerziellen Umfeld (um traditionalle Bedenken zu zerstreuen):
Die neuen EC2 SLA definieren, dass ein Kunde 10% der Gebühren für die letzten 365 Tage zurückerstattet bekommt, wenn die Verfügbarkeit unter 99.5% fällt. Dabei wird die Zurückerstattung nur für zukünftige Gebühren gut geschrieben. Die Zurückerstattung ist auf 10% gedeckelt. Strafen/Schadensersatz werden keine zugestanden. Und zu allem Übel ist die Definition der Verfügbarkeit noch so, dass der Kunde sich selbst darum kümmern muss ausgefallene Instanzen neu zu starten, und nur wenn dies nicht gelingt gilt der Service als ausgefallen. D.h. wenn eine Amazon Instanz alle Stunde ausfällt und der Startup einer neuen Instanz 5mins dauert, so gelten diese 5 Minuten nicht als Ausfall.
Bei den S3 SLA werden Gutschriften für erfolglose Requests gezählt. 10% bei unter 99.9% und 25% bei unter 99%. Dabei kann Amazon aber weder Requests zählen die nicht angekommen sind, noch steht Amazon mit Strafen/Schadensersatz für Datenverlust ein. Gleiches gilt für EBS, hier gibt es keine SLA, die typische jährliche Fehlerrate (AFR - Anual Failure Rate) wird mit 0.1% - 0.5% angegeben (Lokale Harddisks haben angeblich 4%).
Natürlich wird AWS durch diese SLA unter Druck gesetzt einen guten Service zu erbringen. Von daher haben diese schon einen Effekt. Der Kunde muss darauf aber vertrauen und das Risiko eines Schadens komplett selbst tragen. Eine reduzierte Amazon Rechnung wird Ihn da kaum trösten.
Cloud Computing definiert nicht nur die Technologie neu, sondern auch die Ökonomie des Outsourcings: statt ewig Langer Vertragsverhandlungen, umfangreichen SLA Monitorings, Schuldzuweisungen und umfangreiche Konventionalstrafen (die zu Aufschlägen beim Betreiber führen um sein Risiko abzusichern) wird auf ein Kooperatives Vorgehen gesetzt, das von Vertrauen geprägt ist. Deswegen haben es auch die Großen Anbieter in dem Markt einfacher akzeptiert zu werden. Die technischen Vorkehrungen die ein Betreiber trifft werden stärker betrachtet als seine Vertraglichen Zusagen. Zusätzlich ist die Lösung durch den Kunden schon stärker auf Ausfall ausgelegt.
(Diesen Artikel nehme ich zum Anlass eine neue Cloud Kategorie hier im Blog einzuführen)
Betrachtet man sich allerdings die SLAs, so muss man sagen diese sind ziemlich nutzlos in einem kommerziellen Umfeld (um traditionalle Bedenken zu zerstreuen):
Die neuen EC2 SLA definieren, dass ein Kunde 10% der Gebühren für die letzten 365 Tage zurückerstattet bekommt, wenn die Verfügbarkeit unter 99.5% fällt. Dabei wird die Zurückerstattung nur für zukünftige Gebühren gut geschrieben. Die Zurückerstattung ist auf 10% gedeckelt. Strafen/Schadensersatz werden keine zugestanden. Und zu allem Übel ist die Definition der Verfügbarkeit noch so, dass der Kunde sich selbst darum kümmern muss ausgefallene Instanzen neu zu starten, und nur wenn dies nicht gelingt gilt der Service als ausgefallen. D.h. wenn eine Amazon Instanz alle Stunde ausfällt und der Startup einer neuen Instanz 5mins dauert, so gelten diese 5 Minuten nicht als Ausfall.
Bei den S3 SLA werden Gutschriften für erfolglose Requests gezählt. 10% bei unter 99.9% und 25% bei unter 99%. Dabei kann Amazon aber weder Requests zählen die nicht angekommen sind, noch steht Amazon mit Strafen/Schadensersatz für Datenverlust ein. Gleiches gilt für EBS, hier gibt es keine SLA, die typische jährliche Fehlerrate (AFR - Anual Failure Rate) wird mit 0.1% - 0.5% angegeben (Lokale Harddisks haben angeblich 4%).
Natürlich wird AWS durch diese SLA unter Druck gesetzt einen guten Service zu erbringen. Von daher haben diese schon einen Effekt. Der Kunde muss darauf aber vertrauen und das Risiko eines Schadens komplett selbst tragen. Eine reduzierte Amazon Rechnung wird Ihn da kaum trösten.
Cloud Computing definiert nicht nur die Technologie neu, sondern auch die Ökonomie des Outsourcings: statt ewig Langer Vertragsverhandlungen, umfangreichen SLA Monitorings, Schuldzuweisungen und umfangreiche Konventionalstrafen (die zu Aufschlägen beim Betreiber führen um sein Risiko abzusichern) wird auf ein Kooperatives Vorgehen gesetzt, das von Vertrauen geprägt ist. Deswegen haben es auch die Großen Anbieter in dem Markt einfacher akzeptiert zu werden. Die technischen Vorkehrungen die ein Betreiber trifft werden stärker betrachtet als seine Vertraglichen Zusagen. Zusätzlich ist die Lösung durch den Kunden schon stärker auf Ausfall ausgelegt.
(Diesen Artikel nehme ich zum Anlass eine neue Cloud Kategorie hier im Blog einzuführen)
Oracle und Amazon arbeiten zusammen um Oracle Anwendungen im Amazon Grid anzubieten. Es gibt jetzt einige Images die von Oracle kostenlos bereitgestellt werden. Oracle erlaubt sogar den Betrieb von Produktiven lizenzierten Anwendungen im EC2 Grid. Die Konfiguration ist sogar für offiziellen Support zertifiziert.
Besonders interessant sind aber auch die Möglichkeiten die vorinstallierten Anwendungen wie Application Express oder Enterprise Manager Grid einfach mal ausprobieren zu können.
Besonders interessant sind aber auch die Möglichkeiten die vorinstallierten Anwendungen wie Application Express oder Enterprise Manager Grid einfach mal ausprobieren zu können.
Geschrieben von Bernd Eckenfels
in Cloud, Datenbanken, Infrastruktur, Vernetzung
| Kommentare (0)
| Trackbacks (0)
Im Gegensatz zum Begriff Grid Computing ist das Thema Cloud computing etwas eindeutiger definiert. Es geht darum IT-Resourcen (Rechner oder Laufzeitumgebungen) aus der Wolke des Internets einzukaufen, also die Anwendungen remote zu betreiben.Die bekanntesten Vertreter dieses Genres sind Amazon's EC2 (Elastic Cloud Computing - eine Serverfarm auf der man Xen Images auf Stundenbasis laufen lassen kann) und Google App Engine (eine Python Web Server umgebung für Web Anwendungen).
Beide haben grade aktuell Neuigkeiten zu vermelden: Google App Engine ist nun offen für alle Entwickler (die kostenfreie Einsteigerversion erfordert eine SMS Registrierung, und kann auch mit Google Apps for Domains zusammenarbeiten).In der Public Beta des Amazon Cloud Services werden bald persistente Volumes möglich sein: damit sind dann auch klassische Enterprise Anwendungen einfach zu betreiben und nicht nur Compute Jobs (Video Rendering) oder replizierte Datenbanken.
In zwei kommenden Artikel will ich beide Dienste etwas näher vorstellen, und meine Bewertung dazu abgeben wo und wie das Utility Computing funktionieren kann.
(Seite 1 von 1, insgesamt 5 Einträge)
Layout by Ricky Wilson | Serendipity Template by Carl Galloway | Login
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-10@eckenfels.net
Read More
Suche
Kategorien
Umfrage
Wirtschaftskrise
Archive
Archive
Blog abonnieren
Blogsphere
Top Referers
www.google.de (22)
justintv.bukb.0lx.net (6)
flighttracker.leadhoster.com (5)
hoteljobs.net23.net (4)
spiderman3.yourfreehosting.net (4)
zagasdasa.ru (4)
aeropostalecan.scienceontheweb.net (3)
autotraderni.superihost.com (3)
avatartrailer.awardspace.co.uk (3)
besplatnifilmovi.prv.pl (3)
justintv.bukb.0lx.net (6)
flighttracker.leadhoster.com (5)
hoteljobs.net23.net (4)
spiderman3.yourfreehosting.net (4)
zagasdasa.ru (4)
aeropostalecan.scienceontheweb.net (3)
autotraderni.superihost.com (3)
avatartrailer.awardspace.co.uk (3)
besplatnifilmovi.prv.pl (3)
Top Exits
www.golem.de (66)
www.heise.de (54)
www.oasis-open.org (37)
www.mela.de (36)
www.microsoft.com (35)
itblog.eckenfels.net (33)
blogs.msdn.com (29)
blogs.sun.com (29)
twitter.com (29)
www.ddvg.de (25)
www.heise.de (54)
www.oasis-open.org (37)
www.mela.de (36)
www.microsoft.com (35)
itblog.eckenfels.net (33)
blogs.msdn.com (29)
blogs.sun.com (29)
twitter.com (29)
www.ddvg.de (25)

Kommentare