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.
  • 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.
• 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").
  • Practical Relevance: Optimizes cost by scaling resources only when needed, supporting massive parallelism, and integrating with data lakes.

Visual: Workload to Compute Mapping

Loading diagram...

⚠️ 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?