17 - Serverless Solution Architecture Discussions

Microservices Architecture

awsserverlessmicroservicesecsapi-gatewaysaa-c03

Overview

This is not exactly serverless, but it is a useful discussion. We want to move to a microservice architecture where many services interact, for example through a REST API. Each microservice can have a different architecture, so you are free to design each one.

Why microservices:

  • A leaner development lifecycle for each service
  • Each service scales independently
  • Each service has its own code repository

Architecture Example

Users ─HTTPS─▶ ELB ─▶ ECS ─▶ DynamoDB            service1.example.com
Lambda ─▶ ElastiCache  (calls service 1 via its ELB)   service2
ELB ─▶ EC2 Auto Scaling ─▶ RDS  (calls service 2)      service3.example.com
Service Architecture Notes
Service 1 ELB → ECS → DynamoDB ECS is for Docker containers on AWS. DNS query to Route 53 returns an alias record
Service 2 Lambda → ElastiCache Serverless; ElastiCache as the backend for Lambda "just for fun". Calls service 1 through its ELB
Service 3 ELB → EC2 Auto Scaling → RDS Classic architecture. The EC2 instance calls service 2 before deciding

Each service has a DNS name or URL (service1.example.com, service3.example.com). The point is that you are free to design each microservice the way you want.

Three microservices, three designs

Each microservice is free to use its own design Service 1 ELB ECS DynamoDB Service 2 Lambda ElastiCache calls service 1 via its ELB Service 3 ELB EC2 Auto Scaling RDS calls service 2 first
You are free to design each microservice.

Two Communication Patterns

Pattern How Services
Synchronous Explicit calls to other microservices API Gateway, Load Balancer (HTTPS calls)
Asynchronous Put a message and do not wait for or care about a response; something else happens SQS, Kinesis, SNS, Lambda triggers, S3

Synchronous versus asynchronous

Synchronous Explicit calls to other microservices API Gateway Load Balancer HTTPS calls Asynchronous Put a message, do not wait for a response SQS, Kinesis, SNS Lambda triggers, S3 Something else happens
Know which services belong to which pattern.

Challenges

  • Overhead of creating each new microservice
  • Issues optimizing server density or utilization
  • Complexity of running multiple versions of each microservice simultaneously
  • Proliferation of client-side code needed to integrate with many separate services

How Serverless Helps

  • API Gateway and Lambda scale automatically and you pay for usage, so no worry about server utilization.
  • Easily clone APIs or reproduce environments in API Gateway.
  • Generate a client SDK through Swagger integration for API Gateway.

Exam Tips

Key points
  • Microservices are a design. Use any AWS services you like, it solves some problems and adds others.
  • Know the synchronous (API Gateway, Load Balancer) versus asynchronous (SQS, Kinesis, SNS, Lambda triggers, S3) patterns.
  • Serverless (API Gateway + Lambda) removes server utilization worries.

Q&A

Q1: Why choose microservices?

Answer: Leaner development lifecycle per service, independent scaling, and a separate code repository per service.

Q2: Which AWS services fit synchronous versus asynchronous communication?

Answer: Synchronous: API Gateway, Load Balancer. Asynchronous: SQS, Kinesis, SNS, Lambda triggers, S3.

Q3: What challenges come with microservices, and what helps?

Answer: Per-service overhead, server utilization, multiple versions, and client-side code growth. Serverless patterns (API Gateway, Lambda) help with auto-scaling, pay per usage, API cloning and SDK generation via Swagger.

Related: 16 - Serverless Overviews/11-Amazon-API-Gateway, 16 - Serverless Overviews/02-AWS-Lambda, 14 - Decoupling Applications SQS SNS Kinesis MQ/07-Amazon-SNS, 14 - Decoupling Applications SQS SNS Kinesis MQ/02-SQS-Standard-Queues.

Check yourself

Quiz

Flashcards

Click the card (or focus it), then use ← → to move and Space to flip.