S3: All content tagged as S3 in NoSQL databases and polyglot persistence
Monday, 29 April 2013
Amazon Web Services Annual Revenue Estimation
Over the weekend, Christopher Mims has published an article in which he derives a figure for Amazon Web Services’s annual revenue: $2.4 billions:
Amazon is famously reticent about sales figures, dribbling out clues without revealing actual numbers. But it appears the company has left enough hints to, finally, discern how much revenue it makes on its cloud computing business, known as Amazon Web Services, which provides the backbone for a growing portion of the internet: about $2.4 billion a year.
There’s no way to decompose this number into the revenue of each AWS solution. For the data space I’d be interested into:
-
S3 revenues. This is the space Basho’s Riak CS competes into.
After writing my first post about Riak CS, I’ve learned that in Japan, the same place where Riak CS is run by Yahoo! new cloud storage, Gemini Mobile Technologies has been offering to local ISPs a similar S3-service built on top of Cassandra.
-
Redshift is pretty new and while I’m not aware of immediate competitors (what am I missing?), I don’t think it accounts for a significant part of this revenue. Even if some of the early users, like AirBnb, report getting very good performance and costs from it.
Redshift is powered by ParAccell, which, over the weekend, has been acquired by Actian.
-
Amazon Elastic MapReduce. This is another interesting space from which Microsoft wants a share with its Azure HDInsight developed in collaboration with Hortonworks.
In this space there’s also MapR and Google Compute combination which seem to be extremely performant.
-
Interestingly Amazon is making money also from some of the competitors of its Amazon Dynamo and RDS services. The advantage of owning the infrastructure.
Original title and link: Amazon Web Services Annual Revenue Estimation (©myNoSQL)
Monday, 16 July 2012
From S3 to CouchDB and Redis and Then Half Way Back for Serving Ads
The story of going form S3 to CouchDB and Redis and then back to S3 and Redis for ad serving:
The solution to this situation has a touch of irony. With Redis in place, we replaced CouchDB for placement- and ad-data with S3. Since we weren’t using any CouchDB-specific features, we simply published all the documents to S3 buckets instead. We still did the Redis cache warming upfront and data updates in the background. So by decoupling the application from the persistence layer using Redis, we also removed the need for a super fast database backend. We didn’t care that S3 is slower than a local CouchDB, since we updated everything asynchronously.
Besides the detailed blog post there’s also a slidedeck:
Original title and link: From S3 to CouchDB and Redis and Then Half Way Back for Serving Ads (©myNoSQL)
via: http://dev.adcloud.com/blog/2012/07/13/nosql-not-only-a-fairy-tale/
Wednesday, 28 March 2012
Basho Announces Riak-Based Multi-Tenant, Distributed, S3-Compatible Cloud Storage Platform
Coverage of the announcement of a new product from Basho: Riak CS: a multi-tenant, distributed, S3-compatible cloud storage platform:
- Klint Finley got the scoop: NoSQL Company Basho Unveils New Cloud Storage Software
- PR announcement
- Barb Darrow for GigaOm: Basho arms would-be Amazon killers with AWS-compatible storage
- Sudheer Raju for Tools Journal: Riak CS From Basho Enables Enterprise Cloud Storage
- Joe Brockmeier for RWW: Cloud Storage Competition Heats Up With RiakCS
- Liam Eagle for thewhir: Basho Launches Riak CS Cloud Storage Platform, Aims at Service Providers
My notes about Riak CS will follow shortly.
Original title and link: Basho Announces Riak-Based Multi-Tenant, Distributed, S3-Compatible Cloud Storage Platform (©myNoSQL)
Tuesday, 24 January 2012
A Cost Analysis of DynamoDB for Tarsnap
Tarsnap is a service offering secure online backups. Colin Percival details the costs Tarsnap would have for using Amazon DynamoDB:
For each TB of data stored, this gives me 30,000,000 blocks requiring 60,000,000 key-value pairs; these occupy 2.31 GB, but for DynamoDB pricing purposes, they count as 8.31 GB, or $8.31 per month. That’s about 2.7% of Tarsnap’s gross revenues (30 cents per GB per month); significant, but manageable. However, each of those 30,000,000 blocks need to go through log cleaning every 14 days, a process which requires a read (to check that the block hasn’t been marked as deleted) and a write (to update the map to point at the new location in S3). That’s an average rate of 25 reads and 25 writes per second, so I’d need to reserve 50 reads and 50 writes per second of DynamoDB capacity. The reads cost $0.01 per hour while the writes cost $0.05 per hour, for a total cost of $0.06 per hour — or $44 per month. That’s 14.6% of Tarsnap’s gross revenues; together with the storage cost, DynamoDB would eat up 17.3% of Tarsnap’s revenue — slightly over $0.05 from every $0.30/GB I take in.
To put it differently getting an 83.7% profit margin sounds like a good deal, but without knowing the costs of the other components (S3, EC2, data transfer) it’s difficult to conclude if this solution would remain profitable at a good margin. Anyway, an interesting aspect of this solution is that the costs of some major components of the platform (S3, DynamoDB) would scale lineary with the revenue.
Original title and link: A Cost Analysis of DynamoDB for Tarsnap (©myNoSQL)
via: http://www.daemonology.net/blog/2012-01-23-why-tarsnap-wont-use-dynamodb.html
