A new post by William Vambenepe discusses how much simplicity we really want in our datacenter automation mechanisms at the expense of flexibility. It is inspired by Sun’s announcement of the Sun Cloud initiative. William notes:
The Sun API is very simple and its authors are proud of that fact. Indeed they should be proud of avoiding unneeded complexity. They have probably also kept out (at least so far), some needed complexity
The foundation of the Sun Cloud is the resource model and the API for accessing/manipulating these resources. The resource model defined by Sun Cloud is based around a Cloud resource, a representation of a user's view of all accessible resources in the cloud and provides access to the cloud itself and its components. A cloud can contain one or more Virtual Data Centers (VDC) - a representation of a user's view of available resources in a single virtual data center. A VDC contains a set of public addresses - static, publicly accessible Internet Protocol (IP) addresses, which can be attached to a particular VM via an interface; clusters - groups of VM and VNet resources, segregated for purposes of grouping by common functionality and volumes - remote WebDAV volumes that may be accessed by the same credentials used to access this information. A point-in-time representation of the contents of a volume is defined by a snapshot. As we have defined above a cluster contains Virtual Machines (VM) - virtual computers associated with a cluster, with the state defined by a backup representing a snapshot that was taken of a specific VM and Virtual Network (VNet) - a virtual private network to which an interface associated with a VM may be attached. An interface represents a network interface card (NIC) associated with a specific VM, and documents an IP connection (from this VM) either to a VNet (virtual private network) or to a public address (a static public IP address accessible from the Internet).
According to Tim Bray’s post the APIs provided for a Sun cluster, represent:
... a unified view of the storage and compute and networking services. It’s built around the notion of a VDC, which contains networks and clusters of servers and public IP addresses and storage services. The idea is to give you the administrative and operational handles to build something really big and ambitious. The VDC notion is really slick and I think something like it is going to be required in any serious cloud API going forward.
At the bottom level, the interface is based on HTTP and tries hard to be RESTful. All the resources - servers, networks, virtual data centers - are represented in JSON.... This interface does more than just Resource CRUD; there are operations like "Start server" and "Snapshot storage". The kind of thing that classic REST design patterns don’t really give you a cookbook for. Here’s an example of how it works: the representation of a server includes a bunch of "controller" URIs; a POST to one of these constitutes a request to do something, say reboot the server.
On top of the low-level REST there’s a set of libraries for those who’d rather not deal with HTTP messaging; available off the top in Java, Ruby, and Python. On top of that there’s a command-line interface suitable for shell-scripting, except for it emits JSON instead of classic-Unix lines-of-text.
Finally, there’s a Web GUI so you can build your VDC by dragging and dropping things around. It’s nice demo-ware and I can see people using that for getting a quick ad-hoc server deployment on the air on short notice. But my bet is that for heavy lifting, you’re going to want to script your deployments, not drag-and-drop them.
William questions whether the APIs based on this simple hierarchical model can represent the complexity of real datacenters:
Look at a datacenter today. Make an inventory of all the networking equipment, storage, servers, hypervisors, operating systems and infrastructure services that it contains. Consider all the configuration settings of all these resources (as they would be represented in a complete, authoritative and consistent CMDB, that most elusive creature). Add to it all the controls and APIs they expose. That’s a lot of data, even if you don’t consider the applications layer. That’s a few orders of magnitude larger than what the model in the Sun Cloud API can describe. That gap (between our CMDB model and the Sun Cloud model) is what we should look at and analyze. Why are they so far apart? How big is the ideal datacenter automation and virtualization model?
He suggests that:
The right place to be, between the "omniscient CMDB model" and the "Sun Cloud model" is somewhere in the middle, with a couple of incrementally complex layers. Of course they are so far apart that saying "somewhere in the middle" is a cope-out.
Sun Cloud.provides a set of APIs that can be used by both cloud creators and users. Time will show whether this simple set of resources and API will prove to be sufficient for building and using clouds or a more complex API set is going to be required.
