Cloud APIs Must Walk on Water

If you've been part of a software development project, you know that sometimes it's hard to get the team to all agree on best practices for interface design, database optimization, or even what technology to use. In this analysis, we take a look at some of the movements in cloud computing that start to lay a framework of good as it relates to this technology.

In this context, API designers for cloud applications need to think ahead and avoid common pitfalls. For several reasons, more than ever before. First, because many people will be accessing your one piece of code. Second, is that in this world of open APIs, it's easy to compare your code against another.

We notice that data management practices are at the core, and details matter when provisioning in platforms. At the same time that groups are forming to align practices and forms of virtualization and cloud standards, a voice whispers that perhaps this is a free-market problem. People who benefit at solving it, will; others will ignore it or compete directly. We enjoyed this post from Joyent on where standards matter in a practical sense.

In essence, the question raised: If a vendor makes it easy and bakes in the ability to "just do it", do you know or care about the standards? This seems to mirror an iPhone development paradigm, which is to expect work from the vendor SDK or libraries. The SDK wraps standards implementations, which is done in the way best understood by that vendor.

Do Unto Others as You Would Have Done To You

We know the cloud is big - perhaps it will inevitably be bigger than the Internet itself as it usurps our conception of location, space and time.

Where power forms, rules, groups, and organizations do as well. In information technology there is always tension between open standards and defacto standards. The former are crafted through agreements, the latter through leadership and market dominance.

We asked in a prior series "Will a single company become the dominant provider in the cloud?" Today we look at the more practical side of "who is winning now" - who is setting the rules and who is in the trenches.

Quite a number of the responses to our earlier posts emphasized that "the cloud should be free", meaning that it should have governing principles to avoid one vendor from owning the landscape.

Here are a few groups that have emerged to provide some context in how this may come together, both philosophically and practically. In both, the devil is in the details. A good summary of some of the current combining of forces is by the Open Grid Forum. (In our opinion, grids have given way to clouds as the dominant concept in this technology makeover).

• A resource directory of initiatives is located at the Cloud Standards Wiki, which in itself was formed by a handful of organizations and movements working to align around setting rules and patterns for cloud computing.
• The Open Cloud Consortium is organized around developing practices around sharing resources and has recently focused on a developing a test bed.
• The DMTF is working at the core definition of virtualization. It recently focused on the 1.1 version of the Open Virtualization Format (OVF) specification that focuses on packaging virtualization instances and creating a portable mechanic distribution by defining envelope and collection parameters around the virtual machine and its services. The organization, which contains members of IBM, Microsoft, Dell, VMware, XENSource, Sun, and NEC, has submitted 1.1 for consideration as an ANSI and ISO standard.
• The efforts by the federal government in its data.gov initiative shows that there's a market that's starting to see the value of raw government data formats. Soon, we would expect this to be powered by a mesh of computer resources that allow all sorts of jobs - integrated jobs - to work with these data sets. It would comprise an active government cloud.

Do Not Covet Thy Neighbors Network Resource

When looking for things to avoid, we found a lot of philosophical questions around data ownership, logging and portability. These discussions are alive and well and seem to be being absorbed into vendor solutions and consortiums like the ones mentioned earlier.

For a more practical view, we turned to a friend of ReadWriteWeb, Thorsten von Eicken, and have summarized his thoughts from a recent post, "Top Cloud API Sins. Bold items are our (loose) mapping to biblical terms.

• Do not covet your neighbors resources.: Listing of resources without the details, e.g., a list-servers call that doesn't return all the details for each server. This makes it very expensive to poll for server state changes ...


• Do not make cast idols: Not returning a resource id on creation. Some APIs don't give you a server i.d. when you request a server...


• Labor six days, rest on the seventh: Providing a task queue. Several APIs I've seen have a task queue that is supposed to provide updates on tasks that are in progress E.g., you launch a server and you get a handle onto a task descriptor. For us that's just overhead...


• Though shall not bear false witness: Not returning deleted resources in a "list resource" call. In particular, terminated servers must be returned in a list servers call for a certain duration, probably at least for an hour. Ouch!...


• Shall not covet his neighbor (or force me to repaginate): Pagination that goes page-wise instead of using a marker, e.g. where you get page one or the first 100 resources and then issue a query for "page 2″ or "from 100 on". Explain to me how a client can get a consistent resource listing when resources can be added and removed concurrently...


• Randy Bias added to Torsten's post: Treat others as you want to be treated Your UI MUST use your API so you understand how to be a consumer of your own API...

We plan on keeping up with this list and seeing how it intersects with implementations and standards that evolve.

Nirvana: Smells Like Services Orientation

Torsten goes on to describe a picture of the future. "Now here's what I'd really like to see. This is what we're working on for internal purposes and it's not easy, which is an event based interface instead of a request-reply based interface... "

Smart services in the cloud, rather than resources alone. This starts to get us closer and closer to an object-orientated network. Maybe that's what the cloud will be for platforms, infrastructure and software. The industry has been quick to identify the layers. But perhaps the point is piecing them together in a smart transactional framework.

A way to engineer highly reliable systems around these architecture challenges may sound familiar to those who monitor existing data centers today.

Torsten continues, "We run a good number of machines that do nothing but chew up 100% cpu polling EC2 to detect changes. Fortunately cpu cycles are cheap :-)".

This is practical intervention between vision and get it done.

We find it refreshing to hear this type of dialog in the industry and see a fresh opportunity for defining efficient patterns for this next generation of the cloud infrastructure.

Perhaps a new concept is forming: "Divine Computing".

What buying decisions will be based on the openness of cloud resources and common APIs?

Photo credit: tsarkasim, Amsterdam Esogna