About Dynamic Servers

Fastly's Load Balancer allows you to create pools of origin servers that you dynamically manage using Fastly's Dynamic Servers feature to distribute and direct incoming requests. The benefits include:

• support for any infrastructure deployments including any type of server instances and one or more data centers, regions, or cloud providers
• high availability of web applications when using health checks
• compatibility with TLS termination, HTTP/2, and IPv6
• server stickiness without requiring a cookie-based approach
• implement any number of request routing rules/conditions to select a pool of origin servers

To set up Dynamic Servers, you attach a pool to a service, then add versionless origin servers that are stored separately from your VCL configuration. You can use the Fastly API to programmatically add, remove, and update pools and origin servers.

How Dynamic Servers work

Like dictionaries and ACLs, Dynamic Servers have two major components: the pool and origin servers within it. Pools act as containers for origin servers that store the hostnames or IP addresses of servers to which incoming requests can be directed. Each pool is attached to a version of a service, but origin servers are versionless and any changes will become effective immediately.

When Dynamic Servers might be useful

Dynamic Servers might be useful for organizations that need to load balance requests among origin servers. They can be used to:

• evaluate new server instance types and new software deployments.
• independently scale individual microservices.

More specifically, they can be used as:

• Local Server Load Balancer (LSLB) where they are used to balance requests among origin servers within in a single region, such as AWS EC2 instances in the US East region, or within a single data center or on-premises location.
• Global Server Load Balancer (GSLB) where they are used to load balance requests among origin servers across any geographically distributed infrastructure deployments such as:
  • within multiple regions of an Infrastructure as a Service (IaaS) provider (e.g., AWS, GCP, Microsoft Azure).
  • between multiple IaaS providers (e.g., AWS, GCP, Microsoft Azure).
  • as part of hybrid infrastructure deployments that include a combination of on-premises origin servers or data centers and IaaS providers.

Getting started

You'll need to follow these steps:

1. Create a pool in a working version of a service that's unlocked and not yet activated.
2. Add at least one origin server to the newly created pool, keeping in mind the limitations.
3. Activate the version of the service you associated with the pool.

Once the pool is created, properly associated, and filled with origin servers, it can be called in your service.

Limitations

Keep the following limitations in mind as you use Dynamic Servers:

• Pools cannot be created with custom VCL. If you create a pool using the API, you can use the API to make changes to it and use custom VCL to interact with it.
• Pools need at least one enabled server entry. Origin servers cannot be deleted when a pool only has one enabled entry left.
• Origin server deletions are permanent. If you delete an origin server, it is permanently removed from all service versions and cannot be recovered.
• When you delete a pool, you'll only delete it from the service version you're editing. Pools are tied to versions and can be cloned and reverted. When using pools, we want you to be able to do things like delete a pool from a current version of your service in order to roll back your configuration to a previous version using as few steps as possible.
• Event logs don't exist for origin server changes. If you use the API to add, update, or remove an origin server, there will be no record of it. The only record of a change will exist when you compare service versions to view the point at which the pool was associated with the service version in the first place.