Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

API Buyer Beware: The Issue of AWS Compatibility

DZone's Guide to

API Buyer Beware: The Issue of AWS Compatibility

See what one developer thinks about creating tools meant to interact with market leaders and whether that should be a primary concern.

· Cloud Zone
Free Resource

Are you joining the containers revolution? Start leveraging container management using Platform9's ultimate guide to Kubernetes deployment.

If you are going to hitch your wagon to an API, it would seem that AWS is the horse that can win the race. There has been a long-running conversation (read: argument) over the way to address compatibility within APIs for systems outside of Amazon Web Services. The most notable of which is OpenStack.

Every time it comes around to the OpenStack Summit and Design Summit, we hear the same conversations beginning around whether or not Swift should emulate S3, and whether Nova should emulate EC2. The ability to do this would be enabled by the use of compatible APIs to let developers use the similar construct to deploy, manage, and consume resources, using the AWS-like instruction set

Using AWS compatible APIs has a clear win. This ensures the use of similar constructs across platforms. Isn’t that what we have been searching for in the world where there is a “one cloud” approach using an abstraction to all of the underlying infrastructure? Let’s see why this is a happening.

S3 or Swift API?

In the world of object storage, OpenStack Swift is one of the most popular platforms that you will find out in the world. Swift is not just geared for web-based environments as it seemed likely to be in the beginning. The use-cases of Swift object storage are far and wide across all technical and business consumers. The underlying architecture is very cool, and quite resilient. Cool-factor aside, the Swift project is able to be used as a standalone product all unto itself.

SwiftStack has made a business from this. They have also seen the shortcomings in the native S3 compatibility within the OpenStack project which caused them to build out a more versatile solution using their Swift S3 Emulation Layer which has also been provided as an open source project.

The S3 Emulation Layer doesn’t quite cover all of the feature set that AWS S3 does, however, it is a viable alternative to allow you to use common API usage between your on-premises SwiftStack and the AWS S3 in the cloud. That’s handy for a number of reasons.

EC2 and the Nova API Challenge

Randy Bias said it best in his blog post from 2015 which details the work being done around the standalone EC2 API that is actively developed against as we speak.

I couldn’t say much more than that I agree with Randy. We need to support the EC2 API if we want to be able to be a viable alternative for AWS on the compute and networking layers within an OpenStack cloud.

Even outside of OpenStack, we are seeing more platforms and services that are recognizing that AWS has set the standards for API consumption within their vast set of offerings across the entire AWS ecosystem. It’s difficult to battle that kind of momentum.

Some Standards Aren’t Always Collective Standards

Hey, if you don’t believe that a market leader can drive standards, check back in a couple of years to see how many companies who manufacture and sell headphones are using the Apple lightning jack. There will still be the traditional 3.5mm connector for a long time, but the real reason for this example is that we can see the markets shift to the popular, rather than the most technically capable solution.

Should we be supporting AWS-compatible APIs across the OpenStack projects? Let us know your thoughts in the comments below.

Using Containers? Read our Kubernetes Comparison eBook to learn the positives and negatives of Kubernetes, Mesos, Docker Swarm and EC2 Container Services.

Topics:
cloud ,integration ,aws ,api

Published at DZone with permission of Eric Wright, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}