DevOps for SMEs: Where to Start With a Small Team

DevOps for SMEs is a handful of habits, not a department. You can adopt most of them with the people you already have, and the order matters more than the tools.

I learned that on a SaaS startup I worked with as a technology consultant from its early stages. The founders decided to replace their external software house with an in-house team. My job was building that team, developing a workflow, and training the future team leaders. The product launched almost 8 months before its main competitor, and the project came in nearly 15% under the client’s initial budget, even with the cost of building a team.

This post covers what DevOps isn’t, the order I’d do things in, what to measure, and how much of this a very small team can skip.

Before You Hire a DevOps Engineer

Hiring one “DevOps engineer” and telling developers it’s now that person’s problem creates a new silo with a fashionable name.

Tools won’t fix that either. They make good habits cheaper and bad ones faster.

Often the people you need already work for you. At a small Central European IT company that ran managed services for infrastructure on AWS and on-premises, I prepared a team of senior SysOps administrators for DevOps roles and introduced new DevOps, SecOps and SRE standards. Experienced people who know how production fails are a better starting point than a stack of certificates.

DevOps for SMEs: The Order I’d Do Things In

Each step pays for the next one. The exception is the platform, which can come early if the product needs it, as Kubernetes did at that startup.

• 1. Put everything in version control: code, configuration and infrastructure definitions.
• 2. Automate the build and the tests. Every change gets the same checks, and nobody has to remember them.
• 3. Describe infrastructure in code, so that an environment can be rebuilt rather than remembered.
• 4. Add monitoring that tells you about a problem before a customer does, and backups you have tested. Safe releases depend on both.
• 5. Make releases routine. Start with rolling updates and health checks, and add blue-green only where the money justifies it. Zero-downtime deployments covers the options.
• 6. Protect the repository, because it now controls production. See GitOps security.
• 7. Ask whether you need an orchestrator. Kubernetes for SMEs answers that one.

At the startup I did two things first. CI/CD with infrastructure as code, so a deploy no longer depended on one person’s laptop and any environment could be rebuilt from the repository. Then monitoring, alerting and backups we had actually tested. You can’t run a SaaS on “a customer will tell us when it’s down”. The team started at three to five engineers, with nobody dedicated to operations, and grew to eight to twelve, with one or two people owning the infrastructure.

What to Measure

You don’t need a dashboard wall. DORA’s software delivery metrics are a sensible starting point: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Pick two. In my view, a small company gets most of the value from lead time and recovery time: how long a change takes to reach customers, and how long it takes to recover when one goes wrong.

In my experience those are also the two a board will follow.

How Much of This Can a Small Team Skip?

A good deal. A three-person team with one product has better things to do. For them, version control, an automated build, a backup that has been tested, and a protected main branch are the essentials. The rest can wait until a release frightens someone.

The other warning is about dependence. If your delivery depends on one person, a resignation is an outage with a notice period.

The opposite extreme exists too. A regulated, multi-cloud program like the AML and KYC platform needed infrastructure as code from the first day. Most SMEs are somewhere in between, so buy only as much process as your risk justifies.

Bottom Line

Start with what makes a change safe and repeatable, and add tools only when a real problem asks for them. Treat DevOps as a way of working that your existing team can grow into. Measure two numbers. If your releases are still an event, you already know where to start.