An insightful post by Thorsten of Rightscale. While the post starts with cloud.com’s evolution, what caught my attention was the statement about cloud apis viz: ” … the API itself is more a programming exercise than a fundamental issue, it’s the semantics of the resources behind the API that really matter. Seemingly obscure stuff like: can you reattach a disk volume across datacenters, or can you move an IP address across datacenters, things that deeply affect how one builds redundant services in a particular cloud.” so true …
Couple of observations:
- While the API syntax doesn’t matter, the models behind the APIs do matter, because the models determine the flexibility, the agility and the extensibility …
- The resources semantics do matter, and I hope the resources exposed via the cloud APIs include not only the compute and storage but also the network as well as the interconnections there of
- And the resources semantics need to declarative rather than specific – proper layering of the configuration-provisioning-automation-orchestration functionalities are very important in a cloud infrastructure. The upper layers (and APIs thereof) should be working at the declarative orchestration-automation capabilities (#5 in architecture diagram), dealing with what; with the lower network devices dealing with the how of configuration and provisioning (#4 in the same diagram). In short, no static configurations, but orchestration and automation based on declarative rules and policies; no early configurations, but just in time configurations based on the state of the cloud applications.
- There seems to be two sets of APIs – EC2 style for public clouds and vCloud style for private clouds. I am not sure if this is due to gravity or because of distinct functionality. But in real terms there is no big conceptual or implementation difference between the two … What says thee ?
