A county records portal still runs three unrelated apps on one long-lived middleware host that operators patch in place after each CVE. What cloud-native deployment posture should replace that shared farm?
Select an answer to reveal the explanation.
Short Explanation
A shared patched-in-place app server is like one town generator powering three buildings: when you shut it down to fix it, everyone goes dark. Cloud-native prefers sealed, replaceable process images you roll forward. That keeps release identity, scale, and blast radius per app.
Full Explanation
Multi-app middleware that is patched in place ties several workloads to one runtime lifecycle. Scale decisions, failure domains, and what “version is live” all blur together. The cloud-native replacement posture packages each workload as a self-contained process image or function and advances by deploying a new revision rather than nursing a long-lived shared farm. Bigger shared hosts and OS-only installs keep the same coupling problem.