31–40 of 65 posts
5 years, 1 month and 28 days after S3 is publicly launched. It is just a reminder that the threat by incumbents to startups is hardly worth worrying about.
A compelling reason for our use case to switch from S3 is their support for lots of buckets coupled with CNAME support: http://code.google.com/apis/storage/docs/reference-uris.html Due to Amazon's limitation of 100 buckets per account and the coupling between bucket name and CNAME, hosting files for our clients and supporting custom CNAMEs has not been possible for us. If we were to move to Google Storage, it would b…
Another good reason for certain use cases is its support for resumable uploads: http://code.google.com/apis/storage/docs/developer-guide.htm... Afaik S3 can't do that.
http://aws.typepad.com/aws/2010/11/amazon-s3-multipart-uploa...
So if a bunch of people from Japan decide to download from your app, you are screwed.
5 years, 1 month and 28 days after S3 is publicly launched. It is just a reminder that the threat by incumbents to startups is hardly worth worrying about.
Wait, who's the incumbent and who's the startup? Amazon was founded four years before Google...
5 years to clone a product that Google already has the infrastructure for and is within Google's core mission seems excessively long.
5 years, 1 month and 28 days after S3 is publicly launched. It is just a reminder that the threat by incumbents to startups is hardly worth worrying about.
Amazon was hardly a startup 5 years ago. And we're talking about a service and a space that's difficult to replicate and get into. S3 had resources most startups won't have to get that 5-year lead.
5 years, 1 month and 28 days after S3 is publicly launched. It is just a reminder that the threat by incumbents to startups is hardly worth worrying about.
Amazon was hardly a startup 5 years ago. And we're talking about a service and a space that's difficult to replicate and get into. S3 had resources most startups won't have to get that 5-year lead.
* who, even worse for their case, already had the infrastructure, resources, engineers, etc. to get it done.
Earlier quoted context omitted.
Oh it gets much worse if you assume that you replace your hard drives every 3 years (their warranty period) which would add a $1.94/month depreciation cost. You could add into the cost / GB of bandwidth to access the files, not as easy to factor into a TCO model in the personal use case.
The way I was accounting for it you have to replace the drive in 3 years, you have 3 drives. So you've got a cost of $210 that recurs every three years (purchasing the drives). If you distribute that cost across the 36 months that is a $5.83/month fixed cost (doesn't vary by storage usage because you have to replace the entire drive). Unlike Google which can amortize depreciation on a per-GB basis because they are sp…
A compelling reason for our use case to switch from S3 is their support for lots of buckets coupled with CNAME support: http://code.google.com/apis/storage/docs/reference-uris.html Due to Amazon's limitation of 100 buckets per account and the coupling between bucket name and CNAME, hosting files for our clients and supporting custom CNAMEs has not been possible for us. If we were to move to Google Storage, it would b…
I just wish either one would support SSL for CNAMEd buckets.
If you don't like it, ask your browser vendor to support section 3.1 of RFC 3546.