Different kinds of help
A deployment view shows where software runs. A quality review tests why the arrangement is suitable. Operational objectives help decide whether it is working well enough. These can be used within the same methodology.
| Approach or asset | Useful contribution | Decision still needed |
|---|---|---|
| Cloud Well-Architected frameworks | Amazon Web Services (AWS), Azure and Google organise platform reviews around service quality and operational trade-offs. | Map their questions to the actual workload and responsibilities; check each provider’s specific guarantees. |
| Site Reliability Engineering (SRE) | Connects user-facing service objectives, measurement and reliability work. | Agree which outcomes matter, who owns the target and what happens when it is missed. |
| C4 deployment diagrams | Map software instances onto execution and infrastructure nodes for a named environment. | Record configuration, failure relationships and support responsibilities alongside the view. |
| Infrastructure as code | Makes infrastructure configuration repeatable and reviewable. | Protect credentials and management state; review intended effects and reconcile changes made elsewhere. |
| Progressive deployment | Exposes a change gradually, using health checks before widening its use. | Choose meaningful checks, compatibility rules and a workable recovery path. |
These are complementary frameworks, practices and records. A deployment tool can reproduce a configuration that still fails a service requirement.
Where to run
| Choice | Useful when | Trade-off to examine |
|---|---|---|
| Managed application and data services | Available service contracts fit the workload and operating team. | Configuration, quotas, identity, supplier dependency and exit remain owned. |
| Virtual machines or physical hosts | Runtime control, compatibility or placement needs justify direct management. | Patching, recovery, capacity and support require continuing attention. |
| Container platforms | Packaging and placement across a set of services need consistent management. | Orchestration, images, networking and persistent storage add responsibilities. |
| Functions or managed jobs | Work can fit the platform’s execution and scheduling contract. | Time limits, repeated delivery, concurrency and cold startup must fit the operation. |
| Device or edge execution | Local response, connectivity or data placement makes execution near the user useful. | Device variation, updates, stored data and synchronisation need explicit handling. |
These are illustrative choices. A solution can combine them, and the software’s component count does not determine its deployment count.
Reliability choices
A single deployment may be sufficient for an agreed service level. Additional instances can protect against some failures, but shared storage, identity, network routes or configuration can still interrupt all of them. Describe the failures an arrangement addresses before adding another location.
Recovery objectives should follow the cost of lost work and interruption. A second region adds coordination, recovery and cost questions; it does not settle data consistency. For the cancellation example, preserving accepted ownership is part of deciding whether the service has recovered.
Choosing a useful combination
Start with the requirements and constraints, compare a few plausible options, and identify the assumption most likely to change the decision. A small experiment can test a transaction guarantee, representative load or restore procedure before committing to a larger arrangement.
The case example proposes one application release and a durable transaction store for evaluation. No vendor, runtime, instance count or recovery target has been selected. The tests should inform those choices.
Methodology configuration
Use a platform review, service assessment or release-readiness record already familiar to the team. Map provider terminology and lifecycle steps through Methodology configuration. Keep the decision and its reason linked to the environment that implements it.
Sources and editions
Selected primary guidance checked in September 2026:
- AWS Well-Architected pillars: operation, security, reliability, performance, cost and sustainability.
- Azure Well-Architected Framework: quality questions and architectural decisions.
- Google Cloud Well-Architected Framework: design for change, maintained architecture descriptions and platform review; page reviewed 28 January 2026.
- Google SRE Workbook: Implementing SLOs: service objectives and user-facing measures, 2018.
- C4 deployment diagram: deployment nodes and software instances in a named environment.
- HashiCorp Terraform state: the relationship between configuration, real resources and protected management state.
- Microsoft safe deployment practices: progressive exposure and health checks; updated 17 June 2026.
- AWS disaster recovery guidance: objectives, recovery strategies, testing and configuration drift.
The reading date identifies the material consulted; it is not its first publication date. This comparison is selective, with no provider selection or complete framework assessment.