DevOps in a nutshell
Vive la révolution
Movements are generally born out of frustration. A brief glance though the history books tells us this: the Reformation was born out of dissatisfaction with the dominant religion, the French Revolution born out of anger at the practices of the ruling elite. The DevOps revolution has fortunately not involved loss of life, but its impact on those of us in IT has been significant and will only increase with time.
The traditional development life-cycle was linear — software was developed and then passed (or “thrown over the fence” in some cases) to operations to run. An invisible wall stood between software developers and software operations, a wall erected with good intentions including the need for security and stability — but a barrier that made life frustrating for both sides. With little understanding of the world of operations, developers would write code that — to use the well-known IT joke — “works on my machine”, however this code was found wanting when deployed to the vastly more complex real world of operations. By the same token operations were often seen as a bureaucratic impediment to developers being able to get value into the hands of the end customer.
So in the simplest sense DevOps is a coming together of the worlds of Development and Operations. Hence: DevOps
History
Compared to movements like Lean and Agile, DevOps is the new kid on the block. The term ‘DevOps’ was first coined by Patrick Debois and Andrew Shafer in 2008 . DevOps has built upon a strong foundation laid by the Lean and Agile movements and indeed many of the key moments in DevOps history have occurred at Agile conferences.
The Three Ways of DevOps
The Three Ways of DevOps, a concept first coined by Gene Kim (author of The Phoenix Project and The Unicorn Project, more on these later) in a 2012 blog post describes three ‘ways’ that, if followed, result in a greater level of collaboration between development and operations. From the blog post:
These “three ways” were given life in Gene Kim’s work ‘The Phoenix Project”. This work of fiction describes itself as ‘a novel about IT, DevOps and helping your business win’.
The story follows Bill Palmer, a middle management IT professional who finds himself unexpectedly promoted to VP of IT Operations and in charge, from an operations point of view, of a highly visible and critical project — the phoenix project. Guided by the unconventional yet very wise Eric Reid, Bill takes the project from zero to hero and on the way learns valuable lessons from the world of DevOps. For example, Bill learns that there are four types of work in IT: Business Project work, IT project work, operational change and unplanned work.
Since the original blog, more comprehensive ways of visualizing the flow of value from development, to ops, and back again have been developed. You will often see eight phases drawn as an infinity loop:
The Five Ideals
Gene Kim’s latest work The Unicorn Project is somewhat of a sequel to The Phoenix Project — looking at the project that gave name to the first book through a different lens. The Unicorn Project tells the story of Maxine, a gifted technician sent to work in the distressed ‘Phoenix Project’ development hub. She joins with Kurt to form a ‘rebellion’ who work tirelessly to turn around a dire company situation and ultimately triumph against the forces of bureaucracy and mediocrity
Along the way the sage, Eric imparts 5 ideals to her and her band of DevOps rebels.
- The First Ideal: Locality and Simplicity.
- The Second Ideal: Focus, Flow, and Joy
- The Third Ideal: Improvement of Daily Work
- The Fourth Ideal: Psychological Safety
- The Fifth Ideal: Customer Focus
Technical Practices
A large part of the DevOps culture is a focus on technical practices that enable and accelerate this flow of value and feedback between development and production operations. The poster child for DevOps technical practices is Continuous Delivery, the ability to deploy, to production a continuous stream of potentially releasable functionality.
The range of technical practices and tools that surround DevOps is vast, as the below illustration shows:
However seeing DevOps as purely a set of technical skills and tools would be a mistake. Yes DevOps has an unmistakable geek flavor, but DevOps speaks to the business on a deeper level.
The Inverse Conway Manoeuvre
In 1967 computer programmer Melvin Conway introduced an idea that has since become known as ‘Conway’s Law’:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
In other words, the software architecture will ultimately reflect the company structure. An ‘inverse Conway manoeuvre’ then both leverages this discovery and flips it on its head. You structure the company to align with the technical architecture you want to achieve.
Team Topologies
The latest thought leadership to come from the rich soil of DevOps comes with the recent release of Matthew Skelton and Manuel Pais’ ‘Team Topologies’, which leverages and builds on the Inverse Conway principle. To achieve the technical and operational design excellence that companies today strive for only four fundamental types of teams are needed within a software organization:
- A stream aligned team. The most common team type, this team type focuses on an end business outcome such as an area of a software product. This is a self organizing and self-sufficient team.
- An enabling team. An enabling team exists to empower other teams. This team doesn’t as a rule do the work, rather they teach and train other teams how to work effectively.
- Complicated subsystem team. This team type will be relatively rare, and wraps around a specialized and complex area, for example a Virtual Reality interface.
- Platform team. Platform teams exist to give stream aligned teams leverage, literally a platform, to enable and accelerate the flow of value from planning to coding to operations.
With these four fundamental team types, or ‘topologies’ defined the authors look at how teams interact, defining three primary team interaction modes. What these are I’ll leave up you, the reader to explore — Team Topologies has some powerful concepts and is well worth a read.
The future
Make no mistake, despite or maybe because of, its quiet, agreeable and somewhat geeky demeanor, DevOps has the heart of a revolutionary. To which I can only say:
Vive la révolution!
