Why looking for "the cloud that fits our company" fails
A company-wide choice assumes every workload shares the same conditions. Usually it does not. A public web service used by external customers turns on sudden traffic and user-facing latency. A nightly aggregation job turns on its execution window and its dependency on internal data. An internal admin system may have few concurrent users, yet permissions, auditing, and links to existing business systems come first. A database carries a heavier movement and recovery burden than the application in front of it.
Bundle them together, ask "do we stay on AWS or move to another CSP?", and the differing demands disappear into one average. The outcome usually drifts one of two ways. Either the vendor with the most features is chosen and complexity nobody uses comes with it, or the lowest monthly base price is chosen and unexpected load appears in data movement, support, operating headcount, and incident response. Either way the problem is not the vendor but the fact that workload conditions were never separated before the comparison.[1]
What is the right unit for a workload?
A workload is the execution unit whose purpose, responsibility, and failure impact can be judged on its own. It need not match one server. One server can host several workloads. One workload can span several servers and managed services.
The AWS Well-Architected scoping guidance asks for the workload's owner and purpose, the impact of an outage, its boundary, and its external dependencies before any review begins. Those questions put business results and lines of accountability ahead of an infrastructure asset list.[2]
If any one of five conditions differs materially, the component becomes a candidate for a separate workload: the business owner or final approver; whether it can be started, stopped, and retired independently; the sensitivity, location, and retention terms of the data it handles; outage impact and support hours; and user geography, latency targets, demand pattern, and external dependencies.
Conversely, components that share purpose, owner, data, failure impact, and operating model, and that always change together, belong in one workload. There is no need to split down to microservices from the start, nor to copy the current server list into a workload list.
Map dependencies and rehearse the transition — Group dependent systems, rehearse the move and agree rollback conditions before cutover.
Workload Classification Matrix
The matrix below recomposes the NIST role and control model together with the architecture review items of AWS, Azure, and Google Cloud into a single placement decision order. It is not a table for comparing product features but a table for settling requirements before that comparison starts.[3][6]
Cells are never filled in by guesswork. Each entry is marked confirmed or unknown. Confirmed values carry their evidence and approver.
Statements such as "regulation requires it to stay in country", "a dedicated line is mandatory for security", or "24-hour support is essential" need a check on who confirmed them, and against which law, contract, internal policy, or business requirement. A data residency or regulatory conclusion that applies to one industry cannot be carried across to another organisation unchanged.
Axis | The question recorded on the card | Typical recorded values | How it is used in placement |
|---|---|---|---|
| Purpose and ownership | What business result does this workload produce, and who is finally accountable? | Customer order processing, internal report distribution / business owner / technical owner | Clarifies outage impact and approval accountability. With no owner, placement is not approved |
| Boundary and lifecycle | What changes together with it, and what can be stopped separately? | Independently deployable, changed jointly, time-boxed project, always-on | Separates components whose lifecycle and change cadence differ |
| Interaction and state | Does the user wait for an immediate response? Is state kept during execution? | Interactive, batch, event-driven / stateful, stateless, mixed | Judges whether one failure and scaling model covers them. Implementation is not chosen here |
| Demand and performance | Is load steady or spiky, and are special compute resources needed? | Steady, bursty, seasonal, scheduled / latency sensitive / GPU required, not required, unknown | Checks whether candidates support the shape of demand. Server sizing is left to separate measurement |
| Users and geography | Where are the users, and what latency is acceptable? | Domestic users, multi-region users, internal-network users / latency target fixed or open | Narrows region and network candidates. User location alone does not imply a data residency requirement |
| Data and movement | What data is read and written, and from where to where does it move? | Data class, storage location, processing location, retention terms, movement path | Only conditions confirmed by security, legal, contract, or policy owners become hard constraints |
| Dependencies and network | Which databases, identity systems, external APIs, or on-premises systems does it depend on? | Tight coupling, loose coupling, synchronous calls, asynchronous delivery / ingress and egress paths | Checks latency, connection stability, data movement, and how failures propagate |
| Failure impact and recovery | If it stops, what happens to customers, revenue, and operations, and how much is tolerated? | Blocked immediately, degraded operation possible, recoverable by next business day / approved outage and loss levels | Records only whether recovery targets constrain the candidates. Recovery design is out of scope here |
| Operating capability | Who handles patching, monitoring, incident response, and support requests? | 24-hour response, business-hours response, outsourced operation, role undecided | Removes candidates whose operational complexity the team cannot actually carry |
| Cost structure and exit | Which usage moves the bill, and what must move when the environment changes? | Always-on usage, idle hours, data movement, support, licences / portability confirmed or unconfirmed | Identifies the main cost drivers and exit constraints rather than the cheapest monthly price |
Do not mix hard constraints, preferences, and unknowns
Even with a requirements list, weighing every item equally distorts the decision. Three states have to be kept apart.
The rule is short. Only environments that meet every hard constraint become candidates. Priority is settled by comparing preferences inside that candidate set. While an unknown that could change the candidate set remains open, judgment is held.
Existing contracts, discounts, a partnership with a vendor, and team familiarity are usually preferences. Without a documented contractual constraint or a technical dependency, none of them is promoted to a hard constraint. A partnership is not evidence of technical superiority either.
Unknown is kept as its own state so that blanks in the decision are not hidden. Hunting for the vendor with cheaper transfer rates while data volumes are unmeasured is out of order. So is comparing 24-hour service designs while nobody owns night-time incident response.
State | Meaning | Rule | Examples |
|---|---|---|---|
| Hard constraint | A condition that disqualifies a candidate when unmet | One violation removes the candidate. Evidence and an approver are required | Approved processing region, mandatory connectivity, required support hours, a specific ownership boundary |
| Preference | Desirable but tradeable against other advantages | Compared only among candidates that already pass every hard constraint | Existing team experience, a familiar console, current contracts, discounts, speed of adoption |
| Unknown | A condition whose fact or owner is not yet confirmed | Never treated as zero or as fine. Assign an owner, evidence, and a due date | Data class undecided, peak load unmeasured, no night-shift responder, data path unmapped |
Workload Placement Card
Classification results survive better on one card than in meeting minutes. The form below can be filled in before any cloud vendor is named. It has seven blocks.
The card looks long, but the fields you cannot fill are precisely today's decision risk. Not every field needs detailed design. Each one needs at least confirmed, not applicable, or unknown.
- Identity
- Identity records the workload ID and name, the business result it produces, the business and technical owners, and its current lifecycle stage.
- Boundary
- Boundary records what is inside and outside the workload, what changes with it, and its main external dependencies.
- Behavior
- Behavior records interaction and state, the demand pattern, latency and performance targets, and any special compute requirement.
- User & Data
- User and data records where users and callers are, the data class, storage, processing and movement locations, retention terms, and who confirmed the requirement on what evidence.
- Failure & Operations
- Failure and operations records outage impact, approved outage and data-loss tolerance, support hours, patching, monitoring and incident ownership, and the escalation path.
- Economics & Exit
- Economics and exit records the main cost drivers, idle and variable usage, data movement paths, portability constraints, and whether an exit or recovery route exists.
- Decision State
- Decision state records hard constraints, preferences, an owner, evidence and due date per unknown, the candidate environments, the candidate operating model, and whether vendor comparison can begin.
Workload to constraint to operating model to vendor
Cloud choice narrows in four steps. Define the workload, then fix the constraints. Settle the operating model, and compare vendors last.
Operating model here is not a step for picking a deployment technology. It is the step that decides which of operating system, runtime, data, observability, and incident response the internal team carries and which goes outside. The NIST reference architecture likewise shows how the control boundary between provider and consumer shifts with the service model.[4]
The operating model comes first because two services offering the same capability can leave very different scopes of responsibility with the team. For a team without the headcount to carry the management burden, a low infrastructure price is not advantage enough. Conversely, a workload that cannot absorb platform constraints cannot be placed on operational convenience alone.
Google Cloud's hybrid and multicloud strategy guidance also asks organisations to check business use cases and per-workload requirements and plan which workload runs where, rather than applying one environment across the whole organisation. That does not make using several clouds a goal in itself. When several workloads converge on the same candidate, one vendor is chosen. When conditions differ sharply, different placements follow.[5]
Cards diverge inside a single company. A public product catalogue serves external users, is read-heavy, sees sharp swings in request volume, and holds little state, so user geography and latency, the content refresh path, and the degradation allowed during an incident are checked first. A settlement batch job runs on a fixed schedule, depends heavily on state and internal data, and delays the next task when it fails, so data location and movement, the completion deadline, rerun ownership, and night-time support are checked first.
Two workloads sitting in the same company does not make one environment the automatic answer. Nor do different characteristics force different vendors. What the card shows is not a vendor count but the reason placement judgments must be separated.
Step | What it decides | What it does not do here | Output |
|---|---|---|---|
| 1. Workload | Purpose, ownership, boundary, state, users, dependencies | Naming a vendor or picking a product | The workload list and its boundaries |
| 2. Constraint | Failure impact, data, region, latency, operations, exit terms | Building a scorecard that mixes musts with wants | Hard constraints, preferences, unknowns |
| 3. Operating model | Who carries patching, observability, incident, support, and security duties | Detailed design of VM, PaaS, container, or Kubernetes | Feasible division of responsibility |
| 4. Vendor | Actual regions, services, support, and pricing of candidates that meet the conditions | Comparing unlike products on monthly price alone | A shortlist and the remaining checks |
Operations connected from observation to improvement — Respond using service indicators and alerts, then connect change records and incident reviews to improvements.
A preflight for whether vendor comparison can begin
If these eleven items go unanswered, requirements are completed before any vendor comparison sheet. The first four ask about the workload itself: whether the business result and the business and technical owners are named; whether scope and main dependencies are documented; whether behaviour such as stateful, stateless, interactive, or batch is classified; and whether outage impact and the tolerable outage and data-loss targets are approved.
The next four ask about constraints: whether the data class and its storage, processing, and movement requirements are confirmed along with their evidence; whether user location, latency targets, and network paths are confirmed; whether hard constraints, preferences, and unknowns are separated; and whether every unknown that could change the outcome has an owner, evidence, and a due date.
The last three ask about operations and cost: whether accountability for patching, monitoring, incident response, and support hours is fixed; whether the usage that moves cost and the exit constraints are identified; and whether candidates can be compared on the same region, support, responsibility, and usage assumptions.
READY does not mean the choice is made. It means the real work can now start: actual region availability, service responsibility boundaries, support terms, portability, and cost computed at the same usage.
Verdict | Condition | Next action |
|---|---|---|
| READY | Every hard constraint is confirmed and no material unknown can change the candidate set | Begin the real vendor and service comparison |
| CONDITIONAL | A candidate set exists but some non-essential unknowns remain | Run a limited comparison with stated assumptions alongside further verification |
| NOT READY | Data, failure impact, ownership, or operational duties are still undecided | Stop the price and feature comparison and finish the placement card |
Where this article stops
Decisions remain even after the placement card is complete. How to measure request volume and resource demand, why cost arises on each network path, which backup mechanism prevents which failure, how to put numbers on tolerable outage and data loss, how to compute cost per customer or transaction, and how to review the full cost of a migration each need their own analysis.
Whether to pick VM, PaaS, container, or Kubernetes, which signals define service health, and how deployment and rollback are implemented are likewise not settled here. This article only records whether such a requirement exists as a placement constraint on the workload.
A good cloud decision leaves a placement map, not a logo
If the only line surviving a cloud selection meeting is "we went with vendor A", the same argument restarts from scratch at the next workload.
What should survive instead is which workload narrowed to which candidate environment on which condition, what was mandatory and what was merely preferred, and who confirmed which unknown. Then the structure of the judgment can be reused even when vendors change or new regions and services appear.
Choosing a cloud well is not a matter of lengthening the vendor list. It is separating the workloads, fixing failure cost and operating constraints first, and comparing only the candidates that clear those conditions.
