Unit 6: Serverless and Microservices Architectures

I. Architectural Foundation

Serverless computing and microservices are cloud-native architectural approaches that reduce infrastructure management and support independent scaling. Serverless shifts server provisioning and maintenance to the cloud provider, while microservices divide an application into small services aligned with business capabilities.

• Defining properties:
  • Managed infrastructure: AWS provisions, patches, and operates the underlying compute platform.
  • Event-driven execution: Events such as an HTTP request, an Amazon S3 upload, or an Amazon EventBridge schedule initiate processing.
  • Elastic scaling: Capacity increases or decreases according to requests, events, tasks, or configured policies.
  • Usage-based charging: Serverless charges commonly depend on requests, execution duration, and allocated resources rather than continuously running servers.
  • Service independence: Microservices can be deployed, scaled, and updated separately when boundaries are designed correctly.
  • Automation: Infrastructure as code, continuous integration and continuous delivery (CI/CD), monitoring, and policy controls replace manual administration.
• Core assumptions:
  • Stateless compute: Persistent state belongs in services such as Amazon DynamoDB, Amazon S3, Amazon Aurora, or Amazon ElastiCache.
  • Failure tolerance: Networks, functions, containers, and downstream services can fail; retries, timeouts, idempotency, and dead-letter handling are necessary.
  • Loose coupling: Amazon SQS, Amazon SNS, and EventBridge reduce direct dependencies between components.
  • Least privilege: Every Lambda function, container task, and API operation receives only the AWS Identity and Access Management (IAM) permissions it requires.
• Common distinction:
  1. Serverless: Uses highly managed services such as AWS Lambda and API Gateway; operational control is lower, but management effort is reduced.
  2. Containerized microservices: Package applications as container images; control and portability are greater, but networking, orchestration, and image management remain important.

II. Serverless Architecture — Design Without Server Management

A. Serverless and architectural considerations

Serverless architecture combines managed compute, storage, integration, and messaging services into event-driven applications.

• Meaning of serverless: Physical servers still exist, but AWS manages capacity provisioning, host maintenance, availability, and much of the scaling process.
• Execution model: A producer creates an event, a managed service routes it, compute processes it, and the result is stored or emitted to another service.
  • Example path: API Gateway → Lambda → DynamoDB.
  • Asynchronous path: S3 → EventBridge → SQS → Lambda.
• State management: Lambda execution environments are temporary, so business state must not depend on process memory or a particular instance.
  • DynamoDB can store entity state.
  • S3 can store durable objects.
  • AWS Step Functions can coordinate workflow state.
• Event coupling: Direct synchronous calls give immediate responses but can propagate latency and failure; queues and event buses isolate producers from consumers.
• Concurrency planning: Each simultaneous Lambda invocation generally consumes one concurrency unit. If 300 requests execute simultaneously, approximately 300 concurrent executions may be required.
• Idempotency: Reprocessing the same event must not create unintended duplicate effects. A payment handler can store an event identifier in DynamoDB and reject an already-completed transaction.
• Security boundaries: IAM execution roles control AWS API access, resource policies control who may invoke services, and encryption protects data in transit and at rest.
• Observability: Amazon CloudWatch metrics and logs, AWS X-Ray traces, and correlation identifiers help follow one request across distributed components.
• Cost model: Cost should include function invocations, execution duration, API calls, data transfer, logs, workflow transitions, and persistent storage—not Lambda alone.

B. Applications and limitations

Serverless is strongest for variable, event-driven workloads but is not automatically ideal for every application.

• Suitable applications: Web APIs, file processing, scheduled automation, stream processing, notifications, lightweight data transformation, and unpredictable traffic fit the event model.
• Operational benefits: Teams avoid operating servers, gain automatic scaling, and can deploy small units independently.
• Cold starts: A new execution environment may add initialization latency; large packages, runtime initialization, and VPC configuration can increase startup work.
• Service constraints: Lambda has quotas, including a maximum invocation duration of 15 minutes, making long-running computation a better fit for containers or batch services.
• Distributed complexity: More managed components create additional IAM policies, logs, failure paths, and service integrations.
• Vendor dependence: Deep use of provider-specific event formats and integrations can increase migration effort.

III. AWS Lambda — Event-Driven Serverless Compute

A. Building serverless applications with AWS Lambda

AWS Lambda runs function code in response to events and automatically manages the underlying execution environments.

• Function structure: A Lambda function contains handler code, a runtime, configuration, dependencies, and an IAM execution role.
• Handler inputs: The handler receives an event containing invocation data and a context object containing runtime information.

def lambda_handler(event, context):
    name = event.get("name", "user")
    return {"statusCode": 200, "body": f"Hello, {name}"}

• Defined symbols:
  • event: Dictionary containing request or event data.
  • context: Object exposing metadata such as request ID and remaining execution time.
  • statusCode: HTTP-style response status used by API integrations.
• Invocation types:
  1. Synchronous: API Gateway or an application waits for the function response; errors are returned to the caller.
  2. Asynchronous: Services such as S3 submit an event for later processing; Lambda manages retries and can route failures to destinations.
  3. Poll-based: Lambda event source mappings poll services such as SQS, DynamoDB Streams, or Amazon Kinesis.
• Resource configuration: Memory can be configured from 128 MB to 10,240 MB; CPU allocation increases with memory. Timeout, environment variables, ephemeral /tmp storage, and concurrency are also configurable.
• Deployment methods: Code can be uploaded as a ZIP package or deployed as a Lambda-compatible container image. AWS SAM, AWS CloudFormation, or the AWS CDK can define repeatable infrastructure.
• Configuration safety: Secrets belong in AWS Secrets Manager or Systems Manager Parameter Store rather than source code or unencrypted environment files.
• Version management: Published versions are immutable, while aliases such as dev or prod can direct traffic to a version and support gradual deployments.
• Performance practices: Initialize reusable SDK clients outside the handler, minimize deployment size, avoid unnecessary network calls, and use provisioned concurrency for latency-sensitive functions.

B. Applications and limitations

Effective Lambda design accounts for retries, duplicate events, dependency failures, and finite execution time.

• Error handling: SQS redrive policies can move repeatedly failing messages to a dead-letter queue for inspection.
• Back-pressure: Reserved concurrency can prevent one function from consuming all regional concurrency or overwhelming a database.
• Monitoring: Important CloudWatch measurements include Invocations, Errors, Duration, Throttles, and ConcurrentExecutions.
• Limitation: Lambda is unsuitable when software requires persistent host access, specialized unsupported hardware, or execution longer than 15 minutes.

IV. Amazon API Gateway — Managed API Front Door

A. Extending functionality using Amazon API Gateway

Amazon API Gateway publishes secure HTTP, REST, and WebSocket interfaces that connect clients to Lambda functions or other backends.

• API types:
  • HTTP APIs: Lower-cost, streamlined APIs for common HTTP routing and Lambda or HTTP integrations.
  • REST APIs: Feature-rich APIs supporting capabilities such as API keys, usage plans, request validation, and transformations.
  • WebSocket APIs: Persistent, two-way communication for chat, live dashboards, and notifications.
• Request flow: A route such as GET /orders/{id} maps an HTTP method and path to a Lambda integration; the path parameter becomes part of the event.
• Authorization: APIs can use IAM authorization, Amazon Cognito user pools, JWT authorizers for HTTP APIs, or Lambda authorizers for custom decisions.
• Traffic protection: Throttling limits request rates, usage plans can govern client consumption, and AWS WAF can filter malicious web traffic where supported.
• Validation and transformation: API Gateway can validate parameters and payloads; REST APIs can use mapping templates to translate between external and backend formats.
• Deployment control: Stages such as dev, test, and prod isolate configurations. Custom domains provide stable public names.
• Cross-origin access: Cross-Origin Resource Sharing (CORS) headers determine whether browser applications from another origin may call the API.
• Observability: Access logs, execution logs where applicable, latency metrics, error metrics, and X-Ray tracing reveal client and integration behavior.

B. Applications and limitations

API Gateway separates public API concerns from backend business logic but introduces an additional managed layer.

• Benefits: It centralizes routing, authentication, throttling, monitoring, versioned deployment, and backend integration.
• Failure distinction: A 4xx response commonly indicates a client or authorization problem, while a 5xx response commonly indicates integration or backend failure.
• Design caution: Large payloads, long-running operations, or sustained high-volume internal communication may require S3 uploads, asynchronous workflows, or direct service networking.
• Security caution: An API key identifies a consumer for metering; it is not a substitute for authentication and authorization.

V. AWS Container Services — Microservices at Scale

A. Running microservices with AWS container services

AWS container services package each microservice and its dependencies into an image and use orchestration to deploy and scale instances.

• Amazon ECR: Elastic Container Registry stores private container images, supports image scanning, and integrates with IAM.
• Amazon ECS: Elastic Container Service schedules containers using AWS-native task definitions, services, clusters, and tasks.
• Amazon EKS: Elastic Kubernetes Service provides a managed Kubernetes control plane and supports Kubernetes objects such as Pods, Deployments, and Services.
• AWS Fargate: Serverless compute for ECS or EKS removes EC2 instance management; CPU and memory are assigned per task or pod.
• EC2 launch model: ECS or EKS on EC2 provides greater host control and can support specialized instance types, but teams manage node capacity and patching.
• Service exposure: An Application Load Balancer can route /catalog and /orders to separate target groups and services.
• Service communication: Synchronous HTTP or gRPC is simple but tightly time-coupled; SQS, SNS, and EventBridge support asynchronous communication.
• Scaling: ECS Service Auto Scaling can adjust desired task count using CPU, memory, or custom CloudWatch metrics.
• Deployment safety: Rolling, blue/green, and canary strategies reduce release risk. Health checks prevent traffic from reaching unhealthy tasks.
• Data ownership: Each microservice should own its data model; sharing one database schema creates coupling that undermines independent deployment.

B. Applications and limitations

Containers suit long-running, portable, or runtime-specific workloads, but microservices increase operational coordination.

• Advantages: Containers provide dependency isolation, consistent environments, runtime flexibility, and support for processes exceeding Lambda’s duration limit.
• Operational costs: Teams must manage image vulnerabilities, service discovery, network policies, deployment strategies, and capacity choices.
• Architecture risk: Splitting a small system too aggressively can create a distributed monolith with many network calls but little service independence.
• Selection principle: ECS offers simpler AWS-native orchestration; EKS fits organizations requiring Kubernetes compatibility; Fargate minimizes node administration.

VI. Well-Architected Serverless Design

A. Applying Well-Architected principles to serverless architectures

The AWS Well-Architected Framework evaluates workloads through six pillars and applies them to functions, APIs, events, data stores, and deployment processes.

• Operational excellence: Define infrastructure with SAM, CloudFormation, or CDK; automate deployments; use structured logs, dashboards, alarms, and runbooks.
• Security: Apply least-privilege IAM roles, encrypt data with AWS KMS, store secrets securely, validate input, and protect APIs with authorization and WAF controls.
• Reliability: Use multi-Availability Zone managed services, asynchronous buffering, exponential backoff, jitter, dead-letter queues, and idempotent consumers.
• Performance efficiency: Select suitable Lambda memory, avoid unnecessary function chains, use caching where appropriate, and load-test concurrency and downstream capacity.
• Cost optimization: Match architecture to traffic, control log retention, avoid unnecessary API transitions, and compare Lambda duration costs with container costs for steady workloads.
• Sustainability: Reduce idle resources, right-size memory and container tasks, minimize wasteful data movement, and use efficient managed services.
• Serverless-specific review: Evaluate event sources, concurrency, retry behavior, payload size, service quotas, observability, and failure destinations rather than reviewing compute alone.

B. Applications and limitations

Well-Architected design requires explicit trade-offs because optimizing one pillar can affect another.

• Trade-off example: Provisioned concurrency reduces Lambda startup latency and improves performance predictability, but it increases cost.
• Resilience example: Adding SQS between API processing stages absorbs traffic spikes, but changes immediate synchronous processing into eventual processing.
• Review practice: Architecture reviews should occur before production and after major workload, traffic, security, or dependency changes.
• Improvement principle: Findings should become prioritized engineering actions, such as narrowing an IAM policy, adding an alarm, testing recovery, or configuring a dead-letter queue.