DevOps theory for beginners

You can treat your cloud just like it was a data center full of servers with system administrators cracking the whip over them, but that misses the point of how to get the most from your cloud with DevOps.

The real secret of clouds is that they enable developers and system administrators (operators) to work together, hence DevOps: The portmanteau of development and operations.

By automating server operations, both programmers and administrators can focus on making the most from their hardware’s raw computing power. This is done using DevOps programs such as Chef and Puppet, or by leveraging earlier technologies such as version control systems like Git, to start automating system administration.

The credit for coming up with this idea goes to Patrick Debois, an IT consultant who came up with the idea of bridging the gap between projects and operations by using Agile programming techniques.

The point of all this, as DevOps expert Damon Edwards explained, is that “DevOps is a response to the growing awareness that there is a disconnect between what is traditionally considered development activity and what is traditionally considered operations activity.”

That’s because, Edwards explained, “Development-centric folks tend to come from a mindset where change is the thing that they are paid to accomplish. The business depends on them to respond to changing needs. Because of this relationship, they are often incentivized to create as much change as possible.”

At the same time, “Operations folks tend to come from a mindset where change is the enemy. The business depends on them to keep the lights on and deliver the services that make the business money today. Operations is motivated to resist change as it undermines stability and reliability. How many times have we heard the statistic that 80% of all downtime is due to those self-inflicted wounds known as changes?”

Now this notion annoys the heck out of some programmers. Jeff Knupp, a noted Python programmer, for example, claims that DevOps is killing developers and encouraging a work environment where everyone is encourage to become a Jack of all trades and a master of none.

There may be something to his stance in some companies, but when it comes to the cloud, DevOps isn’t about forcing developers into becoming “technology utility players,” it’s about letting the technology carry the burden of server grunt work.

As James Urquhart, a cloud expert, has pointed out, “First, server virtualization — followed by storage and network virtualization — introduced us to the idea that physical systems operations can be decoupled from the digital elements that they host. Operating systems no longer have to be shackled to physical servers. File systems no longer have to be locked down on specific spindles. Connections between servers are no longer statically assigned to specific physical switch ports.”

It was one thing when servers needed constant hands-on attention to keep them running. Today, everything, especially in the cloud, is virtualized.


With DevOps, developers and system administrators can finally get past their wall of confusion.

No, we’ll never really get to NoOps. We’ll always need someone to go around pulling dead servers from racks. At the same time, in the 21st century cloud, we need people who can both manage and develop in clouds. In short, we need people who are adept at DevOps.

True, some people will always be better at administrating than programming and vice versa. To make the most of the cloud, though, where’s it’s all virtual all the time, we need operators who can work with developers and programmers who get along with administrators. If those qualities happen to be in one person, that’s great. But it’s the ability to cross the decades-old gap between development and operations that’s now a rare, valuable skill.

By using Agile techniques, which at heart is about working and talking together to achieve common goals, DevOps can help you make the most of your cloud. If you don’t use DevOps techniques as well as programs, don’t be surprised if your cloud projects go slowly, go over-budget, and never live up to their promise.


  1. DevOps is not just for cloud based environments. DevOps fits “any” environment. The ground swell for DevOps (continuous integration thru continuous deployment) is gaining by day. Minimizing human in the loop delays and errors are the at the forefront for gained efficiencies. With the mindset change occurring rapidly…it only gets better.

    • Totally agree. Automated testing, automated build, continuous integration and agile development concepts have been around way before any clever IT marketing guru invented “DevOps”, let alone “Cloud”. I agree that the advent of virtualisation has brought about the ability to automate “more” with regard to infrastructure, just as Software Defined Networking, for example, will further enhance this capability. Don’t be lulled into thinking you need a “Cloud” to do “DevOps”! Beginners beware!

      The paradigm that DevOps embodies (the theory that needs to be understood for beginners) – advocating agile software development practices, bringing QA, Devs and Ops people together in a collaborative work environment, and aggressive automation of delivery without sacrificing quality – is sorely missed in this article however it should be the salient point given the title.

      I encourage those seeking foundation learning to check out “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”, presented back in 2009: (slides located at It’s eloquently discusses “DevOps” concepts without the use of buzzwords.

  2. Mike hovey says:

    This article formats well on my PC screen – not so well on my iPhone. Is there a format accessible for mobile devices?

  3. Randy Steinberg says:

    While it is long overdue to recognize that application solutions fail unless they can be operated at minimal cost and risk, there are roughly 40-50 areas of support that need to be considered to adequately run a solution in production. Server administration and release management are only 2 of them.

  4. I see DevOps really springing from a Lean mindset, where the old assembly line approach (“Tayorism”) has been proven to produce worse quality at slower speeds. The brilliance of the seminal book, “The Phoenix Project,” lies in how well it explains the problems caused by multiple hand-offs (wait-states) and siloed roles.

    In that book, you can clearly understand the value of the solutions that come under the DevOps moniker. Oh, and nowhere in that book are Chef or Puppet mentioned. Tooling certainly becomes important to optimize your practices. Much more important are the practices and people themselves.

    More than anything, DevOps is a philosophically driven mentality, one grounded in the human element. Like Agile, for me, DevOps is a moral imperative. We should not continue to suffer through old waterfall, assembly-line ways of doing things that lead to death-marches and burn-out. Especially when there are demonstrably better ways of doing things.

  5. Peter ODonoghue says:

    We’re starting to partner with Damon Edwards within NPS to help some of our dev and ops teams understand and embrace the lean thinking underpinning DevOps. Running a workshop on 3/16. Also seeing an interest in DevOps training for our customers.

  6. Prabht Kumar says:

    That’s why, the system administrators should participate with their programming colleagues at the beginning of the projects in order to percept the objective of project.

  7. DevOps with Agile techniques in what future holds …

  8. Considering this is titles ‘DevOps theory for beginners’ I haven’t really come away with any understanding of DevOps, other than it’s based on Agile (which wasn’t explained either) and is to do with server automation.

    • Fully agree with that Alistair.

      Other missing elements (and I also watched the Flickr video) are that there is no mention of an upfront Change Process, with analysis/impact assessment/approval all still needed before any actual coding starts. Likewise no mention of any formal testing – just a nod to ‘automated testing’ – and to be honest I have never ever seen automated testing cover the aspect of User Acceptance.

      Maybe I’m just ‘old school’ but what is descibed just seems to be a modern excuse for a hackers paradise, because all we hear is developers making changes, speaking to Ops and then ‘bang’ an automated build and deploy sees the change magically appear in Production. These must be either extremely minor changes or bug-fixes, otherwise I’m missing something.

      As a Configuration Manager, I’m comfortable with the development/automated buil/deploy concept, even at the rate of 10/day mentioned by Flickr – that just means 10 new baselines/day. Its the clearance to deploy to Production that does not work for me. Evn auto-deploy to controlled testing environments is questionable, as the test team need to have stable/unchanging environments until they are ready to accept a new batch of changes.

  9. There are lots of nice things you can do with devops these days such as blue/green deployment ( ).
    Convincing people that continuous integration and deployment is a good idea is also half the battle…but these do rely on development teams being highly disciplined and going full steam on TDD to make sure they have as close to 100% good coverage on their code.
    As for going about yanking old servers from your data centre….if you have a whole bunch of cheep bare bones machines like google or facebook…you can just leave dead machines in place and move their processes to another bit of your cluster.

  10. I totally agree with the gap between Dev and Ops.
    Many people/projects have so called adopted DevOps yet are mainly doing Dev(ops) where the ops is limited to providing the ‘real’ Ops with for instance Java WAR files for distribution. With the coming of containers (docker) this is even more true. They are sometimes used to speed up development (since it sometimes takes Ops a long time to set up dev/test/accept) and have environments as close to Ops as needed, but the final Ops still uses traditional methods.
    A serieus mindshift is needed and CIO/CEO support to make it really happen.

  11. Steve Cowles says:

    I really like the illustration – that’s very much how I see it. As for the title ‘DevOps’ it has many definitions, but I think the bottom line is tools that claim to enable it will either make work easier and the processes to share information over the divide easier, and they will succeed, or they won’t and will fall by the wayside. I think its the tools that claim to support ALM that are interesting.

  12. Thank you very much I really like the illustration – that’s very much how I see it. As for the title ‘DevOps’ it has many definitions.

  13. Its true for next generation outcome of IT Solutions evolution and WiFi revolution Changes like traditionally with global culture impact from Mainframe to Computers and now Mobiles and future Hybrid Computing Virtually everywhere peace of each individual growth with common life and survive in the public, private and Governance with Law follow up of modern lifestyle from ancient generation studies worldwide.

  14. Thanks for sharing


  1. […] so you get that DevOps is important. Yay you! But how broadly has DevOps been accepted? That’s a darn good question, and […]

  2. […] DevOps is among the most sought after skills in the industry. Fifty-eight percent of hiring managers are seeking DevOps professionals while the need for developers remains the top position on their list at 74 percent. Open-source professionals also feed this trend as 13 percent of the surveyed identified DevOps as the most in-demand skill today –more than any other category. […]

  3. […] into containers. At the same time, managing these more advanced data centers is moving from DevOps tools to Kubernetes cloud container orchestration. […]

  4. […] also lend themselves to DevOps tools, such as Ansible, Chef, and Puppet. This gives you the advantage of making it easy to automate […]

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.