Describe the workload first

A technology decision becomes clearer after documenting traffic patterns, response-time expectations, deployment frequency, background jobs, dependencies and compliance requirements. An API serving short event-driven requests has different needs from a persistent WebSocket service or a data-processing worker.

Also consider the team: if engineers already operate containers with reliable pipelines and monitoring, introducing another runtime carries a learning and operations cost.

Where serverless is strong

A combination such as API Gateway, Lambda, SQS and managed storage can be effective for event-driven workloads or APIs with uneven traffic. The platform handles server management and scales execution units in response to events. This lets a small team focus on application behaviour and permissions.

  • Good fit for webhook processing, scheduled tasks, event transformations and compact APIs.
  • Keep functions focused and use queues to absorb bursts or retries.
  • Design around execution limits, cold-start sensitivity and connection management.
API Gateway -> Lambda -> SQS -> worker Lambda
                    |
                    +-> DynamoDB / S3 / RDS proxy

Where containers are strong

Container deployment on ECS or Kubernetes provides more runtime control for long-running services, custom system packages, predictable warm processes, background consumers and workloads with specialised resource profiles. A container image is also portable across environments.

That flexibility brings responsibility: capacity planning, scaling rules, image patching, networking and deeper operational ownership. Managed container orchestration reduces some burden, but the system still needs careful monitoring and deployment practices.

A hybrid architecture is normal: a stable API container can work alongside Lambda event handlers and managed queues.

A practical decision path

  1. List execution duration, traffic pattern, state and dependency requirements.
  2. Choose the simplest managed runtime that supports those constraints.
  3. Prototype the risky part: latency, database connections, throughput or deployment workflow.
  4. Measure cost and operations under realistic traffic rather than theoretical maximum scale.
Architecture questions
  • Can requests complete independently and quickly?
  • Does the process need to remain continuously available?
  • What failure, retry and observability model is easiest to operate?
  • Can the team deploy, debug and secure the chosen runtime well?

Good architecture is contextual. Serverless and containers are tools in the same cloud toolkit; disciplined selection matters more than loyalty to either label.