Skip to main content

Adaptive Edge Engine

The Adaptive Edge Engine (AEE) is a collection of components that manage different aspects of operating your Project on our dynamic, multi-provider, global hosting platform.

  1. LocationOptimizer manages the selection of locations where the Projects run.
  2. HealthChecker monitors Project health.
  3. TrafficDirector manages the routing of traffic to healthy Projects wherever they are deployed.

The above pieces work together in the following flow:

  • The LocationOptimizer selects locations for your Project based upon your strategy definition in your location-optimizer ConfigMap (see below). The locations selected by the AEE may be ones where the workload is currently running, or they may be new ones.
  • Next, the Project is deployed to any newly selected locations. The Project deployments are tested by the HealthChecker, and when they become healthy they are classified as "ready to receive traffic".
  • Once an instance of a Project is ready, the TrafficDirector updates Internet routing information so traffic can be "directed" to instances of your Project.

If the selected locations are the same as your current locations, you will see no changes.

Other components of the AEE manage additional dimensions of your Project in the background such as location orchestration and scaling.

LocationOptimizer

The LocationOptimizer calls the SolverServiceV1 strategy to solve for the locations of servers for your Project. This strategy implements various policies to deliver a variety of different deployment styles. You define parameters to pass to the policy to modify its operation to best deliver the desired results. The policies and their parameters are discussed in more detail below.

Policy descriptions and examples

Dynamic

This policy uses traffic data (e.g., http requests per second) to find an optimal set of locations for your Project subject to your parameter specifications. The optimization function selects locations to minimize the geographic distance travelled by the requests sent by your end users. With the dynamic policy, the selected set of locations is expected to change over time as your Project's traffic patterns change. See here for more information on the traffic signal used for dynamic location selection.

Special handling is required when the Project traffic data is NULL or 0. In cases of no traffic signal (e.g., the Project is not receiving any HTTP requests) the LocationOptimizer will meet the minimumLocations condition by selecting arbitrary locations. The mustInclude parameters will be honored if present, but if there are fewer of these than minimumLocations, additional locations will be chosen regardless of geography.

{"strategy":"SolverServiceV1","params":{"policy":"dynamic"}}
  • Required parameters
    • policy: This is required to obtain the desired solution methods.
  • Optional parameters
    • minimumLocations: minimumLocations ensures that the Project will be deployed to a minimum number of locations to ensure availability. Default is 2.
    • maximumLocations: maximumLocations can be used to set a coarse upper limit on the number of locations. Default is 5.
    • mustInclude: mustInclude conditions represent “include this in my solution” conditions. Multiple conditions can be specified as key:value pairs. The LocationOptimizer selects one location per condition specified in the mustInclude array. For example, mustInclude = [{"region": "europe"},{"region": "northamerica"},{"region": "northamerica"}] will result in 3 locations, one in Europe and 2 in North America. See table of available terms here. With the dynamic policy, your selected locations may include additional locations determined by traffic. Default is NULL.
    • mustNotInclude: These represent conditions that must not appear in the solution set. They are specified in the same manner as the mustInclude conditions. Default is NULL.
    • chooseFrom: This feature is only available on the Enterprise plan.

A dynamic LocationOptimizer configuration specifying all parameters looks like this (note that minimumLocations and maximumLocations are equal to their defaults in this example):

location-optimizer.yaml
{
apiVersion: v1
kind: ConfigMap
metadata:
name: location-optimizer
namespace: default
data:
strategy: |
{
"strategy":"SolverServiceV1",
"params": {
"policy": "dynamic",
"mustInclude": [
{"region":"europe"}
],
"mustNotInclude": [
{"region":"asia"}
],
"minimumLocations": 2,
"maximumLocations": 5
}
}
}

Static

This policy results in a fixed set of locations that meet additional, stated requirements. Deploys your Project to a fixed set of locations that meet the mustInclude conditions. Upon the first implementation of the static policy, the SolverService will solve for a set of locations that meets the specifications. This set will continue to be used as long as it meets the specifications. If it does not, as when your specifications or the underlying network have been changed, then a new set is obtained.

{"strategy":"SolverServiceV1","params":{"policy":"static", "mustInclude":[{"region":"europe"},{"region":"oceania"}]}}
  • Required parameters
    • policy: This is required to obtain the desired solution methods.
    • mustInclude: In this policy, the mustInclude parameter is the only input used to define the desired result. mustInclude conditions represent “include this in my solution” conditions. Multiple conditions can be specified as key:value pairs. The LocationOptimizer selects one location per condition specified in the mustInclude array. For example, mustInclude = [{"region": "europe"},{"region": "northamerica"},{"region": "northamerica"}] will result in 3 locations, one in Europe and 2 in North America. See table of available terms here.
  • Optional parameters
    • chooseFrom: This feature is only available on the Enterprise plan.

Anycast

This policy is available on the Enterprise plan. It should only be used under specific circumstances and requires supporting actions such as changing your DNS records. See the Anycast explanation to know if and how you should use our Anycast networks.

This policy results in a set of locations that are part of our Anycast network.

{"strategy":"SolverServiceV1","params":{"policy":"anycast","network":"global-045"}}
  • Required parameters
    • policy: This is required to obtain the desired solution methods.
    • network: Indicates which Anycast IP space you are using in your DNS records as explained here.
  • Optional parameters
    • None

Development

This policy results in a set of locations that are dedicated to non-production and micro-environments.

{"strategy":"SolverServiceV1","params":{"policy":"development"}}
  • Required parameters
    • policy: This is required to obtain the desired solution methods.
  • Optional parameters
    • None

TrafficDirector

The TrafficDirector is responsible for routing traffic to edge deployments and it has multiple strategies it can execute to manage this. Two DNS-based strategies are currently available with the default being a geo-DNS strategy that selects routes based on geographic proximity.

HealthChecker

The HealthChecker executes one or more strategies for each Project to determine if the Project has been deployed/scheduled successfully and is ready to accept traffic. The HealthChecker also executes additional background strategies to monitor the health of the locations hosting Projects.

Two strategies are currently available to the HealthChecker configuration. Those strategies are:

  • deploymentMetricsHealthCheck: Monitors platform metrics to detect that the minimum replicas per container are running for each deployment.
  • envHTTPHealthCheck: An agent queries the Project with an HTTP POST request and monitors and interprets the response

The deploymentMetricsHealthCheck is included by default for all Project. The envHTTPHealthCheck is included by default for HTTP Projects.