Question 1

How do I reduce deployment risk without slowing down releases?

Accepted Answer

Small and often;
To reduce the risk of a deployment is to make each piece of work as small as possible. small change equals small risk.
The same logic works for releases. This does mean you would have to increase the frequency of deployments and releases so that they are smaller and therefore lower risk.

In practice this means shipping single-feature or single-fix changesets — often behind a feature flag — rather than batching a week's work into one release: a change that touches one code path is much faster to review, test, and roll back if it turns out to be wrong.

Question 2

What is the best way to do a zero-downtime deployment?

Accepted Answer

There are three well documented modes for zero-downtime deployments.

1. Canary - If your deployment is sufficiently large, you can stage a gradual deployment of the smallest component and scale up as confidence grows. e.g. you have a 10 node cluster, upgrade just 1 cluster first, and update the rest gradually. This means any failure is small and can be isolated, meaning the service overall experiences no downtime.

2. Blue-Green deployments - With the duplication of an entire application, you can operate in an active/passive configuration, where the passive configuration is upgraded via a deployment. This passive side can then be tested fully before the switch occurs. Once happy a switch configures the systems to swap over, passive becomes active and active becomes passive. This also enables a swift rollback if necessary.

3. Feature switches - In code a feature switch enables fine grain control over specific features in an application. The application can be deployed with the code intact, but the switch is off. Then the switch can be enabled (usually via configuration) for that feature to test with very low impact on the rest of the application or service.

Most teams in practice combine two of these — a canary rollout (e.g. 5% of traffic for 15 minutes before continuing) paired with a feature flag, so a bad release can be halted by traffic percentage and killed by flag without needing a full rollback.

Question 3

How do you roll back a bad release quickly?

Accepted Answer

With version control this is made easy. Version controlled source with a build pipeline creates a versioned artifact. With configuration as code, also in source control, this specifies the version of artifact to be deployed.
If a bad release/artifact is discovered, updating the configuration to the 'last known good' configuration and therefore artifact, should restore service.

This rollback path is only fast if it has been exercised — practise deploying the 'last known good' tag as a drill, not for the first time during a live incident.

Question 4

What is blue-green deployment and how does it achieve zero downtime?

Accepted Answer

A blue-green deployment is where you have two identical environments in an active/passive configuration. The active environment receives live traffic and the passive can receive test traffic.

These are independent environments. It can be just one layer in the stack, or the whole stack — for example, just the web server layer or the entire application stack.

If we label the live environment as green, the blue environment can be used for the new release or deployment, and undergo QA (Quality Assurance) testing before the decision to switch.

The switch from green to blue is near instant, and because we have already tested the blue environment, we can be confident that no downtime will occur.

Should the worst happen, a rollback is near instant too — simply switching traffic back from blue to green.

The main trade-off is cost: blue-green needs a second full environment running in parallel during the switchover window, which is why teams that cannot justify doubling infrastructure often use rolling or canary deployments instead.

Question 5

Deployment vs release: what is the difference?

Accepted Answer

Short answer: a **release** is a versioned, deployable artifact; a **deployment** is the act of putting that artifact into a running environment. A release happens once per version; the same release can be deployed many times, to many environments.

**Release**

A release is the creation of a deployable artifact with a specific tag, usually a semantic version tag (`v2.4.1`, a Docker image digest, a build number). Tagging the artifact once means every later step — integration tests, staging, production — runs against the exact same bytes, so "it passed in staging" and "it is running in production" refer to one identical thing.

**Deployment**

A deployment is where we take that artifact and configure the target environment (test, staging, production) to run it. This includes updating the running instances/containers/servers to the chosen version/tag, and it can happen more than once for the same release — you might deploy `v2.4.1` to staging on Monday and to production on Wednesday without creating a new release in between.

**Deployment vs release, at a glance**

- **What it produces** — Release: a versioned artifact. Deployment: that artifact running somewhere.
- **How often it happens** — Release: once per version. Deployment: once per environment, and can repeat.
- **What can go wrong** — Release: the build/packaging step, or a bad version tag. Deployment: environment config, rollout strategy, or infrastructure.
- **How you undo it** — Release: cut a new version. Deployment: roll back to the previous version already released.

This split is also why "deploy" and "release" are not always the same moment for end users: you can deploy code to production behind a feature flag (deployed, not released to users) or roll a release out gradually via canary or blue-green deployment (see [What is blue-green deployment?](/questions/blue-green-deployment/)). For how this fits into the wider pipeline, see [What is a software deployment pipeline?](/questions/software-deployment-pipeline/), and for what to watch once a deployment is live, see [What DevOps metrics should you track to measure deployment health?](/questions/devops-metrics-deployment-health/).

Question 6

What is the difference between monitoring and observability?

Accepted Answer

Monitoring is the active state of things and alerts. A dashboard can show you the state of components and the system as a whole. Working, impaired or failed.
Observability is where you gather further evidence such as logs and metrics. This information enables you to track down the root cause of the monitoring alerts and fix it. It is sometimes used as an early warning system. As an example; a disk usage metric can enable you to extrapolate ongoing disk usage and plan for upgrades.

A concrete example: a dashboard showing "API error rate: 12%" is monitoring. Being able to trace that 12% down to a specific downstream database connection pool exhausting on a specific node, using logs and traces, is observability.

Question 7

How do you set up alerting that actually gets acted on and not ignored?

Accepted Answer

The biggest problem with alerting is the sea of red. If everything is urgent, then nothing is urgent.

At the beginning there should be a sea of green checks. But this is the ideal. In reality, alerts are setup in the mist of an incident when things are on fire.
A more tactical approach should be chosen. Only setup alerts on what matter most, today. No more. Until those fires are put out. Then add more alerts, gradually over time, most important to informational.

If it isn't critical, do not add it. Likewise for Errors, and Warnings.
Only after the gradual build up of alerts, making them green as you go, should you attempt to model the whole application or infrastructure.

A practical starting rule: alert on symptoms users would notice — error rate, latency, availability — not on every underlying cause. A disk at 80% full is worth a dashboard entry, not a 3am page, unless it is actually about to run out.

Question 8

What metrics should I track to know my deployment pipeline is healthy?

Accepted Answer

The main metric to watch is the pipeline execution time. This provides a **baseline** and any deviation can signal a warning or failure of a infrastructure component. As a deployment pipeline can touch and rely on multiple `infrastructure components`, it is a useful indicator of infrastructure health.

Another metric to watch is wait time. this is the amount of time the pipeline had to wait before being executed. A long wait time is an indicator that the `build and deploy` infrastructure is under resourced or broken.

You might want to track the deployment failures vs deployment success. This can give you a glimpse into your code quality. Improving code and tests will improve this statistic.

As a starting set, track these three per pipeline: execution time (baseline plus deviation), queue/wait time before a run starts, and the pass/fail ratio — trending any one of them weekly tends to surface infrastructure or code-quality problems before they cause an outage.

Question 9

How can external DevOps expertise provide an unbiased view of your challenges?

Accepted Answer

**Quick answer:** an external DevOps expert isn't invested in your team's past tooling decisions or internal politics, so they assess your infrastructure, processes, and pipelines against what actually works elsewhere — not against "how we've always done it here" — and can name the uncomfortable problems an internal team may be too close to see.

External experts bring an unbiased view of your DevOps challenges. They analyze your infrastructure, tooling, and processes, and offer actionable insights without being influenced by internal politics or legacy decision-making.

Question 10

How do fractional DevOps experts give you access to top-tier talent at lower cost?

Accepted Answer

**Quick answer:** a fractional DevOps expert is a specialist who works part-time on a contract basis, so a startup or budget-constrained company gets senior-level DevOps expertise without the cost of a full-time hire — paying only for the days actually needed.

A fractional DevOps expert is a highly skilled professional who works part-time on a contract basis, providing specialist DevOps expertise without the commitment of a full-time hire. This approach has several advantages.

Cost efficiency — we can be expensive because we know our stuff, but if you're a startup or a company with a limited budget, a fractional expert gives you access to top-tier DevOps talent at a fraction of the cost, paying only for the time and expertise that you need.

Question 11

How can a fractional DevOps expert help scale your business?

Accepted Answer

**Quick answer:** a fractional DevOps expert lets a business scale support up or down with demand — busy around a launch or migration, quiet otherwise — while bringing an outside perspective that reduces risk and technical debt through established best practices in automation, monitoring, and infrastructure as code.

A fractional DevOps expert can give you flexibility and scalability. Your business may not require a full-time DevOps engineer all year round — a fractional expert allows you to scale your DevOps support up and down as needed, whether you're preparing for a major product launch, migrating to the cloud, or improving security compliance. A DevOps expert can give you an objective, fresh perspective, and if you want reduced risk and less technical debt, a DevOps expert can help by implementing industry best practices.

In automation, monitoring, and infrastructure as code, a fractional DevOps expert reduces risk and improves security, and also helps avoid costly technical debt that can slow down development in the long run.

Question 12

Why is collaboration so fundamental to DevOps and open-source success?

Accepted Answer

**Quick answer:** collaboration is why open-source software exists at all — projects like Linux and WordPress run a large share of the internet because hundreds of contributors shared work instead of each solving the same problem alone; without that collaborative model, most of the free infrastructure the internet depends on wouldn't exist.

Sharing is caring, and sharing is key in software development and DevOps. After all, if we didn't share stuff we wouldn't have open-source software, and without open-source software we wouldn't have many great projects. WordPress runs a lot of websites, and the Linux kernel itself runs most of the worldwide web — nearly every server on the internet, if it's not Microsoft, is running Linux. That kernel is open source, and open-source projects are the result of a handful, sometimes hundreds, of developers all contributing to the same source.

Imagine if you had to pay for that — that'd be very expensive. But imagine the value that we get out of it: I'm running a Linux desktop right here, and I get value because it works and allows me to do my job. So without collaboration we wouldn't have open source, and without open source we wouldn't have a lot of things on the internet right now. So let's collaborate.

Question 13

How does automation help you work smarter rather than harder?

Accepted Answer

**Quick answer:** automation lets you do boring, repetitive work once (writing the automation) instead of doing it by hand every time, which cuts both wasted effort and the mistakes that creep in when a human is bored or going through the motions — the trade-off is that any bug in the automation now repeats perfectly every single run too, so it still needs testing.

Automation can help you avoid overwork. In my line of work I love to automate — this is ultimately because I'm lazy, and it also helps me with two things.

One: boring work. Who likes to do the same thing over and over again? It's exciting doing something once, sometimes even twice, but by the third time, if it's something boring that you don't find interesting, it's starting to stretch a little bit. So I use automation to get the computer to do that, because computers love doing boring stuff over and over and over again.

Two: it also helps me reduce the mistakes I make, particularly if my heart's not in it or if it's boring and I'm just going through the motions — that's when it's easy for mistakes to creep in. If you've automated something, you know exactly what those mistakes could be and you can correct for them. Computers are great at doing exactly the same thing every single time. This does mean we have to be careful of bugs, because they'll do exactly the same thing every single time too.

But by having automated tasks, our computerised friends can help us do the boring stuff so that we can do exciting stuff, like thinking. Anyway, happy automating.

Question 14

How does a fractional DevOps expert help accelerate software releases?

Accepted Answer

**Quick answer:** a fractional DevOps expert accelerates releases mainly by optimising the CI/CD pipeline itself — introducing best practices that reduce downtime, streamline workflows, and make deployments faster and more reliable, without the overhead of a full-time hire.

By optimizing your continuous integration and deployment pipelines, a fractional DevOps expert helps accelerate software releases. I introduce best practices, reduce downtime, streamline workflows, and ensure faster, more reliable deployments.

A fractional DevOps expert can also give you flexibility and scalability. Your business may not require a full-time DevOps engineer all year round — a fractional expert allows you to scale your DevOps support up and down as needed, whether you're preparing for a major product launch, migrating to the cloud, or improving security compliance. A DevOps expert can give you an objective, fresh perspective.

Question 15

Why is mentorship important in a DevOps career and how does it work?

Accepted Answer

**Quick answer:** mentorship in DevOps works best as guided discovery, not answer-giving — a mentor listens to understand what actually motivates the person they're helping, then steers them toward finding their own answer rather than handing it over, because lessons learned by working through a mistake stick better than ones just told to you.

Mentorship — what's it really about? Well, if you're an old fart like me — I'm over 50 now — I want to help you. I don't care how old you are, age is just a number, but if you're starting out in something, I want to help you progress, and the best way I can do that is by listening to you. I want to understand what drives you, what motivates you, and as a mentor I need to understand that so I can help you and steer you the best possible way.

Being a mentor is about using your life experience, listening to what somebody else needs help with, and then giving them gentle guidance so they can find the answers themselves. We don't want to just tell them the answers — not only would that be too easy, but if you get stuff easily it can be forgotten again or taken for granted. It needs to be worked at, and by using our experience we can create situations where the person we're mentoring can learn and find out the best way. It's okay to make mistakes — that's the best way of learning — but with a mentor you can make fewer of them.

So let's grow together.

Question 16

What do you need to know before building a tech startup in 2025?

Accepted Answer

**Quick answer:** before writing any code, validate the idea (a landing page collecting real email signups is a stronger signal than a friend saying "that sounds cool"), build a minimum viable product that doesn't need to be real software, then choose a tech stack based on developer availability rather than novelty, and build DevOps and CI/CD practices in from day one so scaling later doesn't mean a costly rebuild.

Software development is expensive, so before we go into that let's talk about everything you need to know before you start developing software.

**1. Idea validation**

Before you spend a day, a week, a minute, or even some pound notes on your new idea, it's vital that you get it validated first. Sounds obvious, but so many people skip this step. You need to know that somebody else is actually going to find your idea useful. How would you tell somebody about your idea without worrying they'll run off with it? Well, they're not going to run off with it — execution is very, very hard, and as we get into this you'll find out how hard that is.

Telling people what your idea is — if they go "oh yes, that's amazing," that's validation. It's not "oh, I'm going to go do that myself," because that's really hard to do, as we'll get into. So tell people what your idea is and gauge their reaction: is it interesting, do they find it interesting, or do they just shrug? You need to ask a lot of people.

Two good ways of asking: have a landing page. The landing page should say "here's a service or product I want to offer, would you be interested in it — give me your email address." You'll be surprised how hard it is to get email addresses off people, even if they like you, so if they sign up off a page like that, that's a very strong validation signal. Other options are market research techniques, like looking at Google Trends and keyword research — are people even looking for the idea you've had? If they are, you'll see evidence of that.

Of course, the strongest evidence is somebody already doing it — are there competitors in the market already? This isn't necessarily a problem. How many times have you gone down a high street and there've been four restaurants all on the same street? That's fine — they all offer something different while being in the same place, but they're basically offering the same product: food. If your idea is related to food, maybe it's a new restaurant offering Indian food with some Japanese influence — you get the point, there's already going to be competition in one way or another related to your idea.

If there isn't any competition and you can't find any, I'm sorry, that's not validation — that's probably a bad idea. Somebody's probably tried to do it before, lost a load of money, and that's why you can't find any evidence of it. So look out for competition. Once you've validated your idea with some Google Trends research, some keywords, a landing page collecting email addresses, and checked whether there are any competitors out there, the next thing you need to do is build a minimum viable product (MVP).

**2. Minimum viable product**

An MVP doesn't necessarily need to be any software whatsoever. I've seen minimum viable products that were on a notepad — just enough to give the illusion of what the app could do. If you're talking about an app that identifies pictures as you upload them, you can probably mock something up pretty quickly that doesn't actually work but gives the illusion that it's working. Again, this is just to get people to validate your idea. By having the landing page, the wait list I mentioned earlier, and an MVP, you should get a pretty good idea of whether you're going to have enough people interested in your idea to make it worthwhile. It's worthwhile even if only one person wants it, but it's a lot of effort to go to for just one person.

**3. Technical foundation**

So we've got the idea validated, hurrah, and we know what our MVP should look like — let's talk about the tech stack. What I mean by a tech stack is the technology you and your developer team are going to put together. If you're a developer, you'll probably already have a good idea of what that should look like; if you're not, I've got another video on tech stacks for startups I'll link in the description. Essentially it needs to be something where you can find a good supply of developers — there's no point going for something obscure. You'll find it easier to hire Python, PHP, or JavaScript developers than, say, COBOL developers — they exist, but they're harder to get hold of, and if they're harder to get hold of they'll be more expensive, and as a startup, costs matter.

Next up is infrastructure decisions. Infrastructure needs to be supportive when you're small and supportive when you're big, to give you room to grow — the best thing about startups is scaling up, but you want to scale in a way that doesn't cost an arm and a leg and stays easy for your developers and infrastructure people to change. If you start small, you can start off with something like serverless or very small servers that don't cost you very much, then scale up to bigger servers or different technologies as you go. Depending on the technology stack you've chosen, this can be easier or harder, but it's another consideration for scaling — you don't want to spend a ton of budget re-architecting the entire infrastructure just to get a little bit bigger, so have a little forethought before you even get started.

Your scalability considerations should cover: how many users do you expect to have, and how many simultaneous connections do you expect? Both will tell you how much scale you need. And because I'm in DevOps and operability, I wouldn't go very far without saying you need a DevOps pipeline. Some of my customers use a DevOps pipeline to test and build their new release, then use another pipeline to deploy that release to the production servers, with testing on the test servers along the way — all automated so it just relies on a button press, empowering them to release when they need to without relying on someone else to hand off the deployment. All this saves you time and money.

**4. Development strategy**

You've probably heard of Agile methodology. What that means is you don't know all the answers when you start — simple as that. One of the Agile principles is "we value working software" and use that as a definition of progress; there are 11 others, you can look up the Agile Manifesto. Because we don't know exactly where we're going when we start out, we just know the direction we're travelling in, our MVP.

Then there's sprint planning. A sprint is a way of breaking up work — you don't necessarily have to use sprints in the initial stages if you don't want to, but you've probably heard of a kanban board or to-do board: what needs to be done, are we doing it, and has it been done. It's a visual representation of the amount of work currently being done (you don't want too much of that at once) and what's actually been done, which you can celebrate. Sprint planning just goes one stage further and says we're going to pick these items and do them in the next week or two, however long the sprint is, and at the end of the sprint you can see how well you did against what you planned, celebrate what you've done, and move on to the next sprint.

Also, CI/CD pipelines — continuous integration and continuous deployment. This means you want your code in production, where somebody can use it, as quickly as possible, hopefully multiple times a day depending on your deployment cadence — after all, once a developer's done a thing, it's of no value to anybody until it's deployed. And lastly, quality assurance: you need to make sure testing is in place so you don't break stuff as you go. As part of the CI/CD pipeline you can have automated tests, so that when somebody commits code to a repository it's immediately tested, and if any of those tests fail it doesn't get deployed — it doesn't break anything, it just gives feedback as quickly as possible back to the developer so they can fix it. That way you can keep moving forward with new features while fixing bugs as soon as you find them.

**5. Launch preparation**

Being Agile, your software should be working all of the time, but you'll want to invite your beta testers as early into the process as you can, well before the MVP is ready for general consumption. Your beta testers can test whether stuff is working the way they like, give you suggestions and feedback, and you should provide a feedback channel for them — either speak to them daily or give them a way to send feedback directly to your developers — so you know what's going right and wrong as quickly as possible. The beta testers can guide you on what's working well and what's working badly.

Also, marketing fundamentals: once your beta tests have got to a certain stage, and you think the software is good enough (not finished, just good enough), you can work on your marketing and spread the word. There should already be a market ready for this software — that's the whole point of doing the market research in the first place. So all you're doing is telling everyone who registered interest that you've now got something to show them — that's your big launch. If you've got enough interest to start with, it should be a great and glorious affair.

The final note on launch preparation is legal consideration. Some of what you're doing may have legal implications, so it's important to check you're not breaking the law in any area, or if it's a grey area, get it clarified by your legal team before you go ahead — things like copyright infringement and so on.

And so there we have it, my list of things to do for startups. Don't forget those metrics to track: how many people are logged in at any time, how many members you've got, how many of those are paying for membership — all good things to see that you're on the right track. If you want more answers to your questions, you can hit me up directly either through tech-answers.club or on my LinkedIn, and I'll be happy to help you out. And, as always, may all your deployments be smooth.

Question 17

Why do most tech startups fail and how does DevOps help prevent it?

Accepted Answer

**Quick answer:** most tech startups fail from operational, not product, problems — no automated testing or deployment process, so a change that should take minutes takes days, and a scaling spike becomes a rebuild-from-scratch crisis instead of a config change. DevOps culture (automation, CI/CD, infrastructure as code) turns those failure points into routine, low-risk events.

Hey everyone, welcome back to the channel. I'm Neil Millard, and today I'm talking about something that can make or break your startup: DevOps culture. I know, what a surprise, a DevOps channel. Anyway, if you're building a startup, or thinking about it, this video could save you months of headaches and thousands of pounds. About 50% of startups fail within their first 5 years, and for technology companies, inefficient development and deployment processes contribute to those failures. Today I'm going to show you how DevOps culture can help you avoid these common technical pitfalls. Let's get into it.

**A cautionary tale**

Let me start by telling you what DevOps culture is. From my consulting days, I once worked with a startup that had to rebuild their entire infrastructure from scratch 6 months after launch, because they didn't implement proper DevOps practices from the beginning. This cost them a fair bit of money and 3 months of time during which they couldn't deploy any new code, because they had to rebuild everything. 3 months is a long time when you're a startup.

**Continuous improvement and breaking down silos**

DevOps culture isn't just about tools and automation, it's about creating a mindset of continuous improvement — improving everything, not just the code, but the processes within the business too: how cash flows in, how cash flows out, reporting, all sorts of things. If you can measure things and continuously improve them, you can get better.

DevOps culture also tells us about breaking down barriers between development and operations — and maybe there are other barriers in the business that need breaking down as well. In the early days of a startup the team is usually quite small, maybe two or three of you, so there aren't going to be many barriers between you — in fact some of you'll be wearing multiple hats. But as the team grows, you want to instil a culture of cooperation and communication, so that as the business continues to grow, you're all still talking to each other and cooperating.

**Building in scalability from day one**

DevOps also talks about scalability — building it into your DNA from day one. You've got big goals, so you need to structure things so they'll scale easily, otherwise you're just setting yourself up to fail.

**Quick iteration and feedback**

Here's why it matters for startups specifically. In the startup world, being able to quickly test ideas and pivot based on user feedback is crucial. DevOps culture enables this through automated testing and deployment, continuous integration pipelines, and feature flags for controlled rollouts. I've spoken about all of these in previous videos — I'll dig out some links and put them below.

Here's a quick example of how this works in practice: a CI/CD pipeline with automated testing built right in. It builds the product, runs the tests to make sure everything works, then deploys it to a server. After it's deployed, we use something called blue-green deployments, so we can deploy to a brand new server and then throw some more tests at it — integration tests, smoke tests, that kind of thing. They're a bit black-box, but they make sure everything works after it's actually been deployed, and once we're happy with all of that, we switch it into live.

**Cost efficiency**

Now let's talk money, everyone's favourite topic, me included. DevOps culture can dramatically reduce your burn rate — the amount of money you get through in any given day, week, or hour. Automation reduces manual operations work, which means it reduces costly mistakes. With infrastructure as code, everything's visible, and you can see what a change is going to do before it happens — or if it blows up, you find out quickly — which means we can catch issues before they become expensive problems.

Let me share some real numbers from a recent client. They had a bunch of servers running and didn't really know what they were doing with them — well, they knew what they were doing, but they didn't know whether the servers were actually busy or not. Through monitoring, we could see how many servers were busy and how many they didn't need to pay for at certain times. What the client decided to do was scale right down to just five servers at 6pm, then gradually scale up during the day as it got busier, up to a comfortable maximum — in this case about 50 servers. That way they weren't paying for servers overnight when they weren't doing anything.

**Scalability**

This is where it gets exciting. When your startup hits that hockey-stick growth, you need to be ready — you need to be able to scale systems really fast. If you've already got infrastructure as code, tweaking a number from 5 to 10 is easy, and bang, you've scaled up automatically. That means infrastructure as code is your best friend, and common scaling mistakes can be avoided by being prepared — you know you're going to have to scale, so plan in advance.

**Team culture**

Finally, the secret sauce to successful startups isn't just their tech, it's the people. You need to hire right, and you need to have the culture right. DevOps culture means you attract better talent — you can say "look, we've got processes that deal with scalability, monitoring, and communication." It reduces burnout because you're working together through problems — you don't feel isolated, you don't feel like you're on your own — and it creates an ownership mentality. If you're a small team sharing all of the problems as well as the big wins, then everybody gets a share of the good and the bad, and ownership becomes yours.

So if you're building a startup, or thinking about it, don't wait to implement DevOps practices — start now. Drop a comment below with your biggest DevOps challenge and I'll personally respond with some advice. Don't forget to check out tech-answers.club, who are sponsoring this, for more detailed guides and resources, and it doesn't hurt to hit subscribe and the notification bell so you know when I come out with more content. Thanks for watching, and as always, I hope all your deployments are smooth.

Question 18

How do you track technical debt and measure DevOps delivery performance?

Accepted Answer

**Quick answer:** track the four DORA metrics per component, not just for the system as a whole (lead time for changes, deployment frequency, change failure rate, and recovery time), and separately track planned vs. unplanned work — reducing unplanned work (bugs, hot fixes, interruptions) is usually the fastest way to both pay down technical debt and improve your DORA numbers, since they're the same underlying problem.

You want to continuously deploy, you want to deploy faster, but there are two things in your way. There's the CAB, the Change Advisory Board — they want to slow you down and make sure everything's measured. And there's technical debt, which makes everything slower, like walking through treacle when you're developing code. So today I'm going to talk about how you can go faster, how we can work with the CAB, and how we can reduce technical debt. Let's go.

If you've got more questions like these, come over to tech-answers.club and ask me there — our community is very welcoming, very friendly, and we can help each other out.

**What is the CAB?**

The Change Advisory Board exists at a certain level of an organization to reduce the amount of disruption that changes give the business. At best, if disruption occurs, customers can't do what they need to do — they can't run their reports or whatever else. At worst, you're working for an e-tailer and something happens to production, meaning customers can't order stuff — you're turning money away, and the business really dislikes that. So the CAB is there so you can advise the rest of the business on what you're changing, what the benefit will be, how it could go wrong, and how you'll mitigate it if it does.

But when we're doing continuous deployment, that goes against the grain of that a little bit, so we need to demonstrate to the board that our changes are standard, routine, and automated, and that if something does go wrong we've got an automated fix straight away. Sounds easy, but how do we get there?

**Planned vs unplanned work**

Changing our code isn't easy — we've got several constraints pulling on us. We've got planned work, which is new features we want to put into the code, and unplanned work, which is stuff like bugs and hot fixes. We can analyze what's going on by looking at our stats and therefore reduce the unplanned work, because we don't really want to keep going back and fixing stuff that should already be fixed.

**The DORA metrics**

How can we analyze what's going on? From a DevOps perspective we've got DORA to help us — the DevOps Research and Assessment group, set up by Google about 10-12 years ago. They give us a bunch of statistics we can measure to work out where we are and how fast and stable we're going. They break down largely into two categories: throughput, how quickly we can get stuff done, and reliability.

Throughput measures the velocity of changes being made, and we assess it with two measurements. Change lead time is the amount of time it takes for code to be committed until it gets to production — shorter is better. Deployment frequency measures how often we deploy — once a day, once an hour, once a minute? The quicker the better, and the more routine we can make it, the more we can just keep running. After all, if a deployment only takes 5 minutes, fixing something with a hot fix and deploying it is a relatively low-stress task — if it all goes wrong, you can roll it back within 5 minutes too.

For stability, we've got two main measures. The change fail percentage is the number of deployments that fail versus the number that work, expressed as a percentage — if we do 100 deployments and one fails, our fail percentage is 1%, again lower is better. Failed deployment recovery time is very important, especially for the CAB — that's how long it takes to recover to a known good state following a failed deployment, and this hopefully is measured in seconds, not minutes (if you're in minutes, you're in trouble).

**Tracking metrics per component**

This is all good in theory, but how do we implement it? For each application you're deploying, you should have those four stats — not just four stats for the whole system, but four for every single component. If you've got a three-tier application — a web front end, a database, and a middle layer connecting the two — then you want four stats for each of those three components: how stable is a database change, how stable is an API or middleware change, how stable is a front-end change. You can track each one separately, since you might have different teams working on each, so being able to track each separately helps everyone know where they are.

**Moving the needle**

So we've got the stats — how can we improve them? This is where unplanned work comes in. As a quick refresher: planned is stuff you want to do, unplanned is stuff you didn't plan on, like hot fixes, bug fixes, and interruptions from the business. We can categorize the work, which gives us another stat showing how much work we wanted to do versus how much we didn't, and use that to get the right staff with the appropriate skills to go faster.

The important thing is that with these stats we can make things visible — put them on a dashboard, because what gets tracked gets improved. If the team can see them, they can share their own ideas about how to make things better. If we're tracking these stats, the result should be less unplanned work, so we can focus on the fun stuff — the planned work we actually want to do.

**Reducing technical debt**

As part of this we also want to reduce technical debt. Technical debt is where code has been implemented and doesn't really work as well as it could, because it wasn't planned that way — most technical debt isn't actually planned, it's the result of somebody doing the best work they could within the time constraints they had. But as the system grows, like a bowl of spaghetti, that tiny little bit is no longer fit for purpose and needs to be chopped out, recoded, or rewritten to make everything else better.

A good example of technical debt is a piece of code that needs to be touched every single time something changes in the codebase — maybe you've got a list somewhere that's manually typed in, and every time you add something you have to go update that list. That's an extra 5 seconds you're not getting back, but once you know the list is really long, you can probably write some code to update that list automatically when you add new functions — that's what I mean by rewriting it. If we're reducing technical debt and reducing unplanned work, we should see improvements in our DORA stats too: better stability, fewer bugs, fewer failed deployments, and a reduction in deployment time.

**Common pitfalls to avoid**

- **Setting metrics as the goal.** If you make broad statements like "every application must deploy multiple times today," chances are teams will try to game those metrics, which is probably not the result you want. Track individual metrics per application, and remember that trying to measure a complex system with just one number doesn't work — people will work out how to reduce that number without making the real change you're actually going for. Identify multiple metrics that matter, including ones with a healthy amount of tension between them.
- **Letting industry standards block your progress.** Some people will say "well, you need to have a CAB." That's true, but don't use that as an excuse not to bother — use it as a strength you can work with. The CAB is there to help keep business stability, and you want that stability so you can get paid, so work with it rather than treating it as a shield.
- **Making disparate comparisons.** You might have lots of stats, but remember those stats are quite discrete in what they're measuring — a piece of middleware software behaves differently to front-end software, so you can't really directly compare the two, especially if you're using different programming languages for each layer.
- **Siloed ownership.** Share all four metrics across the deployment, operations, and release teams to encourage collaboration and shared ownership. The metrics don't belong to any particular team — the teams should work together to improve the statistics. Deployment stats are the responsibility of everyone from developers through to testers, and you should avoid team competition — these stats exist so the business gets better and deployments improve, not so one team can say "our unplanned work is lower than yours." The point is to make the whole business faster, not to one-up another team.
- **Measuring instead of improving.** If it takes a lot of effort to come up with a measurement, spend that effort improving the thing instead, even if you don't know the exact number. For a small organization with limited time and budget, you want the improvement, not necessarily the precise measurement. If you know intuitively that doing something will make a process faster, don't worry about knowing the exact number — just make the improvement. If you know something's going to reduce deployment frequency from once every two weeks to once a week, just do it.

And that's all I have for you today. Thanks for asking the questions on the forums at tech-answers.club, and I'll see you soon in the next video. Till then, may all your deployments be smooth.

Question 19

Why does the quality of your AI prompts determine the quality of the output?

Accepted Answer

**Quick answer:** an LLM is optimised to produce grammatically plausible text, not factually correct text — it doesn't inherently know the difference between "the dog walked down the street" and "the dog flew down the street," both are valid English. A vague or under-specified prompt gives the model more room to fill gaps with something plausible-sounding but wrong, so prompt quality directly controls how much of that gap-filling happens.

Prompt engineering is trying to get the right answer back out again, and that can take a lot of work on our part to get the correct answer without any hallucinations, or "boasting" as we might call it if it were a human. That's a slightly different thing to machine learning — machine learning is really quite niche and locked down to a specific task, but this does mean that LLMs have quite strange limitations.

They can create plausible stuff — after all, an LLM is originally designed as a translator, and its whole purpose is to create a line of text that's correct from a grammar point of view, not correct from a context point of view. You can say "the dog has walked down the street" — that's complete, true, and plausible. "The dog is flying down the street" is also valid as English, but complete rubbish, because we know that dogs can't fly. The computer doesn't necessarily know that, so it can make stuff up — it doesn't really have true awareness. There's a lot of things we infer just by being alive that an LLM doesn't know about, because it's only ever read stuff.

They're also very computationally expensive to run, because they're doing lots and lots of calculations — we've modelled the brain, and brains are very efficient with their energy, whereas computer silicon isn't. And, like I've already mentioned, LLMs require careful prompt inputs in order to get the right response out.

Question 20

What are the top tech questions developers are asking in 2025?

Accepted Answer

**Quick answer:** in 2025, developer questions cluster around a few themes: which platform-as-a-service to deploy on (Heroku vs Railway vs Render), when to scale horizontally vs vertically, whether an internal developer platform is worth the setup cost for a small team, and how AI tools fit into an existing DevOps workflow without replacing the people running it.

**Platform as a service.** Heroku gives you a very easy way of deploying your application — you give it a git repository, you've got some special config in there, and it installs it for you and gives you a server address. Happy days, minimal effort on your part. There are a couple of other companies that do a similar thing — Railway and Render. Both look different, both do things slightly differently, and both have simpler payment plans, and as a platform as a service they'll give you the extra add-ons you want — need a database, sure, just add it on, need more CPU, sure, just add it on.

**Horizontal vs vertical scaling.** Horizontal scaling is where we take the same cookie-cutter process — be it a server, a virtual server, or a container — and stamp out more of them to give us more capacity, so we can go from two servers to four to eight to 32, however many it takes for the workload. Vertical scaling is where we make the resource bigger — give that virtual server more memory or more CPU. There are pros and cons depending on where you are and what layer you're working at — it's quite common for web or proxy servers to scale horizontally, but for database servers it's more common to scale vertically, and of course you can blend the two.

**Configuration management.** Another tool that lets us personalise the server — say we've got a Python app, we make sure Python is installed, then install a virtual environment and a package manager like pip or poetry to install all the dependencies, install a web server, and once that's done we can get the thing running. This reduces toil and manual work.

**Internal developer platforms.** As part of my operability, DevOps, and SRE role, I want to present a situation where everything is self-service: the developer says "I want to start a new project," the documentation says "here's a template, off you go." The developer says "I want to deploy it," the documentation says "go to this URL on our portal, click this button, feed in some information, and it will deploy it for you." There's a pipeline behind the portal that builds and tests it for you, so all of that extra cognitive load is taken away, and everything and everybody is just a little bit happier.

This sounds amazing to the developer, but there's a catch — an internal developer platform (IDP) might not be the right solution for your organisation. It could be over-engineering what you already have, it could be too complex, and there are always budget and team-size constraints. IDPs take a lot of effort to get working — I was on a project where it took about 18 months from inception to the first live service. That's something your business might not be able to support. Nine years on, a team joining that service can now pick up their tickets and deploy a fully working service within 3 weeks — pretty impressive, but that's a lot of groundwork to lay first. Once it's up and running, 3 weeks is great, but it relies on a lot of foundation your business might not be ready to invest in. If you've only got a team of two developers, that's a lot of hassle to go through for two people — that doesn't mean you shouldn't use guardrails or CI/CD pipelines, but you don't have to go as far as a full internal developer platform.

**Will AI replace you?** Probably not. With technology it's always about doing or delivering more with the same resources — we have a food processor at home, and even a klutz like me in the kitchen can make mayonnaise with it, producing something I couldn't make without that technology. AI is the same — it's not about replacing you, it's about augmentation, and focusing on work you wouldn't otherwise get done. On larger teams I've often paired with somebody else, either with the same skill set as me — DevOps pairing — or a different skill set: maybe a tester if we're writing tests, a programmer if we're creating programming guidelines, or someone from the logging team if I'm setting up more alerts. Automation, to me, is the heart of DevOps, SRE, and platform engineering — providing tools and functionality so developers have an easier life. What's the one thing I can do today to make tomorrow easier for everybody else, including myself?

**Service industry transformation.** We've already got lots of robots in factories doing boring, repetitive, precision work — making a car out of metal is quite simple, but with fabric it's all a bit wobbly and tricky, so there's a service industry transformation coming too. This will disrupt the jobs market like the Industrial Revolution did several hundred years ago. New roles will be created because somebody's got to look after all these robots.

And this is why I'm here — I want to be more useful to you. If you've got any questions about SRE, DevOps, or platform engineering, come along every Wednesday — I run a free Q&A and the link is at tech-answers.club. I'd like to finish with a joke: a developer and a system administrator walk into a bar. The barman says, "What is this, some kind of DevOps joke?" And they reply in unison, "It's not a joke, it's a collaborative deployment," then proceed to spend the next hour arguing about who's going to write the infrastructure code. Maybe not that funny, but jokes and humour are what get me through the day. Until next time, see you at the Q&A sessions every Wednesday over at tech-answers.club.

Question 21

What is Ansible and how do you use it for configuration management?

Accepted Answer

**Quick answer:** Ansible is a configuration management tool — it excels at keeping existing servers' software and configuration up to date (install/remove packages, update config files, run routine housekeeping), stored as playbooks in git so it counts as infrastructure as code. For provisioning the underlying cloud infrastructure itself, Terraform is generally the better fit; the two are often used together.

Ansible, yes, it's a tool for configuration management. It can be saved into git repos, so it counts as infrastructure as code. It can also manage infrastructure like AWS, but I would recommend using Terraform for that purpose — Ansible really excels at looking at the configuration and keeping everything up to date on your servers. It can install, remove software, update configuration, and other housekeeping tasks.

**What is Ansible made up of?**

- **Inventory** — that's your servers.
- **Playbooks** — a link between the servers and what you want them to do.
- **Roles** — a group of tasks.
- **Tasks** — what actually configure the server.
- **Variables** — because we want to keep the variables separate to the code.
- **Groups** — where we can group the hosts together.

Question 22

What is AI and how does it work, from machine learning to large language models?

Accepted Answer

**Quick answer:** machine learning is teaching a computer to find patterns in data through examples rather than explicit step-by-step instructions — supervised (learning from labelled examples), unsupervised (finding structure in unlabelled data), or reinforcement (learning from reward/penalty feedback). Large language models are a specific, much larger case of this: trained on huge amounts of text using transformer architectures and self-attention, they predict plausible next words rather than "knowing" facts the way a database does — which is also why they can confidently generate wrong answers.

AI is a bit wonky sometimes — what the heck is it, where did it come from, what does it even do, how does it work? In this video I'm going to go through these lovely questions, telling you that it's not magic, and I'll show you exactly how it works.

Before I do that, though, just a quick mention of tech-answers.club — deploying code, creating code, is hard work. As an expert in CI/CD, observability, and DevOps and things, I've created a community so we can come together and help each other out. So if you're on my channel, you're probably in DevOps or interested in DevOps.

**Why does this matter for DevOps?**

AI can help us in a number of ways. Yes, it sort of helps with creating code, but it can also analyze lots and lots of data — that's what it's really good at, so it can analyse data and then give us trends. It can look at other things and code, and analyze it and tell us whether there are any security flaws in there — it's really good at sucking in information and summarizing.

It's also important to DevOps engineers from the other side of the fence — we've got our colleagues over in big data and machine learning, and they want infrastructure to be able to run their models and hold their data. The other side of the coin, as an operability engineer, is providing those environments to those very learned data colleagues of ours.

So a quick overview of AI history and what it can do for us — we might get to a point in the future where we wake up and the DevOps pipelines have been optimized overnight, your code's been reviewed and it's given you some pointers. Yeah, it's still not so great, is it, so maybe we'll just relegate it to making us coffee, but you'll have to go get it yourself. But we're in 2025, who knows — we've got AI agents (look at my previous video for that sort of stuff) and they're going to transform how we work. We can use ChatGPT, Claude, and Gemini to do those things, but by working as a team, just like humans, they can accelerate their power and understanding.

In fact, at the weekend I was talking to some colleagues and they said Facebook held an experiment you've probably heard about, where they put one AI over here and one AI over there and let them talk to each other — it wasn't very long before they'd invented their own language and were quite happily conversing, and us humans didn't have a clue what they were talking about. So getting them to talk to each other is good, but as a team you need a good manager, like any kind of work group.

**Teaching versus programming**

Let's talk about why AI exists in the first place — it's teaching versus programming. When I'm a programmer talking to a computer, I'm giving it step-by-step instructions — I can't just say to the computer "walk out there and pick up a thing," that's not enough detail. When you're programming it, well, first you have to stand up — okay, how do I stand up, well you've got to move your legs and keep your balance, and once you've managed that you've then got to get into the hallway — well there's a door in the way, you've got to open the door, or the door's locked and you've got to unlock it — it's a lot of stuff you need to think about and pre-empt just to tell the computer how to do a thing. We know all of this, but we do it so automatically that we forget it's there.

How do we know it? We are taught it, through two ways. We're taught it by somebody actually showing us a thing — if you're watching videos on YouTube like this one, you've got people demonstrating how to do a thing and then you can copy them, similar to how we learn language: we listen to the adults around us and we just copy them, and eventually we work out how to speak. Walking is a slightly dodgy case, because we can see people walking and the grown-ups help us a little, but for the finer detail — keeping our balance and so on — we've got to work that out on our own, so there's a certain element of self-taught going on as well.

**How do machines learn?**

So we've got machine learning — how do machines learn? There are three main ways: supervised, like the grown-ups helping us do the thing; unsupervised, where we're just messing about trying things — you know, we've unpacked the box, pulled the tech out, and instead of looking at the manual we just push all the buttons and work it out on our own; and that's closely tied with reinforcement learning, where you do something and you get better and better through practice, and you get the reinforced message that you're getting better — like when you're riding a bike, you go a little further, then you fall off, you try again, you go even further the second time without falling off, and eventually you stop falling off. Maybe.

In machine learning terms, supervised algorithms are supervised by "here's a bunch of pictures and we're going to label them for you" — a bit like when you learn language. I remember talking to Sophie, my daughter, and she would often point at things — I'd be holding her and she'd go "that, that, that," and I would tell her what it is — that's a light switch, that's a light, that's the carpet — and over time she would learn these things through the labels. The goal is that they understand the picture through the label, so that when you show it the label, or the picture, either way round, it can then give you the other half of that particular thing.

Unsupervised learning is where there's a data set and it doesn't have labels — I know, right, you didn't see that coming. The goal here is to infer what stuff is through a natural structure — that sounds like complete gobbledygook, but I'm sure it'll become apparent shortly.

Reinforcement learning is where we get the AI to make a sequence of decisions and it learns to achieve a goal without any particular direction — the closer you get to the goal, the more we give you a prize. So it makes decisions following a policy, takes some actions, and if the action was good then it's rewarded, and if the action was bad then it's not rewarded. A bit like dog training, I suppose.

**Real-world examples**

This is great, but give us some examples of real life, I can hear you saying. I use AI every day, whether I like it or not, because there are various tools that use AI. Part of my job is looking after web servers — lots of web servers — and we look at the traffic that comes in and classify it. This could be identifying where somebody is based on their IP address, and whether the account they're attempting to access is a corporate account or a personal account, and whether they've accessed from that location before, so we can have live analysis. You've probably seen the emails, right — "we've just detected a login from Timbuktu" and we're alerting you to it, because normally you're not on holiday in Timbuktu, normally you're sitting in London or Paris or something. By having AI monitor the logs we can generate alerts like that. We can also go wider — we can see if the same IP address is being used for multiple logins, and that might flag fraud detection.

My favourite example has got to be Asda, a supermarket in the UK — you've got those scales in the vegetable aisle, you've picked up some bananas, put them on the scales, and there's no panel to tell the scales what you've just put on there, but there's a camera. It can see — amazing, so it's picture recognition. It looks at the picture, and if it knew my name it would say "Neil, you've put some bananas on there, let me weigh them and print out a ticket for you" — there's a ticket with bananas, and I'm like, fabulous, off I go. I haven't got to faff about with a user interface trying to find "fruit, yellow fruit, banana," or any of that — it just prints off the ticket, which I think is an awesome use for AI.

**Supervised learning models**

So machine learning is what we're talking about — how to get a machine to learn something — and we've already mentioned supervised, unsupervised, and reward-based (reinforcement) learning. Let me give you an example of some supervised learning models — these are really great sounding names, academics love them, naming things is hard, what can you do.

- **Linear regression** — sounds very posh, but really it means "here's a sequence of stuff, guess what comes next," like a quiz question — what's next, 1, 1, 2, 3, 5? The Fibonacci sequence. Or if you're predicting trends, it can look at a graph going all over the place and predict or extrapolate the trend. You can get it to either predict new numbers or flag if something doesn't fit.
- **Logistic regression** — used for binary classification tasks, quite literally is it a yes or is it a no, and it estimates the chances of yes or no based on the inputs you give it. You can label it because it's supervised — if you get all these numbers that's a yes, if you get all these numbers that's a no, and you give it thousands of examples and it learns.
- **Decision trees** — these models predict the value of a target by learning simple rules inferred from the data, so it can come back with a more varied answer than just yes or no — a percentage, say 40%, or something like that.
- **Random forests** — an ensemble (posh word) of decision trees, typically used for classification and regression, for model accuracy and overfitting control. Overfitting is where, if you train something, you've got to watch out for it fitting the training data too closely. There was a picture-recognition experiment designed to spot tanks — they showed it pictures labelled "tank" or "no tank," and when they came to test it, there was a picture with no visual indication of a tank, but the person who took it knew there was a tank on the field at the time. It turned out the computer wasn't spotting tanks — it was spotting whether it was a sunny day or an overcast day, because it just so happened all the tank pictures were taken on a sunny day. So overfitting is something you've got to watch out for, because it can make your model very rigid and unable to pick up anything new — with a random forest you can throw some extra stuff at it just to widen the parameters a little.
- **Support vector machines (SVMs)** — effective in high-dimensional spaces. A dimension is an input coming into your neural network or machine learning model, so if you've got a lot of inputs coming in, an SVM takes all of the inputs, processes them through a system, and comes out with an answer, usually a classification — labelling pictures of cats versus dogs, say.
- **Neural networks** — a lot of the other models sit underneath this, in a sense, and they enable you to encode a large number of functions. Where SVMs are essentially plotting a line through data points and classifying which side you're on, a neural network mimics how our brains work and enables you to encode much more complex information — rather than a straight line, you can have a wiggly line, circles, all sorts, based on having more and more neurons, which gives you the ability to encode more complex information.

**Unsupervised learning models**

There's less to cover here, but we'll go through it quickly.

- **Clustering** — stuff like K-means, hierarchical clustering — sounds impressive, but it's where you group stuff together, a type of classification.
- **Association** — finds rules that describe large portions of the data, like looking at a load of Twitter/X posts and deciding whether people are happy or sad.
- **Principal component analysis** — a statistical procedure that uses an orthogonal transformation to convert a set of correlated values into a set of uncorrelated values. It looks like complete gibberish, but these are very good for noisy environments — really grainy photos and so on, it can still figure it out.
- **Autoencoders** — a special type of neural network that takes in a lot of unlabelled data and just kind of remembers it, which is sort of the basis for how a lot of large language models work.

**Reinforcement learning models**

- **Q-learning** — a model-free reinforcement algorithm that learns the value of an action in a particular state — it comes out with a state and we tell it how good it is, sometimes called a fitness function.
- **Deep Q-networks** — combines Q-learning with neural networks, making it more complicated.
- **Policy gradient methods** — use the parameters of a policy directly, as opposed to estimating the value of the actions, so if you've already got a program a programmer wrote that takes these inputs and produces this output, you can feed those same inputs into something like a neural network and reinforce it based on how close it gets to the existing model.
- **Monte Carlo tree search** — Monte Carlo is a reference to casinos and gambling, and is often used to create true randomness — random number generators on computers aren't truly random, it's a calculation, and true randomness takes a lot of work (measuring lava lamps and so on). With a Monte Carlo tree search we're throwing lots of true random stuff at it so it can work out the answer based on how well it's doing — useful for games like Go or chess.

So, in summary: machine learning is where we get a load of data, throw it at a machine, and tell it how the answer should look — is it right or wrong (supervised), or is it just learning a whole load of stuff and figuring it out afterwards (unsupervised/reinforcement)?

**What makes large language models different**

The first thing is scale and architecture — most large language models have effectively read the entire internet, that's a lot of scale, whereas traditional machine learning typically focuses on specific, narrow tasks: classify this picture library, or classify whether this email is spam. LLMs also use massive transformer architectures (more on that in a bit) and they learn language through self-attention mechanisms, allowing them to understand context across long sequences of text.

The training approach is also quite different — machine learning is often supervised with labelled data (this is an image of a cat, this is an image of a dog), whereas with language models we're just throwing lots of words at it and it's inferring the context, structure, and grammar through its own labelling system. What this really means is we have no idea exactly how it works, and it's got a general ability — machine learning gives a model one specific thing to do (is this email spam, is there a tank in this picture), whereas with LLMs we're giving general sentences and we want words back that sound right — which is great, because it can write code, translate languages (the original point of these things, believe it or not), summarize text, create gibberish or "creative output," and reason about problems, all within the same model — but again it's not very specific, it's quite generic about what it "knows."

The biggest thing to note is that as large language models get bigger and can handle more context, they develop emerging properties — because it's a large neural network, it can do and remember lots of things, and it pushes our expectations by coming up with surprising answers we didn't expect. Again, that comes back to us not truly knowing how it works — we don't even fully know how the thing between our own ears works. So we have to take a different approach with large language models — because it's not very specific, we have to get better at asking questions.

Computers are very good at remembering things, and that's lovely — we're all quite good at remembering things too. Ask you in a pub quiz: when did Princess Diana die, what year was it? You go, "yep, I know the answer" — it's in there somewhere, it's totally 1997, there you go. Prompt engineering is trying to get the answer back out again, and that can take a lot of work on our part to get the correct answer without any hallucinations (or "boasting," as we might call it if it were a human).

This is a slightly different thing to machine learning — machine learning is really quite niche and locked-down/specific, but this does mean LLMs have quite strange limitations. They can create plausible stuff — after all, an LLM is originally designed as a kind of translator, and its whole purpose is to create a line of text that's correct from a grammar point of view, not correct from a context point of view. "The dog walked down the street" is complete, true, and plausible. "The dog is flying down the street" is also valid English, but complete rubbish, because we know dogs can't fly — but the computer doesn't necessarily know that. So they can make stuff up — they don't really have true awareness, and there are lots of things we infer just by being alive that they don't know about, because they've only ever read stuff.

They can also be very computationally expensive to run — because they're doing lots and lots of calculations. We've modelled a brain, and brains are very efficient with their energy, whereas computer silicon is not so efficient, and like I've already mentioned, they require careful prompt inputs to get the right response out.

**What is a transformer?**

No, not from another planet, they don't turn into cars — they just get data in and transform it into something else. They're used a lot in large language models. Let me explain with a simple analogy: imagine you're at a huge conference, a big round table, loads of people, everyone's having conversations, it's really noisy, sounds like a nightmare. People are looking for attention, and attention, when someone's talking, is acknowledged by eye contact — you can gauge that someone's listening to you because they're looking at you.

So when someone speaks at the table, you don't pay equal attention to everybody — you mainly focus on the people relevant to what's being said, though you might glance at someone who made a related point earlier to bring them back into the conversation. In transformers it's all about this **self-attention** — each word pays a different amount of attention to the other words in the sentence. My example earlier — "the dog was flying down the street" — we want to pay attention to "dog," "flying," and "street"; we're not really worried about the rest of the words, they just give a little more context.

We've also got a certain amount of **parallel processing** — computers can multitask, they can focus on many conversations at once, so we've got this huge conference table with lots of conversations going on, whereas as humans we use our attention for eye contact and listen to one person at a time. Parallel processing enables the machine to listen to everybody all at once and take in all that information — though that has some drawbacks: older systems processed words one at a time, like a single person trying to follow multiple conversations by running around the tables, whereas newer systems, transformers, process everything at once — like having a conversation with multiple people and watching different parts of it simultaneously, which is difficult for us to get our heads round.

They also have **positional understanding** — just like knowing someone spoke at the start or the end of a conversation, transformers add a positional encoding to each word, so it knows whereabouts it is in the sentence, like giving people a seat number, and remembering the exact order every word came in. With all of that, it's effectively labelling the entire corpus of information coming in, so it can spew it back out again — though you can probably see the problems with this: if it's "listening" to multiple conversations at once there can be crossover you may not want, which is partially why AIs can come out with rubbish.

The real power comes down to finding relationships between those complex sets — understanding the relationships between words, between conversations, and building a simple or complex model between those words, combining the information in new ways, and doing that over and over again until something grammatically sensible pops out. That's why, when you type something in, the AI produces the answer word by word — it's finding out what the next word should be, doing something like a million calculations before it picks the one it likes best. That's really inefficient computationally, but it happens really fast, and yet the result comes out relatively slowly — our efficiencies are just different.

What this does mean is they can take all this information in, and we can use chatbots to steer the conversation and get information out — they can analyze text, understand the context, the words, and the weighting, and then give us an analysis or a summary. More recently there's speech recognition too — because we all talk slightly differently, but it's just turning speech into text, and because it understands how text should be structured, it can therefore understand what we're saying, or at least transcribe it.

**Where to go next**

That's my brief introduction to AI. Got any questions? Hit me up below. I'd like to know what's next for you with AI — if you want to go one step further and you're a programmer, look at some of the API integrations into the chatbots, and learn more about those machine learning concepts, because it all comes down to the basics — large language models are really sitting on top of that, which is why we didn't have them earlier, we had all the machine learning first. Experiment with open-source models — you can go on Hugging Face and download different trained models, because training takes a ton of resource, even more than running the thing — or run something locally on your machine, like Ollama, which will run certain models and let you experiment locally without paying OpenAI fees.

If you're not a programmer, there's still stuff you can do to play with this — there are no-code interfaces like n8n. The biggest thing you can do is research prompt engineering — what's the best prompt to give a large language model to get out what you actually want. And remember that AI has limitations — it understands what an English word looks like, but it doesn't necessarily understand the context. It doesn't know that dogs can't fly, it doesn't know that normal hands are supposed to have four fingers and a thumb, and so it can make mistakes.

That's all I have for you — that was a long one, thanks for sticking with me. If I can answer any questions, head on over to tech-answers.club and I'll do my best to help. If you want generic answers, go and talk to AI, and it may or may not give you the truth — it's up to you to decide. But until next time, may your deployments be smooth.

Question 23

How do you use development templates to automate and streamline workflows?

Accepted Answer

**Quick answer:** development templates are pre-built infrastructure/pipeline scaffolding a team can reuse instead of writing it from scratch for every new project — a developer starts a new project from a template, follows documented self-service steps to deploy it, and the CI/CD pipeline behind it builds and tests it automatically, removing repetitive setup work and cognitive load from every new project.

These are the templates people can use to have the infrastructure running, so that when they deploy stuff they haven't got to write it themselves — they can just use the templates on their machine or the shared architecture, because there's no doubt a Jenkins server lying about somewhere, and build stuff with the basic scripts and templates.

The advanced level is the full developer portal with comprehensive automation — everything you could possibly imagine is automated. Create a repo on GitLab? Yep, that's automated, you click a button and that repo is already prepopulated with the template. Everything can be automated to the point where developers just get their code, do the developing, and commit it — on the commit it automatically gets built, and after the commit they get a button asking where they want it deployed. An internal developer platform isn't just a tool, though.

Question 24

What are the top three technology predictions for 2025?

Accepted Answer

**Quick answer:** the top technology trends to watch are AI moving from a novelty to a working part of the development workflow, continued consolidation around a small number of dominant cloud/platform patterns, and growing pressure on teams to demonstrate DevOps maturity (automation, deployment frequency, recovery time) as a competitive differentiator, not just an internal efficiency measure.

Welcome to 2025 — what is this year going to bring? Well, I'm glad you're here, because I've got three top predictions of what I think is going to happen in 2025. I'm Neil Millard from tech-answers.club, DevOps Professional of the Year last year, and I help IT professionals with software delivery, DevOps, and careers advice.

It's a long time since I started in IT, in 1995 — 30 years ago. I was a trainee for two years, an engineer for two years working on desktops, two years on server software, and then I went contracting. But like any great planning, we need to know where we are first — I fly helicopters, you may have noticed on the channel, and we have aviation maps that tell us where we can go, where we're not supposed to go, and the bit in the middle where you have to ask permission. Last year I covered a lot of what was happening in open source and things (I've got another video about those changes), but meanwhile, let's get on with it.

What are the new things we can look forward to? Could it be to do with communication, the way we talk to each other — mobile phones were the biggest change in that area, maybe something else. Containers — let's containerize everything, I don't know if you've tried this, sometimes it works really well and sometimes it's really, really hard. Maybe there's something in there for us. Or is it to do with CI/CD pipelines — my pet project is automating CD pipelines so you can build your software, get it tested, get it deployed, and focus on what you love doing, which is writing code.

Well, all of those things could be achieved with AI. AI launched onto the scene in 2023 and it's been growing in popularity and power ever since. Imagine waking up to find your entire Ops pipeline has been optimized overnight, your code is reviewed, your infrastructure is scaled — your coffee, well, you still have to make that yourself — but in 2025 AI agents are going to transform how we work in ways that will make ChatGPT look like a calculator. Let's dive in.

**Prediction one: multi-agent systems**

Three simple words, but what it means is we can use a multi-agent system together with AI. There's software like CrewAI, where AI agents can become autonomous systems, and those autonomous systems can plan complex tasks, execute multiple steps without human intervention, arguably learn from their mistakes, and — this is the biggie — collaborate with other AI agents. When it's talking about breaking tasks into smaller tasks, it can hand those off to separate agents — it's all AI at the back end, but you give it a different context, a different instruction, and it can come back with better results, and that collaboration will really bring the whole thing together.

Will they replace you? Probably not. When we're talking about technology it's always about doing or delivering more with the same resources — we have a food processor at home, and apparently it says on the box you can make mayonnaise with it. Even if a klutz like me in the kitchen can make mayonnaise with a food processor, that's providing an output I couldn't achieve without that technology. AI is the same — it's not about replacing you, it's about augmentation and focusing on work that wouldn't otherwise get done. AI can't create genuinely original stuff, it just takes stuff it already knows about and rehashes it together, and if it trains too much on its own output there's a horrible feedback loop that causes it to collapse — "model collapse," they call it. Studies show that after five or six training loops down the line, AI suddenly starts spitting out garbage because it's just regurgitating its own stuff. So humans cannot be replaced by AI.

**Prediction two: cloud repatriation**

Remember when everyone said cloud is the future? Well, plot twist, apparently it isn't always. There's stuff you need to know about moving to the cloud — infrastructure costs, data transfer costs (transferring from here to there, and everything is data), storage costs once you've transferred it, and then there are hidden operational costs — somebody's got to pay for the people actually creating, running, and keeping this thing from breaking.

So let me show you the real cost comparison. Modern hardware efficiency, great. Predictable workloads, great. When you're at scale with modern hardware and predictable workloads, cloud is not always the answer. Picture this: your data, your hardware, and therefore your rules — you've got complete control over the infrastructure, customization and optimization are all possible because you control everything, and there's lower latency for specific use cases — you can put specific stuff next to other stuff, put your database right next to your application servers, even on the same switch. In the cloud you don't have that much control — it's like owning versus renting, but for your servers.

So we're talking about cloud repatriation. Some of the bigger players have already done it — they moved over to the cloud, ran it there, and are now moving stuff back to the main data centre. The thing is, it's not all or nothing — you can have smart workload distribution and cloud-bursting strategies (I spoke about that in another video), where we take a hybrid of a static workload that gives us the baseline, and use the cloud for the spiky stuff, those big traffic-spike moments. It's like having a vacation home in the cloud — you only use it temporarily. If you're thinking about cloud repatriation, I've put together a decision matrix at tech-answers.club — there's a free link down there where you can get that cloud repatriation matrix.

**Prediction three: robot revolution**

Imagine never having to iron your clothes again. Show a robot a tangled shirt and — mind blown — a simple robot could hold up the ironed shirt, and that might change the entire economy. Maybe this is the year of the robot revolution. Why is ironing a really good example? Because if a task is really complex but requires precision, and is repetitive but variable — you don't always wear the same clothes, and they don't always need the same level of ironing — and it's a high-demand service (I ask you, who loves ironing? Some people might, but most people see it as a chore), then it's a genuinely hard robotics problem. Trying to iron fabric is really hard — it's like trying to teach a helicopter to hover; a standard helicopter can't do it, which is why we gave it four blades and called it a drone. Really tricky.

But what happens when we give robots the power to master those tasks? Service industry transformation. We've already got lots of robots in factories, because factory tasks are repetitive and easy to do, without a lot of finicky precision changes — everything's where it's supposed to be, and making a car out of metal is quite simple, but with fabric it's all wobbly, foldy, and tricky. So we could see a service-industry transformation that disrupts the jobs market like the Industrial Revolution did several hundred years ago. What will happen is new roles get created, because somebody's got to look after all these robots — regular jobs will decline, but new jobs will take their place, jobs only humans can do, so there'll be a ripple effect across the economy: some employment decrease, but tech jobs increasing, and people having more time for training and leisure. Because prices will drop due to automation, there'll be more disposable income, meaning more spending on professional services.

So what do we do about the low-level, unskilled jobs the robots could easily take? There's a thing called universal income, and I think it's a solution — it's a bit like a DevOps pipeline, but for society. It automatically distributes wealth: it takes wealth from companies because their costs are dropping from using robots instead of staff (and they're not going to drop their prices, so we tax them instead) and distributes that to the populace. It also provides an economic stability mechanism — a bit like the benefit system in the UK, except the biggest issue with the benefit system is it costs a ton of money just to run. If everybody gets a universal income, you don't have that management overhead of deciding who's "worthy" — everybody just gets it — and with that extra money in your pocket you'd be encouraged to take on training, and part-time work might become the norm. Still waiting for the four-day week myself.

So what would you do with your free time if robots handled all your chores? Let me know in the comments below. Remember when cloud computing seemed radical? This one's coming faster than we think — the question isn't if, but when, and I think 2025 could be the year.

Do you have any tech questions I can help with? I've been an IT expert for over 20 years (well, apparently 30, according to the intro) — head on over to tech-answers.club and we can talk about all sorts of fun things. Thanks for watching, and if you got this far, be sure to subscribe and like the video, and I'll see you in the next one.

Question 25

How do you use DevOps practices to boost your deployment speed?

Accepted Answer

**Quick answer:** DevOps speeds up deployment mainly by breaking down silos between development and operations and tightening the continuous integration/continuous deployment loop, so code reaches production as quickly and safely as possible instead of queuing behind manual handoffs.

Is it DevOps? Well, DevOps is primarily about breaking down silos — communication, and CALMS (continuous integration and deployment is part of that, but I prefer CALMS as the wider term) — and it's about getting code to where it needs to be deployed and working as quickly as possible. Its main purpose is to shrink the gap between developers and operations, and the smaller we can get that gap, the less handover, the smoother the deployments. You can start deploying stuff once every hour, or even quicker, if your coders are fast enough.

Question 26

What are the common pitfalls to avoid when using Ansible?

Accepted Answer

**Quick answer:** the main Ansible pitfall is using its `shell`/`command` modules to run arbitrary scripts instead of Ansible's own idempotent modules — a raw shell command re-run adds a duplicate line or repeats an action every time the playbook runs, whereas a proper Ansible module checks current state first and only changes what actually needs changing, which is what makes a playbook safe to re-run.

But there are some pitfalls. Ansible does allow you to write custom code — you can run a bash script or something — however, if done badly, or without awareness, it means you lose the ability to run the playbook over and over again idempotently. If you're just running a bit of bash code that appends an extra line to the bottom of a file, then every time you run the code it's going to stick that line on the bottom again, and before long you've got six, seven, eight identical lines at the bottom of the file, which is probably not what you want. With mindfulness you can make sure it handles being run multiple times — the inbuilt Ansible modules have already got this in mind, so they'll do that sort of thing for you.

**Dynamic inventories** — I've mentioned this already. Let's say our servers are in AWS — we don't necessarily know what the hostname's going to be, we don't even know what the IP address is going to be, so we can run a utility script that goes off into our AWS account and gathers what the servers are. We can put tags on those servers, and those tags will form group names inside the Ansible inventory, so then we can target the groups in the same way we always do, and we know which server that's going to affect based on the server tags.

**Secrets** — what's a secret? Well, we've got our variables, haven't we, and we don't want variables that contain sensitive information inside our repository. Ansible Vault enables us to encrypt those secrets so we can store them in the repository and they're still relatively safe. This way we can use continuous deployment, running the same code over and over again with our secrets, so we're reasserting what our server should look like, and we've got our secrets safe, with all that important information — database usernames, passwords, and so on — away from prying eyes.

Question 27

How does a hybrid EC2 and Lambda strategy maximise cloud efficiency?

Accepted Answer

**Quick answer:** run a baseline of EC2 for steady, predictable compute (cheaper per hour than Lambda at constant load) and use Lambda to absorb traffic spikes on top of it — the combination gives you a cheap floor and elastic ceiling instead of over-provisioning EC2 for peak load you rarely hit.

We can combine a couple of strategies to be really strong with our approach. We can have something running on an EC2 machine that gives us a baseline amount of CPU compute, and it's relatively cheap compared to Lambda. We can then tie that to Lambda to deal with our peaks when we're really busy, and by mixing the two together we get a blend of a cheap base cost and a slightly more expensive peaky cost, to work with our traffic flows if they're not really flat and predictable.

Question 28

How do Heroku, Railway and Render compare for deploying applications?

Accepted Answer

**Quick answer:** Heroku, Railway, and Render all offer the same core pitch — point them at a git repository and they build, deploy, and give you a server address — but differ on pricing model and add-on ecosystem; the right one usually comes down to which pricing plan and database/add-on options fit your budget, not a functional gap between them.

Platform as a service — Heroku gives you a very easy way of deploying your application. You give it a git repository, you've got some special config in there, and it installs it for you and gives you a server address — happy days, minimal effort on your part, and there it is.

There are a couple of other companies that do a similar thing — Railway and Render. Both look different, both work slightly differently, and both have simpler payment plans, and as a platform as a service they'll give you the extra add-ons you want — want that database? Sure, just add it on. Want more CPU? Sure, just add it on.

Question 29

What is the difference between horizontal and vertical scaling, and when should you use each?

Accepted Answer

**Quick answer:** horizontal scaling adds more identical instances (2 servers to 4 to 8) to spread load across them, while vertical scaling makes a single instance bigger (more CPU/memory). Web and proxy servers typically scale horizontally well since requests are easy to distribute; databases are more often scaled vertically first because splitting data across nodes adds real complexity — most production systems end up blending both.

There's horizontal scaling and vertical scaling. Horizontal scaling is where we take the same cookie-cutter process — be it a server, a virtual server, or a container — and we just stamp out more of them in a horizontal direction to give us more of those things, so we can go from two servers to four to eight to 32, however many it takes for our particular workload.

There's also vertical scaling — that's where we make the resource bigger, so that virtual server, we give it more memory or more CPU and make it bigger that way. There are pros and cons depending on where you are and what layer you need to fix. It's quite common for web servers or proxy servers to scale horizontally, but for database servers it's more common to scale vertically, and of course you can blend the two together.

Question 30

How do you use Ansible to automate the setup of a Python application?

Accepted Answer

**Quick answer:** an Ansible playbook for a Python app typically installs Python itself, sets up a virtual environment and package manager (pip or poetry), installs the app's dependencies, and configures a web server in front of it — the same repeatable steps every time, instead of manually SSHing in to set each server up by hand.

Ansible is another configuration management tool that lets us personalize the server, and for this our app is a Python app, so we're going to make sure we've got some Python installed — that'd be a great start, wouldn't it. It's then going to install a virtual environment and a package manager, pip or Poetry or something, that installs all the dependencies. It's going to install a web server, and once all that's done we can get our thing running — easy peasy.

Question 31

Do you really need an internal developer platform, and what are the trade-offs?

Accepted Answer

**Quick answer:** an internal developer platform (IDP) is worth building once the organisation is large enough that self-service (a developer requests a new service and gets a fully provisioned, tested, deployable environment without waiting on another team) pays back the significant upfront build cost — often 12–18 months of dedicated effort. For a team of two or three developers, that overhead usually isn't justified; solid CI/CD pipelines and guardrails deliver most of the benefit without the full platform investment.

Hi, a warm welcome to you, I'm Neil Millard, the DevOps and IT expert, and I also talk about contracting and stuff. Today we're talking about internal developer platforms, because developing code presents you with choices, and deploying is hard — choices are hard, and we just want to help each other out. Before that, I'd just like to mention tech-answers.club, where you can join me every Wednesday for a Q&A to ask all of your tech questions — deployments, DevOps, Kubernetes, containers, all that fun.

**What is an internal developer platform?**

It's essentially a customized self-service infrastructure and workflow ecosystem that standardizes and simplifies software development processes. Developers have a lot of choices when they develop code, so if we've got deep DevOps expertise already on hand, we can answer a lot of the questions common developers will have at that organization — what programming language should I use, or how are things deployed around here. It also provides a standardized CI/CD approach, with pipelines doing most of the hard work for you, plus automated testing, build, and self-service release. There's also a central hub for documentation, templates, and knowledge, with some built-in security and compliance guardrails, and on the back end, no DevOps setup would be complete without observability and monitoring.

**Why might you need one?**

It solves developer cognitive load — a lot of the decisions are made for the developer, so they can just get on with developing code without worrying about everything else that goes along with it. Here's a template application that just says "hello world" — it's written in a language the organization has agreed to support, using specific libraries to get you going fast. You pick up your ticket from whatever ticketing system you're using, download the template, and make your first build, then write some tests. Your first build is there, ready to go, and you can iterate on it from there based on whatever the ticket says. With those choices of language, frameworks, and dependencies all sorted, it just leaves the development bit, and with the pipelines in place and automated testing, those are covered for you too.

The benefit of having these things standardized is that it's easier to support, because everyone's trodden the same path before — you'll know the issues they're going to hit, you'll know how to solve them, and there'll be shared documentation they can access without bothering us, the DevOps people, or anybody else except maybe their team, who can say "have you seen this before? No, but have a look at the docs, there's the answer for you." So it speeds up learning for new starters and speeds up development, because there's lots of support already there — if all the developers were doing their own thing, they'd be hitting the same issues and brick walls over and over again, but for different languages and different frameworks. By building some guardrails in, you keep everyone on the same path, so everyone gets supported equally and strongly from day one, and it reduces toil and manual work.

As part of my operability, DevOps, and SRE role, I want to present a situation where everything is self-service. The developer says "I want to start a new project" — the documentation says "here's a template, off you get." The developer says "I want to deploy it" — the documentation says "go to this URL on our portal, click this button, feed in some information, and it will deploy it for you." Well, I've not built it yet — the answer is the same: look at the documentation on the portal, there's a pipeline that will build and test it for you. All of that extra cognitive load is taken away, and it makes everything and everybody a little bit happier.

**The catch**

This sounds absolutely amazing to the developer, but there's a catch — an IDP might not be the solution your organization is looking for. Potentially it's over-engineering what's already there, potentially it's too complex, and there are always budget constraints and team-size constraints. IDPs take a lot of effort to get working — I was on a project where, from inception of the IDP to the first live service, it took about 18 months, which is something your business might not be able to support. On the back end of that, though (that was nine years ago now), a team joining that service can start, pick up their tickets, and deploy a fully working service within three weeks — pretty impressive, but that's a lot of groundwork to go into at first.

So once it's up and running, three weeks is great for developing a fully tested and deployed product, but it relies on a lot of foundation, and your business might not be up for that investment. If you've only got a team of two developers, there's probably a lot of overhead to go through just for two people — that doesn't mean you shouldn't use guardrails, doesn't mean you shouldn't use CI/CD pipelines, but you don't have to go as far as a full-on internal developer platform.

**Steps to deploy an internal developer platform**

1. **Basic** — shared documentation, some basic scripts, just so everyone can get started.
2. **Intermediate** — self-service infrastructure templates, so people can have infrastructure running without writing it themselves, on their machine or shared architecture (there's no doubt a Jenkins server lying about somewhere), building stuff with basic scripts and templates.
3. **Advanced** — the full developer portal, with comprehensive automation. Everything you could possibly imagine is automated — create a repo on GitLab, yep, that's automated, you click a button and that repo is already prepopulated with the template. Everything can be automated to the point where developers just do the developing, commit their code, it automatically gets built, and after the commit they get a button asking where they want it deployed.

An internal developer platform isn't just a tool, though — it's a philosophy of empowerment. It's my job to be as invisible as possible — I want to provide the tools and the self-service aspect of things to developers so they feel empowered to do what they need to do without me getting in the way. The only time they contact me is if something's not quite working right, a bug, or if they want a new feature. So the IDP is your team superpower — it reduces complexity once it's set up, and it amplifies developer productivity, as in my example earlier: three weeks from inception to live deployment for a fully fledged app.

An IDP is not one-size-fits-all, it's not a template I can just give you — it's going to be unique to your organization, their choices, and their needs. The goal isn't just efficiency, it's creating an environment where developers can do their best work with the least friction. So how do we do this? We start small and iterate, kind of the agile way — we involve the developers at the platform design stage, after all they know what they want, they know how they work, and the experienced ones in your organization will know how things like to be done (that's not necessarily the best way, so we can guide them and bring those guardrails closer and closer to the ideal, using all of their experience and existing knowledge). Then we continuously measure and improve, and we want to keep things as simple as possible — simple makes our lives easier, simple makes their lives easier, and we don't want to chase complexity for the sake of it.

So what are you waiting for? Look at your current development flow — are there any bottlenecks? Where are developers spending most of their mental energy on non-coding tasks? Let me know in the comments below, and tell me about your experience of an internal developer platform too. Just to finish off, here's a little joke: why did the DevOps team call their IDP a magician? Because it turned manual chaos into automated brilliance. Not really that funny, was it — anyway, if you want to tell me your jokes, come along to the Q&A, or join us at tech-answers.club, where we can get together and support each other in all things IT, operability, DevOps, cloud, and all those wonderful other buzzwords. Till next time, may all your deployments be smooth.

Question 32

What is the difference between DevOps, SRE and Cloud Ops?

Accepted Answer

**Quick answer:** DevOps is the practice/culture of developers and operations working together across the whole software lifecycle; SRE (Site Reliability Engineering) is a more prescriptive discipline that applies software-engineering rigour (error budgets, SLOs) specifically to keeping systems reliable; Cloud Ops is the narrower, more traditional operational work of running and maintaining cloud infrastructure day to day. The three overlap heavily and the exact boundary varies a lot by company.

I was in the pilots' lounge the other day when the barkeep says "what do you do, then?" and I said "operability." He said that doesn't help him at all — what's operability? Well, this video is for him. I'm going to tell you what operability engineering is — quite straightforward really, but let's go through it one step at a time. Before I get into that, did you know you can come along to a free Q&A every Wednesday at lunchtime, where you can ask any tech questions you like, at tech-answers.club.

**Is it DevOps?**

DevOps is primarily about breaking down silos — communication, collaboration (continuous integration and deployment is part of that, but I prefer thinking of it as collaborative workflow), and getting code to where it needs to be deployed and working as quickly as possible — build and deploy, easy peasy, right. Its main purpose is to shrink the gap between developers and operations, and the smaller we can get that gap, the less handover, the smoother the deployments — you can start deploying stuff once every hour, or even quicker, if your coders are fast enough.

**Is it SRE?**

SRE — site reliability engineering — is a thing Google have championed for ages, and I guess it could be that. The main thing about SRE is having the service running to an acceptable level, which means you end up with two things: a service level objective, which is how much of the time it goes right, and error budgets, which is how many times it goes wrong. Error budgets exist because every time something goes wrong, your users think "that's rubbish," but they only have a certain amount of tolerance for that before they give up and use somebody else's product. So you develop a service level objective that's high enough to make sure your users don't leave, but low enough that your devs have got a chance to fix all the bugs.

Then there's proactive and reactive monitoring — proactive monitoring is where we're actively thinking about what can go wrong and fixing it before it does, and reactive monitoring is having those lovely dashboards so that when something does go wrong and eats into our error budget, we can identify it and do something about it.

**Is it Cloud Ops?**

If it's not exactly DevOps and not exactly SRE, perhaps it's Cloud Ops. Cloud Ops is all about cloud architecture and design — when I say cloud, this might be a public cloud like Azure, Google, or AWS, or it could be an internal cloud. For many years I was on-site in a data centre racking servers, and we used virtual servers to give customers who wanted servers quickly a faster response — spin up a VM, here's a template, off you go, build a server in what was probably half an hour back then; five minutes would be acceptable these days.

Cloud Ops is all about architecting the design, optimizing costs, and keeping those costs down — if you're running a server 24/7, don't pay cloud prices for it, you're wasting your money, you might as well have a data centre. It's also about security and compliance — making sure there are no holes in the system, that the people who need access have got access and those who don't, don't, and complying with whatever rules and regulations you need to, to keep the data safe.

**Where operability fits**

Operability engineering is all of those — it's about being maintainable as part of the design, it's about being scalable (again, cloud design, being able to deploy stuff fast), and it's about being observable — knowing when things go wrong and how often things go right.

Here's a handy way to break it down: DevOps is about reducing friction between development and operations; site reliability engineering is about system availability and performance — knowing when it's working well, when it's not, and making it work better; and Cloud Ops is about optimizing cloud resources and infrastructure so we're providing a decent service without paying lots of money, and reducing the bill where we need to.

All three care about **automation** — prioritizing and reducing manual intervention. Developers don't like touching servers, so give them a button to deploy the code. **Continuous improvement** — iterating on what we've got: as an SRE you're reducing errors, as a Cloud Ops engineer you're reducing costs, and as a DevOps engineer you're making things go faster and reducing development time. **Observability** — creating transparent, monitorable systems so we can see how fast builds are performing, how long a deploy takes, when errors are creeping up and eating into our error budget, and how much our bills are. **Infrastructure as code** — we want to treat infrastructure with the same rigour as software development: it's version controlled, we know exactly where it is, and we can deploy it quickly.

All of those things come into DevOps, SRE, and Cloud Ops. DevOps ensures a smooth development and deployment of code; SRE maintains uptime and makes sure users don't experience errors; Cloud Ops optimizes cloud spending and infrastructure — what's the minimal amount of infrastructure we need to provide that uptime.

So, over to you in the comments below — describe your understanding of operability in one tweet-sized explanation, can you do it? Operability isn't about choosing one approach, it's about understanding how these disciplines complement each other to create a robust, efficient tech system. So is it all of the above? Yes, as I said to the guy in the pilots' lounge.

I'll leave you with a joke: why is DevOps always prepared? Because there's always something in the pipeline. If you thought that was rubbish, let me know — come over to tech-answers.club, join me on the live Wednesday session, and tell me your favourite joke instead. I'll see you on the next one.

Question 33

What does a typical day look like for a DevOps engineer?

Accepted Answer

**Quick answer:** a typical day mixes monitoring dashboards and alerts, reviewing and approving pipeline/infrastructure changes, pairing with developers on deployment or automation problems, and a smaller share of hands-on scripting or infrastructure-as-code work — less "firefighting all day" than people expect once monitoring, automation, and CI/CD are properly in place.

Hi, I'm Neil, a DevOps engineer, an SRE, a platform engineer — but what the heck do I do all day? In this video you'll find out.

**Morning checks**

How do I start the day? Coffee, obviously. I then walk into my office — a lot of my colleagues work from home, and some walk into an office if they're close enough, maybe one or two days a week. I'm not obligated to either, but it gives me a chance to stretch my legs, otherwise I'd sit down all day and just drink coffee.

I get in, and the first thing I need to do is look at the dashboards — check to see if all the infrastructure is ticking along nicely. Is Jenkins running, has it rebooted over the weekend, do I need to do anything to it, are the agents running, are they registered correctly, are they processing jobs, is anything running particularly hot? I jump into a dashboard that shows me CPU usage, and check if anything's bouncing off the ceiling. Some things I've got alerts set up for already, like how much database space we've got, whether we're running low. Those kinds of things all get checked in the morning, and take me about an hour or so. Once everything's tickety-boo, I either raise a ticket for something that's gone wrong, if it's not urgent, or fix it there and then, in which case we have runbooks already written so we know exactly what to do.

**Standup and pairing**

Next comes standup — this is where I confer with the team about what I intend to do today and what I did yesterday, and hear from them about the same, so we all know what each other's doing and don't have any conflicts during the day. If we do have conflicts, maybe it's an opportunity to work together. On larger teams I've been on, I often pair — this means I work alongside somebody else, either with the same skill set as me, or a different one — maybe they're a tester if we're writing tests, a programmer if we're creating programming guidelines, or from the logging team if I'm setting up alerts.

**The work itself**

Once standup's done, we move on to actual work. We look at the kanban board and what we just discussed about what we're going to do — this might be a range of things. We might have to upgrade some stuff — that happens quite often, say Artifactory drops a new version, so we have to upgrade it, come up with a plan, and write a runbook if we don't have one already, then do it in test, ready to go live the following day.

Or maybe we're adding new functionality — I've been part of a team putting together an API for build and deploy that takes inputs and events from all sorts of things, the simplest being a GitHub webhook: something changes on GitHub, it sends a request through to the API, the API analyzes it and does something with it — it might build and test because it's a PR check, or build and publish an artifact because somebody merged a PR. Then we might need a new feature in that API — for instance, checking that other dependencies need updating. We've added a new tool into the pipeline that now does an additional check: are you running up-to-date software, are your dependencies up to date. There are always little improvements that make everyone's life easier.

**Afternoon and evening**

Moving on to the afternoon, there's probably some more programming — I love programming, I love automating things, and automation to me is the heart of DevOps, SRE, and platform engineering. I'm providing tools and functionality so the developers and other people on my team have an easier life — what's the one thing I can do today to make tomorrow easier and better for everybody else, including myself?

Then in the evening it's time to catch up — research new tools that are available, read the newsletters, maybe learn something, or on some occasions present at a meetup, virtually like this or in person (those are starting to come back now — I had an in-person meetup last week, very exciting). I also run a Q&A session every Wednesday.

**In summary**

So there you have it, what a day looks like for me — I start the morning with checks to make sure everything's running fine, then attend standup to catch up on what everyone achieved yesterday and what we hope to achieve today. Then I get on with work, usually scripting — could be Terraform, could be APIs, could be Python, could be Go — expanding features or fixing bugs in the tools we run. In the evening, connecting with the community, answering your questions, asking questions of my mentors and peers, gathering knowledge, and generally making myself more useful to everybody else. That's why I'm here — I want to be more useful to you.

Got any questions about SRE, DevOps, or platform engineering? Come along every Wednesday — I run a free Q&A, link at tech-answers.club — and I'll do my utmost to serve you and answer your questions.

I'd like to finish with a joke: a developer and a system administrator walk into a bar. The barman says, "what is this, some kind of DevOps joke?" and they reply in unison, "it's not a joke, it's a collaborative deployment" — then proceed to spend the next hour arguing about who's going to write the infrastructure code. Okay, maybe not that funny, but jokes and humour are what get me through the day. Until next time, I'll see you on the next Q&A session, every Wednesday over at tech-answers.club.

Question 34

How do you bring order to chaotic DevOps infrastructure using Ansible?

Accepted Answer

**Quick answer:** Ansible brings order to chaotic infrastructure by turning manual, undocumented server configuration into version-controlled playbooks that describe the desired state — so instead of remembering which of twenty servers has which manual tweak, you have one source of truth you can re-run safely, and a git history of exactly what changed and when.

Hello, welcome to the channel, I'm Neil, your DevOps expert, and I also run a group called tech-answers.club — I'll tell you more about that later. Today I'm going to talk about Ansible: what it is, what it's used for, and how you can get loads of benefit from it.

Infrastructure takes management — if it doesn't get managed, it turns into a giant mess. If you've ever worked in a data centre, you might have seen those pictures of bad cable management — the back of a rack with cables of different colours in a spaghetti mess, a bit like some code I've looked at. With proper cable management it can look nice, neat, and tidy, and make it really easy to maintain — and that's what Ansible can help us do for our servers.

**What is Ansible?**

Ansible is a tool for configuration management. It can be saved into git repos, so it counts as infrastructure as code. It can also manage infrastructure like AWS, but I'd recommend Terraform for that — Ansible really excels at looking at the configuration and keeping everything up to date on your servers: install, remove software, update configuration, and other housekeeping tasks.

What is it made up of? An **inventory** — that's your servers. **Playbooks** — a link between the servers and what you want them to do. **Roles** — a group of tasks. The **tasks** are what actually configure the server. **Variables**, because we want to keep the variables separate from the code. And **groups**, where we can group the hosts together.

The fundamentals are that this is infrastructure as code — everything is, in theory, written down in code, and we execute Ansible playbooks to make that a reality on our servers. One of the benefits of having it in code is we can run it over and over again, not just on other servers but even on the same server, so we can prevent configuration drift.

**Playbooks and roles**

A playbook is a YAML file that links the inventory to the tasks through the glue of roles — it tells us what server groups should be applied with what roles, and the roles contain the tasks. Roles can also be made up of modules — reusable pieces of code, so if we've written some tasks and put them into a role, we can store those as a module. Provided we keep the variables separate, we can share those modules with other parts of the business, colleagues, or friends — or they can share theirs with us, so we don't have to do the hard work if they've already done it. Take a look at Ansible Galaxy for more examples of this.

Variables are important because not every server is the same — some have unique attributes, like the server name, or, if they're hosting a website, the website address or the name of the SSL certificate. We can group hosts (the name for servers in Ansible-land) into groups, and apply variables at the host level and the group level — at the group level we can say "we want these hosts to have this role," and that's what the playbook does.

**A quick demo**

I've got a server I created, and an Ansible playbook called "docker-host" — it's got several files in it, a README of course, and the playbook itself. What we need is the hosts file — that contains variables we can apply to the groups. Let's create one: we've got our host, called "ansible-demo," and all hosts need to be in a group, so let's put it in one. Because we're going to SSH in as a host, let's make sure we can contact it over the network by pinging it — there we are, and that's what the Ansible playbook command is going to look like.

Let's SSH into the server — I used another Ansible playbook to configure this server so I could SSH onto it with my username — and try running the `docker` command, and it's not there. So let's look at the actual playbook — it also contains an NTP role, but we don't need that since this server already has NTP set up, so we'll comment that out, and we're not hosting anything so we'll get rid of Let's Encrypt as well. Essentially all it's going to do is install Docker for us.

So let's run the playbook — it removes old Docker versions, adds the dependencies we need and the repo, then finally installs Docker. Took about 25 seconds on my machine. Like I said, we can run these things multiple times and that's okay — it just reasserts the configuration you want, and everything else is skipped if it doesn't need to do any work, all driven off the host file we created earlier. The playbook contains roles, the roles contain tasks, and the tasks start off with a main file, where we can do stuff like check the operating system, so we can have different tasks for Debian and different tasks for Red Hat because they use different commands, and finally the tasks at the bottom level do what I mentioned — installing Docker and, most importantly, starting the Docker service. Head back over to the server, and lo and behold, Docker now exists.

**Scaling it up**

That's a very simple example, but what else can happen in the real world? Doing this on one server is fair enough — you could probably achieve the same by SSHing in directly, not much time saved — but if you've got multiple servers, say 20 web servers, you wouldn't want to log into all 20, set up accounts, add packages, and create configuration files by hand, that would take a long time, especially in a dynamic environment. If you want to reconfigure all those servers, having this playbook just to play, it's all done in about 35 seconds.

You can also use the playbook across multiple environments — many of my customers have a dev environment, a testing environment, a staging environment, and a production environment, and you can use the same code against all of them, ensuring consistency across all of those, which is very important, and makes things easier.

**Pitfalls**

But there are some pitfalls. Ansible does allow you to write custom code — run a bash script or something — however, if done badly, or without awareness, it means you lose the ability to run it idempotently, over and over again. If you're just running a bit of bash code that appends an extra line to the bottom of a file, every time you run it, it sticks another line on, and before long you've got six, seven, eight identical lines, which is probably not what you want. With mindfulness you can make sure it handles repeated runs — the inbuilt modules already have this in mind.

**Dynamic inventories** — I've mentioned this already. Let's say our servers are in AWS — we don't necessarily know the hostname or even the IP address in advance, so we can run a utility script that goes off into our AWS account and gathers what the servers are. We can put tags on those servers, and those tags form group names inside the Ansible inventory, so we can target the groups in the same way we always do, based on the server tags.

**Secrets** — what's a secret? We've got our variables, and we don't want variables containing sensitive information inside our repository. Ansible Vault enables us to encrypt those secrets so we can store them in the repository and they're still relatively safe. This way we can use continuous deployment — running the same code over and over with our secrets, reasserting what the server should look like, keeping database usernames, passwords, and other important information away from prying eyes.

**Performance**

Ansible works by SSHing onto the server, doing the thing, and exiting again, so there are a few things we can do to speed this up:

- **Forks** — enables us to contact more than one server at a time. If we're configuring those 20 servers, we can run with `forks: 20`, hitting all 20 servers at the same time.
- **Async operations** — other configuration management tools like Puppet run async by default, and you have to massage them to do things in the right order. Ansible does things in order by default, but you can tell it to run certain tasks asynchronously, so it doesn't have to do them one after the other. This can speed up your playbooks.
- **Disable host key checking** — if you're in a trusted environment, this can save you one or two seconds on every SSH connection, and given Ansible connects, does the thing, and disconnects for every task, that can add up significantly across a playbook.

So that's Ansible — we talked about the inventory, the playbooks that tie the inventory to the roles, the roles and Ansible Galaxy for modules, variables that let us personalize servers (which we can even encrypt with Vault), and groups that keep our hosts together and tidy.

If you've got any questions, put them in the comments below, and come and ask me at our weekly Q&A every Wednesday at lunchtime — free, at tech-answers.club. Hope that's helped you understand what Ansible is, and until then, may all your deployments be smooth.

Question 35

What are the best ways to deploy a Python application and how much do they cost?

Accepted Answer

**Quick answer:** common ways to deploy a Python app range from cheapest/simplest to most flexible: a platform-as-a-service like Railway or Render (pay-as-you-go, minimal setup), a managed container service (AWS Fargate, similar per-request/per-hour cost, more control), a full VPS you manage yourself (cheapest at scale, most operational overhead), or serverless functions for spiky, low-traffic workloads (pay only per invocation). The right choice depends more on how much ops work you want to own than on cost alone.

Hi, I'm Neil, your DevOps expert, come and ask me questions. Today's question is: I've got this wonderful Python app deployed and it runs wonderfully on my machine — how can I deploy that to the internet so the rest of the world can enjoy my hard work? Well, here are seven ways to deploy your Python app, and if you stick around to the end there's a cost comparison chart and a little flowchart to help you decide which one is right for you.

We all want smooth deployments, and to get smooth deployments we need a plan, and the plan in code is DevOps — easy, right. We've got our Python app, and we're looking at seven different ways to deploy it to a server, because there's always a server somewhere, even if we're not running it ourselves, for the internet to see our hard work.

**1. Bare metal**

You can't get any more basic than this — whether it's a Raspberry Pi, or something bigger like a Dell PowerEdge server (I cut my teeth largely on HP servers, or Compaq as they were known before that). Aside from unpacking it, installing the CPUs (they don't come with the CPU installed), and sliding it gently into the rack in the air-conditioned room, you switch it on and you're greeted with a boot screen. What it does mean is you've got full control over the hardware — you know exactly what's going in there, the exact amount of memory and CPU is all available to you, nothing else is going to steal it. Want a graphics card for some CUDA work? Put one in, or several — you know exactly what's in there, full control, it's in your data centre.

The admin is a bit more tricky, though — you get a black, scary boot screen asking for a boot device. Load up a well-known Linux distribution of your choice, Red Hat or Debian-based, stick it on a USB drive, and click through the install. If you've got a lot of these to look after, you might use a golden image with an unattended install file that installs a predefined suite of packages — more admin effort up front, but handy at scale (when I was doing this I was deploying hundreds, even up to a thousand servers by the time I was done).

Once it's booted with an OS on it, we can run Ansible — a configuration management tool that lets us personalize the server. For our Python app, we make sure Python is installed, install a virtual environment and package manager (pip or Poetry), install all the dependencies, install a web server, and then we can get our thing running. Easy peasy — but the start is hard. You do get full control, though.

**2. Virtual private server**

You've probably seen these — Amazon EC2, Linode, droplets from DigitalOcean. It's a bit like the bare metal server, except you've only got a slice of it, and you don't get that scary boot screen (some providers do give you access to it, but you're in the same situation) — they give you an operating system to start with, so you can SSH into it and off you go. Of course, don't just SSH in manually — use an Ansible playbook like before, which installs Python, patches, a web server (Apache, nginx, Unicorn, or whatever you choose). Again, full access to the operating system, but you're not necessarily in full control of the hardware — you don't know how many other people are sharing the CPU and memory with you, or whether there's a usable graphics card (some VPS providers do offer that option). You get what you pay for — the more you spend, the bigger server you get. Once deployed, you've got your Ansible playbook, happy days, server deployed.

**3. Docker containers**

Who hasn't heard of Docker containers — very easy to run on your local machine, you've got a Dockerfile, you spin the thing up, five seconds later your Python app is running in a container. Getting that onto the cloud is a different matter — quick to deploy, but a bit trickier to monitor because we don't have access to all the surrounding ecosystem. If you're on a VPS, say two VPSes, each can run Docker Compose, pulling our built Docker image from wherever it lives, which simplifies the VPS or bare-metal setup by removing the need to install lots of dependencies — everything goes in the container, and the only dependency we need on the host is Docker.

We can also use a Compose-like configuration to deploy to a hosted provider — Google Cloud Run lets you provide a configuration for your container and it'll run it on Google's servers for you; likewise AWS provides ECS (Elastic Container Service), where you provide a similar config and it hosts your container happily.

**4. Serverless**

Why worry about a server at all? It doesn't cost much to run, because you only pay while the function is running — for a web app that's typically a request comes in, we process it, and reply, all in well under a second, so you've paid for that tiny snippet of time, which is cheap if you're not getting much traffic. The downside is scaling cost — if you're getting millions of requests per second, all those little charges add up and can end up costing more than owning the server yourself. You can do this on Google Cloud Run, which lets you write a function hosted on Google Cloud, or on AWS with Lambda, where you upload your code as a zip file and it runs when triggered.

You might think you're getting away without worrying about anything else, but you do need extra infrastructure — AWS gives you API Gateway, which takes in the request, passes it to the function, the function does its thing and replies back to the gateway, which goes back to the customer. So you need this extra piece to trigger your function and handle the request/response, a bit like a web server. It can get more complicated still — the gateway could go to the Lambda, which goes to a VPC endpoint, which goes to a database (I haven't mentioned databases yet — that's another complication altogether, but if your Python app needs storage, you'll need a database at some point; for all the options above, a database is usually an add-on service).

**5. Platform as a service**

Heroku gives you a very easy way of deploying your application — you give it a git repository, with some special config in there, and it installs it for you and gives you a server address. Happy days, minimal effort on your part. Railway and Render do similar things, both slightly differently, both with simpler payment plans, and as a platform as a service they give you the extra add-ons you want — need a database? Just add it on. More CPU? Just add it on. Costs can scale up quickly, but they scale with you — start very small, end up very large. At the larger end you're probably better off looking at the VPS or bare metal options.

**6. Managed Kubernetes**

If you've got a lot of microservices to look after — not one app anymore, but 10 or 20 working together — you might need something like a Docker cluster, and one way of doing that is managed Kubernetes (not the only way — I've got another video on Kubernetes alternatives, link below). Touching on the alternatives, there's EKS, GKE, and AKS, depending on whether you're Amazon, Google, or Microsoft flavoured — they're all pretty similar, they all bill slightly differently, and whichever you go with probably makes sense based on where you have the most knowledge, or other services already in that ecosystem. At this level you've probably got a team supporting that decision, and to deploy it you can use Helm charts and other definitions. It costs a significant chunk of money — almost a "stupid tax" — but it provides a lot of functionality on the back end.

**7. A hybrid approach**

We can combine a couple of these strategies to be really strong. Something running on an EC2 machine gives us a baseline amount of CPU compute, relatively cheap compared to Lambda, and we tie that to Lambda to deal with peaks when we're really busy — mixing the two together gives a blend of a cheap base cost and a slightly more expensive peaky cost, to work with traffic that isn't flat and predictable.

**Which one is right for you?**

I've attached a decision flowchart below that goes through the questions — do you need full control over the hardware, do you have a support team helping you, do you have multiple containers or just one to look after. Have a look at the flowchart and let me know in the comments if you found it useful. I've also included a cost comparison chart, giving you the upfront basic costs of an average server that can host more than one container, which should give you a clue.

If you want any feedback, ask me a question below, or come along and ask me at my Q&A — there's an invite link at tech-answers.club, I'd look forward to seeing you there. Anything else I can help you with, ask me a question, and I'll see you in the next video.

Question 36

What DevOps practices and secrets should every software engineer know?

Accepted Answer

**Quick answer:** the DevOps practices most engineers underrate are: writing tests to protect against *other people* breaking your code, not just your own; treating infrastructure as code so environments are reproducible and reviewable; and building small, frequent changes into the habit rather than saving everything for a big risky release.

Hi, welcome back to the channel, I'm Neil Millard, the DevOps expert, here to answer any of your IT questions — if you're in IT and have a question, come ask me, there'll be a link in the comments. Today's subject is DevOps in software engineering — what the heck does that mean? Let's crack on. I'm going to talk through several things: the role of DevOps in software engineering, understanding the historical divide between development and operations, promoting a "you build it, you run it" mindset, implementing cross-functional teams, and techniques for improving collaboration and empathy, which is kind of at the core of what DevOps is about.

**A little history**

Skip ahead if you already know what DevOps is. The goal of DevOps was to reduce context switching and handoffs — you've had the issue before where you ring up somebody and they say "oh, hang on, wrong department, let me hand you over," which is fine, but the two minutes you spent describing your problem, you now have to repeat to the next person — there's no handoff of information between the two parties, and this wastes a lot of time. The biggest handoff in software development is where the developers finish their code and want to get it into production, but production is guarded by ops engineers who don't want anyone touching their precious servers — a bit odd, really, because without software running on them there'd be no point to the servers.

So the initial and most obvious goal of DevOps is to get developers talking to the ops people — hence the term "DevOps." If we get these two teams working together, there's less handoff — developers know exactly how the app works, server operators know exactly how the servers work, and before, there was often little understanding from either party of the other. So let's collaborate — software engineers understand servers, server engineers understand software. Crazy idea, right? That was well over ten years ago now, and you can read more about it in a most excellent book, "The Phoenix Project" — it's a bit of a story, but if you like stories, it's awesome.

**A real example**

How do DevOps practices actually improve stuff? They enable information to be shared between the two parties. Let me give you an example. I was at a customer site, and the developers were developing a .NET application that needed to run on two servers for reliability — if one goes down, the other picks up the slack, or even spread the load between the two. Amazing — except they'd written the application so that every time a customer's traffic moved to the other server, it would ask them to log in again. If you're halfway through a process and the server goes down, or the current server is too busy and your traffic gets routed to the other, less busy one, great — except it asks you to log in again, and you have to start the whole process over. Not a great experience, and the developers couldn't understand why it was happening.

So, with my ops-and-DevOps hat on, I went down to their office in person and sat with them to understand the problem. It turned out the fix was pretty easy — each server had a local database for cached information, and a shared database for session data. That session data was encrypted, which is fine, except each of the two servers was using a *different* encryption key. That meant if you jumped over to the other server, it could see you had session data, but couldn't do anything with it because it was encrypted with the wrong key. So I said, "hey, use the same encryption key across both servers," and — I know, I'm amazing — they did, we deployed it to pre-prod, it worked, rolled out to prod, and the customer experience instantly got 100% better.

This is where talking to each other and understanding things paid off — I needed to understand how the application worked, and they needed to understand how the servers worked, and working together we found the solution.

**The historical divide**

Operations were traditionally very protective of their servers, networks, cables, physical boxes — it's all very complicated, and how could a developer possibly understand any of that? Likewise, the developer mindset was "well, code involves libraries and source code and things, it's very complicated, why would a server person know anything about that?" I've heard software developer friends say "oh, DevOps is so boring" — usually meaning the sysadmin side of DevOps, what a lot of people call cloud engineers, or SREs, which is ultimately systems engineers who happen to store their configuration as infrastructure as code — that's not really DevOps, but I digress.

There was a mindset divide, different priorities, different goals. The goal for sysadmins was to keep the server running with as little downtime as possible — fine, until a developer comes along with a new, not-quite-tested version of their code, loads it onto the server, the ops guys try to follow the README, it doesn't install cleanly, there's a misconfiguration, and two hours later they've done a massive rollback, all on a weekend because that's when servers are least used by customers. A very poor feeling for the ops guys, who tried to do a deploy and got completely stuffed by the developers, and the developers weren't happy either, because they had their lovely code and the "stupid" ops guys couldn't even install it. This went on for years — just throwing code over the wall. Documentation got a bit better, perhaps, but no one thought to put the two teams in the same room, and from that siloed approach came the mistrust between them.

**You build it, you run it**

One answer to this is "you build it, you run it" — developers and ops share responsibility for both developing and running the application. This includes application health (does it actually work on the server), performance (does it work well on a server), and whether servers need upgrading or code needs rewriting — none of those decisions can be made unilaterally, they need to be joint. By working with the operational side, developers got operational experience, understanding how networking and servers work and how that impacts their code, and operations engineers could contribute to the design process — making sure that when you scale an application across more than one server, you're not doing daft things like a different encryption key per server, but sharing the same key across the whole architecture, so everything works smoothly.

**Cross-functional teams**

The easiest way to implement "you build it, you run it" is a cross-functional team — one team containing several developers and several ops/DevOps people, to break down the silos. The smallest team you could get away with is a team of two — one developer, one ops person, pairing together, both learning from the other, both deploying together. A cross-functional team doesn't just cross-pollinate knowledge between the two, it gives them a shared direction to face in. We can reflect this in metrics — shared goals like application uptime, which depends on both developers and sysadmins, and other metrics like server errors or application errors, which are closely linked — if both parties are looking at these, they can work together to solve them, and through knowledge sharing and joint problem-solving you build trust and build the relationship.

In a remote-working world, is that easier or harder? Not sure — we've all got webcams now, like the one I'm talking to you on, so we can set up online meetings, though it's much better to see somebody in person, so onsite or in-person meetups are good too, particularly outside of a work environment — a beer, maybe. I run a monthly tech meetup where I live, called Western Tech Meetup, you should come along.

By facilitating regular meetups and feedback loops, we ensure we're on the same path, sharing ideas, even sharing criticism after a while — if the process is failing, we should be comfortable enough to call it out and resolve it together. If you want to go radical, you can even swap roles — how well can the developer administer a server or application in production, or how about ops writing some code for the application itself? That might sound mad, but especially if you're pairing, swapping who's at the keyboard and who's observing and chipping in can foster a great understanding of each other's challenges.

Of course, something will always go wrong, no matter how well you do it — so by having a trusted, blameless postmortem, going through the events that unfolded, you can solve problems together, building trust and getting to a working solution.

**In summary**

That's what I've got for you today — we covered the role of DevOps in software engineering, understanding the historical divide, promoting a "you build it, you run it" mindset, implementing cross-functional teams, and techniques for improving collaboration. If you've got any questions for me, head over to devops-answers.com, or stick them in the comments below — I love answering questions, I love helping IT professionals, and we can work together and collaborate soon. Until then, may all your deployments go smooth.

Question 37

How do apps handle massive traffic spikes like Black Friday without breaking?

Accepted Answer

**Quick answer:** handling a traffic spike like Black Friday means balancing headroom against cost — auto-scaling rules that add capacity ahead of predicted demand (not reactively, once it's already struggling), caching aggressively at the edge to keep load off origin servers, and load testing at realistic peak volume beforehand so the first time the system sees that traffic isn't the day it actually matters.

Hi, I'm Neil, a DevOps expert, and today I'm going through the Black Friday challenge — that time of year in e-commerce that's high traffic and resource intensive, where you've got to balance high turnover against the high cost of cloud resources. Let's go through the steps: planning, real-time monitoring, autoscaling in action, and financial controls.

**Pre-planning**

We can look at last year's stats — how busy was the website last year? Analyzing the previous Black Friday's traffic helps us understand what might happen this year. We can run load tests against the app in a pre-production or dedicated performance environment, to see how much traffic we can throw at it before it breaks — that gives an indication of where a bottleneck is, or where a bug fix could make things go faster. We can calculate the resources required to run at specific levels, and therefore how much it's going to cost, and use this data to set thresholds so we know when things are getting busy — and of course we can use GitOps to help set all this up.

**Real-time monitoring**

Once we're in the Black Friday period, we should be monitoring so we have a clue what's going on. Key metrics to watch:

- **Request times and request rates** — how many requests we're getting per second (or smaller units for a really big site), so we understand what's going on with our servers. Each request will also have a response code, delivered after a certain response time, so we can see how long requests take and what code results. Most of the time it'll be a 200, meaning everything went fine — if we get errors, we should track those, since an error might be a bug or a bottleneck somewhere else.
- **CPU and memory usage** — adding more CPU or memory might help next year, or right now if we've got autoscaling set up (more on that below).
- **Error rates** — some errors are expected at a certain baseline level, because stuff always breaks, and you need to be ready for that. Error rates can spike when a specific microservice is hit, or when the database slows down, or something else — as they increase, they give us more data to make the system better next time.
- **Cost** — while the system is running, we can work out cost per hour, per minute, or even per request. This gives us information to plan later, or to make a real-time decision about whether we need to scale immediately.

**Autoscaling in action**

There are two types of scaling: horizontal and vertical. Horizontal scaling is where we take the same cookie-cutter process — a server, a virtual server, a container — and stamp out more of them, so we can go from two servers to four to eight to however many it takes for the workload. Vertical scaling is where we make the resource itself bigger — give that virtual server more memory or more CPU. There are pros and cons depending on where you are and what layer needs fixing — it's quite common for web or proxy servers to scale horizontally, and for database servers to scale vertically, and of course you can blend the two.

For scaling policies, we want to know when to scale up, and more importantly when to scale down. You might have a policy that says "CPU usage above 70% for 5 minutes, scale up horizontally, add another unit to the server farm," and then scale down again if it drops to, say, 10% CPU usage. But don't be fooled — that sentence hides a lot of complexity. Scaling down is hard — what do you do if there's a request already in flight? Make sure that node isn't handling any traffic before you kill it. The other gotcha is you don't want to be flapping — scaling down, then up, then down, then up — so you want a scale-down cool-off period to make sure the spike has really gone, and you're not just idle for a few seconds.

While we're talking about load and scaling, have you thought about regional distribution? Some providers let you put servers closer to the customer — if you're in the US, servers on the West Coast and more on the East Coast, distributed to match where the traffic is.

**Financial controls**

Scaling up costs more money, so we want cost monitoring and cost alerts in place — this lets us understand how much we're spending in real time, and whether we're spending too much or too little against our forecasts. Alerts tell us when we hit certain thresholds, and our configuration will usually have a maximum already defined — a system alert that says "scale up until you hit a maximum of 32 instances," and at that point it doesn't matter if CPU is still above 70% for 5 minutes, don't scale up any further. Sometimes that's okay — a customer hits the limit, sees "sorry, we're busy, try again in 5 minutes," and for your business that might be an acceptable trade-off.

Another way to control costs is paying upfront for a discount — if we know we're going to be busy and use a certain amount of resources, will our supplier give us a discount for money up front? In AWS this is called reserved instances — you reserve an instance up to a specific amount of usage (all day, or half the day) for a specific term (1 month, 3 months, a year, 3 years), depending on the expected workload. For particularly spiky traffic or short durations, spot instances can be useful — much cheaper than on-demand pricing, but very temporary, and can be shut down with two minutes' notice. Finally, tag your resources so you can attribute cost to a specific project, which lets you analyze costs further.

**Pro tips and best practices**

- Don't optimize first — load testing is your friend. Run the load tests, find out what actually needs optimizing, then optimize it. Don't guess, you're wasting time — find the limits and bottlenecks, and that tells you what to optimize.
- Some things are too expensive to scale, like an Oracle database that charges per CPU — that's a lot of backend cost just for a temporary change. Maybe there's a better way, like adding a caching layer (a query cache in front of the database), or putting things into a queuing system so they can be processed later, once the system catches up.
- Understand your budget — scaling will cost money, so you need to know how much budget you have to set those top limits.
- Traffic management — sometimes it's okay to put a customer in a queue and make them wait a little longer, if you're hitting the top limits of your resources.
- Top tip: don't deploy changes to your infrastructure at peak times, even if it's struggling — resist the urge to change anything, or you might give yourself proper downtime during the event.

Once the event is over and the dust has settled, make sure everything has scaled back down — you don't want to keep paying for capacity you're not using. Review the effectiveness of the scaling you had in place, particularly around error rates, and analyze the costs: how many transactions did you do, how much did it cost you to do them, was it worth the extra cost? Only your business can tell you that.

I hope that gives you a great idea of what you can do about the Black Friday chaos coming up in a couple of weeks. If I can help in any other way, reach out, and I'll see you next time — may all your deployments be smooth.

Question 38

What are the most valuable insights from experienced DevOps engineers?

Accepted Answer

**Quick answer:** across conversations with experienced DevOps engineers, a few themes recur: automation isn't always the answer (some manual steps are cheaper to keep than to automate), communication and stakeholder skills matter as much as technical depth, tool choice should follow the team's actual constraints rather than what's trendy, and having a clear rollback plan matters more than trying to prevent every possible failure.

Hi, welcome back to the channel — today I'm talking about the six things I learned talking to 50 DevOps engineers (actually nearer 100, probably) over the course of a year. We're going to talk about why automation isn't always the answer, the unexpected skill that matters more than technical expertise, how to approach tool selection, and what to do when things go wrong.

**1. Automation isn't always the answer**

Should you automate everything? Mixed response — most engineers said no. So what do you automate, if not everything? DevOps engineers focus on giving business value first — understanding the pain points of the business and fixing those first. Pain points are often created by two things: manual entry going wrong (relying on a user to give correct information, which the computer then follows blindly until something breaks downstream), or a long, boring process where people just make mistakes. If we can automate those steps, we reduce the mistakes.

Automation is only worth implementing where it genuinely improves the process — there's an XKCD comic about exactly this: here's how much time you spend on a process, here's how much time is worth spending automating it. The engineers I spoke to also asked "should we" before "can we" — the first reason to automate something needs to be a good one. What sort of tasks are we talking about? Number one is the deployment process, but that's huge, so start with a small piece — maybe the software build, maybe testing, maybe creating the artifact, maybe setting up the deployment environment, or the deployment itself. Take each piece, automate it a little, and eventually you end up with a whole CI/CD pipeline once they're joined together.

**2. Communication matters more than you'd think**

The second thing good DevOps engineers do is communicate. Bridging the gap between development and operations is crucial. The best engineers are excellent at explaining complex problems or concepts simply. DevOps and development environments are very complicated, and the people paying you — the ones who can write the cheque — aren't necessarily as technical as you are (why else would they be hiring you?). So you need to explain, a bit like sales, the benefit of doing certain things: "yes, this takes a couple of weeks, but once it's done, your users save themselves an hour every time they do a deployment" — a cost-benefit analysis.

The concepts can get wider than that — trying to explain Kubernetes to a non-technical stakeholder, maybe just call it a magic black box, but explaining what a Docker container is might be useful if they ask. The best engineers understand the fundamentals well enough to explain step by step what each bit does. This does mean that most top DevOps engineers spend a significant chunk of their time — somewhere between a fifth and half — in meetings and documenting: meetings to shape direction, gather information, and influence, and documentation on the back end so the knowledge can be shared with whoever comes in to look after what we've put in place. Part of DevOps is planned redundancy — we come in, make stuff better, and go away again — but to go away cleanly, we need documentation so those following in our footsteps understand what we meant, how to look after the thing, and what to do when it goes wrong.

**3. Tool selection**

Good engineers understand principles over specific tools — knowing how a hammer, a nail, and a wall work so you can select the correct hammer, or stepping back further and realizing you actually need a screwdriver, not a hammer at all. There are lots of tools available to the DevOps community, and they can be a hindrance or a benefit depending how you use them. Great DevOps engineers can also adapt to different tech stacks and platforms — you're rarely walking into a greenfield site, there's usually stuff already there, not optimal, not working as well as it could, and you have to take that stack, those tools, and that platform, and change small bits at a time to make the whole thing run smoother. Sometimes that means ripping out a tool and replacing it, but that's usually not the first answer — understanding the tech stacks and principles well enough lets you guide the customer through incremental improvements instead.

DevOps experts also focus on patterns and practices that work across tools. If teams are siloed — often for good organizational reasons, but not necessarily the best way for them to work together — you get handoffs, and handoffs are deadly for a process: somebody has all the context on a thing, and has to somehow impart all that information to somebody else. If you're sitting right next to each other, that's easy, you can pair on it. If you're just writing a Jira ticket and expecting somebody else to read and fully understand it, that's a lot harder. Changing that pattern and practice, to remove the handoff between dev and ops, is one of the reasons DevOps exists.

**4. Incident management**

Having a structured approach to handling failures is critical — stuff will go wrong, I guarantee it, usually because several small things conspire together at once; any one of them alone wouldn't cause a problem, but three or four stacking up is enough chaos for something to break.

First, you've got to spot the failure — logging, monitoring, alerting — but with the right amount of alerting, so you don't go noseblind to red alerts. Once you've identified the error, is there an easy fix? Maybe we can automate fixing it, or stop it happening again. If it's a chunkier error, that's a different path — the postmortem. Postmortems are learning opportunities, not blame sessions — we don't want to know who caused it, we want to know what went wrong, when, and what we can do to fix or prevent it, and if we can't fix or prevent it, at least find a workaround that minimizes impact.

These engineers also build systems expecting failure to happen — monitoring in place to tell us when stuff goes wrong, maybe an automated attempt to fix a couple of things before a human needs to get involved. One cloud approach is making servers or containers replaceable — if one fails, it gets killed and replaced as quickly as possible, completely automated, with a record kept so we know if it happened too often or for too long and there's a root cause to investigate. Ideally, the users running on the system never notice a thing.

**5. Security first**

Security is built into the process from the start, not bolted on afterwards. Continuous security scanning and testing is standard practice, part of the build pipeline — we want to know everything is secure, from the hosting to the code to the libraries and dependencies, and because we've got automated testing in place, we can catch vulnerabilities before we even deploy, and fix them right away. It's a first-class citizen, a feature, not an obstacle. Keeping the right people in and the wrong people out is very important — security breaches involving usernames and passwords are horrendous PR and bad for your customers, and can genuinely lose you customers. Keep the data safe, and treat security as first class.

**6. Continuous learning**

This field changes rapidly, and we have to constantly adapt and learn — if you don't, you stay in the same place, or worse, get left behind. The engineers I spoke to dedicate time weekly to learning new tools and practices, staying up to date with trends — containers were once new, serverless was once new, AI may be a thing now, and whatever's coming next, we need to keep our eyes on it. As a side note, most of the people I spoke to have active side projects — partly to keep their minds from going stale, and partly as a way to test new tech, like setting up a home lab with Docker containers or a couple of graphics cards to see what AI is all about. Being able to mess about with this stuff in your own space, in your own time, keeps you fresh — it's certainly something I do a lot of.

So those are the six things I learned speaking to over 50 DevOps engineers. Got any questions? Head over to devops-answers.com, link in the description, where I'll give you the opportunity to ask me questions in a group session. I hope you found this useful — until next time, may all your deployments be smooth.

Question 39

How do you navigate the DevOps toolchain without getting overwhelmed?

Accepted Answer

**Quick answer:** navigating the DevOps toolchain without overwhelm starts with grouping tools by the problem they solve (source control, CI/CD, infrastructure as code, monitoring, secrets) rather than trying to learn every tool in every category — pick one solid, well-supported option per category that integrates with what your team already uses, and resist adding a new tool unless an existing one genuinely can't do the job.

Welcome back to the channel — today we're talking about navigating DevOps toolchains: what the tools are, what categories they fall into, which ones are right for you, how they fit together, and then maintenance and evolution, because nothing stands still.

**Where does the tool live?**

Before the categories — as with everything in computing, a tool can be local/data-centre, or in the cloud. It might be **software as a service** (somebody hosts it on the cloud, you get a login, create an account, off you go), **self-hosted** (on-prem, in your own data centre, or hosted by you in the cloud — you look after the whole thing: the machine, installation, patches, updates), or a **hybrid** — some of the tool in the cloud, some more local. The classic example is CI/CD, where the main thing might be in the cloud but you run local agents on machines you control.

**Version control**

Version control comes in two parts — a server element, where you back up or save your source so it can be shared with the team, and a local component on your development machine. There are two main types worth mentioning: Subversion (SVN), with clients like TortoiseSVN and servers like SourceForge, and Git — much newer, developed by Linus Torvalds, the same guy behind the Linux kernel — which also has a client/server setup: a local client on your machine, and a server you can SSH into to push your source code. On top of Git you've got feature-rich hosting like GitHub, Bitbucket, or GitLab, all of which come with self-hosted versions too — GitHub Enterprise if you've got the budget, or GitLab, which has an open-source self-hosted edition you can install on your own hardware or VMs.

**CI/CD**

If you're using GitLab or GitHub for source control, they come with CI/CD options out of the box. GitLab CI uses YAML to configure runners, and you can run this hybrid — GitLab as SaaS, but your own runners acting as agents locally or in a data centre. Same for GitHub — GitHub Enterprise if you want to self-host, or GitHub as SaaS with your own private agents executing your Actions.

There are plenty of other CI/CD tools — Concourse, largely built around Docker-based setups, with its own server and agents, and the granddaddy, Jenkins, usually self-hosted, though some companies offer a SaaS version too. Either way, you need to look after your agents and make sure they have what they need — most of these tools let you use Docker-based agents so you can spin them up and destroy them quickly.

**Monitoring and logging**

Everything needs to be monitored — how else will you know it's broken (or not)? SaaS options include Datadog and New Relic; self-hosted options include Nagios, Prometheus, and Grafana. These all have similar components: an admin layer for managing users, a database layer where the metrics flow in (watch the size — that grows fast; two weeks' retention is usually enough for production issues to be spotted and diagnosed), and a reporting/visualization layer — dashboards, graphs, all the pretty stuff.

Monitoring also gives you a third element: alerting. You have a baseline, and when something absurd happens — traffic dies, or spikes — you want to know straight away, so alerting tools like Sensu, PagerDuty, and others plug into these systems. Logging sits slightly outside all this — you can create metrics from logs, but logs carry the actual detail of what the application is doing (who accessed what URL, which user, and so on) — again, watch how much you retain, it takes up a lot of space.

**Infrastructure as code**

Tools like Terraform create your infrastructure, and importantly can detect drift and destroy infrastructure too — important for keeping a handle on cost, because cloud providers are very good at inviting you to create things and then billing you for them; you need to be responsible about pruning what you don't need. Infrastructure as code can also be managed directly by cloud providers — AWS has CloudFormation, Azure and Google have their own equivalents — but Terraform can control those too, across providers.

**Configuration management**

Once infrastructure is configured — firewalls, subnets, networks, a couple of servers spun up — we need to tell the servers what to do. The tool of choice is usually Ansible, or if you prefer a more declarative style, Chef or Puppet, and there's also SaltStack if that's your thing.

**Containers**

Container solutions exist for cloud, local, and hybrid deployments. Docker on its own is great — a machine just hosting Docker, with something else managing what runs on it, like Docker Swarm, or scripts, or Docker Compose for something a bit more elevated. Or you might want Kubernetes — practically a data centre in itself, with load balancers, ingress gateways, monitoring, everything you could possibly need, and a price tag, support burden, and learning curve to match. To pare that down, AWS offers ECS, a bit like a more advanced Docker Swarm (which isn't really being developed any more, now ECS exists) — Google Cloud has a similar offering with Kubernetes under the hood too.

**Artifact stores**

Once you're building and compiling code through your CI/CD pipeline, it needs to store that output somewhere safe. JFrog Artifactory is very popular — available as SaaS or a licensed self-hosted version. Nexus is another option for storing certain artifact types, and if you're just dealing with Docker images, you could run your own Docker registry.

**Cloud platforms**

The final category — public cloud, like AWS, Azure, Google Cloud, or smaller players like Hetzner and DigitalOcean, all providing an API that Terraform can talk to: "give me a server," and billing starts once it's built; configuration management then makes that server useful. You can also go private — if you want more control and cheaper, more robust hardware than the commodity servers cloud providers charge you for, you can run your own APIs on top of it with OpenStack or VMware.

**Evaluating and integrating tools**

How do you evaluate all this? Watch out for knowledge bias — if you've used a tool before, you'll gravitate to it, which is fine because of the learning curve, but it might not be the best tool for the job, so evaluate other options too. A community helps you bounce ideas around here.

Some tools integrate really well together — Grafana works well with the ELK stack and a load of other things. Check whether SaaS options work well with GitOps, whether they fit into pipelines, and whether they have a command-line interface or require going through an API — we want these things to talk to each other, be automatable, and be user-friendly.

**Maintenance**

If it's self-hosted, you're on the hook — if JFrog announces a new patch version for Artifactory, you install and upgrade it yourself (maybe with some vendor support). SaaS versions cost a little extra, but the provider takes that responsibility off you, making life easier. Review things regularly to make sure you're patched with the latest security releases, and don't forget new tools keep appearing — Kubernetes didn't exist 20 years ago, and today's established tools keep shipping new features too.

So that's a summary of a lot of tools across the DevOps space — self-hosted, SaaS, and blends of the two. Don't always default to the tool you've heard of — there might be something better, and next week there might be a new tool none of us are even aware of yet. Got any questions? Stick them in the comments below, or find me on LinkedIn — I'm also running live Q&A sessions soon at devops-answers.com. Until next time, may all your deployments be smooth.

Question 40

What is cloud computing and how does it fit into the DevOps era?

Accepted Answer

**Quick answer:** cloud computing — renting compute, storage, and services on demand instead of owning hardware — is what made DevOps practical at scale: infrastructure as code, auto-scaling, and managed services only work because the underlying infrastructure is API-driven rather than a physical box in a server room, which is why DevOps as a discipline grew up alongside the major cloud providers.

Welcome back to the channel — today I'm talking about embracing the cloud: what it is, how it can help you, mistakes to avoid, and specifically how DevOps sprung out of the cloud (or did the cloud create DevOps — who knows). I'll also touch on infrastructure provisioning, since defining infrastructure is a big part of the cloud, and serverless computing, since there's no point having the cloud unless you can use serverless — we don't want to look after servers, right — and managed services.

**What is cloud computing?**

Cloud computing is using someone else's hardware — essentially everything that's not on-prem is public cloud computing (there's also "private cloud," but we're not talking about that today).

**The rise of the cloud**

Before AI, before Kubernetes, Amazon Web Services was created in about 2001 — yes, that's a long time ago. They started with S3, a way of storing data securely with lots of nines of durability, so it doesn't go walkabout (keeping the data safe is very important). Shortly after, they developed EC2, Elastic Compute Cloud, where you can request a virtual machine on demand — again, back in 2001, before AI, before Kubernetes, before serverless was even a thing.

Why does "elastic" matter? The whole point of elasticity is being able to pay for exactly what you need. If your application runs fine on one server, only pay for one server — but if it suddenly spikes on a Friday afternoon because all your customers want their stuff done before the weekend, and you need four servers, traditionally, running on-prem, you'd have to have those four servers running all the time. The advantage of cloud elasticity is you can borrow somebody else's servers for when you need them — spin up four servers for the Friday afternoon rush, then by 6pm, when everyone's down the pub, spin them back down to one, and everything's happy for the weekend. We've serviced those customers without paying for four servers all week.

For that to work, servers need to be able to spin up as quickly as possible — there's no point having a server if it takes ages to build. In the days of CD-ROMs, and before that floppy disks, building a server could take days. With cloud and online networking, we can get that down to five minutes, sometimes less. Public cloud providers also want a self-service portal, so you can request servers yourself — after all, they can't start billing you until they've delivered the service — and tools like Terraform let us do this even faster than clicking through a console.

The downside is that on-demand computing costs money (I've got another video on why AWS servers cost so much — link in the description) — the short answer is, while that server exists, somebody's got to pay for it.

**Pets versus cattle**

This led to the next big idea in cloud computing: pets versus cattle (I believe a Microsoft person coined the term). In the old days, a server took ages to arrive from the supplier, you spent days building it, and then you nursed it — redundant power supplies, redundant CPUs, redundant everything, because it's the only one you've got and you don't want it to die. It's your pet. The cloud flips that on its head — if you can have a server up and running on demand within five minutes, and switch it off as soon as demand disappears, then it's like cattle: you raise it, it's useful for a while, then you retire it. A bit brutal, but if you can automatically build your servers, you don't need to treat them like pets.

**Provisioning and configuration**

Where do these servers come from? Ultimately, the cloud API — whether Linode, AWS, or Azure, they all have APIs where you can request a server with a given amount of CPU and memory, and bolt on a couple of disks. Cloud APIs can be a little clunky and change constantly — just look at how often the Terraform AWS provider gets updated.

To help us, there's configuration management. Once the cloud API spins up the server, we need to configure it — step one, get the server (like ordering hardware), step two, configure it: load the OS, load all the software, configure the settings, user accounts, and so on. Configuration management tools like Puppet, Chef, or these days most commonly Ansible, handle this — you load your configuration, the server spins up, asks "what's my configuration," and an Ansible playbook configures it in a couple of minutes, ready to work for you. Bundling the API calls together in Terraform modules, plus Puppet, Chef, or Ansible for configuration, is what we mean by configuration as code.

**Other cloud tools and services**

Besides the big cloud services — Azure, Google Cloud, AWS — there are other ways of accessing the cloud, like Microsoft 365 or Google Workspace (email, Word, spreadsheets), which also run on somebody else's computer, so they qualify as cloud too — the software developer builds the software and sells it to you monthly along with the servers needed to run it, they make more money, you get more convenience, win-win.

Then there's serverless and managed services — S3, as I mentioned, definitely uses servers, but you don't look after them. Same with the Google AI Platform, Amazon RDS/Aurora (a database service where you don't manage the backend), GitHub Actions, or Cloudflare for WAF and CDN needs — all of these use servers, none of which you touch directly, because you don't need to look after them, but they're serverless and they're cloud services.

**Migrating to the cloud**

The scariest phrase you can say to any engineer is "lift and shift" — don't do that. If you're just going to lift a server and shift it into the cloud unchanged, you might as well keep running it on your own hardware — you won't save money, because you'll pay for the hardware, the data centre, and the software still needs looking after. You're wasting your money, and the server you've already got may well be more resilient — cloud providers don't always tell you their commodity servers are cheap precisely because they're expected to fail, with no built-in failsafe. S3 works so well because it's thousands of servers working together with replicated data — if one dies, no impact on the service. If you've got one server running a service and it dies, that's a direct impact on you.

If you're migrating a cluster, there might be some gains, but the real gain isn't in lifting and shifting — it's in re-architecting your software so it can automatically scale, following demand as it ebbs and flows through the day, rather than paying for the peak number of servers you need all the time. That, plus using managed services so you don't have to look after servers at all, are the two big reasons cloud computing can save you time and money — and saving time means not paying engineers so much for undifferentiated work.

**In summary**

We've covered the cloud services themselves — AWS, Azure, Oracle, OVH, DigitalOcean, Linode, and plenty more — and whichever you choose, you don't have to lock yourself in if you're using infrastructure as code; tools like Terraform let you blend providers, though I wouldn't recommend it for a single service, stick with one platform there. Being multi-cloud in the broader sense (Microsoft 365 for productivity, AWS for servers and databases) is fine, but spreading engineers thin across every cloud provider's quirks costs more without much benefit. With infrastructure as code, Terraform links into the cloud APIs to provision servers, then configuration management gives them a personality and gets them working for you in as little as five minutes.

Other tools worth mentioning: managed services, online office and collaboration tools, managed infrastructure like databases, and of course, containers. If you're migrating and adopting the cloud, please don't lift and shift — it'll cost you more in the long run. Use the cloud-native features, and look at something like the Twelve-Factor App methodology, which lays out the factors that make an application flexible and cloud-ready.

Any questions, put them in the comments below, I'd love to answer them — until next time, have fun, and may all your deployments be smooth.

Question 41

How do you use declarative provisioning to manage DevOps infrastructure?

Accepted Answer

**Quick answer:** declarative provisioning means describing the infrastructure you *want* (a config file stating "3 web servers, this database, this network") and letting a tool like Terraform or CloudFormation work out how to get there, rather than writing imperative step-by-step scripts. The benefit is that the same file is both documentation and the single source of truth, and re-running it is safe because the tool only changes what's actually different from the target state.

Hi, welcome back to the channel — today we're talking about infrastructure as code: what it is, the benefits, the tools that help you handle it, and managing it day to day.

**What is infrastructure as code?**

To me, infrastructure as code is storing your configuration as code that can be tested, deployed, and maintained in a repeatable way. We want infrastructure we can repeatedly install and deploy as many times as we need — tear it down, set it up again. Some people tear down their whole dev environment on a Friday, because there's no point paying for it over the weekend if you're on a cloud provider — that's one way cloud can be cheaper than running your own data centre — then Monday morning, an automated process creates it all from scratch again.

We can do this because the infrastructure is defined in code, which means we can test it — statically, or by running real tests against it — and deploy it again and again. Why does this matter? If it's repeatable, it's less effort. Are you afraid your server might fail or get deleted? Not if everything's backed up — keep the data safe, keep the configuration safe, and you can restore everything exactly as it was.

**What counts as infrastructure?**

Servers, networks, the rules governing access and security around them, where the logins go. Application configuration — what your application needs to run, the name of the environment, the subnet, even the subnet definition. Servers where the code runs — we can tell the code it's scalable, what the minimum number of instances is (one, two, three) and the maximum we want to spend on scaling up. When we scale down, we lose any data on those servers, so where do we back that up to? Most of the time it's just the logs — we're not editing code live on production servers, so we keep those logs and the monitoring data somewhere safe, and the server itself can be destroyed easily. Networking matters too — servers need to survive in a network, they're pretty useless if they can't talk to anybody else.

**What does the code look like?**

Some tools come with their own language, like HashiCorp's, and others just use YAML, depending on the tool. Let's talk about the tools: Terraform, Ansible, and something to run the pipelines, like a Jenkins server.

**Terraform**

Terraform uses HashiCorp Configuration Language, and can go cross-cloud with multiple providers and modules. Providers expand core Terraform with functions for a specific upstream API — AWS, Google Cloud, Azure, all have APIs we can manipulate through a program, and in this case that program is the Terraform provider. The AWS Terraform provider talks to the AWS API, so using Terraform, talking to that provider, we can create and destroy AWS resources; similarly, a Google Terraform provider talks to the Google API. There are many, many providers available, from hardware to software — there's even a JFrog Artifactory provider, so you can configure your local Artifactory instance through Terraform code.

So we've got Terraform and a provider that knows how to talk to the API — but what tells it what to actually do? That's defined in modules. You don't have to use modules — you could have one massive file with a main file, outputs, and variables all together — but that gets unmanageable fast. Most configurations I see have a main.tf with outputs and variables, defining which modules to pull in, and each module in turn has its own main file, outputs, and variables, so you can tell each module what you want, it does its thing in the main file, and reports back what it did via its outputs. Terraform allows a lot of flexibility in how you split files — in fact, when it runs, it concatenates all the .tf files together and runs them as one — but for us humans, it's better to name things sensibly, splitting a module's infrastructure component from its security or access component, say.

**Ansible**

The next tool that often comes up alongside infrastructure as code is Ansible. Ansible does something slightly different to Terraform — it's configuration management. It also uses YAML, and has a similar concept to modules, except in Ansible they're called roles. A role structure has its own convention, again best practice to separate things out — at bare minimum it just needs a `main.yaml`, which has to exist, but you can expand it with separate YAML files for more detail. For example, the main YAML might detect whether the operating system is CentOS or Debian, and include the relevant file accordingly — most roles are set out this way to be cross-compatible with multiple operating systems.

Each role has a given goal — managing a Jenkins deployment, or a web server, say — and you can combine multiple roles into one host configuration, so the host says "okay, I'm a Jenkins server, and I need whatever else that role requires" (Jenkins has dependencies, so you might also have a role that says "I need to be a server capable of running Java").

**Managing it as code**

Because it's code, we can use our normal code tools to manage it — git, and because it's in git, we can execute it in pipelines through our CI/CD server (ironically, you could set up a Jenkins server using another Jenkins server — probably not the best idea, a chicken-and-egg problem, but I digress). Once we've got the code, we can version control it, manage it, share it, and run it as we see fit — and if it's in a CI/CD pipeline, we can test it too, using the testing tools available in both Terraform and Ansible.

**In summary**

Terraform, HashiCorp's tool, runs infrastructure as code that we store in a git repository and run through a pipeline system like GitHub Actions, GitLab, or Jenkins. This creates a remote state file, which we need to keep safe, so Terraform can tell what's changed and what hasn't. Through its providers, Terraform talks to whatever API it needs — GitHub, AWS, Google Cloud — and we can run this code over and over to keep everything up to date, or scale down by running init, plan, and apply, and then destroy at the end of the week, ready to build it all again Monday.

Ansible then comes along to help configure the servers Terraform created — we add hosts to an inventory (a list of hosts and the roles they have), put those together in a playbook, and the Ansible server uses the playbook to assign roles to servers in the inventory. Once Terraform has created the servers, Ansible configures them so they're ready for work.

These aren't the only tools that do these jobs — if you don't need to go cross-cloud, you might define things directly in CloudFormation for AWS, or the Azure/Google Cloud equivalents. For configuration management, besides Ansible there's Chef and Puppet, which are closely related, or SaltStack if you want to go a bit left-field.

I hope this has been useful — any questions, put them in the comments below and I'll answer as best I can. Until next time, may all your deployments be smooth.

Question 42

How do containers streamline deployments beyond just Kubernetes?

Accepted Answer

**Quick answer:** containers streamline deployments beyond orchestration by packaging an app with its exact dependencies once, so it runs identically on a laptop, a CI runner, and production — you don't need a full Kubernetes cluster to get that benefit; a single container on a small VM or a managed container service already removes most "it works on my machine" problems.

Hey everyone, welcome back to the channel — today we're talking about containers, a vital tool in any DevOps engineer's toolbox, and it's not just about Kubernetes. Containers are light, agile, and get stuff done, and they don't always need a fully fledged Kubernetes cluster to be useful. Let's get started with the basics.

**What is a container?**

Imagine your application running in a container — in DevOps terms, containers hold all of your application code and all the dependencies that go along with it, so it can run as one single package. The advantage of these little packages is they're small, lightweight, contain everything they need, and run just about everywhere. The most popular container tech out there is Docker — think of a container image as a blueprint: once you've built it, you can create multiple copies of that same blueprint, all exactly the same.

Containers give us the "build once, run anywhere" mentality and ease of deployment — this solves the classic "well, it works on my machine" problem. If a developer can build it into a container, it'll work the same way on their machine, a colleague's machine, a cloud server, or that dusty old server in the corner of the office nobody's ever switched off.

**The benefits**

- **Consistency across environments** — containers eliminate the "works on my machine" scenario; your code behaves exactly the same in dev, staging, and production.
- **Isolation and security** — each container is isolated and runs in its own little bubble, so one bad app can't bring down the whole fleet.
- **Scalability and resource efficiency** — because the image only contains exactly what it needs, it's lightweight, so you can deploy it without the overhead of a full virtual machine.
- **Rapid deployment and rollbacks** — containers deploy really quickly, which means if something goes wrong, you can roll back to the old version just as fast.

**Where to deploy your containers**

Container deployment isn't just about Kubernetes — while Kubernetes might be the star player, it's not the only option:

- **Docker Swarm** — like Kubernetes but simpler and more straightforward, native to Docker, so great if you've already got Docker. An all-in-one ecosystem, easy to set up, less complex, and good for smaller deployments.
- **Amazon ECS** (Elastic Container Service) — great if you want managed, scalable clusters without diving deep into Kubernetes. Amazon also offers EKS, a managed Kubernetes deployment giving you the full Kubernetes experience with AWS doing the heavy lifting. Azure offers Container Instances and a managed Kubernetes experience too.
- **Virtual machines or bare metal** — you can also deploy containers directly here, which gives you the most control, and is a good fit if you're working with sensitive data or legacy systems that need custom configuration or hardware.

So which deployment solution should you use? In classic consultant-speak, it depends. If you're looking for simplicity and a quick start, Docker Swarm or container instances might be your best bet. For larger, more complex systems needing robust orchestration, Kubernetes — either on AWS (EKS) or Azure — is the way to go. For fully managed, scalable environments with tight cloud integration, look at ECS. Your choice should align with your specific workload, team expertise, and long-term strategy.

**Containers and CI/CD**

Of course, we're DevOps, so we can't skip CI/CD — a good container isn't much use if it's not seamlessly integrated into your delivery pipeline. Integrating containers into your CI/CD pipeline gives you a clear path from code to production — building images, running tests in isolated environments, and deploying updates at speed. Tools like Jenkins, GitLab, GitHub, and Azure DevOps all have built-in support for container-based workflows, making your deployments a breeze.

That's the lowdown on containers beyond Kubernetes — whether you're deploying to the cloud, on-prem, or somewhere in between, containers give your DevOps workflow real agility, and the right deployment strategy will keep things running smoothly no matter the situation. Drop your questions and thoughts in the comments below, I'd love to hear about your container journeys — until next time, keep your deployments smooth.

Question 43

How do monitoring, logging and alerting work together in a DevOps environment?

Accepted Answer

**Quick answer:** monitoring collects and displays current state (is it up, is it healthy), logging records detailed events for after-the-fact investigation, and alerting turns a monitoring signal into a notification a human acts on. They work together as a pipeline: monitoring spots that something is wrong, logging tells you why, and alerting makes sure the right person finds out in time to act on it — skipping any one of the three leaves a gap.

Welcome back to the channel, I'm Neil, and today we're going to talk about monitoring and observability — what monitoring is, collecting and analyzing it, some tools to help you do the job, and alerts, or how not to end up staring at a sea of red.

**What do we mean by monitoring?**

I'm talking about metrics — the numbers we need to monitor. Then there are logs, which tell us more detail about what's going on, situational awareness, like errors. And tracing, a bit of the puzzle not everyone touches on, more on that in a moment. Why does it matter? In a software delivery team, fast feedback means you can fix things faster — if it's broke, fix it; if it's not broke, don't fix it. I can't stress that second part enough.

**Logs**

Logs are about the detail. You need to find where they live first — some on the servers, some from the application itself (someone logged in, someone's password expired, someone tried to access something in the database without permission). What gets logged is entirely up to whoever wrote the application. If you're running web servers, you might want access logs — who's accessing your application, from what IP address, which pages they visited. And error logs — arguably the most important, since knowing what the server knew when an error occurred helps developers fix the problem.

**Metrics**

Metrics are mainly numbers — performance numbers (how fast is it running, is it degrading), session counts (how many customers are using the application at once, since more concurrent users means more load), and error counts. Not all errors are fatal — some are just warnings, some are serious, like disk usage: a warning at 80% and a hard error at 90%, so you can avert disaster in time. And dashboards, somewhere to display all this so you can see at a glance what's going on.

**Tracing**

Tracing an application is more advanced — synthetic journeys, which you may already have from user acceptance testing, let you spot how fast things are going: how long each function or step took, in milliseconds. More often than not, the bottleneck turns out to be the database — how long a SQL query took, and whether it can be optimized. At a basic level, stack traces are a form of application tracing too — when something crashes, does it come with a stack trace alongside the error message? That gives a lot of clues on how to fix the thing.

**Tools**

We've got tools to make this easier — a data server for storage, data collection to get the information in, and data display to show it to ourselves, our users, and management.

**Prometheus** is widely used and very good at handling metric data — not as strong at logs, though it can do that too. Data gets published to the Prometheus server, either pulled or pushed depending on the collector, then stored in a fast database, because metrics come in fast. Something then hangs off the end to visualize it.

The **ELK stack** (Elasticsearch, Logstash, Kibana) is the other major option — Elasticsearch for storing the data, Logstash for gathering it, Kibana for visualizing it. Elasticsearch is better at storing logs than metrics, but it can store both.

For data collection, Prometheus relies on collectors, plus a push gateway for pushing metrics and logs in. The ELK stack uses Beats and other integrations. For visualization, Prometheus commonly pairs with Grafana (a separate package that also works with other data sources), while the ELK stack comes with Kibana, which is great for searching logs but can also display graphs and metrics.

**Alerts**

So what do we do with all this data — how do we know when something's gone wrong? Alerts, based on metrics, based on a baseline — what does "normal" look like. If you know what normal looks like, you know what busy and slow look like too, both useful when tuning servers and capacity. Alerts tell us when something's abnormal — often you want to know when something's too busy, so you can trigger automatic scaling, or get a human involved if it's really busy.

One thing to bear in mind: don't have too many alerts. Too much noise and people start ignoring them, and they stop delivering any value. It also means a status dashboard just looks like a sea of red, which is disheartening — only mark things red if they genuinely need attention. Nothing worse than something being red so often that everyone ignores it, and then when it's really red, nobody notices until it's too late.

**In summary**

Prometheus has its collectors, data server, and visualizations. The ELK stack follows a similar pattern — Beats collecting data, a server storing metrics and logs, and visualization on the end with Kibana or Grafana. I've only scratched the surface here — there are lots of other tools you might already be using, like Sensu, Nagios, AWS CloudWatch if you're in the cloud, SolarWinds if you've got budget for licenses, or Microsoft System Center if you're running a lot of Windows servers.

That's you set up and ready to go with monitoring and alerting — any more questions, put them in the comments below, and as always, may all your deployments be smooth.

Question 44

How do you master CI/CD pipelines in a DevOps workflow?

Accepted Answer

**Quick answer:** mastering CI/CD comes down to a small set of habits done consistently: keep the pipeline fast enough that developers actually wait for it (minutes, not tens of minutes), fail it early on cheap checks (lint, unit tests) before expensive ones (integration tests, deploys), and treat a broken pipeline as a stop-the-line event rather than something to work around.

Hey DevOps enthusiasts, welcome back to the channel — today we're going to talk about CI/CD. If you're new to the term, think of it as the autopilot for your software development process — continuous integration and continuous deployment — and trust me, once you get the hang of it, you'll never want to go back.

**What is CI/CD?**

Imagine your codebase as a helicopter, and every time you make a change, you want to be sure it flies as smoothly and safely as possible. Continuous integration is about automatically testing those changes to make sure nothing's broken — a bit like doing a pre-flight check every time you tweak something. Continuous deployment is like hitting the launch button — deploying your app into production with zero manual intervention, confident because CI has already done all the checks for you.

**Tools**

First up, Jenkins — the old reliable of the CI/CD world, powerful and built for heavy lifting. With Jenkins you set up a pipeline that automatically runs your tests and builds your project on every code change. If you're looking for something a bit more agile, GitHub Actions is sleek, fast, and integrated right into your repository.

Let's set up a simple pipeline in GitHub Actions — here's a small project for tracking deployments, with a branch containing a small change. On that change, some tests automatically run against the pull request, inside GitHub Actions — we can see the individual stages within the job: tests, static analysis, and code coverage. If we head into the repo's workflows folder, there's a YAML file defining the GitHub Actions steps we just saw — check out the code, set up PHP, install dependencies, then run the tests. On the PR, all the tests pass, so let's merge it in.

**Automated deployment**

Our CI pipeline is ready, but what about deployment? This is where CD, continuous deployment, comes in — automating the deployment process so every successful build can be deployed without you lifting a finger, like a good ground crew that knows exactly what to do. You can set up automated deployment to a cloud platform — AWS, Azure, Google Cloud, or others — and deploy with confidence, knowing your code has already been thoroughly tested by the CI pipeline.

**Good practices**

Setting up is just the first step — to keep your CI/CD pipeline reliable and scalable, follow some good practices:

- **Keep your pipeline simple and modular** — you should be able to add and remove parts without breaking things.
- **Use version control for your pipeline configurations** — every version documented.
- **Monitor and optimize** — keep an eye on your pipeline's performance and make adjustments where necessary.

With these practices in place, your CI/CD pipeline becomes a reliable co-pilot, helping your projects take off and land smoothly every time. Thanks for watching — if you found this useful, give it a thumbs up, hit subscribe, and share with your fellow developers. Until next time, may your code always pass the tests and your deployments always be smooth.

Question 45

What is DevOps and where should a beginner start?

Accepted Answer

**Quick answer:** DevOps is the set of practices that removes the wall between writing code and running it in production — automation, continuous integration/deployment, and shared ownership of reliability. A beginner should start with version control and a basic CI pipeline (get a change automatically tested and deployed to a test environment) before touching more advanced infrastructure-as-code or orchestration tooling.

Today we're diving into the world of DevOps — if it feels like some sort of mystical creature from the cloud, don't worry, we're here to demystify it.

**What is DevOps?**

Imagine development and operations as two islands. You could ferry people between them one at a time, which isn't great — what's better is a bridge connecting the two, allowing the teams to collaborate more effectively, enabling faster and more reliable software delivery. In simpler terms, DevOps is all about the culture, practices, and tools that bring developers and operations teams together.

**A bit of history**

In the old days, traditional IT developers would write a piece of code and then toss it over the wall to the operations team, who'd say "good luck with that." The ops team would take the code and try to deploy it, and often face issues, because — surprise, surprise — they didn't write the code, so they didn't have the knowledge and understanding of all its nuances. They were just relying on the code and whatever release notes existed, if any. This us-versus-them mentality led to slow, buggy deployments and a lot of finger pointing. Then someone thought: what if we worked together, shared the responsibilities, and communicated more? And DevOps was formed.

**Why should we care about DevOps?**

DevOps is a bit like tuning an engine — it makes everything run smoother, faster, and more efficiently:

- **Faster time to market** — quicker releases because everyone's on the same page, getting new features out to users faster.
- **Improved collaboration** — replacing "us vs. them" with "we're in this together," developers and operations working hand in hand.
- **Better product quality** — automated testing and continuous integration catch bugs early, before they become production nightmares.
- **More reliable releases** — continuous delivery pipelines mean code that's more stable and less likely to crash.

**Tools**

DevOps has a big toolkit, but you don't need everything in it — here's a quick flyby of some popular tools:

- **Version control** — git is your version control system, think of it as a black-box recorder tracking every change made to your code.
- **CI/CD pipelines** — Jenkins, GitLab, CircleCI: assembly lines automating the process of testing, building, and deploying your code.
- **Configuration management** — tools like Ansible, Puppet, and Chef help you manage your infrastructure as code, alongside Terraform for provisioning.
- **Containerization** — Docker and Kubernetes package everything you need for a deployment into a neat, portable container you can run anywhere.
- **Monitoring and logging** — tools like Prometheus, Grafana, and the ELK stack keep an eye on your systems, like a control tower watching over everything running.

And there you have it — the basics of DevOps demystified. Remember, DevOps is more than a set of tools, it's a cultural shift that helps teams work together — heck, if there are two teams, maybe make it one team (maybe swapping partners is a step too far). If you found this useful, subscribe — this is the start of a series, so there'll be another video along soon. Drop a comment below if there's a DevOps topic you'd like me to cover next — until next time, keep your deployments smooth.

Question 46

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

Accepted Answer

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

Question 47

What is a canary deployment and when should you use it over blue-green?

Accepted Answer

A canary deployment is a progressive delivery strategy where a small percentage of your infrastructure or user traffic — typically 5% or less — is updated to the new version first. If the canary release is stable, the rollout gradually expands until all instances are updated. The name comes from the mining practice of using canaries as early warning systems.

The key advantage over blue-green is cost. Blue-green deployments require a full duplicate of your environment running in parallel. As your application scales, maintaining two complete environments becomes expensive. If budgets are constrained, that cost is hard to justify.

Canary deployments avoid this by updating only a small slice of the existing environment at a time. Any failure from the new release affects only a small percentage of traffic, limiting the blast radius while keeping your overall costs down.

When combined with feature switches, canary deployments give you even finer control — you can deploy code dark (with the feature off), then gradually enable it for a subset of users without needing a new deployment.

Choose canary over blue-green when:
- Your environment is large enough that running two full copies is prohibitively expensive
- You want to validate changes against real production traffic before a full rollout
- You have good monitoring in place to detect regressions quickly

Blue-green remains the better choice when you need an instant, clean cutover with zero risk of partial states, and the cost of a duplicate environment is acceptable.

A common canary schedule is 5% of traffic for 15–30 minutes, then 25%, then 100% — with an automatic abort if error rate or latency crosses a threshold at any stage.

Question 48

What is a rolling deployment strategy and what are its trade-offs?

Accepted Answer

A rolling deployment is where component compute nodes are updated sequentially. This can follow a canary deploy where a very small number of nodes are updated first.

As two versions of code are deployed at the same time, this can give challenges for dependencies such as database schema changes, where the whole stack must support having multiple code versions running at the same time.

Sequential updates also mean a long deployment window, that can be longer with the more nodes you have. This should be mitigated by updating multiple nodes at once.

High availability is maintained during the deployment. As there are lots of nodes available to serve traffic, a very small number of nodes are offline whilst being updated.

Rollback is difficult. If a rollback is required, the current rolling deployment must be stopped and another one triggered to revert to the previous version. This means due to the length of time for a sequential update/revert, the errors will persist until the rollback is complete. Mitigation involves a blue-green hybrid deploy for quick revert. Old nodes are kept in a separate pool until the deployment is complete.

A common configuration caps the change to one node at a time (Kubernetes' `maxSurge: 1` / `maxUnavailable: 0` is the equivalent default idea) — slower than updating everything at once, but capacity never dips and only one node is ever running the new version while the rest catch up.

Question 49

How do you handle database schema migrations in a zero-downtime deployment?

Accepted Answer

If your deployment strategy is Blue-Green, you can use a third copy to apply and validate the schema. Known (by me) as Blue-Yellow-Green. This is suitable if the database software and schema are changing.

1. The yellow copy of the environment is built and synchronised with live data
2. schema and code updated in yellow
3. checks against data and schema change occur. any failures at this point can be spotted. If required a complete rebuild of yellow can restore state without effecting release cadence on blue/green.
4. when yellow is complete, green is synchronised with live data, and the schema applied ready for deployment.
5. green is made live, and blue updated with the schema and synchronised with live data.
6. yellow can be destroyed to save costs

For simpler changes, software can be written to enable upgrades and rollbacks of schema. Schema migration is where a diff of the schema changes are in version control and can sometimes provide a rollback. With this rollback in place, the schema migration can handle the changes to the database schema. This enables a schema migration within the QA/Staging environment for Blue-Green deployments.

For canary or rolling deployments, the code must detect and handle the schema migration. Any breaking changes must be handled by the application gracefully. This involves more management from the application side. This is expected as canary and rolling deployments have a minimum of two versions of code deployed at the same time.

The safe pattern for a breaking schema change is expand/contract: add the new column or table alongside the old one, deploy code that writes to both, backfill the data, switch reads to the new column, then drop the old one in a later deploy — never a single migration that renames or removes something the currently running code still expects.

Question 50

How do you configure zero-downtime deployments with NGINX?

Accepted Answer

NGINX is often used as a load balancer. It can manage web endpoints and monitor health. As a proxy it can also balance load across endpoints.

As you can configure multiple endpoint or upstreams, these can be updated to point to new resources during either a Blue-green or rolling update, depending on your choice of deployment.

The upstream configuration will be updated to point to the new endpoints and the old endpoints removed.

In practice this is an `upstream` block with multiple `server` entries plus a health check, so NGINX stops routing to an endpoint the moment it fails, rather than waiting for the next deploy to notice.

Question 51

What is a feature flag and how does it decouple deployment from release?

Accepted Answer

A feature flag is a configuration option in your code that is checked at runtime.

This 'flag' enables or disables a feature in your code. This means you can deploy the code containing the feature flag with the configuration in an 'off' state, with the feature enabled in configuration at a later time. This is particularly handy with rolling updates or frequently changing code or large releases.

The code can be deployed in a big release update, but enabled in a more controlled fashion.

A concrete example: a feature-flag service (LaunchDarkly, Unleash) or even a simple database-backed boolean both work — what matters isn't the tool, it's that the flag is checked at runtime, not baked in at build time, so flipping it doesn't require a redeploy.

Question 52

How do you roll back a zero-downtime deployment if something goes wrong?

Accepted Answer

For Blue-Green deployments the roll-back is near instant, by flipping the other environment to process the traffic.

In a rolling deployment, this will take a bit longer as the existing deployment needs to be cancelled and a new one kicked off. This is either in the deployment process or via GitOps configuration change to last known good.

Custom rolling deployments can be created whereby new nodes are built and added, whilst the old nodes are removed from a load balancer group. This is how AWS ECS performs rolling updates and enables a much faster rollback.

With monitoring and health checks, rollback can be triggered automatically and therefore roll back to a stable state quicker.

For rolling deployments specifically, most orchestrators expose a direct rollback command (e.g. `kubectl rollout undo` in Kubernetes, or re-pointing an ECS service at the previous task definition) — this re-runs the same rolling process in reverse rather than requiring a fresh manual deploy of the old version.

Question 53

How do you set up zero-downtime deployments on AWS?

Accepted Answer

AWS supports a number of compute runtimes. EC2 instances, ECS tasks, Lambda and others.

The choices are the same for zero-downtime deployments.

1. Blue-Green: Have a passive mirror of the live environment, update the mirror, test the deployment, switch the load balancer to the new environment.
2. Rolling update: Provision new servers or tasks, and swap them out of the live group one at a time. This is the cheaper option as you do not have to have a full live size environment, but it takes longer.

For ECS/Fargate specifically, this is built in via a configurable minimum/maximum healthy percent during rollout (commonly 100%/200% for blue-green-style safety); for Lambda, it's a weighted alias splitting traffic between the old and new function versions.

Question 54

How do you achieve zero-downtime deployments in Kubernetes?

Accepted Answer

This is done with rolling updates. New pods are provisioned and the old pods removed from the load balancer.

AWS ECS follows the same pattern. New tasks are provisioned whilst the old tasks are removed from the load balancer.

Keeping the old pods and tasks around long enough for the rolling update to complete, enables their quick reinstatement should a rollback need to happen.

Health-checks on container images and marking them as essential will help the deployment system know if the deployment is working.

The two settings that matter most are the readiness probe (so a new pod isn't sent traffic until it's actually ready) and a pre-stop hook with a grace period (so an old pod finishes in-flight requests before it's killed) — skipping either is the most common cause of dropped requests during an otherwise "zero-downtime" rollout.

Question 55

How do you test a deployment without affecting production users?

Accepted Answer

Best practice follows a two stage approach.

Have a pre-prod/staging environment that is configured the same as production. This is easy if you have your infrastructure defined in code, aka Infrastructure as Code (IaC). Deploying to your staging environment will give you early indications of possible deployment failures.

Deploying to production can then be done with less risk by using a canary deployment. This is where you deploy the new code to a limited number of servers, to test a new feature without affecting the whole deployment. A similar approach is to have a feature behind a switch, and enable that for a subset of users.

Either approach reduces the blast radius should anything go wrong.

How will you know if your deployment has gone awry? Your monitoring should tell you this through 500 errors or some other logging and metrics collection.

For the trickiest case — a change that only breaks under real production load or data shapes — canary or shadow traffic (mirroring a copy of real production requests to the new version without returning its response to the user) catches issues staging never will, at the cost of extra infrastructure.

Question 56

How do I set up a CI/CD pipeline from scratch?

Accepted Answer

First you need somewhere to orchestrate your CI/CD pipeline. This is a server or service that enables you to configure the pipeline and the steps that should happen.

There are lots of choices, most are yaml based.

1. Jenkins is the oldest and most stable, with lots of plugin support.
2. GitHub actions. built right into your git repo if you host on GitHub. Good community support of plugin 'actions'
3. GitLab CI. Your go to if you are running your git repos out of GitLab
4. Circle CI. A long time supporter of Open Source projects
5. AWS CodeBuild. should you be hosting your apps on amazon, maybe stay native with AWS.

Once your orchestrator is in place. You need to design and create the pipeline.

At the basic level you should have

1. Tests: automated unit tests, with security, code quality, and other guardrails you want for you and your developers. (or AI)
2. Build: This stage will build your deployable artifact. A versioned binary, container image or runnable code.
3. Deploy: host the artifact somewhere to test deployment
4. Health: Healthchecks or integration testing. A higher level of testing when your code is not on your local machine.
5. Approvals: Maybe you want an approval stage. The steps before this are call Continuous Integration. This step is a pivot to Continuous Deliver.
6. Deploy to production environment(s). The penultimate step. The one that delivers the goods.
7. Monitoring: similar the Health, but for production. Enables logging, dashboards, metrics and other monitoring tools.

For a first pipeline specifically, GitHub Actions is usually the fastest path if the code already lives on GitHub — a working build-test-deploy workflow can be a single `.github/workflows/*.yml` file with no separate CI server to run or maintain.

Question 57

What should every CI/CD pipeline include to catch bugs early?

Accepted Answer

During the testing phase, the CI/CD pipeline should be able to catch bugs.

We can help it by providing steps that include linting and formatting.

Unit tests will provide quick feedback and can be run locally to catch the bugs even earlier.

Be sure to keep a check on the test code coverage. If that dips below 100% not all the code is being exercised.

As a rough, commonly cited baseline, many teams target somewhere around 70–80% line coverage as "healthy, not gamed" — chasing 100% usually means testing trivial getters instead of the logic that actually breaks in production.

Question 58

How do you speed up slow CI builds?

Accepted Answer

A lot of contributing factors make up a CI build and any of them can cause a slow down. Here are a few of the suspects that should be checked.

1. CPU usage: is the build agent maxing out the CPU? (cpu load)
2. Memory usage: Excessive swapping of disks or a large amount of memory usage can slow down builds. (free memory)
3. Build Agent availability: In a large estate, maybe the build is waiting a while (job queue time) for a free build agent to become available.
4. Lack of caching: some operations do take time, but we can cache the result. Examples are python `venv` folders, NPM and `node_modules`, go-lang `src` folders or perhaps docker image layers. Each can be stored after the resources are downloaded. Re-hydrating the resources from a known hash/config is faster than downloading all the dependencies.

By checking timestamps of the logging during the build, you can build a profile of where the time is spent and focus your attention on that step.

Make it faster, one step at a time.

The single highest-leverage fix is usually dependency or build caching (for example GitHub Actions' `actions/cache`, or a Docker layer cache) — teams that add it typically cut build time substantially simply by not re-downloading or re-compiling unchanged dependencies on every run.

Question 59

What is a deployment pipeline and why does it matter?

Accepted Answer

A deployment pipeline should be able to give the developers autonomous ability to deploy their code in a repeatable and testable way. This minimised hand-offs and team dependencies, enabling faster deployment and/or fail fast/bug fixing.

A deployment pipeline can be separate to a testing or build pipeline.

First you want a build pipeline, that runs security and unit tests and builds a deployable artifact.

Second you want a deploy/testing pipeline, that may run more security (pen testing) and integration tests after deploying to an appropriate environment.

This second pipeline could deploy all the way to production given the correct Human in the loop gates/approvals and testing sign off.

Question 60

What are the DORA metrics?

Accepted Answer

The DORA metrics are four measures, from Google's DevOps Research and Assessment programme, that are the industry standard for judging how well a team delivers software.

- **Deployment Frequency** — how many deployments happen across a defined period. Small, frequent deployments are better, as they are easier to roll back and have fewer inter-dependencies. Higher is usually better, provided Change Failure Rate stays low.
- **Lead Time for Changes** — the time from a developer marking an issue as fixed in code, to that code actually being deployed and used in production. With a short duration, the context of a change is not lost if something goes wrong, so recovery is usually quicker. The shorter, the better.
- **Change Failure Rate** — the ratio of failed deploys/changes to total deploys/changes. This indicates how ready and stable changes are at the point of execution. The lower, the better.
- **Mean Time to Recover (MTTR)**, also known as Failed Deployment Recovery Time — the time it takes to recover a service to working order after a failed deployment or system fault. The shorter, the better.

The four DORA metrics are useful from a management point of view, but they do not tell you anything about an individual deployment and its health while it is happening — that needs its own set of metrics, tracked in real time.

Want these tracked automatically instead of pulled together by hand? [Get on the waitlist for a self-serve DORA metrics dashboard](https://quiz.deltafamiglia.com/dora-metrics-dashboard?utm_source=devops-answers&utm_medium=content&utm_campaign=dora-metrics-dashboard) — connect a repo and see your four numbers, no sales call required.

Question 61

Q and A with Neil Millard - 26 March 2025 - Collaboration

Accepted Answer

**Session summary:** a live Q&A on why collaboration is foundational to both DevOps and open-source success — tech is built by more than one person, and the practices (code review, shared documentation, breaking down silos between roles) that make open-source projects work are the same ones that make an internal engineering team effective.

Good afternoon — it's Wednesday, it's lunchtime, which means only one thing: I'm here doing the Wednesday Q&A, for all your tech questions, consultancy questions, contractor questions, and anything else you want to go off topic on. Let's dig in. Today we're going to start by talking about collaboration — because tech is built by more than one person. Even the mighty Linus Torvalds, when he wrote Linux, it was a collaborative effort — even though it's got his name on it, everyone needs a leader to get behind, and it's still a collaborative effort.

**Why it matters**

Tech is a team game — there's usually more than one person in a tech team, and the best products come from sharing different ideologies and viewpoints. By collaborating effectively, we bring those ideas together. Companies like Google and Spotify foster collaboration and succeed because of it — studies have shown companies with strong collaboration are five times more likely to be high performing.

**Barriers to effective collaboration**

- **Silos** — teams, or individuals, working in isolation cause problems.
- **Lack of communication** — if you're scared to, or can't, talk to somebody about something, you end up making assumptions ("maybe that person just doesn't like me").
- **Competing priorities** — if you're not talking to each other and you've been given different goals, not everyone ends up pulling in the same direction.
- **Tool overload** — lots of tools, or worse, a choice of tools that do the same thing, creates confusion.
- **Remote and hybrid challenges** — a lot of us work remotely, so we need intentional collaboration just to see what each other are doing, saying, or thinking.

**How to foster better collaboration**

We need to adopt a shared mindset — shift from "my work, my output" to "our work, our success." Cross-functional alignment means we can check in with other teams — in some of the most successful projects I've worked on, we had a small scrum team of six or eight, but we were part of a larger team of maybe 50 people, and we regularly caught up with what the other teams were doing, so we didn't break each other's stuff and could see where we were collectively heading.

Leveraging the right tools helps too — collaboration tools have existed for a while: Slack for chatting, Miro for presenting, Notion for knowledge storage, and by sharing these, teams can collaborate more easily.

We need to create a safe space — encourage open, judgment-free discussion. We all started somewhere, we don't know everything — you might ask me a question and I'll say "I don't know, but I'll find out and come back to you," and you need the strength and safety to say that too. That inspires more conversation, because you've obviously got a gap there, and that's fine — talking to people closes that gap a lot faster than searching online. It's part of why ChatGPT does a good job for a lot of people — it does the searching for you — though the trouble is, if it doesn't find an answer, it just makes something up, which is really bad. You want somebody, human or otherwise, to say "I don't know" if they don't know.

And build a feedback-driven culture. On the most successful projects I've been on, when something goes right, we run a retro and ask what was good, what was bad, and what was so atrociously rubbish we should never do it again. When something goes badly, we ask the same kind of questions — why did it go badly, what were the contributing factors, what could we have done better, and what did we do well despite it not working. Regular retrospectives like that help us grow faster.

**Where collaboration matters in DevOps**

My specialist subject is DevOps — development and operations — and collaboration is key across several areas:

- **Agile development** — sprint planning, daily standups, and retrospectives.
- **Incident management** — when something goes wrong, development, operations, and security all work together to resolve it as quickly as possible.
- **Scaling infrastructure** — making sure we're building resilient, cloud-based systems together.
- **Feature rollouts and testing** — QA needs to collaborate with developers, both so developers know how to make things easy to test, and so QA feedback gets back to developers quickly. Pairing with QA while you write code, getting instant feedback, lets you move really fast.
- **Customer-centric development** — talking to customers, or to support and sales teams who talk to customers, and to the analytics teams, so that feedback actually reaches you.

DevOps itself exists to bridge the gap between development and operations, remove silos, and support collaboration — it promotes shared responsibility, "you build it, you run it." It also brought us CI/CD pipelines, automating faster and safer releases, with a self-service framework for creating, testing, building, and deploying. And monitoring and observability give real-time insight to foresee and prevent system failures, so you can act proactively.

**Summary of fixes for common problems**

- **Lack of shared goals** — align objectives across teams with regular meetings; quarterly is probably the bare minimum, more often is better.
- **Poor communication** — structured meetings, clear documentation people will actually read because it's easy to understand, and asynchronous updates that don't constantly interrupt people.
- **Tool overload** — reduce the number of tools available; have a group discussion and let a leader decide on the definitive tool list, which makes future decisions simpler.
- **Resistance to change** — foster a culture of continuous learning and improvement, and reward people who improve and want to learn.
- **Remote team disconnect** — schedule something low-stakes, like a virtual coffee chat or 30 minutes a day where a demo might happen ("look what I've done, tell me if it could be better") — or team-building activities, in person if you can, that aren't directly work related. Getting to know each other outside of work builds familiarity and friendship, which aids collaboration.

**Key takeaways**

Tech moves fast, so the only way to keep up is by working together — you cannot know everything, you need to rely on colleagues for coverage. Great products come from teams that collaborate well, and they deliver quicker. Ask yourself: how can we collaborate better, what silos can I see, and how can we break them down? At the weekend I went to Product Camp, a group of product managers who get together to discuss how to be better and share knowledge — in that spirit, how can we share, learn, and innovate together?

If you've got any private questions, DM me — LinkedIn's probably easiest, or comment on YouTube. Otherwise, let's get to your questions for today.

Question 62

Q and A with Neil Millard - 16th April 2025 - How do we make deployments SAFER?

Accepted Answer

**Session summary:** a live Q&A on making deployments safer — covering practical risk-reduction techniques (smaller changes, automated testing, staged rollouts, rollback plans) that came up in open discussion, aimed at teams currently deploying manually or infrequently who want a lower-risk path to more frequent releases.

Welcome, everybody — yes, this is an open meeting, anyone can come along and throw questions at me. We've got some slides to help me along with my ramblings. Today we're talking about deployment health checks — making deployments safer with automation.

**A weekend project: Safe Deploy Check**

I was a bit bored at the weekend, so I threw together a tool called Safe Deploy Check just for fun. It doesn't do anything too exciting yet — it looks at your PR and checks a few things. Have you submitted any files that might contain sensitive stuff, like environment variables with keys in them? A little security check. It also checks how big the PR is, simply by counting how many files are in it, and gives a warning if it's over a certain number. There are a couple of other checks in there too. It was only thrown together briefly, just to check things at a high level — there's loads more you could check, like whether there are tests, and whether those tests have decent coverage, which this tool doesn't do yet.

**Why deployment health checks matter**

Bad deployments are expensive, for two reasons: it costs a lot of time to fix the mess that's just been created, and it costs time to properly fix and redeploy the thing later. And when stuff goes wrong, you get hauled into a meeting to discuss what happened and why — more time lost. If you've got customers on the other end and you cause a production outage, that's worse still — damaged reputation, damaged relationships, all because we didn't have a check first.

A simple checklist can prevent a lot of these issues — does it have tests, is the coverage good enough? I purposely wrote my check code to have close to 100% test coverage. But are they decent tests? That's the other half of the story — coverage only tells you a line of code was exercised while your tests ran, not whether the test is any good. If you haven't got tests that actually try to trigger errors, that code might still get "covered," but fail in production for a completely different edge case you never thought of — because that's what production does to us.

**Pre-flight and post-deploy checks**

A deployment health check comes in two halves. The pre-flight side is what we just covered. Post-deploy might be as simple as a health check endpoint — the minimum version, used by Docker, Kubernetes, ECS, or a load balancer, is just "can I reach the endpoint, does it return a 200 OK." But you can go further — is the database available, can I write to it — really exercising all the components your application depends on, so when you hit that health check, you know the app is genuinely healthy. You can also validate the environment, infrastructure, app stability, and user experience — some of this is covered by UAT, app stability can be tested with load or synthetic transactions. Generally, the more testing you have in place, and the earlier you do it ("shift left"), the more stable your deployments will be.

**Key pre-deploy checks**

- **Infrastructure readiness** — I've seen many deploys fail not because a piece of infrastructure was missing, but because the *permission* to reach it was missing. For example: a piece of work needs a new database table for a feature. It works fine in dev. You deploy to UAT, and it dies — worked fine in test, worked fine on my machine, why did it die? Turns out, in Terraform, we forgot to grant the app permission to write to the new table. A health check that properly exercises dependencies would catch that immediately — hit the check, it tells you "I can't write to that table," you fix the Terraform code, and you're done.
- **Dependency availability** — in a microservices deployment, your app might rely on other services: a database over here, an auth service over there. Put those into the health check too, so you've got a little dashboard confirming each dependency is reachable, and can spot instantly if any of them aren't.
- **Secrets and config** — one of the things my weekend tool checks is whether certain config files are being committed. If you're checking in an `.env` file, that's a bad sign — hopefully it's in your `.gitignore`, but accidents happen, and you don't want secrets in your repository, even a private one, because it could accidentally be made public. This is the Swiss cheese model of failure — usually it takes three or four holes lining up (a leaked secret, then a repo made public) before something really bad happens, like someone breaching your AWS account.
- **Version control** — regular commits (even just locally) mean you can always roll back to a previous point rather than losing a day's work. Don't worry about tidiness while committing — you can always squash commits down before opening the PR.
- **Maintenance mode and user comms** — for big or risky changes, a scheduled maintenance window sets expectations, so when there is a bit of downtime, you can point back to the warning you gave.

These are the red flags to catch before you push the deploy button — if your infrastructure isn't ready or something's misconfigured, it's going to bite you the moment you hit that button.

**Key post-deploy checks**

- **Smoke tests** — essentially the same as the health check, sometimes as synthetic transactions: automation (Selenium, Postman, or similar) that drives the app through a set of real user-like actions and confirms everything works.
- **Log monitoring** — generate plenty of logs, and monitor for errors so you get alerted the moment something looks wrong.
- **Service and system metrics** — measure CPU, disk usage, and so on. I've seen panicked "it's all broken" moments that turned out to just be a server that ran out of disk space — an easy fix once you know, but it took 20 minutes to diagnose because nobody was watching that metric.
- **Rollback readiness** — if you've ever sat in a change control meeting, someone's asked "what's your rollback plan," and someone else has said "we fix forward, that's the agile way" — which doesn't cut it if something's really broken. You want an actual way to roll back: canary deployments (deploy to a small slice, test it, and restore the rest of the fleet if it fails), blue-green (deploy everything to the idle environment, switch over, switch back if it goes wrong), or feature flags (deploy the code inertly, then flip a switch to turn the feature on, so you can turn it off just as fast, or restrict it to specific users).
- **Feedback and support loops** — make sure UAT and support have an established way of reporting issues back to you, and write runbooks: if this happens, here are the steps to follow to make everything happy again. It's not just about getting a deployment live, it's about keeping it alive, and rolling back to the last known good state if it isn't.

**What Safe Deploy Check does today**

It's a quick tool, only a couple of checks in there so far — I'd love ideas for what else to add. It doesn't yet check endpoint response, open ports, disk usage, memory/swap, or certificate expiry dates — all good ideas for the future. It's written in Python, builds a small container, and runs inside GitHub Actions, giving you an output report with a rough confidence score on whether the deployment should go ahead (100% is a green light; it usually comes back around 90%, since nothing's perfect). If it finds issues, it lists them against your PR, and it's straightforward to wire into a CI/CD pipeline as a GitHub Action — docs are in the README.

**A few practical rules**

Just because it worked in staging doesn't guarantee production, but it's a strong indicator — that's what staging is for. One mistake I see: people patch something directly in staging until it works, then roll that straight to production — instead, roll back out of staging, fix it properly, and redeploy through the same pipeline you'd use for anything else. Always have a rollback plan; if you don't have one, blue-green deployments are an easy one to adopt. Always check monitoring straight after a deploy — a sudden spike in error rates on a new feature is your cue to switch it off or roll back. And keep runbooks documented, so three weeks after writing a feature, you don't have to rely on memory to know what an error means and what to do about it.

The goal is confidence — not just in deploying, but in recovering fast. One of the key DORA metrics is mean time to recovery after a failure. Failures are going to happen, but if you can recover quickly enough, nobody minds much. Robinhood had an outage in March 2020, right as lockdown started and everyone piled into trading from home — the platform couldn't handle it, and disruptions stopped users executing trades, in some cases costing them real money (one user reported losing out on $15,000 because they couldn't exercise options during the outage). That led to a lot of negative press. A pre-deployment checklist or infrastructure health check might well have caught the underlying capacity issue before it caused an outage.

So: start with a manual checklist, adopt a tool like Safe Deploy Check, or write your own — it's not that hard, I did mine in a weekend. Focus on repeatability and visibility: if it's repeatable, you can automate it; if it's automated, you can make it visible, on a dashboard or as a GitHub Actions check on the PR. Any private questions, find me on LinkedIn.

Someone asked how their team measures up to deployment success, and whether they even know what the DORA metrics are — I've got a video on DORA checks on my YouTube channel if you want to dig in. Someone else asked what the biggest driver was for me putting health checks in place. Honestly, these days, with a lot of experience behind me, it's just a no-brainer — I've done enough deployments and felt enough pain that "why wouldn't you have a health check" is the default question now.

One example: I once built an API that helped manage build and deployment processes (it won an award) across three test environments and a production environment. Code would develop in one test environment, deploy automatically to a third test environment, and only if that included a passing health check would it go on to production. On several occasions, that health check on the third environment caught a problem before production deployment even happened — the team later added a pre-live environment for an extra layer of confidence too. If the health check fails on the way to staging, the automated deployment simply stops there; if it passes, it goes straight to live — no unnecessary waiting, and the code also had feature flags in it, giving even finer control over what was actually live in production.

Question 63

Q and A with Neil Millard - 23rd April 2025 - Platform Engineering

Accepted Answer

**Session summary:** a live Q&A on platform engineering and internal developer platforms — discussing when the self-service investment is worth it, the trade-offs against simpler CI/CD and guardrails for smaller teams, and how contracting/consulting factors into platform engineering work.

Welcome, everyone. Today we're talking about platform engineering.

**What makes a platform engineering team?**

The short answer: infrastructure, build and deploy, developer support, telemetry, and tooling. But what is platform engineering, really? A platform is supposed to reduce cognitive load, increase reliability, and let developers ship code faster. It reduces cognitive load by removing most of the decisions developers otherwise have to make — what should the front end look like, what tool should we use for this — by answering those questions once, up front, and agreeing them into the platform. When a new person joins, you can just say "it looks like this, all these decisions have been made for you, and if you've got other questions, the answer's probably in this document." That gives developers a comfortable place to just get on with developing, with boundaries, guardrails, and tools already set out for them.

**The mission**

Abstract complexity away from developers, so they can do what they love, which is developing code — most developers don't particularly want to deal with servers, infrastructure, and networks, they want to ship features. As a platform engineer, you provide a reliable environment with clear documentation, and lots of self-service built in, so developers don't have to request something and wait on somebody else — they know where to go, and sort themselves out. The platform needs to be reliable (a build should be available straight away, no wasted time), scalable (as the team doubles, the experience stays the same), secure by default, and ultimately, it should enhance developer experience and productivity — empowering developers to do their best work.

**Team composition**

- **Infrastructure** — primarily cloud engineers, looking after cloud, networking, infrastructure as code, and compute — the servers everything actually runs on. Sometimes this includes Kubernetes, sometimes not (if they're clever, they'll avoid it where its complexity isn't worth the value it provides) — but developers don't need to care either way, because it's abstracted away by the infrastructure team. This team also owns security, access, and compliance — least privilege across the infrastructure, so a container can't talk to another unless it's specifically allowed to.
- **Build and deploy** — owns the CI/CD pipelines. They provide default pipelines, and help developers write custom ones if needed (though that means stepping outside the guardrails, so it's less well supported — most developers are better off just using the default). They own the automation servers, build/deploy/test images, and the deployment strategies — usually decided ahead of time, whether that's blue-green, canary (rolling the new version out to one instance before the rest), or feature flags (my favourite) — all aimed at minimizing the risk of deployment failures, so fast, reliable software can ship without breaking things.
- **Developer support** — the single source of truth for tools, documentation, and self-service resources, helping onboard new starters quickly, acting as an internal help desk when developers get stuck, and feeding new feature requests and feedback back into the rest of the platform team.
- **Observability and telemetry** — telemetry gathers data and metrics from the application and infrastructure; observability makes that available through dashboards and alerts. The best telemetry teams don't write every dashboard for you — they provide a couple of good defaults, plus a framework so developers can build their own, focused on what they actually care about. This also covers SLOs and SLAs — a dashboard might show a certain failure rate that's considered acceptable, which helps teams understand and debug their systems when things go wrong, including failures caused by external dependencies outside their control.
- **Tooling and automation** — the right tools for the job: CLI tools, IDEs, SDKs, and libraries, made available so developers know exactly what they need. This also covers things like secrets management — providing a secure store so a deployment can access a secret without exposing it to anything else — and enforcing consistency and best practices around quality and security.

**Collaboration and culture**

Above all, a platform team is about collaboration and culture. These teams aren't just allowed to talk to each other, they're encouraged to — when a developer has an idea, the relevant team can say "we tried that, it didn't work" or "great suggestion, we're building it next sprint." Cross-functional collaboration between application teams and platform teams helps solve issues together — on one project, telemetry, infrastructure, and build-and-deploy pooled resources to upgrade a section of the platform in a little under seven months. Documentation matters too — keeping it close to the code rather than buried in a separate wiki: if there's a runbook for an alert, put it right next to where the alert is defined, so when the alert fires, the source points straight at it.

Psychological safety and continuous learning matter as much — blameless postmortems when something goes wrong, focused on why it went wrong and how several small things lined up to cause it, not on who caused it.

**Challenges**

- Being developers ourselves, we can build things that sound like a good idea but nobody actually uses — worth checking a feature will get enough real utility before building it.
- Empathizing with developer needs, even when a suggestion isn't a good one, and treating it in the spirit it was given.
- Aligning the platform roadmap with business value — the people funding it want to see it's improving the business by making developers faster. One platform I worked on was part of HMRC's COVID service delivery — because the guardrails were already in place, those services were built and deployed within eight weeks.
- Keeping up to date as new tech stacks and tools appear, and deciding when it's worth adopting one.

**Measuring success**

Developer satisfaction and adoption, feedback, satisfaction scores — one of the best metrics is how quickly a change gets from a ticket through the developer loop into production. Failures will always happen, so alerts and runbooks reduce mean time to recovery. And reduce cognitive load for development teams — make the right thing the easy thing. If it's obvious, easy, and a bit fun, developers will use it; if it's not, they'll find a workaround around it.

**Real-world examples and further reading**

Spotify's Backstage started life as a service catalog and has grown into a full open-source developer portal you can self-host, though it may be overkill depending on your project. Netflix has its own equivalent tooling, and Spotify has published a lot more on platform teams and DevOps generally — they're something of a trendsetter here. Worth reading: "Team Topologies" by Matthew Skelton and Manuel Pais, and "The DevOps Handbook" by Gene Kim and co-authors, plus "The Phoenix Project" if you prefer a story-driven, more soft-skills-focused read.

**Takeaway**

Platform engineering isn't just tech — it's culture, mindset, support, empathy, enablement, and evolution, and the goal is making engineers happier and more productive.

One attendee, about to start a platform engineering role, asked for advice going in mostly blind to the specifics of the new company's stack. My advice: don't over-prepare with knowledge you might not need — learn a little as you go, and lean on job descriptions loosely, since they rarely match exactly what you'll actually be doing day to day.

On whether to build or adopt something like Backstage: start with the minimum platform you actually need — most repo hosts already handle basic builds themselves. A lot of what Backstage provides (a UI for secrets management, job tracking) can start out as something much simpler — direct access to your cloud provider's secret store, or even a Trello board — before reaching for an all-in-one platform. Reaching straight for something like Kubernetes or Backstage when you're only going to use a sliver of it costs a lot of cognitive overhead for not much benefit.

On platform engineering versus a traditional embedded-DevOps model: platform engineering pushes automation and self-service far enough that developers don't need to go through DevOps at all — it's just there for them to use. Compared to hiring a DevOps person per team, or a central DevOps team developers raise tickets with, that self-service model scales much better, and management buy-in matters enormously — if leadership backs the platform and makes the easy path also the sanctioned path, adoption follows; without that backing, even a well-built platform struggles against inertia and old habits.

Question 64

Q and A with Neil Millard - 14th May 2025 - A.I edition

Accepted Answer

**Session summary:** a live Q&A on AI for developers and business — is it hype or does it help, how AI is changing day-to-day development workflows, and where it creates real business value versus where the claims outrun the substance.

It's 12:00, it's Wednesday — that can only be one thing, it's the Tech Answers Club Wednesday Q&A. So what are we talking about this week? AI for developers and business — is it hype, does it help, is it a game-changer? Artificial intelligence is everywhere, but what does it really mean? Today's focus is how AI is changing development workflows and creating real business value, plus what's coming next.

**What is AI?**

A broad term for machines doing stuff that typically requires human intelligence — problem solving, pattern recognition (they're really good at that), natural language processing, and decision making (I'll reserve judgment on that last one, unless it's really just pattern recognition in disguise). AI isn't magic, though — it's just maths, data, and models.

**Types of AI**

- **Rule-based AI** — basic if-this-then-that logic, programmers have been doing that for ages.
- **Machine learning** — systems that learn from data.
- **Deep learning** — like machine learning, but more of it.
- **Generative AI / large language models** — similar to deep learning, but with very specific use cases.

**Pattern recognition**

Identifying trends, anomalies, and matches in data. I've worked on projects with huge amounts of website usage data — you hover over a product without clicking, then go somewhere else and click something different, and that hover gets logged. Pattern recognition can spot that when 300 people hover over that product, they tend to do a particular thing afterwards. It's a bit like if-then logic, but the machine searches for the pattern instead of a programmer hand-coding it.

**Machine learning**

Takes that a step further — models are trained on data to improve their performance, so if we feed back what customers actually did after a recommendation, the model refines its future outputs and improves as it goes.

**Large language models and neural networks**

LLMs rely on advanced neural networks — a simple, much smaller model of a brain, more fly than human. Truth be told, nobody fully knows how they work — we've successfully modelled things as simple as a worm's brain, and we know exactly how that works, but once you get up to something as "advanced" as a fly, it gets murky, yet somehow it still works. A large language model is a bit like that: if you could talk to a fly and it understood you, and had read a vast amount of literature, that's roughly what an LLM is.

**Benefits for developers**

- **Code generation and autocomplete** — give it enough code to look at and it can guess the next few lines, a bit like predictive text on your phone. Sometimes it nails exactly what you were going for; sometimes it produces something syntactically valid but logically nonsensical.
- **Debugging assistance and static analysis** — static tools that check syntax and logic (unused variables, undefined functions) already existed; AI has effectively learned those rules too, and can go further — running tests, adding debug lines, reading error messages, and iterating. It doesn't always get there, and can occasionally spin in circles, but most of the time it does okay.
- **Writing test cases** — my favourite use. Whether you write tests first (TDD) or after the code, it's easy to miss scenarios (the "customer orders minus three beers" kind of edge case). Ask AI to generate scenarios you haven't thought of, based on your existing tests and code, and it's very good at making up plausible, creative edge cases — which is exactly what you want here.
- **Documentation** — it can read code and generate an explanation of what it does, which is useful for creating docs and for junior developers getting up to speed.
- **Accelerating your workflow** — rather than spending ages searching Stack Overflow, an LLM has effectively already been trained on it (right answers and wrong answers included), so it can get you unstuck faster.

**Benefits for business**

- **Automating repetitive tasks** — customer support chatbots, data entry, reporting, scraping websites into databases. There's growing interest in AI agents — giving a large language model a very specific role and letting it "stay in character" to carry out a task (which, unfortunately, is also exploited by spammers and scammers).
- **Enhanced decision making with predictive analytics** — AI has effectively read almost everything humans have written, and is good at spotting patterns across many similar documents and reports, summarizing them into something digestible, with a recommendation of what might happen next.
- **Personalization at scale** — in marketing and sales, this is why your Instagram or Facebook feed feels tailored to you: it's reinforcing what you already engage with, which is sometimes useful and sometimes just an echo chamber (YouTube even has a "show me something different" button buried on the homepage for exactly this reason).
- **Cost savings and increased productivity** — the sales pitch, at least. I haven't seen much hard evidence of this yet; the tech is still young, so we'll see.

**Real-world developer use cases**

- **Refactoring legacy code and translating codebases** — genuinely useful, e.g. upgrading old React code to a newer version. The catch is training data isn't always current, so it might default to an older API version it saw more of, rather than the very latest — and you know what happens when it just makes something up instead.
- **ML for CI/CD monitoring and anomaly detection** — feed pipeline data into a model and it can flag anomalies. For example, a Terraform pipeline that produces a plan — if a run suddenly shows costs jumping or dropping a long way from the norm, that's worth an alarm, since it might mean a load of expensive resources are about to be created, or a load of resources are about to be deleted.
- **AI-assisted API generation, unit tests, and infrastructure templates** — genuinely useful for making sure code has decent coverage, including scenarios nobody thought to write manually, catching regressions in CI before anything reaches production.

**Real-world business use cases**

- **Retail** — inventory forecasting and pricing, using pattern matching and prediction, even simulating customer personas to test messaging.
- **Finance** — the UK government uses a fair bit of machine learning to cross-reference large volumes of tax data for anomalies (sudden jumps, VAT/corporation tax mismatches), because it can scan millions of records far faster than people can.
- **HR** — CV screening and candidate ranking, including spotting CVs that look AI-generated or inconsistent against a candidate's LinkedIn profile.
- **Manufacturing** — predictive maintenance from sensor data, spotting patterns that predict a fault will occur down the line, across huge fleets of equipment.

**Risks and challenges**

- **Bias and fairness** — a model only knows what it's trained on; it's much stronger in English and Spanish than less-represented languages, which is a little ironic given LLMs descend from machine translation ("transformer") research.
- **Hallucinations and accuracy** — a model essentially never says "I don't know, let me find out" — it always produces an answer, and there's no reliable way to tell fact from confident fabrication from the output alone, because the model doesn't actually know facts, it knows how language works.
- **Privacy and data governance** — including live legal questions around AI training on copyrighted material, and whether that counts as fair use.
- **Over-reliance on automation** — if you lean on the machine to do something for you, you risk losing the underlying skill yourself, which is fine until the machine breaks and you're stuck.
- **Ethics and governance / explainability** — because we don't fully understand how these models work internally, sometimes challenging an answer gets you a correction, and sometimes the model just doubles down on something wrong.
- **GDPR, data compliance, and responsible model training** — where does the training data come from, and is the model learning things it shouldn't (personal data like emails and phone numbers)? This is why organizations are writing AI usage policies — should AI be allowed anywhere near production, for instance? Probably not.

**Tools to get started**

ChatGPT (LLM), Midjourney (image generation), Hugging Face (a huge repository of trained models), and OpenAI's APIs. For developers: TensorFlow, PyTorch, and LangChain — libraries for building your own models and neural networks. For business: Azure Machine Learning Studio, Google Vertex AI, and Microsoft Copilot.

**What's next**

- Image generation with genuinely legible embedded text — still a weak spot today.
- Voice response — getting close, though still a bit rough compared to text-based LLMs; voice cloning is already surprisingly easy now that the underlying pattern analysis exists.
- Real-time AI agents — give an agent a task, some boundaries, and access to tools, and let it act — still fairly limited by the tools available to it today.
- Vertical-specific models — trained on narrow domains (legal, medical) so they can be smaller and faster, without needing to carry knowledge of everything else.
- No-code/low-code and "vibe coding" tools — letting people with no coding background produce working code, which is powerful but can bite you hard if you don't understand what it produced. It's a tool, not infallible — a bit like the humans who built it. For developers, think co-pilot, not replacement — it's there to make you faster, not replace you, and the same goes for business: AI can make things faster and easier, not replace the judgment behind them.

Any private questions, find me on LinkedIn — that's all for today, back again in September after the summer break.

How do I reduce deployment risk without slowing down releases?

What is the best way to do a zero-downtime deployment?

How do you roll back a bad release quickly?

What is blue-green deployment and how does it achieve zero downtime?

Deployment vs release: what is the difference?

What is the difference between monitoring and observability?

How do you set up alerting that actually gets acted on and not ignored?

What metrics should I track to know my deployment pipeline is healthy?

How can external DevOps expertise provide an unbiased view of your challenges?

How do fractional DevOps experts give you access to top-tier talent at lower cost?

How can a fractional DevOps expert help scale your business?

Why is collaboration so fundamental to DevOps and open-source success?

How does automation help you work smarter rather than harder?

How does a fractional DevOps expert help accelerate software releases?

Why is mentorship important in a DevOps career and how does it work?

What do you need to know before building a tech startup in 2025?

Why do most tech startups fail and how does DevOps help prevent it?

How do you track technical debt and measure DevOps delivery performance?

Why does the quality of your AI prompts determine the quality of the output?

What are the top tech questions developers are asking in 2025?

What is Ansible and how do you use it for configuration management?

What is AI and how does it work, from machine learning to large language models?

How do you use development templates to automate and streamline workflows?

What are the top three technology predictions for 2025?

How do you use DevOps practices to boost your deployment speed?

What are the common pitfalls to avoid when using Ansible?

How does a hybrid EC2 and Lambda strategy maximise cloud efficiency?

How do Heroku, Railway and Render compare for deploying applications?

What is the difference between horizontal and vertical scaling, and when should you use each?

How do you use Ansible to automate the setup of a Python application?

Do you really need an internal developer platform, and what are the trade-offs?

What is the difference between DevOps, SRE and Cloud Ops?

What does a typical day look like for a DevOps engineer?

How do you bring order to chaotic DevOps infrastructure using Ansible?

What are the best ways to deploy a Python application and how much do they cost?

What DevOps practices and secrets should every software engineer know?

How do apps handle massive traffic spikes like Black Friday without breaking?

What are the most valuable insights from experienced DevOps engineers?

How do you navigate the DevOps toolchain without getting overwhelmed?

What is cloud computing and how does it fit into the DevOps era?

How do you use declarative provisioning to manage DevOps infrastructure?

How do containers streamline deployments beyond just Kubernetes?

How do monitoring, logging and alerting work together in a DevOps environment?

How do you master CI/CD pipelines in a DevOps workflow?

What is DevOps and where should a beginner start?

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

What is a canary deployment and when should you use it over blue-green?

What is a rolling deployment strategy and what are its trade-offs?

How do you handle database schema migrations in a zero-downtime deployment?

How do you configure zero-downtime deployments with NGINX?

What is a feature flag and how does it decouple deployment from release?

How do you roll back a zero-downtime deployment if something goes wrong?

How do you set up zero-downtime deployments on AWS?

How do you achieve zero-downtime deployments in Kubernetes?

How do you test a deployment without affecting production users?

How do I set up a CI/CD pipeline from scratch?

What should every CI/CD pipeline include to catch bugs early?

How do you speed up slow CI builds?

What is a deployment pipeline and why does it matter?

What are the DORA metrics?

Q and A with Neil Millard - 26 March 2025 - Collaboration

Q and A with Neil Millard - 16th April 2025 - How do we make deployments SAFER?

Q and A with Neil Millard - 23rd April 2025 - Platform Engineering

Q and A with Neil Millard - 14th May 2025 - A.I edition

What DevOps metrics should you track to measure deployment health?

How do you implement zero-downtime deployments with Docker Swarm?

What is the best programming language for DevOps?

What is a software deployment pipeline?

Do DevOps consultants need professional indemnity insurance?

What is a VPN, and why should you care?

Private network vs public network: what is the difference, and how does it affect developer access?

How do you connect multiple sites and offices with cloud-based communications?

Cloud vs on-prem: what are the real trade-offs?

What is the difference between Docker and Kubernetes?

Ansible vs Terraform: which should you use?

How do you fix CrashLoopBackOff in Kubernetes?

Jenkins vs GitHub Actions: which CI/CD tool should you pick?