Home > Documentation > Architecture

the design goals

This software was designed as middleware between all of the various frontends, cloud management APIs, connector/backend virtualization APIs, network management APIs and protocols, and applicable accounting systems. The software was opened up for use by other vendors and for private use. This is what open interoperability is about!

Our goal is to make sure that we can be compatible with all the necessary use-cases of virtualization and cloud computing at the IaaS layer. We might even surprise ourselves and find that this is useful at other layers too, or useful for applications outside the cloud, but our primary and initial focus is on IaaS. This alone is a pretty hefty goal and we will appreciate the assistance of any IaaS vendors in extending and building this functionality.

As an example of its use, a frontend may be written against Cloud::Infrastructure to take advantage of many different backend virtualization APIs such as libvirt, VMWare API, or even an EC2 connector. Similarly, someone could write a binding for Cloud::Infrastructure which provides connectivity to their proprietary cloud so that they can take advantage of any frontend written against Cloud::Infrastructure. Finally, bindings from Cloud::Infrastructure to accounting systems may be written, so that customers are properly managed and their resources accounted.

To help demonstrate the concept, please refer to our conceptual diagram.

the language

Cloud::Infrastructure itself is written in Perl. While Perl is not the newest kid on the block, we think that Perl is a great, flexible language, a great choice for systems programming and glue. Since our goal is to provide a glue to tie together system components, various APIs, and management utilities, we think that Perl is a great choice to achieve our goals. Additionally, because Perl is not all that new, there are plenty of developers with great experience and expertise to work with Cloud::Infrastructure without very little of a learning curve.

However, because Perl is such a flexible language, 3rd-party extensions could be written in many different languages. For instance, the Perl module Inline::Ruby might allow a developer to offload much of their modules into the Ruby language. Similar hooks to other languages exist as well. There is also the potential for Cloud::Infrastructure to use socket communications to daemons written in other languages -- such as using SOAP or XML-RPC calls. Since Perl is flexible enough to handle this, we intend and expect that Cloud::Infrastructure will be flexible enough to handle all such use-cases. Yet, at this time it is intended that modules included in the stock distribution will be pure Perl code. Once extensions become available, we'll create a public repository where these may be indexed.

Currently, the Cloud::Shell implements multiple high-level language interpreters for frontend code and end-user scripts. Users of Cloud::Shell may upload code into Cloud::Infrastructure which is written in Ruby, Perl, TCL, or Javascript.

the api

The Cloud::Infrastructure API is not yet stable. We will stabilize it over the next few months as we complete the implementations of various frontends and backends, and determine what the applicable use-cases will be, and what we need to accomplish with it. We would appreciate any and all feedback regarding this. However, just because it isn't yet stable doesn't mean you can't start developing against it. If your code gets accepted into our distribution, we'll help maintain it against the evolving API, and if not, we'll provide plenty of assistance to make sure that we can keep your code running with the least amount of ongoing effort.

As a specific example of how the components work together, an IaaS vendor is currently using the frontend Cloud::Infrastructure::Frontend::XenShell, a single connector, Cloud::Infrastructure::Connector::Xen, and for accounting, Cloud::Infrastructure::Accounting::Ubersmith. Once Cloud::Infrastructure is further developed, this vendor's customers will be able to take advantage of multiple other frontends, such as Annelidious::Frontend::OCCI and Annelidious::Frontend::SunCloudAPI.

If you're interested in using, building, or otherwise learning more about the API, read more.