So to speak.
As I sit and watch the AWS emails come in about this new thing and that, I find myself trying to think of a "project" of sorts to really have more fun with the latest AWS offerings. Nothing is really coming to mind.
I'm not trying to create the next Twitter or anything. I just want to keep abreast of the latest technology. One thing I can say about RBX was that we were willing to "try" things if it made sense. I had an immensely fun time working on the Elf Island proposal to use EC2 and S3. Amazon has done a lot in the past year to address my biggest concerns with things. The addition of the management console is just awesome and makes me want to poke at it a bit more.
It's possible that I might move my various family galleries over to S3 backed storage. I'm looking at doing some WoW related stuff as well.
Who knows.
Maybe I'll go ahead and do that hosted Nagios thing I've been wanting to do for so long.
Showing posts with label Amazon EC2. Show all posts
Showing posts with label Amazon EC2. Show all posts
Tuesday, January 13, 2009
Monday, April 14, 2008
Amazon adds Persistent Storage
http://www.amazon.com/gp/html-forms-controller/ec2-persistent-storage
UPDATE: http://www.allthingsdistributed.com/2008/04/persistent_storage_for_amazon.html
Werner Vogels has more detail than I saw in the email at his blog. This is amazing. The ability to MOVE the volume from host to host is more icing on the cake. There is NO reason not to use Amazon EC2 as the starting point for hosting your entry into a new market space (assuming the SLA from Amazon meets your requirements). This is simply the cheapest way to spin up and the concepts are ones that you will use on your OWN environment should you host it yourself at some point.
I got this in my email. This is "a good thing". The biggest problem with EC2 was the fact that it did not offer persistent storage beyond the size of your root volume. Combine that with the performance of your S3 /mnt volume and you couldn't expect to host any database-driven applications of substantial size on there. Obviously people have done it but it required a few layers of complexity that made the solution more work than it was worth (i.e. replication with ANOTHER Amazon instance just to make sure that, should something happen and your VM went down, you didn't lose your database.
This was the BIGGEST sticking point I had with Amazon EC2. We made heavy use of the technology at RBX but the lack of a persistent volume made it simply inappropriate for any production quality applications. To use EC2 appropriately, you had to rethink your application architecture. Before I left, we actually had the opportunity to do that for a customer application that was being written from the ground up. The plan I proposed was to host certain static content and assets on S3 and also provide an EC2 gateway application for more specialized usage. This would shift the burden of bandwidth over to Amazon and provide a more predictable rate scale for the our customer's customers.
One of the biggest questions in a new internet application is hosting. Do you host it somewhere else where you might be limited to a single server and thus have performance probelms? How much bandwidth do we really need? Are we going to go broke OVER-purchasing resources (server capacity, bandwidth).
The Amazon persistent storage makes those choices a little less risky. I'm looking forward to creating some solutions on top of this.
UPDATE: http://www.allthingsdistributed.com/2008/04/persistent_storage_for_amazon.html
Werner Vogels has more detail than I saw in the email at his blog. This is amazing. The ability to MOVE the volume from host to host is more icing on the cake. There is NO reason not to use Amazon EC2 as the starting point for hosting your entry into a new market space (assuming the SLA from Amazon meets your requirements). This is simply the cheapest way to spin up and the concepts are ones that you will use on your OWN environment should you host it yourself at some point.
I got this in my email. This is "a good thing". The biggest problem with EC2 was the fact that it did not offer persistent storage beyond the size of your root volume. Combine that with the performance of your S3 /mnt volume and you couldn't expect to host any database-driven applications of substantial size on there. Obviously people have done it but it required a few layers of complexity that made the solution more work than it was worth (i.e. replication with ANOTHER Amazon instance just to make sure that, should something happen and your VM went down, you didn't lose your database.
This was the BIGGEST sticking point I had with Amazon EC2. We made heavy use of the technology at RBX but the lack of a persistent volume made it simply inappropriate for any production quality applications. To use EC2 appropriately, you had to rethink your application architecture. Before I left, we actually had the opportunity to do that for a customer application that was being written from the ground up. The plan I proposed was to host certain static content and assets on S3 and also provide an EC2 gateway application for more specialized usage. This would shift the burden of bandwidth over to Amazon and provide a more predictable rate scale for the our customer's customers.
One of the biggest questions in a new internet application is hosting. Do you host it somewhere else where you might be limited to a single server and thus have performance probelms? How much bandwidth do we really need? Are we going to go broke OVER-purchasing resources (server capacity, bandwidth).
The Amazon persistent storage makes those choices a little less risky. I'm looking forward to creating some solutions on top of this.
Subscribe to:
Posts (Atom)