We here at Culture Foundry have some clients who see intense traffic spikes due to “real world” events. For this scenario, we’ve written a serverless solution that scales well at a reasonable cost (both in terms of dollars and developer time). The solution doesn’t use new serverless technologies like Lambda or the other FAAS offerings, but rather an older technology, Amazon S3. We leverage S3 and built a publishing system which handles large numbers of users and displays oft-updated information beautifully.
There are three components to the architecture.
The first is a data processing engine that pulls data from a variety of sources and builds a set of JSON files containing the displayed data. This engine can run anywhere and be written in any language. Our system happens to run on EC2 and be written in Go. In addition to pushing the data up to S3, the processing engine sets headers to have the data cached intelligently. For example, recent event data can be set to cache for seconds, whereas unchanging historic data can be cached for months.
The second component is AWS S3 and Cloudfront. An S3 bucket holds the JSON files, including updated files from the data processing engine. Cloudfront sits in front of S3 and caches the data as it is requested. Cloudfront helps with delivery speed, scaling, and decreased cost. You will want to make sure you set up CORS on S3 correctly to allow access for the display component (see below).
What type of problems is this solution not a good fit for?
- Real time updates. Pushing changes to S3 and through Cloudfront takes time, and don’t forget the eventual consistency model of S3. If milliseconds matter (you’re building a stock trading interface, for example), I’d look at a different solution.
- An internal application. While you can lock down access using signed URLs and OAI and TLS, your data will still be traveling over the public internet. If that worries you, this may not be the right fit.
- Small numbers of users. This solution has a lot of moving parts that need to be maintained by expensive software developers. If you don’t expect to have tens of thousands (or more) concurrent users, you will want to stick with a plain old CMS.
This approach leverages the serverless technology of S3 along with a few other components to build a solution that you can still configure via your CMS, but use the power of the network to leverage both AWS S3 and your users’ browsers. Such scaling (both up and down) is transparent and doesn’t require building or managing infrastructure.