Decide how much you run yourself.

Compare five approaches to running a workload: what you operate, what a provider handles, and what it takes to move later.

Platform PlannerSeparate technical constraints from preferences. See which answers narrow your shortlist, and why.7 questionsLive shortlistTrade-offs Start choosingClose section

What should actually run this workload?

Seven questions about one workload. You get a recommendation with its trade-offs stated plainly, an honest second choice, and anything that has been ruled out — with the reason, so you can disagree with it. It is a starting point. Scores are editorial preferences, not benchmarks or compliance approval. Service limits, costs and workload tests must confirm the shortlist.

  1. Question 1 of 7 · Purpose

    Should your organisation be running this at all?

    The cheapest architecture is the one you never write. Worth settling before anything else.

    Choose one No answer selected

  2. Question 2 of 7 · Constraints

    Does the software you intend to keep need something only the host machine can give it?

    Distinguish a hard host requirement from a preference. These approaches can also be combined.

    Choose one No answer selected

  3. Question 3 of 7 · Storage

    Where does the application store data between one request and the next?

    Data written to a local disk is the most common reason a move turns out harder than planned.

    Choose one No answer selected

  4. Question 4 of 7 · Scale

    How many separate services deploy on their own schedule?

    Orchestration earns its cost by the number of things it has to place and keep running.

    Choose one No answer selected

  5. Question 5 of 7 · Operations

    Who looks after the infrastructure once this is live?

    The question most decision documents skip, and most post-mortems reach.

    Choose one No answer selected

  6. Question 6 of 7 · Load

    What does the traffic actually look like?

    Shape matters more than volume here — a busy hour is a different problem from a busy year.

    Choose one No answer selected

  7. Question 7 of 7 · Exit

    How real is the possibility of moving to another provider?

    Be honest here. Most people overstate it, and a few badly understate it.

    Choose one No answer selected
Five approaches. Different responsibilities.Choose a vessel, package the cargo or hand over the voyage. See what remains yours to operate.VMsContainersKubernetesPaaSSaaS ExploreClose section

Five concepts. Different decisions.

Choose what you operate, package or hand over. These options can work together: containers can run on VMs, Kubernetes or a platform service.

Figure 01 Virtual machine
A VM has its own guest kernel and can carry several workloads. Choosing a second isolated guest adds another operating system to maintain. MACHINE 01 SPARE CAPACITY Its own kernel Its own patch cycle Your OS maintenance INSIDE ONE MACHINE APPLICATION RUNTIME + LIBRARIES OS + PACKAGES KERNEL ALL OF IT YOURS TO PATCH MACHINE 02 SPARE CAPACITY Its own kernel Its own patch cycle Your OS maintenance

One ship, one charter.

A VM is a virtual computer with its own operating system. Like chartering another vessel, separating a workload gives you more control—and another OS to maintain.

Ask about your workload

Which workload needs control of its own operating system, and who will patch and operate it?

Details & limits of the example

A charter gives you control over a vessel and its cargo. You can carry several workloads together, or charter another vessel when one needs a separate operating system. You maintain each vessel you choose to run.

Choose a VM when control over the guest OS matters. Capacity, isolation and the number of workloads are separate decisions.

Figure 02 Container
Loose cargo is unpacked and repacked at every transfer between ship, yard and truck. A standard box crosses all three carriers unchanged. DEVELOPMENT CI PRODUCTION REPACKED AT EVERY TRANSFER Each handover is hand-work, and each one can go wrong. ONE IMAGE, COMPATIBLE HOSTS The contents stay the same. Configure each destination.

One box, compatible carriers.

A container image packages an app and its dependencies like a standard cargo box. It travels between compatible hosts; data, secrets and connections still need setting up.

Ask about your workload

What must be captured in a repeatable build and tested on the target host, so this app can move without manual setup?

Details & limits of the example

A standard cargo box moves between compatible carriers without repacking its contents. The image is your box; the host is the carrier. Packaging makes the handover repeatable, but does not move the database or arrange access at the destination.

An image needs a compatible kernel and CPU architecture. Build and test it with the target data, secrets and connections. Containers do not by themselves require Kubernetes.

Figure 03 Kubernetes
A manifest declares three replicas. When one is lost, the observed count falls to two. The ReplicaSet controller creates a replacement Pod and the scheduler assigns a node, assuming sufficient capacity and a working image. DESIRED STATE kind: Deployment replicas: 3 image: app:1.4 DECLARED 3 OBSERVED 3 2 OBSERVE COMPARE ACT CONTROLLERS KEEP CHECKING THE DESIRED STATE

Replace what is missing.

Kubernetes compares what you want running with what is running. Like a watch checking a cargo manifest, its controllers act to close the gap.

Ask about your workload

Which failures should be handled automatically, and who provides the health checks, spare capacity and incident response?

Details & limits of the example

The manifest calls for three boxes on deck. When one is lost, the watch notices the gap and requests a replacement. Someone still has to supply space on deck and working cargo: automation cannot repair every underlying problem.

Reconciliation keeps trying to reach the desired state. You still need health checks, capacity, incident ownership and supported versions of the cluster and its add-ons.

Figure 04 Platform service
Your image sails on the platform’s vessel, wired to the port’s own fittings. Move to another port and the runtime travels, but the managed connectors stay behind on the quay. THE PORT’S FITTINGS IDENTITY QUEUE STORE QUAY YOUR IMAGE MANAGED CONNECTIONS Managed integrations reduce setup work. Check which interfaces are provider-specific. THE CONNECTORS STAYED AT THE QUAY The image can travel. Identity, triggers and data may need migration or adapters.

The port runs the ship.

A platform service runs your code or image on provider-operated infrastructure, like a port supplying the vessel and crew. Supported runtimes and connections vary by service.

Ask about your workload

Which runtime, identity, data and network dependencies must you check before choosing—or leaving—this platform?

Details & limits of the example

The port supplies a vessel and crew, so you can focus on the cargo. Some fittings use standard connections; others belong to that port. A move means checking which connections can travel and which need adapters.

Check the whole dependency map: identity, storage, triggers, networking and runtime support. Test a move before treating an image as proof of portability.

Figure 05 Software service
Handing the operation to a scheduled service transfers the vessel, the crew and the schedule. The cargo and the list of who may sign for it stay with you either way. YOU RUN THE VESSEL, THE CREW AND THE SCHEDULE THE SERVICE RUNS ALL OF IT Every part of it is yours to operate, staff and answer for. You still govern data and access. YOUR OPERATION SCHEDULE CREW SCHEDULED SERVICE Runs the vessel, the crew and the schedule for you. BERTH AVAILABLE YOUR DECISIONS REMAIN YOUR DATA WHO MAY SIGN FOR IT

Buy the service. Keep a cargo owner.

SaaS is a finished application, like booking a scheduled freight service. The provider operates the product; you still govern your data, users and tenant settings.

Ask about your workload

Who owns access, configuration and usable data exports, and which responsibilities does the contract assign to each party?

Details & limits of the example

You stop owning ships and book space on a scheduled service. The cargo is still yours, and so is every decision about who may collect it at the other end.

A provider certificate does not validate your tenant configuration. Agree responsibilities in the contract, control access and test whether you can export usable data.

What you operate. What you still govern.

This comparison assumes cloud VMs, containers on your own VMs, managed Kubernetes, managed application platforms and SaaS. “Yours” means you have work to own; it does not remove the provider’s duties. Exact boundaries depend on the service and contract.

Who is responsible for what. Real boundaries are service-by-service; this is the shape, not the contract.
Layer Virtual machine IaaS Container Packaging Kubernetes Orchestration Platform service PaaS Software service SaaS
Physical estate Datacentre, power, hardware, network fabric. ProviderProviderProviderProviderProvider
Virtualisation Hypervisor, host isolation, the control plane you never see. ProviderProviderProviderProviderProvider
Host OS and nodes Kernel, package updates, CVE response, host agents. YoursYoursSharedProviderProvider
Runtime and dependencies Language runtime, libraries, base images, and their CVEs. YoursYoursYoursSharedProvider
Application code What you wrote, and the bugs in it. YoursYoursYoursYoursProvider
Configuration Network rules, IAM assignments, encryption choices, backup policy. YoursYoursYoursYoursYours
Data and access The records themselves, and every decision about who may read them. YoursYoursYoursYoursYours

“Shared” is where the outages live. A managed control plane still leaves you the node upgrade; a managed runtime still leaves you the tracing, the alert logic and the incident. Read the specific service, not the category.

Twelve-Factor, read as a portability checklist.

Twelve-Factor describes application design principles that help make deployment repeatable. Containers and managed platforms provide useful tools, but do not implement every principle for you. Below, the original twelve are paraphrased alongside practical guidance, followed by three later additions.

The ones that decide whether you can move

If you only ever act on five of them, act on these. Each one is a specific way an application stops being tied to where it is running.

  • III Config in the environment

    PrincipleStrict separation of config from code; anything that varies between deploys lives in the environment.

    TodayKeep deployment settings out of code. Inject secrets securely through the deployment environment or mounted files, and isolate provider-specific secret clients behind adapters.

  • IV Backing services as attached resources

    PrincipleTreat databases, queues and caches as attached resources reached by URL, swappable without a code change.

    TodayStandard protocols reduce code changes, but a new endpoint is only part of a move. Test data conversion, authentication, feature differences and delivery semantics.

  • V Build, release, run

    PrincipleThree strictly separated stages, with releases immutable and uniquely identified.

    TodayA container image can be the build artifact; combining its digest with versioned configuration identifies a release. Pipelines must still enforce the separation and reproducibility.

  • VI Stateless processes

    PrincipleProcesses are stateless and share nothing; persistent data belongs in a backing service.

    TodayKeep durable state outside replaceable application instances. Disposable local caches are fine; required session or business data on one instance prevents safe replacement.

  • IX Disposability

    PrincipleFast startup, and graceful shutdown when the process is asked to stop.

    TodayHandle termination gracefully, typically SIGTERM in Kubernetes. Test readiness, traffic draining and in-flight work against the configured grace period.

The ones the platform helps you implement

The platform provides mechanisms. Your application and operations still need to use them correctly.

  • VII Port binding

    PrincipleThe application is self-contained and exports a service by binding to a port.

    TodayA web process may expose its own port. Workers and batch containers need not listen on one. Configure binding, health checks and ingress for the chosen platform.

  • VIII Concurrency

    PrincipleScale out through the process model rather than by making one process bigger.

    TodayPlatforms provide replicas and autoscalers. The application still needs safe parallel execution, appropriate connection limits and correct handling of duplicate work.

  • XI Logs as event streams

    PrincipleWrite to stdout and let the execution environment handle routing and storage.

    TodayStructured stdout logs simplify collection. Someone must still configure routing, retention, access, redaction and cost controls; logging does not operate itself.

The ones that need a modern reading

Apply the original principles to current tooling without assuming the tooling guarantees them.

  • I Codebase

    PrincipleOne codebase tracked in revision control, many deploys.

    TodayUse a traceable codebase for each deployable application. A monorepo can contain several applications with separate build and release boundaries.

  • II Dependencies

    PrincipleDeclare dependencies explicitly; never rely on packages existing on the host.

    TodayDeclare and pin dependencies, maintain base images and rebuild for fixes. An SBOM inventories components; it does not establish that an image is safe.

  • X Dev/prod parity

    PrincipleKeep development, staging and production as similar as possible.

    TodayAn image reduces runtime differences. Also test the backing services, identity, network and resource limits that differ between development and production.

  • XII Admin processes

    PrincipleRun one-off tasks as one-off processes in an identical environment.

    TodayRun migrations and other one-off tasks from the same release and configuration as the application, with controlled access and a repeatable procedure.

The ones it never covered

Added by Kevin Hoffman in “Beyond the Twelve-Factor App” (2016). He also reorders the original twelve, so the numbering here is ours, not his. Two of the three are now among the deepest hooks a provider has into an application.

  • XIII Telemetry

    PrincipleTreat the application’s own observability as a first-class concern, not an afterthought.

    TodayLogs alone do not cover metrics and traces. OpenTelemetry offers vendor-neutral instrumentation and export; backend queries, dashboards and semantic differences still need migration.

  • XIV Authentication and authorization

    PrincipleIdentity and access are part of the application contract, not infrastructure detail.

    TodayFederation through OIDC reduces dependence on one identity interface. Claims, roles, trust policies and resource permissions still need explicit mapping and testing.

  • XV API first

    PrincipleDesign and publish the contract before building the implementation behind it.

    TodayThe practical portability benefit is that a stable contract lets you replace what sits behind it — including replacing a SaaS product — without renegotiating with every consumer.

What no factor mentions, and every migration hits

Every item on the list above is inside the application. These four are not, and they are what a migration runs into first.

  • Data gravity beats every diagram

    Measure export and import time, egress charges, format conversion and the cutover window. Test a representative data migration; application packaging alone cannot estimate the exit cost.

  • Your infrastructure code is not portable, and that is fine

    Terraform is a portable tool, not portable code: azurerm resources do not become oci resources. What is portable is the module boundary and the pipeline around it. Resist the abstraction layer that promises to hide both clouds — it usually delivers the limitations of each and the strengths of neither.

  • An exit plan you have never run is fiction

    For financial entities in scope, DORA Article 28(8) requires exit plans for ICT services supporting critical or important functions to be comprehensive, documented, sufficiently tested and reviewed periodically. Article 30(3)(f) addresses contractual exit arrangements. Independently of regulation, rehearse a move with representative data and measure the recovery and cutover time.

  • The portability tax is real — pay it deliberately

    Staying portable costs something. You forgo genuinely better managed services, you operate more yourself, and you write adapters nobody thanks you for. Pay it where an exit is plausible or required. Do not pay it on a workload that will be retired before the contract ends. The goal was never zero lock-in — it is lock-in you chose, priced, and could walk away from if you had to.

The detail behind the trade-offsPractical articles and the source documents behind this guide.ResponsibilitiesPortabilityOperations Browse notesClose section

Where this goes into detail.

This page is the map. These are the notes underneath it, in the order they are worth reading.

None of this is a recommendation to containerise. It is a recommendation to know which trade you are making before somebody makes it for you — get in touch if you want a specific workload assessed rather than a category.