We love Swift

There is a special place in our hearts at Aptira for the OpenStack Object Storage project/service known as Swift. Many of us had prior experience with it when we came to Aptira and since we started we’ve done a whole bunch of interesting implementations for our customers in Australia and APAC.

After the proliferation of several new ecosystem projects there have been some renewed discussions in the community asking “what is core?” and this seems to have driven some recent questions where customers would ask us if we felt Swift was “extensible/pluggable enough” and maybe if it even needed some kind of re-design of architecture to “bring it in-line with other OpenStack services”. We thought a quick blog post with our 2c was in order.

Our opinion on the “what is core?” question is pretty simple:

We also recognise the value of ancillary services like Horizon and Keystone but don’t want to take it beyond that. Services (and their respective projects) which fall beyond that scope should have a designation like “ecosystem”. However that is simply our aggregate internal opinion (2c) and we recognise that the community is currently in the ongoing process of trying to answer this question.

Internally and amongst most of the other implementers that we speak with in the OpenStack community is that Swift has always represented the gold standard for what we feel an OpenStack service should be:

• Robust active-active architecture
• Flexible implementation
• Horizontal scale
• Rock-solid codebase and API
• Easy to upgrade from n-1 release to n
• Strong and open development community

You’ll note that these bulletpoints basically boil down to “ops friendly” and “production friendly”, since we are largely an ops company that relies on the OpenStack community at large to “close the loop” when it comes to DevOps. We have always felt like OpenStack services should have some form of “common minimum requirement” and framework that implements it so that all the services are implemented consistently and with the same HA model.  As noted above, we have always felt that Swift represented an exemplar for what those requirements and that framework might look like.

• We are in the middle of a few middleware projects right now to customise how Swift works for the requirements of particular customers. This ranges from custom authentication to minor changes to the existing (extremely) flexible implementation architecture.
• At the same time we are in collaboration with a major storage vendor (I won’t say which, but it’s not one of the 3-letter acronyms) on combining Swift with their hardware for a very large scale deployment at a higher education institution in Australia. On this front I can tell you for a fact that the major proprietary storage vendors are scrambling to make sure their solutions work with Swift. If you’re already a customer or partner, it might pay to actually ask what the roadmap is and current status.

Let’s make it really clear. If you want Swift on top of some other storage solution, it can do that (we will be able to talk more about this mid-year). If you want to extend/modify Swift, you can do that and it’s not even going to require any major departures from the existing architecture. I have a niggling suspicion that this is simply a matter of education and marketing, the OpenStack Foundation could probably consider their messaging, that by and large external perception of OpenStack is still as a “compute” thing only. Better messaging about what an Object Store is, its use cases/problems it solves and why Swift does such a fine job could go a long way to changing those sorts of perceptions (as well as driving developer adoption).