DevOps Services for Reliable Continuous Delivery at Scale

This page sets out what Sthenos does under DevOps, what an engagement produces, and how to tell a real DevOps proposal from a tool list. The practices are grouped by where you are rather than by product name, the vocabulary is defined so both sides mean the same thing before anything is signed, and the four industry standard delivery measures are quoted from DORA rather than from us.

On this page

• DevOps consulting and services, the four lines this page sells
• Our DevOps practices, the five practice areas
• DevOps practices, grouped by what you need next
• The DevOps vocabulary, defined
• The four delivery measures, defined
• What you receive
• How a DevOps engagement runs
• A DevOps maturity self assessment you can run this week
• What moves the cost of a DevOps engagement
• Three ways to engage Sthenos
• What to ask any DevOps company
• More questions about DevOps
• More about DevOps

DevOps practices, grouped by what you need next

Almost nobody buys DevOps in the abstract. They buy it because a release takes a weekend, because staging and production stopped resembling each other, or because the one engineer who understands the deploy is on leave. The catalog below is grouped by where you are rather than by product name, and every practice links to the Sthenos page that already sells it. Where a tool is named, the page on this site that claims it is named with it, so you can check the claim rather than take it.

Assess, when you do not yet know what is wrong

• DevOps maturity assessment. A structured read of how code reaches production today: branching, build, test, environments, release, rollback, monitoring and who owns each. The output is a ranked list of friction points with an owner against each, not a maturity score with nothing behind it. This is the work our DevOps consulting line already describes as identifying friction points and risk.
• Pipeline and platform review. The build and deploy path read end to end, with the manual steps, the undocumented steps and the steps that only one person can perform written down. We read the pipeline definitions and the infrastructure definitions rather than the documentation about them, the same method our production readiness audit uses.
• Production readiness review. The Sthenos seven step production readiness playbook run against the system as it stands. Its seven areas are reliability and failure behaviour, data and recovery, observability, security, performance and capacity, release and rollback, and ownership and operations, and the production readiness checklist scores 29 checks across them from 0 to 4 on evidence rather than opinion.

Build, when the path to production is the problem

• CI/CD pipelines. Automated build, test and deployment so a change reaches an environment the same way every time. Our DevOps engineering services page describes this as continuous integration, testing and deployment across environments, and its Oracle SaaS case study names the pipeline built with AWS CodeBuild and CodePipeline, with static code analysis and quality gates enforced through SonarQube. On Microsoft estates our Azure services page names Azure DevOps alongside CI/CD pipelines and infrastructure as code.
• Infrastructure as code. Environments defined in files, reviewed like code and rebuilt from those files rather than from memory. Sthenos names Terraform, Ansible and CloudFormation for this on the DevOps engineering services page. Infrastructure as code also appears under the DevOps and MLOps practice on our AWS services page, and under DevOps and automation on our Azure services page.
• Configuration management. Standard system configuration applied the same way everywhere so environments stop drifting apart. Ansible, Puppet and Chef are the tools named for this on our DevOps engineering services page.
• Containers and orchestration. Applications packaged so they run the same on a laptop, in staging and in production, then scheduled and scaled by a platform. Docker and container orchestration are named in the case studies on our DevOps engineering services page. For managed Kubernetes, our Azure services page names Azure Kubernetes Service and our Google Cloud services page names Google Kubernetes Engine.
• Environments and release management. Development, staging and production defined from the same source, with promotion between them controlled rather than improvised. Release management as a discipline, from planning and design through testing and deployment, is described on our managed services page.
• Test automation in the pipeline. Tests that run on every change instead of in a manual pass before a release. Our software testing page describes automation frameworks that catch regressions early and support continuous delivery, and this page already sells continuous testing embedded across the delivery lifecycle.
• Observability. Structured logs, dashboards for the handful of metrics that indicate user pain, and alerts that route to somebody awake and able to act. That definition is the observability area of our production readiness checklist. Where the platform already provides the tooling we use it: our Azure services page names Azure Monitor and Log Analytics for operational visibility.
• Security in the pipeline. Static analysis and dependency scanning wired into CI so a vulnerable package fails the build, infrastructure as code policy checks so a corrected setting cannot be reintroduced by the next deploy, and cloud configuration reviewed against CIS Benchmarks. Those are the words our penetration testing and cybersecurity pages already use, and they are where that work is scoped and priced.

Operate, when the problem starts after the deploy

• Managed platform operations. Somebody named owns the pipeline, the environments and the platform after handover. Incident management, problem management, change management, release management and service level management are the disciplines described on our managed services page, and infrastructure management services covers hybrid and multi cloud operations alongside them.
• Incident response and on call. A rotation, an escalation path and a runbook for the three most likely failures, plus a blameless post incident review so the same outage does not recur. Those are checks 7.2 and 7.4 of the ownership and operations area of our production readiness checklist.
• Cost governance. Compute sized for peak and left running at idle, storage that is never lifecycled, egress nobody modelled and non production environments running around the clock are the cost drivers our cloud migration and optimization page names. Cloud autoscaling and cloud governance are the two practices our cloud computing page puts against them.
• Delivery recovery. When a pipeline has stalled, stabilising the build first and restructuring the workflow second, which is the DevOps project recovery line this page already sells.

The DevOps vocabulary, defined

Most DevOps proposals fail at the vocabulary rather than the engineering. These are the terms that come up in every scoping call, defined plainly so both sides mean the same thing before anything is signed.

Continuous integration, continuous delivery and continuous deployment

The three are routinely used as synonyms in vendor copy and they are three different commitments.

Blue green, canary and rolling releases

These are three ways to put a new version in front of users without a maintenance window. The choice is a trade between infrastructure cost and how quickly you want to be able to change your mind.

Infrastructure as code and configuration management

Infrastructure as code describes what should exist: the network, the cluster, the database, the permissions, written as files and applied by a tool that reconciles reality to the file. Configuration management describes what should be true inside those machines once they exist: packages, services, users, settings. Terraform and CloudFormation are the infrastructure as code tools Sthenos names; Ansible spans both, and Puppet and Chef sit on the configuration management side. The reason both matter is drift: without the first, an environment nobody can rebuild; without the second, two servers that were identical in January and are not in June.

Monitoring and observability

Monitoring answers questions you thought of in advance, by watching a fixed set of signals and alerting when one crosses a threshold. Observability is whether you can answer a question you did not think of in advance, from the data the system already emits, without shipping new code to find out. The practical test is the one our production readiness checklist uses: can you answer what changed within minutes, because deploys are correlated with the metrics. If the answer needs a developer to add logging and wait for the next occurrence, you have monitoring.

DevOps, platform engineering and site reliability engineering

DevOps is a working practice: the people who build a system and the people who run it share ownership, tooling and incentives, so the handover stops being a wall. Platform engineering is a product decision that follows from it: a small team builds an internal platform, with paved paths for building, deploying and observing, that other teams consume by choice. Site reliability engineering is an operating model that sets reliability targets explicitly and treats the gap between the target and reality as a budget that governs how fast the team may ship. They are not competitors and you do not have to pick one. Most organisations of moderate size need the practice, benefit from a thin platform, and only need the formal reliability model once several teams are shipping to the same system.

GitOps

GitOps is infrastructure as code plus a reconciler. The desired state of an environment lives in version control, and an agent continuously compares the running environment to that repository and corrects the difference. A change is made by a pull request rather than by a person with console access, which makes the audit trail a by product of how the work is done rather than something assembled afterwards. It only pays off once the state genuinely lives in the repository, which is why it is the last step of an infrastructure as code programme rather than the first.

The four delivery measures, defined

The industry standard measures of software delivery come from DORA, a research programme run by Google Cloud. On its DORA metrics guide the measures are defined as follows, and these are DORA's definitions rather than ours.

What you receive

The artefacts below land on your side of the fence and remain yours. They are what a DevOps engagement should hand you, listed so you can hold any engagement to them.

• Pipeline definitions, held in your repository, covering build, test, packaging and deployment for each environment, so the pipeline can be read, reviewed and changed by your own engineers.
• Infrastructure as code repositories that define each environment, with the differences between environments expressed as parameters rather than as separate hand built estates.
• Environment and release documentation: what each environment is for, how a change is promoted between them, and who may approve that promotion.
• Runbooks for the failures most likely to occur, written to be followed at three in the morning by somebody who did not build the system.
• Dashboards and alerts covering the signals that indicate user pain, with every alert routed to a named destination and alerts nobody can action removed rather than muted.
• Rollback procedures, written and rehearsed rather than assumed, including the database question, which is the one that turns a rollback into an outage.
• A findings and risk register from the assessment, with each item carrying an owner and either a fix or an accepted risk.
• A handover session with your engineers, because a pipeline nobody on your side can change is a dependency rather than an improvement.

How a DevOps engagement runs

Sthenos works in two week sprints, so working software arrives every two weeks rather than at a reveal at the end. The stages below describe the order of the work. We do not publish a duration for each stage, because the honest answer depends on how many services and environments you run and how much of the pipeline already exists.

• AssessWe read the code, the pipeline definitions and the infrastructure definitions, and interview the engineers who run the release. The output is the friction list, ranked, with an owner against each item.Before any change
• BaselineThe delivery path is instrumented so the four DORA measures can be read from your own systems. This happens before any change, because a baseline taken afterwards proves nothing.Before any change
• Agree the targetWhich of the friction points are worth removing first, what the release process should look like when the work is done, and what evidence will show it. This is where the scope is fixed and the work stops being open ended.
• Build, in two week sprintsPipelines, infrastructure as code, environments, observability and pipeline security land incrementally. Each sprint ends with something you can use, so the value does not arrive only at the end.Two week sprints
• RehearseA deployment and a rollback are performed on a production shaped copy before either is trusted in production. A rollback that has never been executed is a plan, not a capability.
• Hand overRunbooks, dashboards, the release documentation and a working session with your engineers, so the team that lives with the system can change it.Your engineers
• Operate or step backEither Sthenos runs the platform under a managed services arrangement, or your team runs it and we stay available for the changes that need us. Both are normal endings and the choice is yours to make at handover rather than at signature.

A DevOps maturity self assessment you can run this week

Run this against your own delivery path before you speak to any vendor, including us. Each item is answerable with evidence or it is not answerable at all. Count the ones where the honest answer is no, and that count is your scope.

• Can any engineer on the team deploy to production today, or does it need one specific person.
• Is every environment rebuildable from files in version control, or would rebuilding staging be a project.
• Does the pipeline run the tests, or do the tests run in a manual pass before a release.
• Has a rollback been executed in the last quarter, on purpose, as a rehearsal.
• Do you know how long a change takes to go from merged to live, as a number you could show somebody.
• When something broke last month, how long did it take to find out, and did a customer tell you first.
• Are secrets in a managed store, or in environment files, a wiki page and at least one repository.
• Does a vulnerable dependency fail the build, or does it get noticed at the next audit.
• Does anybody own the cloud bill, and can they explain last month's change in it.
• Is there a named on call rotation with an escalation path, or an informal understanding that a particular person answers the phone.

The rollback item is the release and rollback area of our production readiness checklist. Structured logs, dashboards for the metrics that indicate user pain, and alerts that route to somebody able to act are the observability area of the same checklist. A short list of no answers is usually a focused piece of work. A long one is a programme, and it is the point at which sequencing matters more than tooling. The full version of this exercise, scored on evidence rather than opinion, is our production readiness checklist.

What moves the cost of a DevOps engagement

Sthenos does not publish a DevOps price band, because a defensible one would have to come from delivered engagements of this specific shape rather than from a market average. Our hourly rates are published on our about page and apply here as they do everywhere. What actually moves the number is below, and you can estimate your own position on each driver before anyone quotes you.

Source: the rate sentence published on our about page, which reads that our rates are $150 to $250 per hour, depending on the seniority and mix of the team. There is no separate DevOps rate.

• How many services and how many environments. One application with two environments and twelve services with four environments are different pieces of work, and the count drives it more than the technology does.
• How much automation already exists. Extending a pipeline that works is cheaper than building the first one, and rescuing a half built pipeline that nobody trusts is sometimes more expensive than either.
• Whether the environments can be rebuilt. If production was assembled by hand over several years, the first cost is discovering what is actually running, before anything can be written as code.
• How many clouds and platforms. A single cloud is one set of primitives. Hybrid and multi cloud estates, covered on our infrastructure management services page, carry more.
• What compliance evidence the pipeline has to produce. A pipeline that has to demonstrate approvals, segregation of duties and an audit trail to an assessor is a different specification from one that only has to deploy.
• How much sits in one person's head. Where operational knowledge was never written down, extracting it is real work and it belongs in the estimate rather than in the risk section.
• Whether we operate it afterwards. A build engagement and an ongoing operations arrangement price differently, and mixing them into one number is how DevOps quotes become uncomparable.

Three ways to engage Sthenos

DevOps work arrives in one of three shapes. They are listed smallest first, and starting at the first one is a legitimate way to find out whether you need the second.

What to ask any DevOps company

These questions are written to be asked of any vendor in this category, Sthenos included. Each one has a bad answer that is easy to spot.

• Ask which of the four DORA measures they will baseline on your systems, and when. A vendor who quotes their own deployment frequency instead of proposing to measure yours has answered a different question.
• Ask to see a pipeline definition and a runbook from a previous engagement, redacted. The deliverables either exist as artefacts or they exist as a description of artefacts.
• Ask who owns the pipeline on the day after handover, by name and role. If the answer is that the vendor keeps operating it, that is a service, not a handover, and it should be priced as one.
• Ask what happens to the tooling if you stop working together. A pipeline built on your accounts, in your repositories, with tools you can license directly, survives the relationship. A pipeline inside the vendor's tenancy does not.
• Ask whether a rollback has ever been rehearsed on a system they delivered. Almost every proposal claims rollback. Rehearsal is the thing that separates the claim from the capability.
• Ask how secrets will be handled, specifically. The answer should name where secrets live, who can read them and how access is revoked, not merely that they are encrypted.
• Ask which certifications they hold and which are their partner's. Audited and self declared are different claims, and so are a firm's own certifications and its partner's. The Sthenos position is stated on our enterprise software development page: where enterprise scale certifications matter, we reference our partner NeoSOFT accurately rather than claiming them as Sthenos's own.

More questions about DevOps

What is DevOps consulting?

DevOps consulting is an outside read of how your code reaches production, ending in a ranked list of what to change and in what order. It covers branching, build, test, environments, release, rollback, monitoring and ownership, and it produces a plan you own whether or not the same firm does the work.

Do you work with our existing cloud?

Yes. Sthenos works across AWS, Microsoft Azure and Google Cloud, and each has its own platform page on this site. Hybrid and multi cloud estates are covered by our infrastructure management services. We do not require a migration as a precondition for improving your delivery path.

Can you set up CI/CD for an existing application?

Yes. An existing application usually already has a build and a deploy, performed by people rather than by a pipeline. The work is to capture what those people do, automate it step by step, and add the tests and gates that make the automated path safer than the manual one.

What is infrastructure as code?

Infrastructure as code means your environments are defined in files held in version control and created by a tool from those files, rather than assembled by hand in a console. It makes environments reviewable, repeatable and rebuildable. Sthenos names Terraform, Ansible and CloudFormation for this work on our DevOps engineering services page.

How long does a DevOps engagement take?

We work in two week sprints, so you receive working improvements every two weeks from the start rather than at the end. We do not publish an overall duration, because it depends on how many services and environments you run and how much automation already exists.

How do you handle secrets and access?

Secrets belong in a managed store the platform provides, read by the pipeline at deploy time and never committed to a repository. Access follows the identity and access management practice on our cybersecurity page: multi factor authentication, role based access control and identity governance, so only authorised users reach critical systems.

More about DevOps

Ready to look at your delivery path? Start with an assessment: a fixed scope read of how code reaches production today, ending in a ranked friction list you own whether or not we do the work it recommends. Talk to our engineers.