Unit 6: Serverless and Microservices Architectures - Subjective Questions

Serverless computing is a cloud execution model in which the cloud provider provisions, manages, scales, patches, and maintains the underlying infrastructure, while developers focus on application code and business logic.

Major characteristics include:

• No server management: Users do not provision or maintain operating systems and servers.
• Automatic scaling: Resources scale according to incoming events or requests.
• Pay-per-use pricing: Charges are generally based on requests, execution duration, and allocated resources.
• Event-driven execution: Functions are invoked by events such as HTTP requests, file uploads, database changes, or messages.
• Stateless compute: Individual function invocations should not depend on local state from previous invocations.
• Built-in availability: The cloud provider operates the service across redundant infrastructure.

The term serverless does not mean that physical servers are absent. Servers still execute the application, but their provisioning and administration are abstracted from the customer.

The following considerations should be evaluated before selecting a serverless architecture:

• Workload pattern: Serverless is suitable for event-driven, intermittent, bursty, or unpredictable workloads. Continuously busy workloads may sometimes be less expensive on containers or virtual machines.
• Execution limits: Functions have limits related to execution duration, memory, temporary storage, deployment size, and concurrency.
• Statelessness: Persistent state should be stored in services such as Amazon DynamoDB, Amazon S3, Amazon Aurora, or ElastiCache rather than in the function environment.
• Latency requirements: Cold starts can affect latency-sensitive applications, especially when functions use large packages or private networking.
• Scalability: Automatic scaling is beneficial, but downstream databases and external services must be protected from sudden concurrency increases.
• Security: The design requires least-privilege IAM roles, secure secret storage, encryption, and controlled API access.
• Observability: Distributed tracing, centralized logging, metrics, correlation identifiers, and alarms are required for troubleshooting.
• Reliability: Architects must plan retries, idempotency, dead-letter handling, failure isolation, and asynchronous recovery.
• Vendor dependency: Deep integration with managed services improves productivity but may increase cloud-provider lock-in.
• Cost: Request volume, execution time, memory, data transfer, API Gateway usage, and related service charges must be estimated.

A serverless architecture is most appropriate when its operational simplicity, elasticity, and event integration outweigh execution constraints, latency concerns, and potential service dependency.

In an event-driven serverless application, an event source detects an activity and invokes an AWS Lambda function directly or supplies records for Lambda to process.

A typical flow is:

1. An event occurs, such as an object being uploaded or an API request being received.
2. The event source creates an event payload containing relevant information.
3. Lambda allocates an execution environment and invokes the configured function handler.
4. The function validates the event, executes business logic, and interacts with other AWS services.
5. The function returns a response or produces another event.
6. Logs and metrics are sent to Amazon CloudWatch.

Common event sources include:

• Amazon API Gateway for HTTP and REST requests
• Amazon S3 for object creation or deletion events
• Amazon DynamoDB Streams for item-level changes
• Amazon EventBridge for scheduled and application events
• Amazon SQS for queued messages
• Amazon SNS for notifications
• Amazon Kinesis Data Streams for streaming records

This model promotes loose coupling because producers generate events without needing to know the internal implementation of consumers.

Important Lambda components include:

• Function code: The application logic executed by Lambda.
• Runtime: The language execution environment, such as Python, Java, Node.js, or .NET.
• Handler: The entry point called when the function is invoked.
• Event object: The input payload supplied by the event source.
• Context object: Runtime information such as the request identifier and remaining execution time.
• Execution role: An IAM role that grants access to required AWS resources.
• Configuration: Memory, timeout, environment variables, networking, concurrency, and temporary storage settings.

The execution lifecycle consists of:

1. Initialization: Lambda creates an execution environment, initializes the runtime, loads the code, and runs initialization code outside the handler.
2. Invocation: Lambda calls the handler with the event and context objects.
3. Response: The handler returns a result or reports an error.
4. Environment reuse: Lambda may reuse the environment for later invocations, allowing initialized clients or connections to be reused.
5. Termination: Lambda eventually removes the environment.

Initialization during a newly created environment contributes to a cold start, whereas reuse usually produces a faster warm invocation.

AWS Lambda functions can be packaged and deployed in two principal ways:

• ZIP archive: The archive contains function code and required dependencies. It can be uploaded directly or stored in Amazon S3.
• Container image: The function and dependencies are packaged as a Lambda-compatible container image and stored in Amazon Elastic Container Registry.

Deployment can be automated with services and tools such as:

• AWS Serverless Application Model
• AWS CloudFormation
• AWS Cloud Development Kit
• AWS CLI
• CI/CD services such as AWS CodePipeline and AWS CodeBuild

A Lambda layer is an archive containing shared libraries, custom runtimes, configuration files, or other dependencies. Layers are attached to functions and made available separately from the main deployment package.

Benefits of layers include:

• Reusing common dependencies across several functions
• Reducing duplication in deployment packages
• Separating application code from libraries
• Centrally updating shared components

However, layer versions should be controlled carefully because changing a shared dependency can affect multiple functions.

Concurrency is the number of Lambda function invocations running at the same time. If a function receives requests per second and each invocation takes an average of seconds, approximate concurrency is:

Lambda creates additional execution environments as demand increases. This supports rapid scaling, but it can also overwhelm downstream databases or external APIs.

Concurrency controls include:

• Reserved concurrency: Guarantees capacity for a function while also setting its maximum concurrency.
• Provisioned concurrency: Keeps pre-initialized execution environments ready to reduce startup latency.
• Account concurrency quotas: Limit total concurrency within an AWS Region.
• Event-source controls: Batch size and maximum concurrency can regulate processing from queues or streams.

A cold start occurs when Lambda must create and initialize a new execution environment. Its impact can be reduced by:

• Keeping deployment packages and dependencies small
• Moving reusable initialization outside the handler
• Selecting an appropriate runtime and memory setting
• Avoiding unnecessary private VPC access
• Using provisioned concurrency for latency-critical functions
• Reusing database connections and SDK clients

Architects should also use queues, throttling, backoff, and load testing to protect downstream services during scaling events.

IAM secures Lambda applications by controlling what can invoke a function and what the function can access.

Important practices include:

• Execution role: Assign each function an IAM role containing only the permissions needed to access AWS resources.
• Least privilege: Restrict actions, resources, conditions, and Regions wherever possible.
• Resource-based policies: Define which AWS accounts or services are permitted to invoke the function.
• Separate roles: Use different roles for functions with different responsibilities instead of sharing a broad role.
• No hard-coded credentials: Use IAM roles rather than embedding access keys in code.
• Secret protection: Store passwords and API keys in AWS Secrets Manager or AWS Systems Manager Parameter Store.
• Encryption: Use AWS Key Management Service keys where additional control over encryption is required.
• Auditing: Use AWS CloudTrail to record management activities and IAM Access Analyzer to identify unintended access.
• API authorization: Protect API Gateway endpoints with IAM authorization, Amazon Cognito, or Lambda authorizers.

These measures reduce the blast radius of compromised code and provide traceability for security investigations.

Lambda environments are temporary and may be created, reused, or removed at any time. Therefore, application correctness must not depend on files, variables, or cached data remaining available between invocations.

Persistent state should be stored externally in services such as:

• Amazon DynamoDB for key-value and document data
• Amazon S3 for objects and files
• Amazon Aurora for relational data
• Amazon ElastiCache for managed caching
• AWS Step Functions for workflow state

An operation is idempotent when processing the same event multiple times produces the same intended result as processing it once. Idempotency is essential because asynchronous events and queue messages may be delivered more than once.

Techniques include:

• Assigning every request or event a unique identifier
• Recording processed identifiers in DynamoDB
• Using conditional writes to prevent duplicate updates
• Designing operations as upserts rather than unconditional inserts
• Making retries safe
• Setting message visibility timeouts correctly
• Sending repeatedly failed events to dead-letter queues
• Using exponential backoff with random jitter

Together, statelessness and idempotency make serverless systems more scalable and resilient to retries, duplicate delivery, and execution-environment replacement.

Amazon API Gateway provides a managed front door through which clients can access Lambda-based business logic and other backend services.

Its major functions include:

• Creating HTTP, REST, and WebSocket APIs
• Mapping routes and methods to Lambda functions or other integrations
• Validating and transforming requests and responses
• Supporting authentication and authorization
• Applying throttling and usage controls
• Enabling cross-origin resource sharing
• Managing deployment stages and API versions
• Collecting access logs and performance metrics
• Supporting caching for selected REST API responses
• Providing custom domain names and TLS endpoints

A common request flow is:

Client → API Gateway → Lambda → Data service → API Gateway → Client

API Gateway therefore separates public API concerns from the Lambda function, allowing the function to concentrate on business logic.

REST APIs provide the broadest API Gateway feature set. They support features such as request validation, transformations, API keys, usage plans, and response caching. They are suitable when advanced API-management capabilities are required.

HTTP APIs are designed for low-latency and cost-effective HTTP endpoints. They support Lambda and HTTP integrations, cross-origin resource sharing, and common authorization options with simpler configuration. They are appropriate for many serverless web applications and proxy APIs.

WebSocket APIs maintain bidirectional connections between clients and backend services. They are suitable for real-time chat, live notifications, collaborative applications, and continuously updated dashboards.

The selection depends on application needs:

• Choose a REST API for advanced management and transformation features.
• Choose an HTTP API for simpler, lower-cost HTTP-based services.
• Choose a WebSocket API when the server must send real-time messages to connected clients without repeated polling.

A typical request-response flow includes the following stages:

1. A client sends an HTTPS request to an API Gateway route.
2. API Gateway performs authentication, authorization, throttling, and optional request validation.
3. The request is mapped into an integration payload.
4. API Gateway invokes the Lambda function.
5. Lambda validates the input, executes business logic, and accesses required services.
6. Lambda returns a structured response containing a status code, headers, and body.
7. API Gateway transforms the response if configured and sends it to the client.

With Lambda proxy integration, the function commonly returns fields such as statusCode, headers, and body.

Error handling should include:

• Returning suitable HTTP status codes such as 400, 401, 403, 404, and 500
• Avoiding exposure of internal exception details
• Logging a correlation or request identifier
• Mapping integration failures to consistent client responses
• Configuring retries only when operations are safe and idempotent

For browser-based clients, cross-origin resource sharing must allow approved origins, methods, and headers. Preflight OPTIONS requests may need to be supported. Production systems should avoid unrestricted origins when sensitive data or credentials are involved.

A well-designed API Gateway API uses several control mechanisms:

Authentication and authorization

• IAM authorization is useful for AWS clients that sign requests.
• Amazon Cognito authorizers validate user tokens for web and mobile applications.
• JWT authorizers validate tokens issued by compatible identity providers.
• Lambda authorizers implement custom authorization logic.

Traffic control

• Throttling limits request rates and bursts.
• Quotas and usage plans can control access for API consumers where supported.
• AWS WAF can block malicious request patterns.

Caching

• API caching can reduce backend calls and improve latency for suitable REST API responses.
• Cache keys and time-to-live values must be selected carefully.
• Sensitive or rapidly changing data should not be cached without appropriate controls.

Observability

• Amazon CloudWatch metrics show request counts, latency, and errors.
• Access and execution logs assist troubleshooting.
• AWS X-Ray or distributed tracing provides visibility across API Gateway, Lambda, and downstream services.
• Correlation identifiers connect logs belonging to the same request.
• Alarms should be configured for elevated latency, throttles, authorization failures, and server errors.

Together, these features protect the API, maintain predictable performance, and support operational diagnosis.

In a container-based microservices architecture, each service is packaged with its code, runtime, and dependencies as a container image. Services can then be deployed, scaled, and updated independently.

AWS services perform the following roles:

• Amazon Elastic Container Registry: Stores, scans, versions, and distributes private container images.
• Amazon Elastic Container Service: Provides AWS-native container orchestration using task definitions, services, clusters, and deployment controls.
• Amazon Elastic Kubernetes Service: Provides a managed Kubernetes control plane for applications that require Kubernetes APIs and ecosystem compatibility.
• AWS Fargate: Supplies serverless compute for containers, removing the need to provision or patch EC2 worker instances.

A typical process is:

1. Developers build and test a container image.
2. The image is pushed to Amazon ECR.
3. An ECS task definition or Kubernetes manifest describes the workload.
4. ECS or EKS schedules the container on Fargate or EC2 capacity.
5. A load balancer routes requests to healthy service instances.
6. Auto scaling adjusts the number of tasks or pods.
7. CloudWatch and tracing tools monitor the service.

Containers are useful for long-running processes, custom runtimes, portable workloads, and applications that exceed function execution constraints.

With the EC2 launch type, containers run on EC2 instances managed by the customer. The customer selects instance types, patches operating systems, manages cluster capacity, and optimizes placement. It provides greater control over hosts, specialized hardware, and cost optimization through detailed capacity planning.

With AWS Fargate, AWS manages the underlying compute infrastructure. The customer specifies task-level CPU, memory, networking, and container configuration. Fargate reduces operational work and provides workload isolation without exposing server management.

Key differences are:

• Infrastructure: EC2 requires host administration; Fargate abstracts hosts.
• Control: EC2 offers more operating-system and instance-level control.
• Scaling: Fargate can add task capacity without first adding cluster instances.
• Pricing: EC2 is billed by instance capacity, while Fargate is based mainly on requested task resources and duration.
• Use cases: EC2 is useful for specialized or highly optimized workloads; Fargate is useful for teams prioritizing simplicity and workload-level scaling.

The choice should consider operational effort, workload consistency, hardware needs, utilization, and cost.

Amazon ECS is an AWS-native container orchestration service. It uses concepts such as clusters, task definitions, tasks, and services. It integrates directly with IAM, Elastic Load Balancing, CloudWatch, AWS Cloud Map, and Fargate. ECS generally has a simpler operational model for organizations focused primarily on AWS.

Amazon EKS is a managed Kubernetes service. It uses Kubernetes concepts such as pods, deployments, services, namespaces, and ingress resources. EKS provides compatibility with Kubernetes tools, APIs, and multi-environment deployment practices.

Major differences include:

• API model: ECS uses AWS-specific APIs; EKS uses Kubernetes APIs.
• Complexity: ECS is usually simpler to operate; EKS requires Kubernetes knowledge.
• Portability: Kubernetes skills and manifests can improve portability, although cloud-specific dependencies may remain.
• Ecosystem: EKS provides access to the broad Kubernetes ecosystem.
• AWS integration: Both integrate with AWS services, but ECS provides a more directly AWS-native experience.

ECS is appropriate when simplicity and AWS integration are priorities. EKS is appropriate when Kubernetes compatibility, ecosystem tools, or organizational Kubernetes standards are required.

Service discovery allows one microservice to locate another despite dynamic task addresses. AWS Cloud Map can register service instances and provide DNS-based or API-based discovery. ECS Service Connect can also simplify service-to-service connectivity and discovery.

Load balancing distributes requests across healthy service instances. An Application Load Balancer supports HTTP routing based on hosts and paths, while a Network Load Balancer supports high-performance transport-level traffic. Health checks prevent routing to unhealthy tasks.

Synchronous communication commonly uses HTTP, REST, or gRPC. It is simple for request-response interactions, but the caller depends on the callee's availability and response time. Timeouts, limited retries, circuit breakers, and fallback behavior are important.

Asynchronous communication uses queues, topics, event buses, or streams, including Amazon SQS, Amazon SNS, Amazon EventBridge, and Amazon Kinesis. It provides temporal decoupling, buffering, and better absorption of traffic spikes.

A robust architecture often combines both approaches:

• Synchronous calls for immediate user-facing responses
• Asynchronous events for background processing and integration
• Dead-letter queues for failed messages
• Correlation identifiers for tracing
• Idempotent consumers for duplicate delivery

This combination reduces coupling and improves the scalability and resilience of microservices.

Microservices should ideally own their data rather than share a common database schema. Independent ownership reduces coupling, but it creates distributed consistency challenges.

Major challenges include:

• Transactions that span multiple services
• Duplicate or out-of-order events
• Temporary inconsistency between data stores
• Schema evolution
• Failure during multi-step business processes
• Building queries that require data from several services

Suitable patterns include:

• Database per service: Each microservice controls its schema and persistence technology.
• Saga pattern: A business transaction is divided into local transactions. If one step fails, compensating actions reverse completed work.
• Event-driven consistency: Services publish domain events that update other services asynchronously.
• Transactional outbox: A service stores its database update and outgoing event in one local transaction; a separate process publishes the event.
• Command Query Responsibility Segregation: Write and read models are separated when their requirements differ.
• Idempotent consumers: Consumers safely handle duplicate events.
• Event versioning: Producers evolve event formats without unexpectedly breaking consumers.

Strong consistency should be used only where the business requires it. Many distributed workflows can use eventual consistency if user expectations and recovery behavior are designed clearly.

The six Well-Architected pillars can be applied as follows:

• Operational Excellence: Define infrastructure as code, automate deployments, use small reversible changes, maintain runbooks, and analyze operational events.
• Security: Apply least-privilege IAM roles, encrypt data, protect APIs, secure secrets, validate input, and record activity using CloudTrail.
• Reliability: Use multiple Availability Zones through managed services, implement retries with backoff, design idempotent operations, use queues and dead-letter queues, and test recovery procedures.
• Performance Efficiency: Select appropriate Lambda memory, minimize cold-start work, use caching, choose suitable databases, process records in batches, and perform load tests.
• Cost Optimization: Use pay-per-use resources, remove unused functions and log retention, select efficient memory and duration settings, and monitor API, data-transfer, and storage costs.
• Sustainability: Reduce unnecessary computation, select efficient managed services, right-size resources, minimize data movement, and remove unused data and duplicate processing.

Applying the pillars is an iterative process. Teams should collect metrics, review trade-offs, and continuously improve the architecture rather than treating the framework as a one-time checklist.

Reliability improvements include:

• Decoupling components with Amazon SQS or EventBridge
• Designing functions to be stateless and idempotent
• Configuring timeouts, bounded retries, exponential backoff, and jitter
• Sending failed asynchronous events to dead-letter queues or failure destinations
• Setting reserved concurrency to protect downstream systems
• Monitoring errors, throttles, duration, queue age, and API latency
• Using deployment versions, aliases, and gradual traffic shifting
• Performing recovery and load tests

Cost optimization measures include:

• Selecting memory based on measured price-performance rather than choosing the smallest value automatically
• Reducing function duration through efficient code and connection reuse
• Using batch processing for queues and streams where appropriate
• Choosing HTTP APIs when advanced REST API features are unnecessary
• Configuring appropriate log-retention periods
• Avoiding unnecessary data transfers and repeated service calls
• Caching safe and frequently requested data
• Removing unused provisioned concurrency and obsolete function versions

A simplified function cost relationship can be represented as:

Optimization must preserve reliability and security; reducing cost should not remove required monitoring, redundancy, or access controls.

A suitable order-processing architecture can contain the following components:

1. Amazon API Gateway exposes endpoints for creating and viewing orders.
2. Amazon Cognito authenticates customers, while API authorization restricts access.
3. An Order Lambda function validates the request and stores the order in Amazon DynamoDB.
4. The function sends an order message to Amazon SQS or publishes an event through Amazon EventBridge.
5. Separate payment, inventory, and notification services process events independently.
6. Long-running coordination can be implemented with AWS Step Functions.
7. Failed messages are sent to a dead-letter queue for investigation and controlled replay.
8. Amazon CloudWatch and AWS X-Ray provide logs, metrics, alarms, and distributed tracing.

Microservices principles are applied because each service has a focused responsibility, can be deployed independently, owns its data, and communicates through stable APIs or events.

Well-Architected considerations include:

• Security: Least-privilege IAM, encrypted data, protected secrets, input validation, and authenticated APIs
• Reliability: Durable queues, idempotency keys, retries with backoff, dead-letter queues, and compensating actions for failed payments or inventory reservations
• Performance: Automatic scaling, appropriate Lambda memory, DynamoDB capacity management, and optional caching
• Operational Excellence: Infrastructure as code, automated tests, deployment aliases, structured logs, and correlation identifiers
• Cost Optimization: Pay-per-use services, batching, suitable log retention, and monitored concurrency
• Sustainability: Efficient managed services, minimal idle capacity, and avoidance of unnecessary processing

The queue or event bus isolates traffic spikes and prevents the public API from waiting for every downstream step. The client can receive an order identifier and later query the workflow status.