Posts Tagged S3
Cloud Computing – DLD09
Posted by Lars Schenk in Video, Virtualisierung on Januar 28th, 2009
If I had to convince a non technical person about Cloud Computing, I would show him this video.
I really enjoyed listening to Dr. Werner Vogels. Dr. Vogels is Vice President & Chief Technology Officer at Amazon.com where he is responsible for driving the company’s technology vision, which is to continuously enhance the innovation on behalf of Amazon’s customers at a global scale.
This vision is why I have moved to EC2/S3 in 2007. I guess, I’ve finally become an Amazon AWS fan boy.
Even if audio is a bit out of sync, it’s worth to listening this long session.
As a developer from the bottom of my heart I like especially this quote: “There is no value in being a system administrator. You do not build a better product by being a better server maintainer.” This is so true, but I wonder how EC2 can free me from typical administration tasks. I still have to maintain my virtual server instances with the whole LAMP stack. Plus I have to think about how to scale horizontally (what to do when I need more virtual server instances).
In contradiction to Amzon’s EC2, Google’s AppEngine promises to free me from doing the admin tasks (no OS/LAMP Stack to maintain) and to solve the scale problem (no Database Replication to set up). AppEngine scales out of the box – the downside is, that it offers a very limited runtime just for you app.
True, a single EC2 instance doesn’t scale out of the box but it also doesn’t limit you in doing what you want to do on your virtual server. With EC2 I have to solve the scaling on my own. For this price I got more freedom.
I’m exited to use and learn about EC2/S3/Storefront each day but I also hope that Google’s AppEngine will offer a wider range of runtime environments in the future. t’s an interesting Cloud-Year 2009! #buzzword
Amazon CloudFront – Content Delivery Network für S3
Posted by Lars Schenk in tech-recipes, Virtualisierung on November 20th, 2008
CloudFront ist eine sinnvolle Erweiterung für Amazon S3: Wenn man S3 bisher als Asset-Server für statische Inhalte eingesetzt hat, so muss man sich für einen Standort entscheiden der möglichst nahe an der Zielgruppe betrieben wird. Ist meine Zielgruppe Europa, so wähle ich den S3 Standort dort und nehme in Kauf, dass User aus USA eine höhre Latenzzeit haben werden.
Mit CloudFront kann ich nun vor meinen öffentlichen S3 noch ein Content Delivery Network vorschalten, dass automatisch meine Inhalte über alle verfügbaren Standorte synchronisert und bei Requests auf meine Inhalte immer die schnellste Verbindung auswählt. Mehr Details zur neuen CloudFront, dem Content Delivery Network von Amazon gibt’s unter aws.amazon.com/cloudfront/ und im original Wortlaut des Developer-Newsletters. Read the rest of this entry »
Google App Engine – Eldorado für Entwickler
Posted by Lars Schenk in Video, Virtualisierung on April 9th, 2008
Google hat eine frühe Version der App Engine vorgestellt (Preview). Es verspricht mir all die Administrativen Task abzunehmen, die ich üblicherweise habe, wenn ich meine Web-Anwendung online bringen will. Ich brauche mich nicht mehr um Server kümmern (seien es klassische RootServer beim Hoster oder virtuelle Server wie z.b. bei EC2). Ich muss mich nicht mehr darum kümmern, wie meine Applikation skaliert. Ich muss also keinen Mechanismus entwicklen wie bei EC2 wo ich meine Server und die Last überwache und ausgefallene Server ersetzte bzw. dynamsch weitere virtutelle Serverinstanzen zuschalten muss wenn mehr Last aufkommt – das alles macht Google App Engine automatisch für mich!
Es entlastet mich als Entwickler von all diesen adminstrativen Tasks die ich überlicherweise beim LAMP Stack habe. Es macht quasi den Administrator in mir arbeitslos und schenkt dem Entwickler in mir die frei gewordene Zeit um mich auf die Anwendung zu konzentrieren.
Teil 1 – Vorstellung der Google App Engine Preview:
Ab 2:50 stellt Kevin Gibbs die Vorteile der App Engine gegenüber dem klassischen LAMP Stack vor. Read the rest of this entry »
Amazon SimpleDB
Posted by Lars Schenk in Virtualisierung on Dezember 14th, 2007
Wow, nach dem Release von Rails2 gibt es nun auch noch ein Weihnachtsgeschenk von Amazon:
Dear AWS Developers,
This is a short note to let a subset of our most active developers know about an upcoming limited beta of our newest web service: Amazon SimpleDB, which is a web service for running queries on structured data in real time. This service works in close conjunction with Amazon Simple Storage Service (Amazon S3) and Amazon Elastic Compute Cloud (Amazon EC2), collectively providing the ability to store, process and query data sets in the cloud.
Traditionally, this type of functionality has been accomplished with a clustered relational database that requires a sizable upfront investment, brings more complexity than is typically needed, and often requires a DBA to maintain and administer. In contrast, Amazon SimpleDB is easy to use and provides the core functionality of a database – real-time lookup and simple querying of structured data – without the operational complexity.
Were excited about this upcoming service and wanted to let you know about it as soon as possible. We anticipate beginning the limited beta in the next few weeks.
Seite zum Beta-Projekt bei Amazon: Amazon SimpleDB und Developer Guide.
AWS-Blog: A Place for Everything – Amazon SimpleDB
Skalieren mit Amzon EC2 und S3
Posted by Lars Schenk in tech-recipes on Dezember 11th, 2007
Jonathan Weiss zeigt in seinem Blog eine überarbeitete Version seines Vortrags zur Skalierung vom Ruby on Rails Apps mittels Amazon EC2 und S3.
Eine etwas älteres Video von seinem Vortrag (mit zum Teil überholten Aussagen, siehe hier und hier), welches aber dennoch wirklich ansehenswert ist, gibt es unter: www.loromoar.com.
Jonathan stellt im Slide 34/35 “EC2 for extra capacity” ein optionales Model vor, bei dem für die DB und den Loadbalancer ein Inhouse-Lösung angetrebt wird (Eigens RZ oder klassischer Hoster). Die Gründe dafür deutet er auch schon im Video an (welches dieses Modell noch nicht zum Gegenstand der Diskussion gemacht hatte): EC2 hat kein persistentes Speichermedium. Fällt die Instanz aus, gehen die Daten verloren. Wenn nicht konstant dedumpt und auf S3 gesichert wird, droht Datenverlust.
Ich fürchte jedoch das gerade bei RoR-Anwendungen recht komplexe und viele SQL Abfragen entstehen, so das sich eine erhöhte Latenz zwischen den Application-Servern die unter EC2 laufen und der Datenbank, die inhouse läuft sehr negativ auf die Antwortzeiten auswirken könnte. Ich würde daher lieber die DB@EC2 belassen und das Verlustrisiko von Daten minimieren indem eine Replikation (Slave) in eine oder mehrere EC2 Instanzen oder auch auf einen Slave im eigenen RZ gemacht wird. Der Vorteil dabei ist, dass die Application-Server kürzere Latenzzeiten zur DB haben und der Traffic innerhalb EC2 bleibt und somit auch kostenlos ist. Fällt die Master-DB aus, so kann ein Slave die Aufgabe übernehmen.
Das Argument den Loadbalancer Inhouse zu nehmen ist, dass beim Ausfall des EC2 basierten Loadbalancers eine neue IP zugewiesen wird und es somit zur vorübergehenden Unerreichbarkeit kommen kann, wenn DNS-Server die Updates nicht rasch genug verarbeiten. Steht der Loadbalancer hingegen im eigenen RZ oder beim klassischen Hoster habe ich eine statische IP und kann das Problem (eher) umgehen, so dass keine DNS-Update erforderlich wird.
Aber man erkauft sich diesen Vorteil zum einen durch mehr Latenzzeit: der Loadbalancer muss nun alle Requests erst an die weit entfernten EC2 Instanzen weiterreichen und auf deren Antwort warten. Der Weg von den Clients zum Loadbalaner kommt in diesem Fall dann noch hinzu. Hier kann es sich dann schon lohnen über eine Proxy/Cash-Lösung nachzudenken. Was aber ebenfalls noch zu berücksichtigen ist: Ich habe nun zwei mal den Traffic zu bezahlen: Einmal zwischen EC2 und dem Loadbalancer und hinzu dann noch der Traffic zwischen dem Loadbalancer und den Clients.
Also auf den ersten Blick würde ich den Loadbalancer doch lieber auch bei EC2 einsetzen…
Ein recht radikaler aber genialer Ansatz ist der Verzicht auf einen dedizierten Loadbalancer.
Lei Zhu beschreibt in seinem Aritkel wie man das Problem mit der dynamischen IP lösen kann indem man ganz auf einen Loadbalancer verzichtet und das Konzept und die Aufgabe des Loadbalancers gleich auf den Client überträgt: Client-Side Loadbalancing!
Zum Slide: Read the rest of this entry »
Amazon S3 nun auch in Europa verfügbar.
Posted by Lars Schenk in Virtualisierung on November 9th, 2007
Nachdem Amazon erst kürzlich die EC2 Instanzen “Large” und “Extra Large” eingeführt hat, stößt Amazon nun mit dem Simple Storage Service (S3) nun auch nach Europa vor:
United States
Storage
$0.15 per GB-Month of storage usedData Transfer
$0.10 per GB – all data transfer in
$0.18 per GB – first 10 TB / month data transfer out
$0.16 per GB – next 40 TB / month data transfer out
$0.13 per GB – data transfer out / month over 50 TBRequests
$0.01 per 1,000 PUT or LIST requests
$0.01 per 10,000 GET and all other requests*
* No charge for delete requestsEurope
Storage
$0.18 per GB-Month of storage usedData Transfer
$0.10 per GB – all data transfer in$0.18 per GB – first 10 TB / month data transfer out
$0.16 per GB – next 40 TB / month data transfer out
$0.13 per GB – data transfer out / month over 50 TBRequests
$0.012 per 1,000 PUT or LIST requests
$0.012 per 10,000 GET and all other requests*
* No charge for delete requests
Zwar sind die die Preise etwas höher als S3 in den USA, aber wenn man plant statischen Content via public buckets verfügbar zu machen, so ist S3 mit Standbein in Europa diesen Aufpreis ganz sicher wert.
Für die Verwendung mit EC2 bleibt S3 USA natürlich attraktiver, da es nicht nur schneller sein dürfte sondern hier auch der Traffic zwischen EC2 und S3 USA kostenfrei ist. Traffic zwischen EC2 und S3 Europa hingegen ist kostenpflichtig.
Damit wird greifbar, was ich mir schon länger wünsche: EC2 auch in Europa.
Automatisierte Backups nach Amazon S3 mit s3sync
Posted by Lars Schenk in Linux, tech-recipes on August 28th, 2007
Um meine Daten nach Amazon S3 zu sichern, habe ich mich unter der vielzahl verfügbarer Tools für S3Sync entschieden. Da dieses in ruby geschriebene Tools sich an rsync anlehnt und es auch unter Amazon EC2 wertvolle Dienste erbringt um das flüchtige Filesystem der virtuellen Server persistent zu halten, ist es für mich die erste Wahl.
Auf einer Debian (oder auch Ubuntu) basierten Linux Distribution erfolgt die Installation mit: Read the rest of this entry »
Latest comments