S3 Compatibility? It’s just an Object Storage Feature
Today, if you want to use object storage, there are a number of very important characteristics that are considered fundamental. The list has gotten long, but one thing stands out: S3 compatibility.
S3, the de facto standard
S3, a protocol and service introduced by Amazon AWS in 2006, has been adopted by developers, software products, and an increasing number of competing services. It’s not the best API, and it doesn’t take advantage of all the features available from the object store (for example, in the case of SDS, there is an entire set of bulk operations optimized for large data movements that are not available on S3), but almost nobody cares. It would be like questioning iSCSI and FC for a storage array, or NFS and SMB for a NAS. Can’t you have something better? Yes, probably, but do the vast majority of end users care? Not at all.
S3 is a feature, not a product
Several times in the storage industry, vendors have associated their products with a single feature because they invested a lot in it, and because, at that time, it was a unique differentiator.
- Data domain was a synonym of deduplication. (Do you know a VTL today that doesn’t do that?)
- 3PAR was a synonym of thin provisioning. (Do you know an array today that doesn’t do that?)
- ROW Snasphot was a synonym of NetApp. (Do you know a NAS today that doesn’t do that?)
And these are only three examples; the list is very long.
In the short term, associating your name to an innovative feature and making it the core of your product differentiation is a good strategy, and it can pay off. But this kind of strategy works for a limited time, until the rest of the industry catches up. At that point you must understand that even if you are still better than others, it no longer makes a difference; you must be ready to change your product and message accordingly.
OpenIO is a S3 compatible object storage
The OpenIO team started working on SDS in 2006, and its first 1PB cluster has been in production since 2009. The set of APIs built to manage objects is today comprehensive, and it made it possible to build front-end connectors for several protocols and services as well as unique features like Grid for Apps. I won’t lie, in the past our S3 interface was poor and supported only a subset of the available APIs. To be fair, in 2006, S3 wasn’t around. Now, we are on par with the best implementations on the market, and our customers have proven it in the field.
What really differentiates an object store?
This enables us to move on to discuss what really differentiates us. In short, our long-term strategy is built on performance, flexibility and freedom of choice. This allowed us to build a product that:
- Supports different hardware architectures (ARM, X86),
- Runs in a very small footprint (1 CPU core and 512MB RAM),
- Scales like crazy (our largest customer has 650 nodes in production, but small customers can start small and grow without any impact on performance),
- Is particularly efficient (by taking advantage of all the resources available in the cluster with dynamic load balancing),
- Has incredible performance (thanks to the ability to work with flash storage and HDDs efficiently),
- Is future proof (allowing customers to change the configuration over time without impact),
- And it can run applications directly into the storage infrastructure (enabling end users to further improve the efficiency of the infrastructure, and get faster results).
S3 is a feature. It’s like saying that a NAS supports SMB. Customers take for granted that when you mention SMB for an enterprise product it supports AD, SMB3, and so on, don’t they? Would you even think of talking to an object storage vendor today who doesn’t have good S3 compatibility?