DevOps as a Service — when it pays off and what it costs

DevOps as a Service is a model in which a company uses the work of a DevOps engineer from an external provider — billed for the time used — instead of building its own infrastructure team. The engineer configures and maintains cloud environments, automates deployments, takes care of monitoring, backups, and security, and responds when production goes down.

It’s worth distinguishing this model from a classic help desk. In well-organized DevOps as a Service, you work with a specific person who knows your system and your technology stack. In a ticket-based model, every problem goes into a queue, and the person who picks it up often starts by reading the history from scratch. During a production outage, that difference is measured in hours.

The figures from the report (Just Join IT, in Polish) are only a starting point. With an employment contract, employer-side costs, equipment, training, and recruitment time come on top of the gross salary. More important than the rate itself, though, is the question: how much infrastructure work do you actually have each month?

In many companies, it’s uneven. Setting up environments, migrating to the cloud, or introducing automated deployments are periods of intensive work. Then come months when updates, cloud cost reviews, and incident response are enough. A full-time position pays off with a steady, heavy workload. With a fluctuating workload, you pay for availability you don’t use most of the time.

The second limitation of a single full-time person is continuity. That person goes on vacation, gets sick, and needs rest — and outages don’t wait. Round-the-clock on-call coverage requires several people on rotation, and expertise locked in one employee’s head is a risk every time they leave.

Service levels (SLA). Response time and resolution time for incidents of different severity. Distinguish them explicitly: response time tells you when someone starts working on the problem, and resolution time — when the system works again. An agreement that only guarantees a response guarantees very little.

On-call rules. During which hours and days it applies, which channel you use to report an outage, and whether on-call is included in the rate or billed separately.

Time reporting. With hourly billing — a report describing the work, ideally weekly or with every invoice. Also check what happens to unused hours.

Ownership of accounts and access. Cloud accounts should belong to your company, and the engineer should receive the permissions needed for the job — no more.

Documentation and ending the engagement. Up-to-date infrastructure documentation and emergency procedures are a precondition for nobody having to start from zero if you change providers.

We write more about the clauses that protect the ordering company in what a software development contract must include.

Good DevOps cooperation should be measurable. A useful reference point is the metrics described by the DORA research program, which has analyzed software delivery performance for years. They include, among others:

• deployment frequency — how often changes reach production,
• change lead time — how long it takes from a code change to its deployment,
• change failure rate — how many deployments require fixes or rollbacks,
• time to restore service after a failed deployment.

It’s worth adding two business metrics: monthly cloud cost and the number of outages noticeable to customers. If none of these metrics improves after a few months, you have a factual basis for a conversation with your provider.

With us, you work with a specific DevOps engineer who knows your system and works on your stack — AWS, Azure, or Google Cloud. We bill for the hours used in a given month: no minimum, no entry thresholds, and no year-long contract upfront, and unused hours roll over to the next month. In the event of a production outage, we respond within an hour, as part of round-the-clock on-call coverage.

For agencies and software houses, we work on a white-label basis — with an NDA and a non-compete covering their clients. You’ll find the details and scope of the service on our DevOps page.