Static Content CAT

From CloudScale
Jump to: navigation, search
Usage diagram of the highly specialized S3 platform for static content servicing

A Static Content service is a deployment that handles requests for only content that does not change, or seldom changes] The Static Content CAT is an architectural pattern that aims to increase efficiency of static servicing by separating requests for such contents (static HTML, images, media and other mostly static files) to a deployment independent from other tasks, and directly accessible to the end users.

This allows for a very specific deployment for servicing the static content that can be tuned for high through-output, for instance with in-memory cache files and fast read-only storage, with minimal computing power, as well as other improvements such as geographically distributed deployment.

Contents

Also Known As

Static Content Hosting, Cloud Storage Service, File Hosting Service, Web Storage

Problem

A web application communicates with a cloud service that needs to handle very different tasks, among them keeping a user's session, obtaining information from different sources, computing the business logic and providing static content to the web application. Depending on the amount of static content, the service provider might be spending an important percent of time transmitting them, and disk and memory resources which could otherwise be used to serve more clients. At the same time, the server is configured to a configuration which benefits neither the computing nor the fast servicing of the static content.

Solution

An example of Static Content on Amazon's S3, and separate web application on AWS, as seen by the end-user

Splitting the service for static content is a very simple solution to the problem. The generated web content must thus refer the static content to a different deployment which will be created specially for that purpose.

Even if we don't add new machines and only re-purpose some of the original ones into static content and dynamic content, we will benefit from the ability of configuring each one in order to maximize their particular job. Computing nodes might not need fast SSD disks, but could benefit from having several CPUs, while a static content server can have a single CPU unit with plenty of RAM for cache, and fast RAID SSD disks.

Beyond specialization, in a geographically distributed situation we can make use of Content Caching to reduce traffic, or in case of secure content also deploy instances of the static content service in different locations, making sure the web pages generated point to the most appropriate one (i.e. based on IP). A simple example would be a company with two main offices in different continents. Having a static service deployment on each location and with in-house fast-Ethernet avoids slow and expensive intercontinental traffic, while keeping the hardware requirements to a minimum. Even public services can benefit from this geographic distribution, deploying instances close to the most important users' concentrations.

Another benefit of the separation of the Static Content service is the possibility of making use of an existing PaaS to reduce the complexity of the system, or even a third-party service such as Amazon S3 or Azure Storage, which might provide flexibly pricing models.

Instead of directly pointing to a different domain, sometimes the URL Rewriting Pattern is used, which can translate the domain to the corresponding service based on the URL, or even to different locations of the same services.

Structure

The client directly access the static content, alleviating the work of the application service

As stated before, the structure is very simple. It contains the application and the static content providers, both of which are directly accessed by the end user. It is the job of the application provider to include in its response the links pointing to the appropriate static content provider (unless a rename patter is used).

In a widely distributed scenario, a Content Delivery network can be used to limit the traffic between far nodes, highly reducing costly traffic and improving bandwidth.

Example

An on-line store sells products, which are conveniently illustrated by static images. The application allows the user to browse and search the catalogue, and to add elements to a cart before finally paying for the goods. Other static content includes CSS files, logos and other aesthetic elements of the site.

Browsing the catalogue produces hundreds of requests to static content, in particular for the images of the articles in display, creating a heavy load on the service upon each page created for the user, which is listing the catalogue.

Having the static content on a separate services prevents that traffic from hogging the application server, which can in turn serve more user sessions, while the specialized storage service efficiently handles the session-less bandwidth-demanding content.

Known Uses

The biggest problem with the pattern are security related, in particular when content access depends on users' permissions, an additional Private Distribution Pattern might be used to alleviate these problems

The patter is also not well suited when the content is not completely static, for instance if it needs changing its meta-data or merging different resources.

Benefits

  • Improved usage of resources
  • Improved decoupling and scalability
  • Reduced system complexity
  • Sharing static content between different applications
  • Simplified monitoring of traffic and bandwidth by type

See Also

URL Rewriting Pattern, Content Delivery Network

References