Kubernetes or managed application services: price the operating work

A cloud platform lead choosing where a small team should run an application is also choosing the work that team will carry into every release and incident. The compute bill is visible immediately. Upgrade testing, access configuration and dependency diagnosis arrive later, often in the same people’s delivery schedule.

“Kubernetes or serverless?” is too broad to settle that decision. Compare specific services and management modes against one workload. Azure Kubernetes Service (AKS) and Azure Container Apps offer a useful example of how the responsibility boundary changes even within a single provider.

Decide which control the workload actually needs

Start with runtime, networking, storage, identity and availability requirements. Identify any requirement for direct Kubernetes API access, custom controllers or cluster-level components. Ask for the application dependency that makes each requirement necessary; familiarity with a tool is a staffing consideration, not proof that the workload requires it.

Microsoft’s container-service comparison says Azure Container Apps is powered by Kubernetes but does not expose direct access to the underlying Kubernetes APIs. AKS provides that access. It also distinguishes AKS Standard, where customers manage cluster configuration and operations, from AKS Automatic, which manages more common tasks such as node management, scaling, security defaults and upgrades.

Those distinctions prevent two expensive mistakes: selecting a service that cannot support a necessary extension, and adopting cluster operations merely because the application is packaged as a container. “Managed Kubernetes” itself is not a single, fixed allocation of work.

The Kubernetes project’s production guidance similarly separates managed control planes, managed worker nodes and services that run workloads without the customer managing a cluster. Handing off one layer does not resolve every question about availability, scale and access.

Compare a realistic application

Take a hypothetical internal case-management service: a web API, a queue-driven document processor and a separate managed database. The application team can maintain its containers but has little capacity to build a cluster platform. It needs private connectivity, controlled releases and evidence that a failed dependency will not lose queued work.

Azure Container Apps is a plausible candidate because its documented features include managed ingress, container revisions, traffic splitting, event-driven jobs and integration with an existing virtual network. Each feature still needs to be exercised against the application’s actual requirements. The presence of a scaling feature does not show that database connections, downstream quotas or the team’s recovery procedure will scale with it.

AKS becomes a stronger candidate if the application has a demonstrated Kubernetes-specific dependency, or if an established platform team already provides a supported service that meets these needs. In the latter case, compare the marginal work of adding this application to that service, including any shared-platform charge. Comparing a mature internal AKS service with a brand-new Container Apps implementation can give a different answer from comparing two greenfield deployments.

Make retained responsibilities explicit

Microsoft’s AKS support policy assigns customers responsibility for workloads, application code and container images, networking configuration, access rules and data. Other areas, including upgrades and node operating-system maintenance, have shared responsibilities. Use the exact chosen management mode to turn that division into named tasks.

The following questions turn the comparison into an operating decision rather than a feature count.

Operating task	AKS evaluation	Managed application service evaluation
Platform change	Who configures upgrade behaviour and tests workload compatibility in the selected AKS mode?	How are platform changes communicated, and how will application compatibility be checked?
Network and identity	Who maintains cluster access, workload permissions and network policy?	Can the service express the required access boundaries, and who maintains them?
Deployment and rollback	Which team supports the delivery tooling and application recovery procedure?	Do revision controls cover the application, and what separate procedure handles data changes?
Diagnosis	Can responders distinguish a cluster problem from a workload or dependency failure?	Does the available telemetry explain the failure despite reduced infrastructure access?

For both options, assign ownership of container vulnerabilities, application configuration, data recovery and the first response to a failed customer journey. A provider support ticket may be part of escalation; it is not the service’s complete incident procedure.

Buy operating capacity with evidence

Run a representative release, rollback and dependency-failure exercise with the team that will operate the service. Record the permissions, knowledge and manual steps each option requires. Include a configuration error and a database change that cannot be undone merely by deploying an older container.

Price the resulting work alongside compute, network traffic, logs, support and shared tooling. A managed application service may be worth a higher unit infrastructure charge if it removes work the team cannot staff reliably. Kubernetes may justify its operating cost when required control or an existing platform service produces a concrete benefit. Neither conclusion follows from the label alone.

Choose the least burdensome option that meets the workload’s requirements and gives the team a credible recovery path. Then define the developer journey the platform must support, so that the selected runtime becomes a usable service rather than another environment developers must assemble themselves.