Looking into DevOps history we can see that it started as the convergence of numerous adjacent and mutually reinforcing movements
- Agile infrastructure and Agile system administration out of Velocity conferences started the convergence but movements had much earlier dates
- believed that computers would become multi-tenant and public. Late 90s was Salesforce's Enterprise applications through a website. Throughout 00s, different AWS services. Anyone remember AWS Mechanical Turk?
- Cloud computing – Commodity computing because computers were so expensive that it was
- Then, Lean, Agile, Continuous delivery
- A lot of you will probably know the Lean Startup, released in 2011 by Eric Ries but before that he was producing some great and influential content on his "The lessons Learned" blog. Some maybe
- Lean So`ware Development book in 2003. Just, looking back further, the term has its roots in the 80s from Lean Manufacturing at Toyota and only then because it was a term used in a paper about the Toyota Production System that came out of MIT. In fairness, Toyota had been applying many of the principles outside of the Lean label for many years prior.
- Agile from February 2001, 17 software ware developers met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile So`ware Development, in were commiged to improving so`ware delivery through beger systems of work
- Continuous delivery is best known through Jez Humble's book of the same name but it has it's roots a few years earlier than this. Both through a paper Jez co-authored with Dan North which describe principles and practices that allow new environments to be created, configured and deployed to at the click of a bugon. They showed how to fully automate your testing and deployment process using a multi-stage automated workflow. However, it's commonly accepted, that automated testing and delivery really had it's publicised birth when Mike Bland Joined Google and worked with Bharat Mediraga to transform how the Google Web Server Team delivered their so`ware.
- And ITIL. Yes, ITIL. Remember, this is DevOPS. Agile and continuous integration and release are the outputs of Development, which are the inputs into IT Operations; and ITIL is still the best codification of the business processes that underpin IT Operations, and actually describe many of the capabilities needed into order for IT Operations to support a DevOps-style work stream. The goal of DevOps is not just to increase the rate of change, but to successfully deploy features into production without causing chaos and disrupting other services, while quickly detecting and correcting incidents when they occur. This brings in the ITIL disciplines of service design, incident and problem management. However, in order to accommodate the faster release cadence associated with DevOps, many areas of the ITIL processes require automation, specifically around the change, configuration and release processes.
- The convergence of these movements culminated in 2009 where the term DevOps was fist used and the name almost happened accidentally when Patrick Dubois couldn't think of a name for his upcoming conference and took inspiration from a recent velocity speech he saw by John Alspaw's called "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr" and took the Dev and Ops and the fact the conference was over 2 days and came up with DevOpsDays
- And well, from that point, interest grew and developers got involved and improved the scripts previously created by operations engineers and accelerated it to next level.
What DevOps is not
- A function
- It's not a function because the scope of DevOps is so wide reaching. You can't turn huge areas of what two whole departments previously did, into the function of one team
- A role or a skill
- It's not a role/skill because, well, you can't define all that into one persons responsibility
- An infrastructure or (Just) Continuous delivery
- Continuous delivery because, as we've seen, this is just one part of the picture
- A quick fix
- Not a quick fix because usually the most difficult thing to change is human behaviour, and this doesn't happen over-night. You'll also come across many challenges unique to your business
So what is it?
Something that anyone can find on Wikipedia
- Adjective for technology people closely collaborating DevOps is a way for IT operations to catch up with Agile IT Development and allow the business to regain trust in the entire IT organisation as a whole. Most significantly on working together on automation tasks
- It's thinking about the system as a whole. Which is vital to creating strong feedback loops, through better metrics, which in turn enable loops to be amplified and shortened, which in turn allow teams to experiment and learn more. Driving innovation and value.
- loosely coupled teams = your IT organisation structure needs to be fluid and Agile with the environment. Where teams, should they need to be, can be disbanded and reassembled as projects transition.
- The breadth of the scope can't be more apparent than at the DevOpsDays conferences that gave birth to the name. If you're unsure what DevOps means to you. I recommend you look at the agenda for one of these events and agend If you can
A little while back I came across a great article (and linked articles) by Mike Loukides on O'Reilly's Radar website describing another, widely misunderstood term, "NoOps". Mike goes on to describe how Operations has evolved over the last few years and how it never really goes away.
Adrian Cockcroft’s article about NoOps at Netflix ignited a controversy that has been smouldering for some months. John Allspaw’s detailed response to Adrian’s article makes a key point: What Adrian described as “NoOps” isn’t really. Operations doesn’t go away. Responsibilities can, and do, shift over time, and as they shift, so do job descriptions. But no matter how you slice it, the same jobs need to be done, and one of those jobs is operations. What Adrian is calling NoOps at Netflix isn’t all that different from Operations at Etsy. But that just begs the question: What do we mean by “operations” in the 21st century? If NoOps is a movement for replacing operations with something that looks suspiciously like operations, there’s clearly confusion. Now that some of the passion has died down, it’s time to get to a better understanding of what we mean by operations and how it’s changed over the years.
At a recent lunch, John noted that back in the dawn of the computer age, there was no distinction between dev and ops. If you developed, you operated. You mounted the tapes, you flipped the switches on the front panel, you rebooted when things crashed, and possibly even replaced the burned out vacuum tubes. And you got to wear a geeky white lab coat. Dev and ops started to separate in the ’60s, when programmer/analysts dumped boxes of punch cards into readers, and “computer operators” behind a glass wall scurried around mounting tapes in response to IBM JCL. The operators also pulled printouts from line printers and shoved them in labeled cubbyholes, where you got your output filed under your last name.
The arrival of minicomputers in the 1970s and PCs in the ’80s broke down the wall between mainframe operators and users, leading to the system and network administrators of the 1980s and ’90s. That was the birth of modern “IT operations”... Read more on O'Reilly Radar
