Global Content Delivery

Introduction

The focus here is the experience from leaving the load-balancer to arriving in the client device. In other words, all the aspects of ensuring good interaction with the user across the Internet.

Introduction to Global Content Delivery

How Global Content Delivery works:

A picture is a good place to start

Starting with the user...

• the user makes a request to the website
• the dynamic DNS lookup ensures the user is directed to the "edge server" nearest him to send the request
• the request travels the "first mile" to the edge server
• then (if not malicious) the request is forwarded across the CDN network towards the "origin"
• the request then leaves the CDN and travels the "final mile" to the origin
• the "origin" then sends the response which follows the path back through the CDN to the user

The clever stuff is:

• the CDN will block malicious requests
• the CDN will optimize the network journey so it is faster and avoids congestion on the Web
• and if configured, will cache the response so subsequent users get a cached copy from the edge server nearest to them which is faster than going to the origin
• and as the CDN answers requests, the origin has less requests to handle

In practice, it is more complex, with a lot of considerations around security, performance and functionality.

Engagement

Reach out to the Platform Team - details TBD

Review and Approval

Any review and approval of a CDN setup, will

• involve both website/API owners and Essity IT Platform team members
• forecasted usage must be estimated to allow costs to be calculated and agreed
• security and delivery aspects must be reviewed and agreed
• project implementation and subsquent operational timelines must also be reviewed/agreed
• a website/API roadmap is also requested, to help plan required changes to the CDN configuration involving resource effort and costs.

Standards and Conventions

Domain Setup

The customer facing subdomain is CNAME'd to the CNAME provided by the CDN e.g.

www.essity.mx.          300     IN      CNAME   www.essity.mx.edgekey.net.

If applicable, the apex record uses a load-balancer/gateway IP which will redirect the HTTP traffic to the CDN

essity.mx.              300     IN      A       52.142.123.60

Architecture and Design

The CDN can then be configured multiple ways to align with the requirements of the website. There are some fundamentals

• the CDN will be configured to receive traffic from declared hostnames
• the CDN will have DDoS, Web Firewall and Bot protection enabled and configured to match the website needs
• the CDN will then accelerate and cache traffic as configured
• the CDN will route to the designated origin(s) as required
• the CDN will ensure the connectivity with the origin is secure e.g. preventing man-in-the-middle attacks
• the CDN will designate values to allow the origin to block non-CDN traffic increasing security e.g. preventing CDN bypass attacks

This level of configuration requires both capabilities in the CDN platform, and the expertise of the team responsible for implementing.

Essity's chosen CDN platforms are

• Akamai App and API Protector
• Azure Front Door Premium

Other CDNs should only be used by exception.

info

If another CDN is in use, steps will be taken to migrate the the standard model. Often this migration can be done with minimal effort and disruption and results in higher service levels both in terms of security and performance

Implementation

Implementation is carried out the Platform Team, in partnership with the website/API owner, along the lines of

• present the architecture and functionality of the website/API
• agree on the required CDN configuration
• set up the CDN to handle the specific "property"
• jointly configure and test the CDN functionality and performance, using a test configuration
• then deploy a production configuration and test once more
• change the customer facing hostname to CNAME towards the CDN = effective go-live
• monitor the performance through the CDN
• if agreed, move operations and support to a self-service model executing by the website/API owner

The steps sound routine, but each stage is characterized by developing a good understanding of the website delivered by the CDN

Handover to allow a website owner to self-maintain will require sufficient training, often gained as part of the implementation process.

Security aspects require further training and expertise. In most cases, security responsibility is maintained by the Essity IT (Infosec and Platform) teams.

CDN setup and operation is, by default, done by Essity IT. Any exception to this must be agreed by all parties.

Operations and Support

The default model is that the Platform Team will operate the CDN ensuring it remains aligned to Essity standards for CDN use.

Self-service, as part of the origin website/API operating model is also possible, subject to training and demonstration of expertise.

It should be noted that the model implemented is not simply 100% Platform, or 100% Self-Service. There are an number of tasks from simple cache flushing to complex delivery rule changes and it is possible to agree on a perferred model between the Platform Team and the website/API owner.

The nature of the agreed operating model must be provisionally agreed in advance of a go-live.

Further capabilities will also be made available including

• self-service traffic reporting and similar metrics via New Relic
• self-service execution of routine tasks such as cache purging

In addition a CDN based solution will require

• synthetic monitoring
• TLS certificate management
• ongoing adaptation to match website changes

Advanced Topics

CDNs are complex and feature-rich so there are numerous possibilities to leverage advanced capabilities, when using the preferred CDNs.

Examples include

• optimization of image and video content
• edge computing
• geographic traffic routing
• automation via APIs/CLIs

See child pages for more details on specifc topics.