Do you need a DevOps engineer or a managed service?

When do you genuinely not need a hire?

When the platform absorbs the operational work and the rate of change is low. If applications deploy from a repository to a managed runtime, the database is a managed instance with automated backups, and the largest recurring question is which environment variable to set, the work remaining is a few days a month. A retainer or a part-time arrangement covers it, and a permanent hire in that situation will start building things to justify the role.

The uncomfortable version of this is that a first infrastructure hire can increase your operational burden. Someone arriving into a simple managed setup will frequently propose moving to a more capable platform, and the resulting estate needs the person who built it, permanently. That may well be the right decision, but it should be a decision rather than a side effect of hiring.

The counter-signal is scale of people rather than scale of traffic. Once several teams deploy independently, the coordination and consistency problems appear regardless of how managed the underlying platform is, and no vendor sells a solution to those.

What does a managed service actually remove?

The operation of the component and nothing about your use of it. That distinction covers most disappointment in this area, and it is worth mapping component by component before assuming a category of work has been eliminated.

What does managed Kubernetes not manage?

The part you spend time on. Cloud providers manage the control plane: the API server, the scheduler and their upgrades. Everything else remains yours, including node pool upgrades, the ingress controller, the storage drivers, certificate management, the autoscaler, and every custom resource definition that has to stay compatible across versions.

The recurring cost is the upgrade cycle. Minor versions arrive regularly and remove APIs that manifests still reference, so someone has to check what will break, update the manifests, upgrade the add-ons in a supported order, and roll the nodes. That is real work several times a year, and it is why teams that adopted Kubernetes because it was managed often conclude a year later that they needed the hire after all.

So the useful question before choosing it is whether you need what it provides. Multiple teams sharing compute, workloads with genuinely varied requirements, or a need to run the same platform in more than one environment all justify it. A handful of web services and a database do not, and a simpler runtime removes the upgrade cycle entirely.

Where does an external provider stop?

At the boundary of what they can be held responsible for, which is usually infrastructure availability rather than your delivery. A managed service provider will keep servers patched, respond to alerts and restore from backup. They will not redesign your release process, argue with your developers about resource limits, or take a position on whether a change should ship today.

The clarifying question to ask any provider is who owns a failed deployment at two in the morning when the change was made by your team and the fault is in your application configuration. The answer defines the contract more accurately than the service description does. If the answer is that they will escalate to you, then you still need someone to escalate to, and that person's availability is the thing you were trying to buy.

Response time commitments deserve the same scrutiny. A commitment to respond within an hour means an acknowledgement, not a resolution, and for a customer-facing outage the difference is the entire incident. That is not dishonest, it is simply what a shared support model can offer, and it should be compared against what an in-house person would actually have done at that hour.

What is the decision rule?

Change frequency. Count how many times your infrastructure configuration changed in the last quarter, meaning networking, permissions, environments, pipelines and platform components rather than application deployments. If the answer is a handful, buy managed services and keep a retainer for the occasions. If it is weekly, you need someone whose job it is, because the coordination cost of routing weekly changes through an external party exceeds the salary.

Weight that by how much the changes are driven by your product. Infrastructure that changes because the provider deprecated something is maintenance, and maintenance outsources well. Infrastructure that changes because product teams are shipping new services needs someone in the room where the decisions are made, and that is the case that a provider structurally cannot serve.

The hybrid arrangement that works is buying the operational floor and hiring for the change. Managed platform components, an external party for out of hours availability if you cannot staff a rota, and one internal person who owns the paved route and works with the teams. What fails is the reverse: hiring one person to both operate everything and improve it, which is the arrangement that produces a permanently busy engineer and no visible progress.

How do you test the arrangement before committing?

Run a restore. Ask whoever currently holds responsibility, internal or external, to recover a non-production database from backup while you watch, and time it. It is the single most revealing exercise available, because it exposes whether backups exist, whether anybody has ever tested them, and how long the real recovery path takes as opposed to the documented one.

Then trace a change end to end. Pick a small infrastructure change, request it through whatever route exists today, and record the elapsed time and the number of handoffs. Companies consistently find that the technical work took twenty minutes and the process took a fortnight, and that ratio tells you whether your problem is capability or coordination. Only the first can be bought.

Do both before writing a job description or signing a contract. They take a day between them and they change what you conclude often enough to be worth the interruption.