In the context of PrEstoCloud, application micro-services, or fragments, can be placed either in a public cloud (e.g. Amazon Web Services), a private cloud (e.g. an on-site OpenStack instance), and on IoT devices located at the extreme edge of the network.
Due to the pay-as-you-go nature of public cloud, it is essential to carefully select (i) the cloud provider, and (ii) the location in which to deploy a fragment, so as to meet operational constraints (such as latency), but also ensure the deployment cost is acceptable to the application owner.
In this article, we look at how unconstrained fragments are placed, depending on use-case choice by DevOps.
We consider a fragment to offload from an edge device (IoT) located in Sophia-Antipolis, France. We further consider that this specific fragment, once offloaded to the cloud, will require 2 CPUs and 6 GB of RAM to be able to work efficiently process the current level of workload.
Based on this information, the Application Scheduling and Placement Controller first matches the required type of virtual machine to either an Amazon Web Services ‘m5.large’, or a Google Cloud Computing ‘n1-standard-2’.
The following table depicts the distance (in kilometers) between the current location of the fragment and the potential data centers where it can be offloaded to, as well as the hourly rate (in US dollars) to run these two specific types of virtual machines.
Amazon Data Centers | ||||||
Location | Paris | Frankfurt | Stockholm | Dublin | London | |
Distance (Km) | 684 | 734 | 1901 | 1454 | 1028 | |
Hourly Cost (USD) | 0.112 | 0.115 | 0.102 | 0.107 | 0.111 | |
Google Cloud Data Centers | ||||||
Location | Hamina | St Ghislain | London | Frankfurt | Eemshaven | Zurich |
Distance (Km) | 2314 | 797 | 1028 | 734 | 1092 | 432 |
Hourly Cost (USD) | 0.104 | 0.104 | 0.122 | 0.122 | 0.104 | 0.133 |
The table shows that the data center located in Stockholm (from Amazon Web Services) provides the cheapest hourly rate, but is located the furthest away from Sophia-Antipolis. It would therefore exhibit the largest latency among all sites. Conversely, the Zurich data center (from Google Cloud Services) is the most expensive of the sites, but it is also the closest.
PrEstoCloud enables a DevOp to customize the placement of a fragment by tuning the parameters α and β in the placement cost function, which is of the general form
where increasing the value of either parameters favors either a cheaper deployment with a larger latency, or a more responsive deployment that is also more expensive.
The table below shows the values computed by the Application Scheduling and Placement Controller for our fragment, depending on the parameter values.
Amazon Data Centers | |||||||
α | β | Paris | Frankfurt | Stockholm | Dublin | London | |
1 | 1 | 1.341 | 1.413 | 2.700 | 2.207 | 1.734 | |
1 | 3 | 1.219 | 1.270 | 1.850 | 1.628 | 1.411 | |
1 | 5 | 1.179 | 1.223 | 1.567 | 1.435 | 1.303 | |
Google Cloud Data Centers | |||||||
α | β | Hamina | St Ghislain | London | Frankfurt | Eemshaven | Zurich |
1 | 1 | 3.188 | 1.432 | 1.788 | 1.448 | 1.774 | 1.152 |
1 | 3 | 2.104 | 1.226 | 1.492 | 1.322 | 1.397 | 1.228 |
1 | 5 | 1.742 | 1.157 | 1.393 | 1.280 | 1.271 | 1.253 |
With an equal weight given to the distance and the cost (α = β = 1), the best location to offload the fragment to is in Zurich, as it is the lowest value. Indeed, while Zurich is the most expensive VM available, the DevOps have expressed that they would rather pay a higher hourly rate for a responsive application (therefore favouring QoE), than a cheaper, but laggier deployment.
As we increase the value of β, therefore prioritizing cheaper VMs at the expense of their proximity, we see that, with β = 3, the Paris data center becomes the best choice, even though it is located further away. With β = 5, St-Ghislain is elected as the best choise, as it is the least expensive within the tolerable latency.
By tuning these parameters, which can be specified per fragment, DevOps are able to customize the deployed application task graph, while still maintaining a tight control over the cost and behavior of their application.