What do DevOps services actually include?

The term covers four different jobs that are usually priced as one: build and release automation, infrastructure defined as code, observability so a failure is visible before a customer reports it, and the on-call arrangement that decides who is woken up. They have different costs and different owners, and a proposal that does not separate them is describing whichever one is cheapest to deliver.

What can a DevOps consultancy own, and what has to stay in-house?

An external team can build the pipeline, write the infrastructure definitions, set up observability and leave you a runbook. What cannot leave is the decision about what an acceptable failure looks like, and the on-call rota. If nobody inside owns those two, the pipeline still works and the organisation has not changed, which is the usual reason a DevOps engagement is judged a disappointment.

Do we need Azure DevOps consultants specifically, or is the platform interchangeable?

The platform matters less than where your identity and your artefacts already live. If the organisation is on Microsoft identity and your build agents need to reach resources inside your own network, Azure DevOps removes work that another platform adds back. If neither is true, the choice is close to arbitrary and should not be the first decision in the project.

How do you tell a DevOps proposal you can rely on from one you cannot?

Ask what is measured today. A proposal that names a target for deployment frequency or recovery time without first stating the current number is describing someone else's improvement. Ask also what happens to the pipeline when the engagement ends, and who holds the credentials it uses.

DevOps services in Tel Aviv

Q: Does the team need to be in Tel Aviv?

For the build work, no. Two things do argue for local: an incident review is more useful in the room than on a call, and data residency or regulatory constraints are easier to satisfy when the people holding production access are under the same jurisdiction as the data. If neither applies to you, location is not a selection criterion and should not be priced as one.

What the term actually covers, which parts an external team can own and which cannot leave your organisation, and what to check in a proposal before you sign it.

In short

DevOps services is four separate jobs sold as one: release automation, infrastructure as code, observability, and the on-call arrangement. An external team can deliver the first three and hand you a runbook. The fourth cannot be outsourced, because it is a decision about who gets woken up and what counts as an acceptable failure. Engagements that are judged a disappointment usually delivered the pipeline correctly and left the fourth job unassigned.

Four jobs, one invoice

Separating them before you talk to anyone is the single thing that most improves the proposals you get back.

Job	What it delivers	Can an external team own it	What it needs from you
Release automation	A commit reaches production through the same path every time, and can be rolled back	Yes, end to end	A test suite that means something, and someone empowered to say a release is blocked
Infrastructure as code	Environments are recreatable from a repository rather than from memory	Yes, and this is where external work pays back fastest	A decision on who may change production, and a place to keep secrets
Observability	A failure is visible to you before a customer reports it	Yes for the plumbing, no for the thresholds	What counts as broken, in numbers, per service
On-call and incident review	Someone answers at 3am, and last month's outage changes something	No. This is an organisational commitment, not a deliverable	A rota, an escalation path, and the authority to stop feature work after an incident

The third column is the honest part of this page. Three of the four are ordinary engineering work and transfer cleanly. The fourth is the one that decides whether anything changed, and no consultancy can supply it.

Azure DevOps specifically

Two of the queries that bring people to this page name Azure DevOps, so it deserves a direct answer rather than a platform-neutral one.

The platform matters less than two facts about your organisation. Where does identity live, and do build agents need to reach resources inside your own network. If you are already on Microsoft identity and the answer to the second is yes, Azure DevOps removes work that another platform adds back: self-hosted agents inside the network, service connections that respect existing groups, and artefact feeds that do not require a second identity system.

If neither is true, the choice between platforms is close to arbitrary and should not be the first decision in the project. Pick it after the four jobs above are separated, not before, and keep the pipeline definitions in your own repository so the choice stays reversible.

The migration case that is worth doing and the one that is not. Moving from a hand-run build to any managed platform pays for itself. Moving from one managed platform to another, with the same four jobs already working, rarely does, and the estimate for it is usually built on the pipeline count rather than on the number of integrations and credentials that have to be reissued.

What to ask before you hire

What is measured today? A proposal that names a target for deployment frequency or recovery time without first stating your current number is describing someone else's improvement.
Which of the four jobs is in scope, and which are explicitly not.
What happens to the pipeline when the engagement ends? Whose repository holds the definitions, and can your own engineers change them without the consultancy.
Who holds the credentials the pipeline uses, and how are they rotated when a person leaves.
What does the first incident review look like, and who attends it from your side.

The fifth question is the one that separates a delivery engagement from a change of practice. If there is no answer to it, you are buying the first three jobs, which is a legitimate purchase, but it should be priced and judged as such.

Signs the estimate will not hold

A percentage improvement is promised before anyone has looked at your current numbers.
The scope is described by tool names rather than by which of the four jobs is being delivered.
There is no line for the work of reissuing credentials and service connections, which is most of the effort in any migration.
On-call is listed as a deliverable.
The timeline is exact and does not depend on how many integrations your build has to reach.

Does the team need to be local

For the build work, no, and pricing locality into that part is not defensible. Two things do argue for people in the same place as you.

Incident review works better in a room than on a call, because the useful part is the argument about what should change, not the timeline of what happened. And data residency or regulatory constraints are easier to satisfy when the people holding production access sit under the same jurisdiction as the data. In regulated Israeli sectors that second point is often the deciding one, and it is a legal question before it is a technical one.

If neither applies, treat location as neutral. Related reading on the infrastructure side: comparison of cloud providers with Israeli regions.

How I work on this

Practice since 2004, work on AI systems since 2023, projects for clients in fourteen countries. I am an independent architect rather than a staffing supplier, so the answer "you need two people inside rather than an engagement" is a legitimate outcome of a review and I will say it.

What a review produces: which of the four jobs is actually missing, what your current numbers are so there is something to compare against later, and a written order of work with the risk named per step. What I do not produce: a target percentage before I have seen what you measure today.

Where to start

Tell me two things: how a change reaches production today, and who is woken up when it fails. Those two answers place you on the table above more accurately than any questionnaire.

Get in touch | Related: integrations, cloud providers in Israel

SLAtech LTD