Building a Runtime Portfolio for a Modernizing Application
Goal
Apply the runtime decision model to a monolith that will modernize in stages.
The Short Version
Modernization should assign each component the simplest runtime that fits while keeping the total platform estate operable.
Decomposition should follow business change, scaling, deployment, and ownership needs rather than runtime fashion. The important architecture move is to make the boundary explicit before selecting a cloud feature. A feature can automate a decision, but it cannot decide the organization's risk tolerance, ownership model, or acceptable failure behavior.
Use this section as a decision tool. Name the actor or producer, the protected or affected resource, the contract between them, the conditions under which the action is allowed, and the evidence that will show whether the design worked.
Mental Model
Show a current monolith and a staged target with component-to-runtime decisions plus a shared operations plane.
flowchart LR
N1["Workload shape"] --> N2["Responsibility boundary"] --> N3["Runtime model"] --> N4["Deployment and scaling"] --> N5["Operations"]Read the diagram from left to right, then review it from right to left. The forward pass explains how work succeeds. The reverse pass asks whether an operator can trace an outcome back to its initiating identity, input, policy, route, or contract.
Architecture Decisions
| Decision dimension | Question to make explicit |
|---|---|
| Compatibility | Which operating system, runtime, network, or hardware constraints are real? |
| Unit | Is deployment a machine, application, container, function, or batch job? |
| Scaling | What triggers scale, and how quickly must capacity appear? |
| State | Can instances be replaced, and where does durable state live? |
| Operations | Which platform work can the team reliably own? |
The answers should be recorded with the workload design. If the answer is merely "the platform default," the team has discovered an assumption, not completed an architecture decision.
Core Ideas
Decomposition should follow business change, scaling, deployment, and ownership needs rather than runtime fashion
Decomposition should follow business change, scaling, deployment, and ownership needs rather than runtime fashion. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
A staged portfolio can retain a legacy component while moving suitable web, worker, event, and batch components
A staged portfolio can retain a legacy component while moving suitable web, worker, event, and batch components. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Platform sprawl must be constrained through paved paths, shared controls, exit criteria, and explicit ownership
Platform sprawl must be constrained through paved paths, shared controls, exit criteria, and explicit ownership. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Provider Lenses
AWS offers responsibility boundaries through EC2, managed application platforms, ECS or EKS, Fargate, Lambda, and batch services. Azure offers Virtual Machines, App Service, Container Apps or AKS, Functions, and batch services. Product names matter only after workload shape, control needs, scaling behavior, and operating maturity are explicit.
Provider lenses are useful for implementation planning, but they should come after the provider-neutral decision. This keeps the reasoning portable and makes differences in defaults, scope, and operational responsibility easier to detect.
Example: Applying the Decision
Modernize an order application with a legacy core, web front end, APIs, image processing, scheduled reconciliation, and bursty workers.
Keep an incompatible legacy component on virtual machines initially, place a conventional web API on a managed application or container platform, use functions for short event-driven tasks, and introduce Kubernetes only when its shared orchestration capabilities justify operating the platform.
A review should finish with named owners, a testable success path, expected failure modes, and observable evidence. That is more useful than a diagram that only proves the components can connect.
Common Mistakes
Rewriting every component before proving a business or operational benefit. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Choosing a distinct platform for every team preference. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Counting application migration as complete while delivery, monitoring, recovery, and ownership remain fragmented. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
If Someone Asks You
How would you create a practical runtime portfolio for a modernizing monolith?
A clear answer is:
Modernization should assign each component the simplest runtime that fits while keeping the total platform estate operable.
I would then show the decision path, the responsibility boundary, and the evidence used to review it. That explanation connects the technical mechanism to its architecture purpose.
What You Should Remember
Modernization should assign each component the simplest runtime that fits while keeping the total platform estate operable.
Questions to Check Your Understanding
Which component traits justify separation?
How can a team limit runtime-platform sprawl?
Which cross-cutting capabilities must work across every selected runtime?
Further Study
Kubernetes Concepts - Use this authoritative source to deepen the section's provider-neutral control and decision model.