starter.wiki中文

Decision map

Infrastructure

How should the application be hosted, executed, packaged, delivered, triggered, and provisioned while keeping placement, transport, scheduling, and work execution distinct?

Recommendation

Start with Hosting

Application and platform teams choosing hosting and compute models, container layers, content delivery, asynchronous execution, message transport, scheduling, and infrastructure provisioning.

Open the starting decision

Scope

Use this boundary to avoid solving adjacent problems in the wrong layer.

Included

  • Application hosting, environments, placement, and deployment operation
  • Request-driven and event-driven serverless compute
  • Container build, image distribution, runtime, and orchestration routes
  • Content delivery, caching, origin, and geographic distribution
  • Background execution, queue transport, and time-based scheduling
  • Declarative infrastructure provisioning, planning, state, and apply workflow

Excluded

  • Serverless database capacity and persistence decisions
  • Application-data caching, database selection, and file persistence
  • Developer workstation environments and local cloud emulation
  • Edge Computing as an independent Task rather than a cross-cutting placement capability
12

Important tools

These tools represent distinct routes inside this decision area; open the relevant Task before treating any as a default.

Decision sequence

Make the foundational ownership decisions before adding specialized capabilities.

  1. What request or event model, duration, state, latency, geography, availability, scale, and operational ownership does the workload require?

    Use the workload and service objectives to frame the broad Hosting decision before choosing a runtime label.

    Hosting

  2. Should the workload use platform-native hosting, Serverless Compute, or Container Platforms?

    Compare runtime compatibility, duration, concurrency, scaling, isolation, portability, build and image workflow, and orchestration burden.

    Hosting Serverless Compute Container Platforms

  3. Does content need geographic caching, origin shielding, cache control, or explicit invalidation?

    Evaluate Content Delivery Networks for content delivery; treat edge execution as a capability of Hosting or Serverless Compute rather than another Task.

    Content Delivery Networks Hosting Serverless Compute

  4. Does work run outside a request, and is it triggered by a message, a schedule, or another event?

    Select Background Jobs for execution, Queues for message retention and delivery, and Scheduled Jobs for time-based invocation. A system may use all three.

    Background Jobs Message Queues Cron & Scheduled Jobs

  5. Which infrastructure resources and changes should be expressed, reviewed, planned, and applied as code?

    Adopt Infrastructure as Code after resource ownership is clear and define provider, state, secrets, approval, apply, and drift workflows.

    Infrastructure as Code

34151617

Decision groups

Each Task owns a distinct user decision rather than a product feature label.

Content delivery

Content Delivery Networks are a distinct cache and distribution layer that can front multiple hosting models.

Infrastructure lifecycle

Infrastructure as Code governs versioned desired state, planning, approval, application, and drift after resource decisions are understood.

567814151617

Common confusions

These boundaries prevent adjacent Tasks from collapsing into one generic shortlist.

Treating Hosting and Serverless Compute as interchangeable labels.
Hosting is the broad environment and deployment decision; Serverless Compute is one request or event execution model with runtime and service limits.
Treating container build, image distribution, runtime, and orchestration as a single undifferentiated product feature.
They are distinct routes inside one Container Platforms Task; orchestration is not required for every container workload.
Treating every workload described as edge as a standalone Edge Computing decision.
Content caching and delivery route to Content Delivery Networks; code execution routes to Hosting or Serverless Compute. Edge placement is a cross-cutting capability and the retired Task aliases to Hosting.
Treating a durable queue and a background worker as the same system responsibility.
Queues retain and deliver messages; Background Jobs execute work and own retry, duration, concurrency, and idempotency.
Treating time-based invocation and background work execution as one decision.
Scheduled Jobs own when and how a target is invoked; Background Jobs own how the work runs and recovers.
Treating infrastructure definitions and the automation runner that applies them as one tool category.
Infrastructure as Code owns desired resources, plans, state, and apply semantics; CI/CD owns pipeline execution and promotion workflow.
910111213

What to defer

Do not add specialized identity systems before the product has the requirement they serve.

The hosting platform's existing runtime satisfies the workload and no request or event function boundary changes scaling, isolation, or operations.

A separate serverless-compute evaluation is useful only when its runtime and invocation model changes the architecture.

The application does not require container packaging, custom runtime dependencies, image portability, or orchestration control.

Container build, distribution, runtime, and orchestration add operating responsibilities that managed hosting may avoid.

All current work completes safely inside the request path and has no message buffering, retry, long-running, or time-trigger requirement.

Workers, queues, and schedulers should follow a concrete asynchronous or time-based workload rather than become speculative infrastructure.

The hosting platform's current delivery path meets geographic latency, origin-load, freshness, and invalidation requirements.

A separate CDN decision is unnecessary until cache and delivery behavior must be owned explicitly.

The resource set is still exploratory and the team has not established stable ownership, review, state, or change-approval requirements.

Infrastructure as Code should encode understood resources and governance rather than stabilize an undefined architecture.

1819

Related starter stacks

See how these decisions appear inside complete application starting points.

Authoritative resources

Standards and primary documentation supporting the Category boundaries.

architecture-guidanceAWS Well-Architected Framework
standardOCI overview
official-documentationKubernetes workloads
official-documentationAmazon EventBridge Scheduler
official-documentationWhat is Terraform?

Sources

Claim-level references used for this decision map.

  1. 1
    AWS Well-Architected Framework

    AWS · Accessed Official

  2. 2
    Vercel Environments

    Vercel · Accessed Official

  3. 3
    What is AWS Lambda?

    AWS · Accessed Official

  4. 4
    AWS Lambda quotas

    AWS · Accessed Official

  5. 5
    OCI overview

    Open Container Initiative · Accessed Official

  6. 6
    Docker Build overview

    Docker · Accessed Official

  7. 7
    Docker overview

    Docker · Accessed Official

  8. 8
    Kubernetes workloads

    Kubernetes · Accessed Official

  9. 9
    Cloudflare Cache

    Cloudflare · Accessed Official

  10. 10
    Cloudflare CDN reference architecture

    Cloudflare · Accessed Official

  11. 11
    Cloudflare Workers

    Cloudflare · Accessed Official

  12. 12
  13. 13
    Vercel Edge runtime

    Vercel · Accessed Official

  14. 14
    Amazon SQS Developer Guide

    AWS · Accessed Official

  15. 15
    Best practices for background jobs

    Microsoft · Accessed Official

  16. 16
    Cloudflare Cron Triggers

    Cloudflare · Accessed Official

  17. 17
    Amazon EventBridge Scheduler

    AWS · Accessed Official

  18. 18
    What is Terraform?

    HashiCorp · Accessed Official

  19. 19
    Core Terraform workflow

    HashiCorp · Accessed Official