Serverless — Serverless Architectures — Theory (Bản gốc slide / Original slide)

1. Case Study 1 — Mobile App "MyTodoList": Yêu cầu

Xây dựng một mobile application với các yêu cầu sau:

• Expose dưới dạng REST API qua HTTPS
• Kiến trúc serverless
• User có thể tương tác trực tiếp với folder riêng của họ trong S3
• User phải xác thực thông qua một managed serverless service
• User có thể ghi và đọc to-do, nhưng chủ yếu là đọc
• Database phải scale được và có read throughput cao

Build a mobile application with the following requirements:

• Expose as a REST API over HTTPS
• Serverless architecture
• Users should be able to directly interact with their own folder in S3
• Users should authenticate through a managed serverless service
• Users can write and read to-dos, but they mostly read
• The database should scale and have high read throughput

2. Kiến trúc REST API Serverless đầy đủ

Kiến trúc được xây dựng dần qua từng lớp:

• REST API layer: Mobile client → (authenticate) Cognito, đồng thời Mobile client → API Gateway (REST HTTPS) → Lambda (invoke) → DynamoDB (query). API Gateway verify authentication thông qua Cognito trước khi forward request.
• Truy cập S3 trực tiếp: Cognito cấp permissions (AWS credential tạm thời) cho mobile client, cho phép client store/retrieve file trực tiếp trên S3 mà không cần đi qua API Gateway/Lambda.
• High read throughput: thêm DAX (DynamoDB Accelerator) làm caching layer giữa Lambda và DynamoDB để tăng tốc đọc — phù hợp vì app "đọc nhiều hơn ghi".
• Caching ở API Gateway: bật thêm caching response tại API Gateway để giảm tải cho Lambda/DynamoDB với các request lặp lại.

The architecture is built up layer by layer:

• REST API layer: Mobile client → (authenticate) Cognito, and Mobile client → API Gateway (REST HTTPS) → Lambda (invoke) → DynamoDB (query). API Gateway verifies authentication through Cognito before forwarding the request.
• Direct S3 access: Cognito grants permissions (temporary AWS credentials) to the mobile client, letting it store/retrieve files directly on S3 without going through API Gateway/Lambda.
• High read throughput: add DAX (DynamoDB Accelerator) as a caching layer between Lambda and DynamoDB to speed up reads — fitting since the app "reads more than it writes".
• Caching at API Gateway: also enable response caching at API Gateway to reduce load on Lambda/DynamoDB for repeated requests.

3. Tổng kết Case Study 1

• Serverless REST API: HTTPS, API Gateway, Lambda, DynamoDB
• Dùng Cognito để sinh AWS credential tạm thời, cho phép app user truy cập trực tiếp vào S3 bucket với policy giới hạn. Pattern này cũng áp dụng được cho DynamoDB, Lambda…
• Caching read trên DynamoDB bằng DAX
• Caching REST request ở tầng API Gateway
• Bảo mật authentication & authorization với Cognito

• Serverless REST API: HTTPS, API Gateway, Lambda, DynamoDB
• Using Cognito to generate temporary AWS credentials to access an S3 bucket with a restricted policy. App users can directly access AWS resources this way — the pattern can also be applied to DynamoDB, Lambda…
• Caching the reads on DynamoDB using DAX
• Caching the REST requests at the API Gateway level
• Security for authentication and authorization with Cognito

4. Case Study 2 — Serverless Website "MyBlog.com": Yêu cầu

• Website phải scale toàn cầu
• Blog ít khi được viết, nhưng thường xuyên được đọc
• Một phần website là file tĩnh thuần, phần còn lại là REST API động
• Phải implement caching ở những nơi có thể
• User mới subscribe thì phải nhận được email chào mừng
• Ảnh upload lên blog phải tự động tạo thumbnail

• This website should scale globally
• Blogs are rarely written, but often read
• Part of the website is purely static files, the rest is a dynamic REST API
• Caching must be implemented where possible
• Any new user who subscribes should receive a welcome email
• Any photo uploaded to the blog should have a thumbnail generated

5. Phục vụ nội dung tĩnh toàn cầu & bảo mật

• Serving static content, globally: Client → Amazon CloudFront (global distribution, edge location) → Amazon S3
• Serving static content, globally, securely: dùng OAC (Origin Access Control) để CloudFront truy cập S3, kết hợp Bucket Policy chỉ cho phép request đến từ chính CloudFront Distribution đó — bucket S3 vẫn ở chế độ private, không public.

• Serving static content, globally: Client → Amazon CloudFront (global distribution, edge location) → Amazon S3
• Serving static content, globally, securely: use OAC (Origin Access Control) for CloudFront to access S3, combined with a Bucket Policy that only authorizes requests from that specific CloudFront Distribution — the S3 bucket stays private, never public.

6. Thêm REST API công khai & DynamoDB Global Tables

• Adding a public serverless REST API: API Gateway → Lambda → DAX → DynamoDB, tiếp nối phần static content ở trên — vì API công khai nên không cần Cognito.
• Leveraging DynamoDB Global Tables: dùng Global Tables để dữ liệu được replicate multi-region, phục vụ user đọc/ghi ở gần vùng của họ, đúng yêu cầu "scale toàn cầu".

• Adding a public serverless REST API: API Gateway → Lambda → DAX → DynamoDB, on top of the static content above — since the API is public, no Cognito is needed.
• Leveraging DynamoDB Global Tables: use Global Tables so data is replicated multi-region, serving users' reads/writes closer to their region, matching the "scale globally" requirement.

7. Welcome Email flow & Thumbnail Generation flow

• User Welcome email flow: khi user mới ghi vào DynamoDB, DynamoDB Streams bắt thay đổi và trigger một Lambda function. Lambda này có IAM Role cho phép gọi Amazon SES (Simple Email Service) qua SDK để gửi email chào mừng — toàn bộ flow không cần server nào.
• Thumbnail Generation flow: user upload ảnh lên S3 (có thể dùng Transfer Acceleration), việc upload trigger một Lambda function khác để tạo thumbnail và lưu lại vào S3. Có thể tuỳ chọn thêm SQS/SNS để thông báo sự kiện cho các hệ thống khác.

• User Welcome email flow: when a new user is written to DynamoDB, DynamoDB Streams captures the change and triggers a Lambda function. That Lambda has an IAM Role allowing it to call Amazon SES (Simple Email Service) via SDK to send a welcome email — the entire flow needs no server.
• Thumbnail Generation flow: the user uploads a photo to S3 (optionally using Transfer Acceleration), the upload triggers a Lambda function that generates a thumbnail and stores it back to S3. SQS/SNS can optionally be added to notify other systems of the event.

8. Tổng kết MyBlog.com (AWS Hosted Website Summary)

• Nội dung tĩnh được phân phối bằng CloudFront với S3
• REST API là serverless, không cần Cognito vì API công khai
• Dùng Global DynamoDB table để phục vụ dữ liệu toàn cầu (thay thế có thể là Aurora Global Database)
• Bật DynamoDB Streams để trigger một Lambda function
• Lambda function có IAM role cho phép sử dụng SES
• SES dùng để gửi email theo cách serverless
• S3 có thể trigger SQS / SNS / Lambda để thông báo sự kiện

• Static content is distributed using CloudFront with S3
• The REST API is serverless, didn't need Cognito because it's public
• Leveraged a Global DynamoDB table to serve data globally (could have used Aurora Global Database instead)
• Enabled DynamoDB Streams to trigger a Lambda function
• The Lambda function had an IAM role which could use SES
• SES (Simple Email Service) was used to send emails in a serverless way
• S3 can trigger SQS / SNS / Lambda to notify of events

9. Case Study 3 — Micro Services Architecture

Yêu cầu: chuyển sang kiến trúc micro service, nhiều service tương tác trực tiếp qua REST API, mỗi micro service có thể khác nhau về hình dạng/kiến trúc, mục tiêu là có development lifecycle gọn nhẹ hơn cho từng service.

Requirement: switch to a micro service architecture, many services interact with each other directly using a REST API, each micro-service architecture may vary in form and shape, the goal is a leaner development lifecycle for each service.

Micro Services Environment: Users → Route 53 (DNS Query), sau đó phân nhánh HTTPS đến 3 micro service hoàn toàn độc lập về công nghệ:

• service1.example.com: Elastic Load Balancing → ECS → DynamoDB
• service2.example.com: API Gateway → Lambda → ElastiCache
• service3.example.com: Elastic Load Balancing → EC2 Auto Scaling Group → RDS

Mỗi service tự do chọn kiến trúc phù hợp riêng — đúng tinh thần micro service.

Micro Services Environment: Users → Route 53 (DNS Query), then branching over HTTPS to 3 micro services that are completely independent in technology:

• service1.example.com: Elastic Load Balancing → ECS → DynamoDB
• service2.example.com: API Gateway → Lambda → ElastiCache
• service3.example.com: Elastic Load Balancing → EC2 Auto Scaling Group → RDS

Each service is free to choose its own fitting architecture — the essence of micro services.

10. Thảo luận về Micro Services

• Bạn tự do thiết kế mỗi micro-service theo cách riêng
• Pattern đồng bộ (synchronous): API Gateway, Load Balancers
• Pattern bất đồng bộ (asynchronous): SQS, Kinesis, SNS, Lambda trigger (S3)
• Thách thức của micro-services:
  • Overhead lặp lại khi tạo mỗi microservice mới
  • Vấn đề tối ưu server density/utilization
  • Độ phức tạp khi chạy nhiều version của nhiều microservice cùng lúc
  • Client-side code phải tích hợp với nhiều service riêng lẻ
• Serverless pattern giải quyết một phần các thách thức trên:
  • API Gateway, Lambda tự scale và tính phí theo usage
  • Dễ dàng clone API, tái tạo environment
  • Sinh client SDK tự động qua tích hợp Swagger cho API Gateway

• You are free to design each micro-service the way you want
• Synchronous patterns: API Gateway, Load Balancers
• Asynchronous patterns: SQS, Kinesis, SNS, Lambda triggers (S3)
• Challenges with micro-services:
  • Repeated overhead for creating each new microservice
  • Issues with optimizing server density/utilization
  • Complexity of running multiple versions of multiple microservices simultaneously
  • Proliferation of client-side code requirements to integrate with many separate services
• Some challenges are solved by Serverless patterns:
  • API Gateway, Lambda scale automatically and you pay per usage
  • You can easily clone APIs, reproduce environments
  • Generated client SDK through Swagger integration for the API Gateway

11. Case Study 4 — Software Updates Offloading

Bài toán: một application chạy trên EC2 phân phối software update theo định kỳ. Mỗi khi có bản update mới, hệ thống nhận rất nhiều request và content được phân phối ồ ạt qua network — rất tốn kém. Không muốn thay đổi ứng dụng, nhưng cần tối ưu chi phí & CPU.

Problem: an application running on EC2 that distributes software updates once in a while. When a new software update is out, the system gets a lot of requests and the content is distributed in mass over the network — very costly. Don't want to change the application, but want to optimize cost and CPU.

Cách khắc phục đơn giản: đặt Amazon CloudFront ở phía trước Auto Scaling group (đang chạy trên 3 Availability Zone, dùng chung Amazon EFS) — không cần thay đổi gì ở kiến trúc ứng dụng.

Easy way to fix things: put Amazon CloudFront in front of the Auto Scaling group (spread across 3 Availability Zones, sharing Amazon EFS) — no changes to the architecture are needed.

12. Vì sao dùng CloudFront?

• Không cần thay đổi kiến trúc
• CloudFront sẽ cache file software update tại edge
• File update không đổi (static), không phải nội dung động
• EC2 instance không phải serverless
• Nhưng CloudFront thì có, và sẽ tự scale thay cho ta
• ASG sẽ scale ít hơn, tiết kiệm đáng kể chi phí EC2
• Tiết kiệm cả về availability, network bandwidth cost…
• Cách dễ dàng để làm ứng dụng có sẵn scale tốt hơn và rẻ hơn!

• No changes to architecture
• CloudFront will cache software update files at the edge
• Software update files are not dynamic, they're static (never changing)
• Our EC2 instances aren't serverless
• But CloudFront is, and will scale for us
• Our ASG will not scale as much, and we'll save tremendously in EC2
• We'll also save in availability, network bandwidth cost, etc.
• Easy way to make an existing application more scalable and cheaper!