The Platform Decision Ladder
Last reviewed · content updated
IntermediateWhat you'll learn
~15 min- Apply the platform decision ladder: highest rung that holds the workload wins
- Identify the specific criteria that legitimately force a workload down to Kubernetes
- Map Meridian's entire estate to target platforms -- and defend each placement
The most consequential decision in this training
Every workload leaving Meridian’s VMs needs a destination. Get this wrong in one direction and you build a Kubernetes estate you staff forever; get it wrong in the other and you jam a workload into a service that cannot hold it. The discipline is a ladder, climbed from the top:
Rung 1 SaaS - someone else runs the whole productRung 2 Native PaaS - you bring code; the platform runs it (App Service, Azure SQL, Azure Functions)Rung 3 Managed containers - you bring a container; still no cluster to own (Azure Container Apps)Rung 4 Kubernetes - you own cluster concerns (AKS)Rung 5 VMs - you own everythingThe rule: take the highest rung that genuinely holds the workload. Descend only when a rung fails a specific, nameable test — never by default, never by fashion.
Each rung down transfers operational burden back to you. Rung 2 means the provider patches the OS and runtime, scales instances, rotates certificates. Rung 4 means you schedule cluster upgrades, patch node images, plan capacity, and staff the on-call that goes with all of it. That burden never appears on the architecture diagram, but it appears on every quarter’s payroll afterward.
A lot of modernization content treats “containerize everything onto Kubernetes” as the finish line. In disciplined shops it is the opposite: K8s is where workloads land when they cannot use a managed service — because the runtime is unsupported, the licensing demands it, or a regulated environment mandates that control. If you cannot name the specific test that forced the descent, you belong on a higher rung. This single habit is the difference between a modernization that shrinks ops and one that swaps VM-babysitting for cluster-babysitting.
The tests that legitimately force a descent
| Test | Example | Descend to |
|---|---|---|
| Runtime or fit the managed tier cannot deliver | Oracle Database — the managed option exists but fails the fit tests (below) | Rung 4 (or 5) |
| Licensing bound to infrastructure control | Per-core licenses requiring pinned hosts | Rung 4/5 |
| Regulated or disconnected environment mandates | Air-gapped enclaves where the platform must be self-contained | Rung 4 |
| Workload shape the service cannot express | Long-lived stateful protocols a container platform cannot route | One rung down |
| Genuine portability requirement (contractual, not aesthetic) | Software you ship to customers’ clusters | Rung 4 |
Note what is not on this list: “we might need the flexibility someday,” “the team wants to learn it,” and “everyone uses Kubernetes.” Those are how ops budgets die.
Prompt first: run the ladder on the estate
For each workload below, apply this decision ladder: SaaS > native PaaS >managed containers > Kubernetes > VMs. Recommend the HIGHEST rung that holdsthe workload. If you recommend descending below native PaaS, you must namethe specific failed test that forces the descent. Flag any workload wherethe answer is genuinely contestable and say why.
Workloads:1. FieldDesk rebuild - Next.js web app, Entra ID auth, relational data2. AssetTrack API - .NET 10 (after porting), REST, stateless3. AssetTrack nightly batch - file-driven ETL jobs4. Oracle 19c database - vendor-locked schema, 15 years of PL/SQL5. Reporting data platform - columnar files + SQL query layerMeridian’s placement map
| Workload | Rung | Placement | Forced descent? |
|---|---|---|---|
| FieldDesk rebuild | 2 | App Service + managed Postgres | No — PaaS holds it fully |
| AssetTrack API | 3 | Azure Container Apps | Mild: containerized for dependency control, still cluster-free |
| Nightly batch | 2/3 | Container Apps jobs on a schedule | No |
| Oracle 19c | 4 | AKS (StatefulSet) or stay on VMs | Yes: the managed option fails Meridian’s fit tests — see below |
| Reporting platform | 2 | Data lake storage + serverless SQL | No |
One workload out of five descends to Kubernetes — and the descent is named, not assumed. A managed option does exist: Oracle Database@Azure, Oracle-operated Exadata and Autonomous services sold through Azure. The ladder demands you name it and then name the failed test — for Meridian: entry scale and cost built for estates far larger than one modest instance, a limited regional footprint, and no presence in sovereign or government clouds. So the one-sentence justification is “the managed offering fails our fit tests” — a sentence that must be re-earned periodically, unlike “no such thing exists,” which silently rots as vendors ship. That test is the entire Lesson 8. The other four workloads shed their operational burden upward, which is the point of the program.
For non-Azure shops the ladder is identical; only the names change — App Runner/Elastic Beanstalk and Cloud Run occupy rung 2/3 in AWS and GCP respectively, EKS and GKE rung 4. The tests do not change at all.
A teammate proposes deploying the rebuilt FieldDesk (a standard Next.js web app) to the new AKS cluster 'since we're already running one for Oracle.' What does the ladder say?
Key takeaway
Climb from the top: the highest rung that holds the workload wins, and every descent must name its failed test. At Meridian, four of five workloads land on managed services — and the one that descends (Oracle) does so for a one-sentence reason. Lessons 2.2-2.3 build the container path for the rung-3 workloads; Lesson 2.4 pays the Kubernetes toll for the one that earned it.