Compatibility concerns in the evolution of cloud computing APIs

Compatibility concerns in the evolution of cloud computing APIs

The world of cloud computing APIs has been constantly evolving since this highly-scalable architecture first gained attention less than five years ago. It is an area with great expectations but little commanding consensus of architecture - so far. Meanwhile, use of services is a common trend, as is use of REST interfaces.

Early cloud architecture leaders included Amazon, Google and SalesForce, with Microsoft, RackSpace and others more recently joining the contest. The later arrivals, it seems, are making design changes that in some ways codify basic approaches to cloud API building.

In some cases, present day applications can be ported over to cloud platforms with little code change. But to truly exploit the new computing paradigm, revisions

    Requires Free Membership to View

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSOA.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSOA.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

are required to capitalize on special APIs associated with individual cloud architectures. That is worrisome for individuals concerned with lock-in.

Some common threads -- some repeatedly used abstractions, if you will -- keep emerging. Web services techniques were central to Amazon's early cloud computing efforts, and the Web services approach continues to drive much cloud activity. While major cloud architectures have doubled back to support conventional relational data interfaces, the cloud computing train really got going with non-relational RESTful interfaces, and these continue to mark a major difference between cloud architecture and other architectures. Each major cloud architecture supports what can be described as RESTful Web services.

Standards efforts have sought to address the lack of consistency in cloud APIs. The Simple Cloud API effort shows how some level of consistent abstraction might be applied across various clouds. This effort, originated by Zend, IBM, Microsoft, Rackspace and others, breaks its basic API taxonomy down into File Storage, Document Storage and Simple Queues. The Simple Cloud API is meant to work with multiple cloud services. Where, for example, one cloud service might use a different method than another would for listing out contents of a directory, the Simple Cloud API would use one method to handle both services.

Depending on your point of view, there are either too few or there are too many cloud APIs. For no strong reason, people associate cloud computing with open source standards. But the different major cloud approaches are not compatible with one another, so possible 'lock-in' on the cloud is still a concern. This is one of the many niggling implementation issues that make cloud development something of a frontier territory.

This was first published in September 2010

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.