2.1.1.3. Selecting Appropriate Compute for Workloads (Monolith, Microservices, Batch)

2.1.1.3. Selecting Appropriate Compute for Workloads (Monolith, Microservices, Batch)

💡 First Principle: Matching the architectural style (e.g., monolith, microservices) and operational characteristics of a workload to the most suitable compute service optimizes development, deployment, and operational efficiency.

Scenario: A company is developing a new order processing system that needs to be highly agile, with development teams independently deploying new features. The system is expected to handle fluctuating transaction volumes and require a scalable, fault-tolerant backend.

The nature of the workload dictates the optimal compute choice. A Solutions Architect must understand these distinctions.

• Monolithic Applications: Large, tightly coupled applications where all components are deployed as a single unit.
  • Compute Options: Often best suited for "Amazon EC2" (allows fine-grained control over OS/dependencies) or "AWS Elastic Beanstalk" (managed environment for web apps). Consider "EC2 Image Builder" to create immutable AMIs for consistent deployments.
  • Elastic Beanstalk in practice: You upload the application; Beanstalk provisions and patches the platform, configures the load balancer, Auto Scaling and monitoring, and the underlying "EC2", "ALB" and "Auto Scaling group" stay visible and tunable in your account. That middle ground (managed, yet adjustable, with no re-architecture) is what separates it from hand-built EC2 and from Lambda.
  • "EC2 Image Builder" pipeline: Automates golden-AMI creation: start from an AWS-managed or custom base image, apply build components (OS patches, application install), run test components to validate, then distribute the AMI to chosen Regions and accounts on a schedule or when the base image updates. "CloudFormation", "CodePipeline" and "Systems Manager State Manager" can orchestrate or configure resources but are not purpose-built AMI build pipelines.
  • Practical Relevance: Simplifies initial deployment for smaller teams but can become a bottleneck for scaling or independent feature development.
• Microservices: Loosely coupled, independent services that communicate via APIs or events. Each service is deployed independently.
  • Compute Options: Excellent fit for container services like "Amazon ECS" (AWS-native) or "Amazon EKS" (managed Kubernetes). "AWS Fargate" can provide serverless containers for reduced operational overhead. "AWS Lambda" for event-driven, stateless microservices.
  • Practical Relevance: Enables independent scaling, faster development cycles, and resilience through fault isolation. Requires mature CI/CD and observability.
  • Decoupling with messaging (exam-critical): Put a durable buffer between a producer and a consumer so a slow or failed consumer neither loses work nor blocks the producer, and the two scale independently.
    • "Amazon SQS" (queue, point-to-point): Messages are stored durably (4 days by default, up to 14) and absorb traffic spikes; consumers poll at their own pace and scale on queue depth. Standard queues give nearly unlimited throughput with at-least-once delivery and best-effort ordering; FIFO queues give strict order within a message group and exactly-once processing (deduplication), at lower throughput. Each message goes to one consumer.
    • Visibility timeout: After a consumer receives a message it is hidden for the visibility timeout (default 30 seconds, max 12 hours). If processing takes longer than the timeout, the message reappears and another consumer processes it again (duplicate processing); set the timeout above the processing time and delete the message after success.
    • Dead-letter queue (DLQ): Configure a DLQ on the source queue with a maxReceiveCount; messages that repeatedly fail (poison pills) move there for analysis instead of blocking the queue. Longer retention, a longer visibility timeout, or FIFO do not isolate them. In an SNS-to-SQS fan-out, put the DLQ on the failing consumer's SQS queue (SNS dead-letter queues attach to a subscription, not to the topic).
    • "Amazon SNS" (pub/sub): One published event is pushed to every subscriber (SQS queues, Lambda, HTTP, email); use SNS-to-SQS fan-out when several downstream services must react independently, and subscription filter policies to send each consumer only the events it wants. Synchronous calls or a shared polling table keep the services tightly coupled.
    • "Amazon MQ": Managed ActiveMQ/RabbitMQ for applications that already use standard broker protocols (JMS, AMQP, MQTT) and cannot move to SQS/SNS APIs; it also qualifies as an asynchronous buffer.
    • SQS vs. Kinesis Data Streams vs. EventBridge: SQS = work queue (one consumer per message, no replay); Kinesis = ordered high-throughput stream with replay and many consumers of the same data (see 2.4.1.4); EventBridge = rules-based event routing between services and SaaS. A load balancer or API Gateway routes live requests but does not durably buffer them, and Step Functions orchestrates workflows rather than buffering messages.
• Batch Processing: Workloads characterized by large datasets, infrequent runs, and often long execution times, typically not interactive.
  • Compute Options: "AWS Batch" (managed service for running batch jobs), "AWS Lambda" (for smaller, short-duration batch jobs), "Amazon EMR" (for big data processing with "Hadoop"/"Spark").
  • Fit details: A "Lambda" invocation is capped at 15 minutes, so longer-running background work belongs on "AWS Batch" or "Fargate" tasks. "AWS Batch" provisions and scales the compute environment for you and can run on "Spot Instances", which makes fault-tolerant, parallel batch jobs cheapest there; one large On-Demand server running nightly pays for idle time and does not parallelize.
  • Practical Relevance: Optimizes cost by scaling resources only when needed, supporting massive parallelism, and integrating with data lakes.

Visual: Workload to Compute Mapping

⚠️ Common Pitfall: Trying to run a large, stateful monolithic application on a serverless platform like "Lambda" without significant re-architecting. This mismatch leads to performance issues, state management complexity, and potential cost inefficiencies.

Key Trade-Offs:

• Development Simplicity (Monolith) vs. Scalability & Agility (Microservices): Monoliths are often simpler to start with but become harder to scale and update. Microservices offer independent scaling and deployment agility but introduce operational complexity (service discovery, distributed tracing).

Reflection Question: Given the need for agility, independent deployments, and scalability for an order processing system, why would a microservices architecture leveraging "Amazon ECS" or "Amazon EKS" be more suitable than a traditional monolithic application on "Amazon EC2", and what trade-offs would be involved?