Skip to main content

Real transformations + complete FAQ

Summary: DevOps is not conference theory — it is what allows Amazon to deploy thousands of times per day and Netflix to survive the outage of an entire data center. This lesson presents five documented transformations, the most frequent causes of failure, and answers the 14 questions everyone asks when getting started.

1. Amazon — the origin of the model​

The mandatory interfaces rule is the most technically interesting one, and it is the one people forget to mention. Forbidding a team from accessing another team's database directly forces it to go through a documented, stable interface. Without this rule, you get services sharing one database — that is, a disguised monolith.

The most revealing fact: AWS was born from this transformation. By building self-service infrastructure for its own teams, Amazon created a product that today represents a major share of its profits. It is the most spectacular example of platform engineering.

2. Netflix — reliability through induced failure​

The reasoning in point N4 is brilliant in its simplicity. Machines will fail, that is a statistical certainty. The only question is: when. Netflix chose to control that moment. A machine shut down at 2pm on a Tuesday, with the whole team available, produces learning. The same failure on a Sunday at 3am produces a crisis.

An important warning if the idea appeals to you: do not install Chaos Monkey in production tomorrow morning. Netflix could do it because its architecture was already designed for resilience and its observability already mature. Applied to a fragile, poorly instrumented system, it simply produces outages.

3. Etsy — the cultural transformation​

The practice in point E6 is an excellent maturity indicator, and easy to assess in any organization. If a newcomer can deploy to production on their first day, it means the process is automated, documented, safe and reversible. No audit provides as much information in a single question.

The order Etsy followed matters: culture first, continuous deployment next. Many companies try the reverse and fail, because in a blame-seeking culture, nobody will dare to deploy frequently.

4. A large traditional enterprise​

This is the most useful case for the majority of readers, because most people work in traditional organizations, not at Netflix.

The central lesson: transform by proof, not by mandate. A top-down directive announcing "we are doing DevOps now" meets legitimate resistance. A pilot team that demonstrates quantified results creates demand coming from the other teams. It is infinitely more effective and more durable.

Point G6 is the one that takes the most time in regulated environments, and it must be approached with caution. The approval committee exists for good reasons — the goal is not to remove it but to replace manual control with automatic control, which is often better accepted by auditors.

5. Why transformations fail​

Cause 4 is the one that kills successful transformations, which is particularly frustrating. A team may have genuinely improved things and lose its budget because it measured nothing beforehand and therefore cannot demonstrate anything. Measure your starting point before changing anything.

6. The 14 most frequently asked questions​

1. Is DevOps suitable for a small company?

Yes, and it is even easier. In a five-person team, there is no wall between development and operations — the same people do both. The cultural part, the hardest one in a large enterprise, is already in place.

What changes is the tooling: you need neither Kubernetes, nor an internal platform, nor an SRE team. A pipeline that deploys automatically, tested backups and decent monitoring are more than enough.

The mistake to avoid: copying the tooling of large enterprises. Docker Compose on two servers is often the right choice for a small organization.

2. And in a regulated sector (banking, healthcare, public sector)?

Yes, and often with more benefits than elsewhere. The opposite intuition is widespread but wrong.

The decisive argument: an automated process is more auditable than a manual one. The pipeline records who approved what, when, which tests were run, which version was deployed. An auditor far prefers that to a folder of hand-signed approvals.

What changes: regulatory controls do not disappear, they become automatic and traceable. Separation of duties is maintained through pipeline access rights, not through different people.

3. Do you need microservices to do DevOps?

No, absolutely not — it is a very widespread confusion.

A well-built monolith can perfectly well be deployed several times a day with a good pipeline. Many organizations deliver excellently with a monolith.

Conversely, badly split microservices produce a system that is harder to deploy than a monolith: you have to coordinate fifteen deployments, manage interface versions, trace requests across services.

The usual advice: start with a well-structured monolith, split only when a specific reason demands it — a separate team, a different scaling need, a technological constraint.

4. How long does a DevOps transformation take?

Depending on the size of the organization:

  • Small team (fewer than 10 people): first results within a few weeks.
  • Medium organization (50 to 200 people): 6 to 18 months for a visible change across the whole.
  • Large enterprise (more than 1,000 people): 2 to 5 years, and never completely finished.

The deciding factor is not size but the starting culture. An organization with a blame-seeking culture will take much longer, whatever its size.

The right indicator: do not aim for the "end of the transformation", aim for a measurable improvement per quarter.

5. Does DevOps eliminate system administrator jobs?

No, it transforms them. Operations work does not disappear: someone still has to think about networking, backups, capacity, security patches.

What changes: instead of executing repetitive manual tasks, you build systems that execute them. The job moves closer to development.

For a system administrator who wants to evolve: learn a scripting language, Git, containers and infrastructure as code. Your system knowledge is a considerable advantage — many developers who come to DevOps have no system culture at all, and it shows.

6. How do I convince my leadership?

Talk in lead time and money, never in tools:

  • "Today, a change takes three weeks to reach our customers."
  • "Our competitor ships every week."
  • "Each incident costs us X euros and Y days of work."
  • "A pilot team can demonstrate a result in three months."

The most effective proposal: ask for a pilot team on a non-critical application, with a measurable goal and a short deadline. It is a low commitment for leadership, and the numbers will do the rest.

Do not ask for a tooling budget for the whole organization as a first step.

7. Should everything be automated?

No. The criterion is simple: automate what is repetitive or risky.

To automate first: anything done more than once a month, and anything where a human error would have serious consequences.

Not necessarily to automate: a task performed once a year can stay manual if automating it costs three weeks. However, it must be documented and tested.

The honest calculation: automation time versus time saved over two years. But add the risk factor — a rare and critical task deserves to be automated even if the time calculation does not justify it.

8. What if my company refuses to change?

Three approaches, in order of preference:

  1. Improve your own scope. You can almost always set up automated tests, version your scripts, document. Nobody will forbid it, and you gain a real skill.
  2. Find an ally — a manager who suffers from the delays and is looking for a solution. A pilot project on their scope.
  3. Consider changing companies. It is not a failure: some organizations will not change, and the market is favorable to DevOps profiles.

In any case: your learning belongs to you. Skills acquired on a personal project are real and transferable.

9. What is the difference between DevOps and platform, concretely?
  • DevOps — the culture and practices: shared responsibility, automation, feedback loops.
  • Platform engineering — an organizational answer to the cognitive load problem. A team builds internal services that product teams consume in self-service.

The relationship between the two: the platform makes DevOps tenable at scale. Without it, asking every team to master Kubernetes, Terraform, observability and security is unrealistic.

The success criterion of a platform: teams use it voluntarily. If they work around it, it is a failure, even if technically excellent.

10. Is DevOps compatible with an external service provider?

It is harder, but possible. The main difficulty is structural: a service provider is often paid by time spent, which does not encourage automation.

What works:

  • Outcome commitments rather than counting days: lead time to availability, uptime, recovery time.
  • A mixed team of internal and external people, with explicit skill transfer.
  • Keeping ownership of the code, the infrastructure as code and the pipelines. Never let a provider be the only one who knows how to deploy.

The absolute point of vigilance: if nobody in-house knows how to deploy your application, you are in a dangerous dependency situation, whatever the contract terms.

11. How do we measure whether our DevOps is progressing?

Four widely used indicators, from the research on delivery practices:

  • Deployment frequency — how often do you release to production?
  • Lead time for changes — how long between code approval and its availability?
  • Change failure rate — what proportion of deployments causes an incident?
  • Time to restore — how long to restore service after an incident?

The most counter-intuitive observation: these four indicators progress together. The teams that deploy most often also have the lowest failure rates. Details in our CI/CD course.

A useful complement: also measure team satisfaction. Excellent indicators obtained by burning people out are not sustainable.

12. Do you need a degree to do DevOps?

No, it is one of the most open trades in IT. Many recognized professionals come from system administration, development, support, or a complete career change.

What actually matters:

  • A demonstrable end-to-end project.
  • The ability to explain your choices.
  • A solid diagnostic method.
  • Possibly a certification to pass the automatic recruitment filters.

The degree helps for some large companies and for obtaining work visas. Elsewhere, it weighs far less than what you can actually do.

13. How much time per week to train while working?

Ten hours a week is a realistic and sustainable pace. That gives roughly six months to reach a hireable level starting from scratch.

The format that works best: one to two hours on weekdays for theory and reading, four to six hours on the weekend for uninterrupted practice — practice requires long blocks.

The classic mistake: chaining tutorials without ever building a personal project. You will feel like you are learning, but you will not be able to do anything autonomously.

The useful benchmark: if you cannot rebuild what you learned without looking at the tutorial, you have not learned it yet.

14. Where do I concretely start tomorrow morning?

If you want to learn DevOps:

  1. Install a Linux virtual machine and work only in the command line for a month.
  2. Create a Git repository and get into the habit of versioning everything in it, including your personal scripts.
  3. Containerize a small application, even a trivial one.
  4. Add a GitHub Actions pipeline that builds and tests it.
  5. Start the Linux discovery course, then follow the track in order.

If you want to improve your current team:

  1. Measure your four current indicators. Today, before any change.
  2. Map the journey of a change, waits included.
  3. Identify the main constraint and attack it alone.
  4. Reduce your deployment batch sizes — it is free and immediate.
  5. Introduce blameless incident analyses.

In both cases: start small, measure, show the results.

7. What you learned in this course​

8. Your next step​

This course was the entry point. Here is the recommended order for what comes next.

The complete discovery track, in order​

  1. Linux Discovery — the bedrock of all infrastructure
  2. Git — the concepts then Git in practice
  3. Docker Discovery — containers
  4. CI/CD Discovery — delivery automation
  5. Kubernetes Discovery — orchestration
  6. Terraform Discovery and Ansible
  7. Cloud Discovery — IaaS, PaaS, SaaS and FinOps
  8. Observability Discovery — metrics, logs, traces, SLOs
  9. DevSecOps Discovery — built-in security

To move on to practice​

The reference reading list​

  • "The Phoenix Project" (Gene Kim) — a business novel, very accessible, ideal for understanding the stakes.
  • "The DevOps Handbook" (Gene Kim et al.) — the methodical and complete version.
  • "Accelerate" (Nicole Forsgren, Jez Humble, Gene Kim) — the quantified evidence behind the whole movement.
  • "Team Topologies" (Matthew Skelton, Manuel Pais) — team organization.
  • "Site Reliability Engineering" (Google) — available for free online.

9. One last piece of advice​

DevOps is not a destination, it is a direction.

No organization has "arrived". Amazon and Netflix keep improving their practices. The question is never "are we doing DevOps?" but "are we better than last quarter?".

And for you, personally, the advice is the same. Do not try to learn everything before starting. Install a Linux machine this weekend. Containerize a small application the following weekend. Add a pipeline the week after.

In six months, you will have a complete project to show, and you will know what you are talking about. That is all it takes to get started.

Remember in 30 seconds​

  • Amazon: split into services, two-pizza teams, mandatory interfaces (the rule people forget), you build it you run it. AWS was born from this transformation.
  • Netflix: do not prevent failures, but work despite them. Induce the failures when the team is present and rested.
  • Do not install Chaos Monkey on a fragile system — Netflix was already resilient and instrumented.
  • Etsy: the decisive change was cultural — blameless incident analyses, before continuous deployment.
  • A newcomer deploying on their first day is the best maturity indicator there is.
  • Large enterprise: transform by proof (pilot team, quantified results), never by top-down directive.
  • Six causes of failure: starting with tools, intermediary DevOps team, top-down directive, measuring nothing, ignoring cognitive load, neglecting compliance.
  • Measure your starting point before changing anything, otherwise you will prove nothing.
  • No need for microservices to do DevOps. A well-built monolith deploys very well.
  • DevOps also works in regulated sectors — an automated process is more auditable than a manual one.
  • DevOps is a direction, not a destination. The question is: are we better than last quarter?

Thank you for taking this DevOps discovery course! 🎉

Last step: take the end-of-course quiz — five corrected and explained questions, three minutes, to check that the essentials are in place.

Then, continue with Linux Discovery or go back to the table of contents.