DevOps Engineering Services to Accelerate Software Delivery

This page is the engineering half of DevOps at Sthenos: the pipelines, environments, monitoring and release paths themselves. The ten services above are set out below on the delivery path they act on, the vocabulary is defined so both sides mean the same thing before anything is signed, and the questions buyers ask most are answered at the end.

On this page

• DevOps Engineering Services We Provide
• Why Should You Choose Our DevOps Engineers
• Benefits of Hiring DevOps Engineers
• Solving IT Challenges In Every Industry, Every Day
• Selected Project Examples
• The delivery path, and which service acts where
• The ten DevOps engineering services
• What you receive from DevOps services
• Infrastructure automation versus configuration management
• The DevOps vocabulary, in short
• What to ask any DevOps service company
• More questions about DevOps engineering
• More about DevOps at Sthenos
• DevOps consulting and services
• Talk to our engineers

The delivery path, and which service acts where

Everything on this page acts somewhere on the path a change takes from a commit to a running system. The figure places the ten services on that path, and the list underneath says what each stage produces.

• CommitA change enters source control and is reviewed before it goes anywhere else.Your engineers
• Build and testAutomated build and test on every change, so a change reaches an environment the same way every time.CI/CD pipeline implementation
• EnvironmentsEnvironments defined in files and rebuilt from those files, with standard configuration applied the same way everywhere, on the cloud estate the work runs on.Infrastructure automation, configuration management, cloud migration and management
• ReleaseThe new version replaces the running one, and the platform carries the load it is given.Scalability and high availability
• OperateWhat happens after a deploy: the signals that show user pain, and the work of making the running system faster and cheaper.Monitoring and alerting, performance optimization

The ten DevOps engineering services

These are the service tiles set out above, in one list, so the whole scope can be read at once and taken into a statement of work.

• CI/CD pipeline implementation
• Infrastructure automation
• Cloud migration and management
• Configuration management
• Monitoring and alerting
• Scalability and high availability
• Security and compliance
• Collaboration and communication tools
• DevOps coaching and training
• Performance optimization

What you receive from DevOps services

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, whoever provides your DevOps development services. The same list is on our DevOps consulting and services page.

• 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.

Infrastructure automation versus configuration management

Two of the ten services above share tools and are easy to confuse. The difference, in the words of the two service tiles and of the vocabulary on our DevOps consulting and services page:

The reason both matter is drift, and Ansible spans both. GitOps comes after them: infrastructure as code plus a reconciler that continuously corrects the running environment back to the repository, which only pays off once the state genuinely lives in the repository.

The DevOps vocabulary, in short

This page names the engineering. The terms below are the ones that decide what gets built, defined in one line each here and at length on our DevOps consulting and services page, where each entry links directly.

What to ask any DevOps service company

These questions are written to be asked of any DevOps service provider, Sthenos included. The first comes from the vocabulary above, the last is where DevOps and security meet, and the rest are from the longer list on our DevOps consulting and services page, which also covers certifications.

• Ask which of CI, CD and continuous deployment they are proposing. Merging and testing on every change, being able to release on demand, and releasing automatically are three different commitments rather than three words for the same thing.
• 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. 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.

More questions about DevOps engineering

What is included in a DevOps engineering engagement?

The ten services listed on this page: CI/CD pipeline implementation, infrastructure automation, cloud migration and management, configuration management, monitoring and alerting, scalability and high availability, security and compliance, collaboration and communication tools, DevOps coaching and training, and performance optimization. Which of them an engagement uses depends on where the delivery path is failing today.

How is DevOps engineering different from DevOps consulting?

Our DevOps consulting and services page sets out four lines of work, consulting, DevOps as a service, enablement and transformation, and groups the practices by where you are: assess, build and operate. This page is the engineering itself, the pipelines, environments and monitoring that the assessment recommends.

Which cloud platforms do your DevOps engineers work on?

AWS, Microsoft Azure and Google Cloud, each of which has its own platform page on this site, and cloud migration and management is one of the ten services above. For an estate that is moving rather than running, we publish a separate cloud migration and optimization practice.

Who owns the pipeline, the repository and the cloud accounts?

You do, entirely, from the first commit. The repository and the cloud accounts are in your name, with no licence back to us and no dependency on us continuing to exist. That is the position published on our custom software development page and it holds for DevOps work as well.

What does DevOps engineering work cost?

Our rates are $150 to $250 per hour, depending on the seniority and mix of the team, and a typical project runs $50,000 to $200,000. On DevOps work the size of the estate, the number of environments and how much of the delivery path already exists all move the total.

Do you publish your own deployment frequency or recovery time?

No. The four delivery measures are deployment frequency, change lead time, change fail rate and failed deployment recovery time, defined by DORA, a research programme run by Google Cloud. Sthenos publishes no figure of its own for any of them. The honest alternative is to baseline your own pipeline at the start and report the trend against that baseline.

More about DevOps at Sthenos

Ready to look at your delivery path? Tell us where a release currently stalls and which of the ten services above you think you need, and we will tell you which one we would actually start with. Talk to our engineers.