The Pheonix Project - What I learned from it.

I recently read the book called 'The Pheonix Project'. A book that was recommended by a lot of folks especially to get started in the DevOps domain. 

This is a book written by Gene Kim, Kevin Behr and George Spafford. I am listing down some of the key takeaways from this book. 

This is a fictional story that revolves around a character named Bill Palmer who is promoted to VP of IT Operations and is quickly given the task of making sure the company's(Parts Unlimited) next big project named 'Pheonix' goes into production. A lot depends on this project failing which Bill's entire IT division may get outsourced. 

Bill quickly forms a team with two of his colleagues Wes and incredible Patty, who swear to clean the swamp. Around this time Bill is introduced to a potential board member Erik, who is a technology hot-shot as quoted in the book. Erik reminded me of Master Oogway and throughout the course Erik guides Bill and shows him how work in IT is comparable to that of the work done in a manufacturing plant. 

Initially Bill is amused at this very thought and dismisses the idea, but as Oogway said "One often meets his destiny on the road he takes to avoid it" .

Bill is eventually making amends in IT to replicate the workflow of a manufacturing plant.

Erik takes Bill to the company's manufacturing plant and riddles him to identify the 4 kinds of Work by observing the work happening at the plant.

Eventually Bill figures out the 4 kinds of works :

1. Planned work .i.e Business projects and requests for new features.
2. Internal projects .i.e Internal requests mostly related to operations such as server/environment creations, server upgrades, software updates, server patching etc.
3. Changes .i.e work  created by the above two kinds of work, generally through feedback. 
4. Unplanned Work - This kind of work is often not tracked. Support for incidents and other unforeseen circumstances that may usually arise from the first three kinds of work.  

Erik talks about 'The 3 Ways', which eventually form the pillars of the DevOps principles that Bill would implement later at Parts Unlimited.

• The First Way - Work should flow in one direction.

Its important to identify the flow of work, and make sure that the work flows on one way. This is achieved by firstly identifying the constraints and removing the constraints. Secondly to limit the work in progress (WIP). WIP is known as the silent killer in both manufacturing and IT both alike.

In the story Patty uses Kanban boards to better visualize the workflow, identify the constraints and limit the WIP. Through this method they identify that one of the major constraints for the Pheonix project was Brent - a superstar who is involved in too many tasks. Bill and Patty try to reduce the work that goes to Brent thereby allowing him time on tasks that were far more critical .i.e the tasks associated with Pheonix. 

• The Second Way - Enabling and amplifying feedback loops so as to identify issues/defects at a much earlier stage. 

The goal is to identify and fix as many defects in the development stage rather than pushing the defects to the operations/staging environment. Having a development environment that is identical to production would help resolve a lot of "But_this_works_in_the_development_env" kind of issues. Security code audits and pentests must happen at a earlier stage (shift-left) too, thereby identifying and resolving as many issues at a much earlier stage as possible.

• The Third Way  - Practice and Repeat.

As Bruce Lee used to say "I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times."  

Unlike the traditional way where the deployments used to happen once in months, the third way is all about deploying as many times as possible. This is where automation comes into the picture where right from deploying machines in virtual environments to running QA and Security checks to deploying the code to production everything is automated.

In the story Bill and his team figure out ways to have code with a minimum viable product(MVP) deployed in production as soon as possible and then further keep integrating new features to it. But unlike before, Bill's team deploys code to production several times and in the process identify repetitive tasks and automate them. 

In conclusion I would say its a very engaging book and it does its job of helping you understand the place of DevOps in today's world.