A brief history of AWS architectures

The way you create architectures on AWS has evolved over the last ten years.

In this blog post, I demonstrate what is better today than ten years before.

2009

In 2009, a typical architecture on AWS used the following components:

• Classic Load Balancer (CLB): Distribute requests across a fleet of EC2 instances.
• Auto Scaling Group (ASG) with EC2 instances: Manage a dynamic fleet of virtual machines.
• RDS database: Fully managed MySQL database offering.

2015

2015 was an innovative year. AWS launched the Elastic Container Service (ECS) to orchestrate Docker containers running on EC2 instances. RDS Aurora was launched to push the limits of relational databases.

Besides that, AWS launched a new category of services to build Serverless architectures:

• Lambda functions: Execute code
• API Gateway (RESTful): Trigger Lambda functions on HTTP requests
• DynamoDB (2012): NoSQL database

2016

The Application Load Balancer (ALB) was released in 2016. The ALB is a layer 7 HTTP(S) load balancer with more capabilities than the CLB. Sounds like a minor innovation? It was a big deal for container workloads.

2017

In 2017, the Network Load Balancer was launched. The NLB is a layer 4 TCP load balancer for high throughput (millions of requests per second) and low latency workloads. It uses the same API constructs than the ALB.

The big launch in 2017 was Fargate. Fargate runs your Docker containers orchestrated by ECS. You no longer have to operate the EC2 instances to host the containers.

2018

In 2018, the relational database scalability issue was finally solved for most workloads with RDS Aurora Serverless. RDS Aurora Serverless provides an auto-scaled relational database for you.

Furthermore, App Sync was launched. App Sync can be seen as a replacement for API Gateway. App Sync is based on GraphQL and integrates natively with Lambda, DynamoDB, and other Serverless services.

2019

I’m curious what we will hear from AWS this year.