The current state of cloud and API standards is almost an exact match for early SOA and Web services standards, and we expect the standards movement will follow a very similar trend. Hopefully, the cloud standards groups will stand a better chance by learning from the mistakes and successes of the Web services standards.
The discussion of cloud standards at Cloud Camp Boston started by asking the question “What do we want to standardize?” As we looked at standards we found that there are three attributes of apparent concern. These include “API lock-in” (a similar concept to vendor lock-in), migration issues, and the richness or functionality of an API.
One interesting problem with setting standards (For APIs and services both) is the granularity of the work you’re standardizing. Some APIs have a very limited scope and effect only a single application with a single purpose. Others address a broad range of applications with any number of different purposes.
One example of scale issues effecting functionality is libcloud which simplifies the process of integrating with multiple popular cloud server providers. Its methods rely on using the “lowest common denominator” to ensure compatibility with all the providers it supports. In other words, it provides for the basic functionality that all providers share at the expense of losing the specifics of each system that help each one excel in their particular niche. One potential pitfall of standards could be the “dumbing-down” of new cloud applications built for mass appeal.
There are also virtualization issues in the cloud. It would be wonderful if there was a single best way to optimize the automatic scaling of applications. But there are complications involved in creating “standardized triggers”. At what point should a system be triggered to bring more servers on line? At what point should the system know to let servers go? What metrics should be involved in the calculations?
In every case, the answer is a resounding “it depends.” Different applications have different needs. If we want to ensure five nines availability, we might be willing to suffer a little latency to avoid the risk of down time. And speed versus availability is just one dichotomy to resolve. Taken together with other issues around hardware, scripting languages and anything else developers argue over, it means once again you can’t be everything to everyone.
But there are areas where the cloud is actually fairly well standardized already, even if only in practice. For example, the infrastructure APIs for service providers are seen by some as the shining example of cloud standards.
In fact, the idea of the cloud came from telecommunications service providers as they transitioned from point-to-point services to VPNs. The cloud was their way of denoting where the clients’ responsibilities ended and the providers’ responsibilities took over.