Rational

Why use IaaS clouds?

From a customer perspective, one of the greatest advantages of the infrastructure-as-a-service (IaaS) cloud computing paradigm is the fact that the customer is no longer required to perform mid/long-term capacity planning of the infrastructure that it will require in the future. The customer can simply allocate as many resources as the current demand requires, increase the capacity when the demand grows, and then release resources when the demand diminishes, at no additional cost for this "elasticity".

Obviously, the capacity planning problem has not disappeared, but has simply moved from the customer’s shoulders, to those of the IaaS providers. On the other hand, from the provider's perspective, IaaS brings a number of advantages that allow for more efficient management of the installed capacity, and consequently a reduced total cost of ownership. One of the main advantages is the possibility of reducing the overall capacity needed to support the aggregated demand of all customers through the consolidation of servers. This is because it is unlikely that all applications will experience peak demand at the same time. In addition, large IaaS providers also benefit from the economies of scale that arise when the number of customers served is big, and consequently a sizable infrastructure is needed.

Why federate these clouds?

Small and medium private IaaS deployments can still take some advantage of the benefits of server consolidation, but they normally experience a smaller utilization of their physical resources, which represents costs that are not amortized by the utility associated with the execution of applications. The smaller utilization comes from the fact that with less applications to serve, it is less likely that peak demands from part of the applications will always coincide with low demands from the others, leading to a smaller potential for server consolidation.

Federation of private IaaS, by which a number of IaaS providers work together for their mutual benefit, has been advocated as a way to increase the infrastructure utilization, and as a consequence increase the efficiency of the federation members. In a federation the utilization can be increased mainly because the larger, and potentially more diverse, aggregated workload is likely to require less resources than the aggregated capacity of the IaaS providers, were they to work isolatedly. Members that are currently experiencing a low utilization of their resources can serve peak loads experienced by other members, thus allowing the local capacity of each member to be reduced. A smaller capacity leads to a higher utilization.

Federation is also a possible solution to host applications that require a geographically distributed deployment, be it to address dependability requirements, or simply to better serve a geographically distributed demand. In this case, capacities can be shared within the federation to increase the geographical dispersion of the resources that each IaaS provider can make avaiable to its customers.

Finally, federation is also important when there is a need to provide local users with a special purpose resources that are not available locally, e.g. GPGPUs, SGX-enabled hosts, etc.

Why Fogbow?

Fogbow is a middleware that comprises a suite of microservices, allowing the simple, efficient, and as non-intrusive as possible federation of IaaS providers. These services can be either local services that run entirely in the administrative domain of an IaaS provider that belongs to the federation (a site, for short), or federated ones, that need to interact with their counterparts running in the other sites of the federation.

Instances of federated services deployed at different sites of the federation use a firewall-friendly messaging service to communicate. The latter must be available at each site of the federation.

The Resource Allocation Service (RAS) is a federated service in charge of routing resource management requests to the appropriate cloud orchestrator running at the provider site. Together with the messaging service, these are the only services that need to be installed in all sites. All other services are optional, and site administrators can autonomously decide which of them they will deploy in their sites.

Fogbow has been designed to make its extension a simple task. Its microservice-based architecture facilitate the introduction of new funcionalities as standalone services, as well as the composition of services to provide enhanced funcitionalities. Moreover, the mandatory RAS can be enhanced and customized via the development of appropriate plugins. Moreover, a high test coverage of the source code is enforced.

Fogbow provides a RESTful API that applications can use to seamlessly manage resources in any of the IaaS providers that belong to a particular federation, no matter which cloud orchestrator middleware are used by these providers. Currently, there is support for the most popular cloud orchestrator middleware available (eg. OpenStack, CloudStack and others). Moreover, adding support to other cloud middleware is simply a matter of developing the appropriate interoperability plugins. For those users that want to interact directly with the system to manage their resources, Fogbow also provides command line and graphical interfaces. See the USE IT section for more details.