What does one mean when they say they want to ‘adopt’ or implement DevOps? What is a ‘DevOps Solution’? DevOps is not a product. It is not a process. It is a philosophy. A philosophy that includes principles and practices effecting People, Processes and Tools.
Adopting DevOps hence, is not just about adopting a product or a process. It is about undergoing Transformational Change.
Organizations want to create innovative applications and features. They create these applications or services to solve a business problem. Either for themselves (better CRM system) or for their customers/users (better Web Portal). Whether they are a startup with an innovative Mobile App; a large financial institution with their complex transactional systems; or a Military contractor building a ‘dirt-to-space’ real-time battlefield management system, they are all looking for a way to make what they build better.
Better can mean many things. For the startup, better may be the number of new features they can get out to their users, fast. Quality may not be their highest priority. For the financial institution, better may be minimizing downtime for their systems every time they push out a new capability. The number of new features they release may be lower on their list. For the military contractor better may be ensuring close to 100% reliability of their system. Innovative features may be trumped by quality and reliability for them.
So, the reason to adopt DevOps will vary considerably from organization to organization and even from team to team within the same organization. The team building the customer website may have very different priorities than the team deploying the new HR system. All reasons are good reasons, as long as it is not ‘it’s the buzzword the VP heard at the last conference’.
Let’s list some of the reasons an organization may adopt DevOps:
- Time to value
- Speed of deployment
- Reduce cost/time to deliver
- Reduce time/cost to test
- Increase test coverage
- Increase environment utilization
- Minimize deployment related downtime
- Minimize deployment time issues (you know, the weekend long deployment marathons)
- Minimize roll-backs of deployed Apps
- Increase the ability to reproduce and fix defects
- MInimize ‘mean-time-to-resolution’ (MTTR) of production issues
- Reduce defect cycle time
- Reduce challenges related to Dev and Ops collaboration
…and I could go on. In a nutshell, the reason(s) to adopt DevOps has to be a reason that provides value to the organization.
The goals for DevOps an organization has will determine which practices and principles of DevOps the organization needs to adopt. I have worked with an organization whose biggest challenge was the limit they had on their ability to test often and thoroughly. Their QA environments took too long to be ‘refreshed’ for every test cycle, extending their test cycles to unacceptable lengths. What they needed to do was virtualize their test environments with ‘production-like’ systems (more on that in the next post), which could be provisioned and populated with ‘fresh’ test data in minutes/hours, rather than the days it took them currently. For them, adopting Continuous Delivery to Test, by building a Delivery Pipeline that would allow them to automate the cycle from a developer kicking off a build to tests being run in a ‘freshly’ provisioned environment, would add tremendous value. This is where they should begin and limit their DevOps adoption too. Once they see value from this one capability, they can examine other areas of challenges for them that can be addressed thru DevOps.
It is not easy or cheap:
Adopting DevOps is not easy or for that matter cheap. Not in terms of cost of tools, people, etc, but in terms of the effort it takes. It would be a multi-month, or depending upon your existing maturity, even a multi-year project. The good news is that if done right, starting and progressing down the path can produce value pretty early. I repeat, if done right.
The main reason it is not easy is because of the transformational change your organization will need to undergo. The People part of the equation will take more effort than the Process or Tools.
So, assess your areas of improvement in your delivery cycle. If you do not have the skills in-house, hire a consultant/consulting organization to conduct such an assessment. The assessment would help determine which areas in the DevOps spectrum of capabilities would provide you the highest ROI. Which would address the key pain-points you have. Then create a roadmap for adoption. <start commercial break> We at IBM conduct such assessments all the time. Contact us…</end commercial break>.
Like to learn more about Adopting DevOps? Check out my new book – The DevOps Adoption Playbook.
- Understanding DevOps – Part 1: Defining DevOps
- Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
- Understanding DevOps – Part 3: The Battle of Dev vs Ops
- Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
- Understanding DevOps – Part 5: Infrastructure as Code
- Understanding DevOps – Part 6: Continuous Deployment
- Adopting DevOps – Part 1: Begin with the Why
- Adopting DevOps – Part II: The Need for Organizational Change
DevOps books I have written:
Other DevOps Posts:
- DevOps 101 – Concepts and Basics (Slides from IBM Innovate 2013)
- What is Water-SCRUM-Fall?
- Leveraging DevOps in a water-SCRUM-fall world
- Monetate’s 12-step program for Continuous Delivery
- The State of DevOps (by PuppetLabs)
- DevOps for Mobile Apps – Slides from IBM Pulse 2013
- Chef for DevOps – An Introduction