What are the five core things every developer needs to know about DevOps?

Quick answer: the five things every developer should know about DevOps are: version control discipline (small, frequent commits), automated testing as a safety net for changes you didn't make, CI/CD so deployment is routine rather than an event, infrastructure as code so environments are reproducible, and monitoring so you find out about problems before your users do.

Hi, I'm Neil Millard, the DevOps expert, Professional of the Year 2024 — today I'm going to talk about DevOps practices and principles, what you need to know about DevOps.

Core principles

Automation — automate things, or to put it another way, have one button click to do stuff, or even better, no button click at all. The button click is just a trigger — it can be triggered by a person, a DevOps engineer, a customer, or something else entirely, like a timer ("do this at 4am") or a webhook based on an event, like a commit to a repo. What we're automating is the magic itself — build code, run tests, deploy code.

Collaboration — working with other people who know what they want, other experts in their field. DevOps is a pretty blanket role, and there are lots of specialist roles within it — a platform engineer who builds a whole toolset, cloud infrastructure specialists, developers, testers, usually somebody gathering feedback from customers (business analysts), and somebody organizing the team. Collaboration extends outside the team too — reaching out to database administrators, data analysts, or an AI team for specific skills as needed.

Continuous improvement — it's all very well having systems and processes and automating them, but sometimes those processes aren't as good as they could be — unnecessary steps, missing steps, a needed extra approval or test. It's not just about what we've automated, it's also about the human side of the process. We can continuously improve what we do as people and what the tooling does, introducing new tools or retiring old ones — making everything better, faster, and slicker for everyone involved.

Customer-centric action (self-service) — whatever I do should help the customer do what they want to do, and if they don't have to talk to me about it, even better — talking to me means explaining their situation, me understanding it, then providing something for them. If those three steps become a button, the customer gets on with what they want faster, without waiting for a DevOps person to be available. The button needs to be reliable — do what it's supposed to do without breaking — fast, and give the customer an awesome experience.

Infrastructure as code — or really, anything as code: documentation as code, infrastructure as code, cloud automation, APIs as code. If we can encode everything, we can automate it, and if it's automated, we can put a trigger or button in front of it. Code is predictable — we know what it's going to do, and it does exactly the same thing every time we trigger it (continuous improvement can change how it's done, but the end result should stay consistent — a bit like not minding which order somebody cleans your house in, as long as the whole house ends up clean). One of my customers uses the same piece of code to build every one of their servers, so all their servers are identical — that keeps things consistent, easy to support, and means everyone knows where they stand.

How DevOps improves software development

• Reduces cycle time — the time between something breaking and being fixed, tied closely to the time it takes to have an idea, code it, test it, and deploy it. Automation and fast feedback shrink that whole cycle.
• Higher quality code — because of collaboration from multiple viewpoints, because it's been tested, and because of product enhancements requested directly by customers.
• Increased reliability — automated tests don't just test your code, they let you test your tests: do they catch everything you've written, all the edge cases, and critically, can they catch regressions? Fixing one bug without breaking something else is what reliability is about, and automated tests are what let you be confident of that. The time spent writing tests feels like dead time — until a bug you fixed ages ago creeps back in, or one small typo in an unrelated file brings the whole site down, and a regression test would have caught it before it reached production.
• Better feedback loop — the quicker you can write, test, and deploy code and see how it operates, the more you're still in the same mindset as when you wrote it. A deployment process that takes a whole weekend means you've forgotten the context by the time you're back in it; one that takes 20 minutes means you're still fresh, and can tweak and redeploy quickly — customer asks for a feature, you build it, deploy it, and can ask the same day whether it meets their need, all without the context switching a slow process forces on you.
• Enhanced security — just as we test for regressions, we can test for security. A lot of the software we ship includes libraries and code written elsewhere, which could carry bugs or security issues, so as well as watching for external vulnerabilities, we test our own code too. Automated tests can check that common attacks don't succeed, that user input can't make our code misbehave, and automated penetration tests can check network access to a server is secure and there are no data leaks. Automating these security tests means they enhance the process without significantly slowing down the feedback cycle.

Key metrics for measuring DevOps success

• Deployment frequency — my number one metric. Bundling a month's worth of changes into one deployment is inherently risky — any one of those changes could cause instability, or interact unexpectedly with another, and worst case, a developer's change gets missed and has to wait weeks for the next window, by which time they've lost all context on it. Deploying once an hour instead of once a fortnight shortens the feedback cycle, gets things live faster, and each deployment tends to be a single change rather than a risky batch — the more frequent the deployments, the better the process usually is.
• Lead time for changes — how long it takes from a change being ready to it actually going live. A two-week lead time is a very long, slow feedback cycle. The shorter this number, the more automated and efficient the process.
• Mean time to recovery (MTTR) — how long it takes to identify a bug and get it resolved wherever it was spotted. If you only deploy to production every two weeks, and your deployment itself takes two weeks, this number is going to be large by definition. Some teams create a separate fast-path release process just for hotfixes to work around a slow main pipeline — but needing that workaround at all is itself a sign the main process needs improving.
• Change failure rate — if you bundle 40 changes into one deployment, and one fails, that's roughly a 1-in-40 failure rate; deploy in much smaller batches, much more often, and that rate tends to drop drastically. Deploying smaller and more often, with short feedback loops, means failures get caught and fixed quickly too.
• Customer satisfaction — the best overall indicator. Do you know who your end customers are, and are they satisfied with the service? How much time are they losing in their processes, how quickly are their needs met, how quickly are bugs fixed — all of this feeds into satisfaction.

How to transition to DevOps

Chances are you're using some form of DevOps already, it just needs continuous improvement — but you've got to start somewhere.

• Start small — the smallest possible change. If there's a deployment process with several manual button clicks, find a way to remove just one click by changing something in the code. Fewer steps and less human interaction reduces your error rate. Incremental, one small thing at a time — like climbing stairs, you can't jump from the bottom to the top in one go.
• Build a cross-functional team — in older, siloed organizations, you might have separate networking, server, and development teams, even on different floors, barely talking to each other. Pull one person from each team into a small target team, working closely together daily, and you get a cross-functional group that can attack a problem from every angle and feed learnings back to their original teams.
• DevOps embedding — take a regular team and embed somebody with strong DevOps skills into it, so they can share knowledge and expertise directly with the team.
• Invest in training — if you've already got an enthusiastic team, rather than bringing in outside help, they might just need training, pointers, or a mentor to ask questions of. I've met plenty of people whose enthusiasm and willingness to ask lots of questions helped them learn fast.
• Adopt the right tools — using appropriate tools makes a world of difference. If your team isn't comfortable with scripting, maybe a different CI/CD server than the default (Jenkins is popular and free, but if your team doesn't know it, something like the CI/CD built into Artifactory or GitLab might suit them better). It depends entirely on what your team is missing — an automation system, or something as simple as parallel batch scripting or bash — and you'll also need monitoring, since fast feedback shouldn't rely purely on customers telling you something's wrong; logs, statistics, and performance graphs from proper monitoring tools do that job far better. There are dozens of tools out there — you don't need all of them, just the right ones.
• Focus on culture — a team that's enthusiastic and wants to learn is a great foundation; a siloed team focused only on their own patch is less so. I've never met someone with a bad attitude in this field, because if you don't keep learning in IT, you get left behind fast — and honestly, there are so many exciting new things to learn, that's part of the fun. A culture of collaboration and continuous learning matters more than any individual skill set — someone with perfect technical skills but no interest in collaborating or learning more ends up with a strangely shaped team around them. Prioritize culture, especially when interviewing and growing your team.

Where cloud computing fits in

Cloud computing helps in a number of ways. Scalability — you can start really small, purchasing tiny units of compute just to get a taste (Amazon even offers a free tier), and scale up your technical resources and the staff who need them as demand and budget grow. I recently came off a project that went from hosting four services to over a thousand, and cloud computing let them scale that without rearchitecting everything underneath.

Flexibility — as well as scaling up, you can scale down. Development environments that are only switched on 10 hours a day instead of 24 nearly halve your cloud costs. Cost efficiency follows directly from that — you only pay for what you're using. Production servers, which need to run around the clock for customers in different time zones, are less flexible here, but developer machines, for instance, can live in the cloud and be switched off entirely overnight, saving real money in a way that's much harder to achieve with owned hardware sitting idle. And cloud platforms give you global reach — data centres worldwide mean that if you're expanding into a new country, you can host your application close to those customers, keeping things fast and synchronized for international and local customers alike.

If you want to know more, I've written a book on this, "Who Moved My Servers?", available on Amazon Kindle — link in the description and comments. I'm also launching a new product, DevOps Answers, at devops-answers.com, where you or your team can ask me DevOps questions on a regular basis — head over there and join the waitlist. Thanks for watching.