Trading Latency and Costs

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.