Why Holoflame 2.0 needed FLAME

A common issue that conventional commercial cloud-based infrastructures such as Amazon Web Services (AWS) and Azure are suffering from is the fact that the user normally does not have real control on the physical machines and the resources that have been booked to host the user services and content. This practically means that the user pays to gain access in a set of resources, but he is not capable of selecting the exact nodes and physical machines that her services will be finally deployed on. Even if a cluster of nodes becomes (for any reason) not functional, the services will automatically move to another cluster and the user will not be informed that such a change really happened. This transparency reduces complexity for the non-expert user but at the same time can cause severe difficulties in services and applications where the user needs to have low-level control of the resources in order to check data that are relevant to the hosting nodes or the network parameters or even find out where service is executed. This issue becomes vital considering edge networking where a node usually serves the nearby users from a geographical point of view. In HOLOFLAME 2.0 it is important to know WHERE a service is executed to facilitate load balancing and that the overall workload is distributed fairly among the different nodes. This will allow us to understand in each step WHAT is the workload of each one of the nodes and whether load balancing is needed to have a fair sharing of execution needs.

Finally, setting up and configuring from scratch installations (as it is required by competitive to FLAME infrastructures such as AWS/Azure) would be a time overkill for an SME with limited resources as we are. The reduction of development time is of outmost importance. In this context, FLAME provides an environment with unique opportunities for an SME since it offers resources easily configurable through VM clusters that can be instantiated by the provider according to the specific needs of an experiment. A set of paradigms and best practices are also provided to help experimenters get familiar with the platform and minimize the time to learn the platform. This is a major advantage for a small software development company that wants to design, implement, and deploy its solutions as fast as possible. This unique feature can certainly make the difference (easy and customized configuration of resources and software tools).