21 API ou pas API ? Telle est la question… La plupart du temps, les utilisateurs n’ont pas vraiment le choix : la décision dépend de l’application. En deux mots, s’il s’agit d’une application commerciale, les utilisateurs n’ont pas accès au code et ne peuvent pas y intégrer de code spécifique. Dans ce cas, si l’application exige un accès fichier et que l’utilisateur choisit une solution de stockage objet, le seul lien possible entre les deux est une passerelle. En revanche, quand les utilisateurs conçoivent leur propre application, ils doivent choisir parmi plusieurs API objet disponibles. Entre autres : une API compatible Amazon S3, une API HTTP/REST propriétaire développée et promue par le fournisseur lui-même, ou d’autres couches comme CDMI. L’autre angle clé est l’approche de standardisation. Qu’en est-il des trois principales API objet ? S3, créée par Amazon, aujourd’hui standard de facto largement adopté et qui joue un rôle de locomotive, Swift, promue par l’OpenStack Foundation, très visible grâce à la puissance de sa communauté et de ses membres, dont l’adoption progresse mais qui compte aujourd’hui moins de déploiements, et CDMI (Cloud Data Management Interface), spécifiée par la SNIA, seul standard officiel du secteur parmi les trois, avec aujourd’hui une douzaine de fournisseurs proposant un serveur CDMI. Chez Scality, en plus de notre propre API objet, le RING prend en charge une API compatible S3, un serveur conforme CDMI et une interface Swift. Nous laissons l’utilisateur choisir celle dont il a besoin selon les exigences de l’application. En plus de cet effort avec OpenStack, Scality contribue depuis la version Grizzly avec un connecteur Cinder qui permet à un cluster OpenStack Compute de consommer un périphérique bloc sur Scality RING.
