AWS Serverless for a global web app

This is the first article in a series about my experience with implementing an AWS Serverless Global Web Application for a large enterprise.

I have written a few posts about a globally distributed web application that one of my clients is re-writing from Microsoft Sharepoint to AWS Serverless. This is a great success on many fronts. Financially, my client thinks that at about $15,000 a year for infrastructure, the app is “practically free”. Developers love it because of all the new technology and easy of working with it. Ops loves it because all they have to do is monitor and escalate as needed. I love it because I can save my customer tens of thousands of $ while improving their global footprint with high performance and high availability. This is a win-win in all senses of the phrase. Today, I wanted to start writing about the technical architecture of this new app. This note is about the architecture at the highest level. Over time, I intend to embellish this with links to more articles about each specific part of the global serverless architecture.

The Requirements

Briefly, the requirement is to serve a web application to be used in around 60 nations in the world that never goes down and is very fast. Costs are not a concern, however, of course, lowest cost solution is preferred. Here are a few bullet points to cover most requirements.

  • Global Web App (60+ countries)
  • All web requests to take less than 3 seconds.
  • Highly Available (no downtime permitted for failures, deployments etc.)
  • Secured using Enterprise hosted Active Directory (SAML)
  • Allow securely uploaded User Generated Content
  • Allow secure download of documents and facial profiles
  • Ensure that no data can be harnessed by bots
  • Allow large data uploads by machine clients (background processing)
  • Do all of this much cheaper and faster than incumbent technology (be up and running in 3 to 6 months)

Constraints

To be honest, there were not too many constraints except for the few listed here.

  • Application must run on Amazon Web Services (our preferred vendor)
  • Developers & Operations staff did not have any prior experience with AWS

High Level View of Architecture

With this in mind, I started to propose a strawman using the following picture in March 2017. Over time, I intend to share here each specific piece of the architecture and how we met all requirements within all constraints.

Fig 1. A very broad, high level architecture of the serverless application

Here is a list of Significant Sub-Systems.

  • Serverless Static Assets (S3, Cloudfront)
  • Serverless API (API Gateway, Lambda, DynamoDB)
  • Authentication (Enterprise Active Directory + Cognito Federated Identities)
  • Secure Upload (Cloudfront pre-signed uploads)
  • Background Processors (Lambda Step Functions, Kinesis Streams, SQS)
  • Continuous Deployment (Codepipeline, Codebuild, Cloudformation)
  • Logs Visualization (Elasticsearch, Kinesis Firehose)
  • Security (IAM, Encryption)
  • Global Replication (DynamoDB, Cloudformation, Active Directory)
  • Performance Testing (Blazemeter, JMeter)
  • Monitoring (Cloudwatch, LogicMonitor)

It was fun, to say the least. We started in earnest in August 2017 and were in a production like environment by December. It costs peanuts and works like a horse. I love it.