Thursday, October 9, 2014

4 Issues that Ail Swift

While I'm a Swift enthusiast, I also realize it hasn't taken over the world. Other object storage systems (open-source e.g. CEPH, and proprietary e.g. Scality, Cleversafe, Amplidata) are finding success in various use-cases. In fact, industry analyst Marc Staimer is outright down on Swift. While his scoring is overly harsh on Swift, he does make a number of great points.

So what ails Swift? Or in other words, what issues need to be fixed to make Swift a clear #1? I can think of four key issues.

1. Access layer

In my two part blog on the access layer, I highlighted how very few applications use REST APIs and instead expect traditional block or file interfaces. The Swift community has done virtually nothing in this area and has relegated this important problem to proprietary cloud gateways. There are no embedded file, block, or Cinder interfaces on Swift (other than proprietary solutions, there are some tangential efforts e.g. openvstorage providing Cinder drivers on top of different object storage systems e.g. Swift - more on this very interesting technology in a subsequent blog). Nor do any advanced interfaces like VTL (virtual tape library) exist. In fact, even the S3 interface is a side project and does not get adequate attention.

I'd love to see contributions to solve this important problem.

2. Core functionality

Swift has been slow to add and harden core functionality. Geo-replication exists, but other object storage systems have replication that's richer in functionality and maturity. Erasure coding is coming soon, but is quite late with respect to the competition. Plus it will take some time to harden.

It would be wonderful to see higher velocity around core storage functionality.

3. Interop

This topic merits its own blog (perhaps later), but the net-net is that application vendors have to certify their application against every Swift public and private cloud. So if there are M applications and N public/ private cloud vendors, M x N interop tests have to be run for everyone to claim interop certification with everyone. This is crazy, it should be M + N!! Folks did the M x N interop testing strategy in Fibre-channel but Ethernet was much smarter and decided not to do this. Look where Fibre-channel is and where Ethernet is (for those who don't know these technologies, Fibre-channel is dying and Ethernet has taken over the world ). The lack of a clean interop strategy is a substantial drag on Swift against say Amazon S3.

I'd love to see a Swift middleware package that provides a way to do functional, stress, error, and performance testing against the Swift API. If an application vendor were to finish testing against the middleware then they should be able to claim interop with every public or private Swift vendor.

4. Lack of Multiple Swift Companies

I'm veering off the open-source project discussion, but given a choice, customers love to see two or more companies productizing a specific open-source technology rather than just one. While this is not a requirement (take MongoDB where there is only one), having multiple companies does help immensely. Hadoop, OpenStack Nova etc. are open-source projects where there are multiple companies innovating!

I'd be ecstatic if the investor community funded one or two more Swift companies.

In summary, it's early days for object storage... Swift has a great shot at world domination but must fix the above-listed four key issues to achieve this.

No comments:

Post a Comment