Since reading The Phoenix Project, I’m finding myself once again enthusiastic about DevOps culture.
When I first learned the term and started working on DevOps projects years ago as a Cloud Architect, I liked the idea and could see its merits. Better consistency of code releases, faster release cycles into production, developing the right solutions for production etc. However, I became a little despondent on the idea over the last few years, since a number of different large organisations have either tried and failed, or are still trying to do this.
So backtracking a little, what is “DevOps”?
Wikipedia, as the source of all truth says its: “A software development method that emphasizes the roles of both software developers and other information-technology (IT) professionals.”
Simply put it’s the concept of developers and operations working together instead of throwing things back and forth over the fence, blaming each other for their problems. It’s about removing that fence. Some confuse this with tools like Puppet, Chef, Jenkins etc. These are tools which help enable IT to work in a DevOps way, but they aren’t in themselves solving the solution.
Reading The Phoenix Project has reignited my enthusiasm in this. The main point I realised I was missing (As is Wikipedia), is the importance of the business drivers for DevOps. It’s not really about doing things faster or using “DevOps Tools”. It’s about providing more value to the business, such as:
- Ability for the business to predict performance
- Increase the feature release frequency, to be one step ahead of competitors
- Respond faster to customers wants and needs
- Tying I.T. issues to business goals, confirming the importance of I.T. and turning I.T. into an enabler, not a bottleneck.
Gene Kim and the team behind the book The Phoenix Project, did a great job of explaining it with “The Three Ways”. These are the steps in the journey to business transformation. In this post, I’m going to summarise these three ways, and as part of each I’ll talk about how cloud can help achieve mastery.
FLOW – The First Way
The first way is about understanding the entire system of the business. In a transformational company, I.T. isn’t a limb which could be cut off, it’s the nervous system of the company. The way I.T. is developed and operated within an organization will affect the overall business goals one way or another. Making sure I.T. is contributing to these goals in a positive way and not wasting time on un-planned work or working on projects which don’t provide value is essential to success. Mastering the first way means increasing flow through the system, making sure any changes within the system don’t adversely effect the rest of the business. the DevOps linkage here is that Operations know whats coming from Developement and Development don’t push anything they know is broken through into Operations.
What it means for cloud
Cloud provides a number of things which can help with flow, by starting to break down the silos within IT:
- IT Process integration – Bringing tools from different groups into a cohesive system.
- Automated Change management – Reducing wait times between teams.
Flow is further increased with:
- Life-cycle Management – Bringing up services quickly and tearing them down just as fast.
- Workflow Automation – This will help to standardise processes and anything repeatable should be automated.
By improving the understanding of the business, cloud also helps by feeding back metrics:
- Costing – Giving the business real costs for services.
- Capacity management – Showing where there’s scope for new projects, helping procurement.
- Compliance – Cloud breeds standardisation which enables compliance.
FEEDBACK – The Second Way
The second way is about creating feedback loops. Back and forth communication is key here. This is a concept which should be adopted across the board. Externally, asking your customers what they need and making changes to accommodate. Internally, understanding how what you produce affects other units and making improvements here too.
In the context of DevOps, this means bringing Development and Operations even closer together. Whilst the first way ensures that the process of moving code from Dev to Ops is improved, the second way evolves the process to make sure Operations are giving feedback to Development. It’s all about continually making corrections and improving quality. This means that Dev can improve their work when they know the results they produce in production. This leads to faster fixes and makes sure issues further down the line aren’t repeated.
What it means for cloud
Cloud can help create feedback loops with its inherent standardisation:
- APIs – Developers typically use APIs and Ops typically use GUIs. With a good cloud platform you have a single platform for both, with API access and a GUI layered on top.
- Centralised Logging – Allow Dev and Ops to use the same logging format, enabling them to share easily.
- Self Service Catalogue – A single source for services to be deployed.
- Role Based Access – Ensuring the right roles have the right access to give confidence in a single tool for everyone.
- Platform as a Service – Enabling standardised platforms for deployment, testing, staging QA etc.
- Blueprints – Allow subject matter experts from Dev, Ops and everywhere else to define policies and bring these into service blueprints.
CONTINUOUS LEARNING AND EXPERIMENTATION – The Third Way
When the first two ways have been mastered, a level of comfort will develop in the processes which have been adapted. Teams will be playing nicely together and in an ideal world, they are more productive than ever. The third way is about moving past the day-to-day business and looking to the future, continually pushing the boundaries of what can be done with I.T. Does the organization want to leapfrog the competition? Of course. So to do this, there is an element of risk taking. Continuous learning and experimentation means pushing failures into the system to see how it reacts, putting pressure on the entire system to see how it can cope and improvements which can be made.
What it means for cloud
By this point, your cloud is being used as a broker for I.T. services. You have gone past Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) and you are now on your way to the holy grail of Anything as a Service (XaaS). To go beyond this, we need to develop a pipeline for continuous delivery. This allows a route for code to be very regularly pushed through from Dev to Testing, QA and Production. Without automation and orchestration this would be very risky, but with the established cloud, utilizing the resource pools and abstracted compute, network and storage fabrics, we are in a much better place to do this. There are many tools which will help with continuous delivery. automated testing, deployment, packaging, and gating procedures to make sure certain rules have been satisfied before moving the code into the next environment. Continuous integration frameworks utilizing the cloud are going to move you closer to mastering the third and final way.
I will leave you with my favourite quote from the book:
“Any improvement not made at the constraint is an illusion.”