While the announcement that VP8 has been open sourced has been met with great enthusiasm, and will probably be the highlight of this year’s Google IO for some time to come, there are many other interesting new announcements which came at this year’s IO. One of which was a Google Storage.
Google storage is nothing less than a competitor for Amazon’s S3 service, and is quite similar in implementation. Did I say quite similar? Try almost exactly the same.
Like Amazon S3, Google Storage gives developers a RESTful API for accessing, creating and deleting objects on Google Storage, but this is only to be expected.
Like S3, Google Storage uses the concept of Buckets, where each bucket is a unique in a namespace. So if you create a bucket called images, which will be accessible via a hypothetical images.googlestorage.com, then no other bucket can have the same name. Each user will have a limit of 1000 buckets to his account. Unlike AWS though, Google will provide this service from user Google Apps domains as well.
Like S3, Google Storage is more of a non-relational database of keys and objects rather than a hierarchical storage service. What this means is, that data stored in Google Storage does not have an imposed hierarchy. There are no files and folders, there is just data objects which have associated metadata. While S3 limits data objects to 5GB with 2k metadata, Goolge allows upto 100GB per object.
Each data object can be accessed by its unique name, which is a 1024byre UTF-8 string. So you can have names such as:
A developer can imply a hierarchy in files by naming the objects carefully, such as:
Here, while it may seem like “image1.jpg”, “image2.jpg” and “image3.jpg” are all in the same “images/2010/02” folder, and “image4.jpg” is in a different folder “images/2010/03” in fact they all lie in the same flat hierarchical structure with names that include the “/” characters. The end user accessing the file as “bucker.googlestorage.com/images/2010/03/image4.jpg“ may feel like there is some hierarchy, but Google Storage wont know the difference. Mor importantly, it will allow you to have names like:
Each object can have associated metadata, as name-value pairs. So for “images/2010/03/image4.jpg“ you might want to store the images resolution, author name, account id, a link to the images thumbnail.etc.
Google Storage will also allow one to define ACLs (Access control lists) for specifying who all can have access to your data. Google has the advantage of letting Google Storage users use Google accounts for setting permissions.
As for the developer himself, similar to Amazon S3, access is granted via the associated access key and secret code, which are shared only between the developer and Google Storage.
Google has opened up early access to this service for developers, and for the testing period, is giving them 100GB of free storage and 300GB free bandwidth. Once it is released though, Google Storage will feature an Amazon S3-like pay for what you use structure.
While Amazon has recently decreased the cost for hosting content on their infrastructure by providing a lower redundancy option for storing less important data, Google’s Storage prices are much higher and stand as follows (taken from the Google Storage Overview):
Google Storage for Developers pricing is based on usage.
Amazon on the other hand charges lesser, anywhere between a maximum $0.15 a GB to a low of $0.055 a GB if you store over 5000 TB.The data transfer charges too are the same for Amazon S3 (for Americas and EMEA, Amazon is cheaper for APAC), however they do provide 1GB free data transfer out.
While it will be interesting to see Google Storage compete in this space, it currently doesn’t seem to stack as well against S3 when it comes to features. Amazon for example had recently announced versioning for Amazon S3 which would allow people to store multiple versions of objects automatically. Google probably has improvements in mind for this service in the horizon, but for not Amazon S3 seems to have the upper hand.