Developer Exchange Blog
DevOps and the Cloud Operating Model
Notes and key takeaways from the Gartner session on cloud operating models.
Assertion: Enterprise IT is crumbling under the weight of its "debt" due to complexity.
"All problems of computer science can be solved by another layer of indirection... except for the problem of too many layers of indirection." --David Wheeler
What does DevOps mean? "Occupy IT" it's about changing the way services are delivered.
Complex Information Technology + Bureaucratic Operations Processes = IT Debt
One way to calculate IT Debt is: Actual cost of change minus the Optimal cost of change.
62% of the functionality being paid for in IT is NEVER or RARELY used.
The cost of IT service delivery goes down along this chain:
- Traditional Enterprises
- The Virtual Enterprise (virtualization, etc.)
- Enterprise/On-premises Clouds
- Public Clouds (e.g., google/amazon)
"The cloud is ultimately less important than the cloud operating model."
The following are characteristic of DevOps:
Resilient Application Architectures
- Programmable infrastructure
- Open Source
- Continuous delivery/release
- Version control
- Value streams
- Shared metrics
- Embrace Risk
- Avoid Blame
- Value Creation
- Two-pizza teams
Boiling the concept of DevOps down, it's:
- Improving collaboration and communication between development and operations teams.
- An adoption of methodologies (and some technologies) used in software development by operations teams.
- A renaissance of infrastructure technologies.
DevOps objectives: It's about driving business value.
- Deliver measurable business value through continuous and high-quality service delivery
- Emphasize simplicity and agility in all areas, including technology, process and human factors.
- Break down barriers between dev and ops by enabling trust and shared ownership, supporting innovation.
- Continuously re-optimize in response to changing business, technology and operational requirements
- Enable the reconstruction of the business from essentially nothing but a source code repository, an application data backup and bare metal resources
- Develop shared metrics -> focus organization on the end goal
- Done means released -> code deploy not code complete
- Separate code from configuration -> Configuration is code and needs controls
- Use test as brakes to go faster -> testing improves throughput
- If it's hard, do it more often ->practice makes perficient
Example, Chaos Monkey at Netflix randomly turns off pieces of their infrastructure IN PRODUCTION. This causes/caused their ops team to get VERY good at service restoration because they have to be on their toes all the time - quickly diagnosing the failure and restoring service.
There is no "manual" for DevOps. DevOps borrows "just enough" best practices from multiple places: Agile, Kanban, Lean IT, OODA (observe-orient-decide-act), ITIL. It's not a pure adoption of any of these, more like taking the most helpful aspects from each as a blend.
DevOps Practice "Heat Map"
Strategize and plan
- Establish technical debt
Architect Solution: Decompose, make simple
Build and Deploy
- Educate operations on the code
- Employ test-driven development
- Automate the build/rel process
- Implement one-step build/deploy
- Deploy the same way to EVERY ENVIRONMENT
- Always ship the code trunk
- Implement code feature and configuration flags (ability to turn features off)
- Develop post-commit hooks for notification
- Subject mgmt. code to same discipline as functional code
- Logging needs to be interpretable and actionable
Operate and Evolve
- Share road maps and upgrade plans
- Employ test-driven deployment
- Automation is code and needs SDLC management
- Treat processes like apps and build error handling into them
- Boot instances from bare minimum packages
- Object role and behavior are no longer fixed
- Reuse management tooling from the dev/test environment
Dev Ops Organization
From the Agile Manifesto: Individuals and interactions over tools and processes.
- Smaller is better (Amazon two-pizza rule... team should be small enough that two-pizzas can feed the team)
- Self organizing is better
- Pairing activities is better
- Face-to-face is better
- Empowered is better
DevOps impact: Ending the Enterprise Process Framework "Cargo Cult"
- Just enough, not best practice
- Fit the process to the reality, not vice versa
- Create an ownership, not employee, society
- Results not CYA-oriented
- Tasks are selected, not assigned
- Bottom-up not top-down-driven
- Practitioner not consultant-derived
- Reward creativity, not conformance
- Emphasize contributions, not credentials
DevOps Impact: Solving the paradox of being both Agile and in Control.
By 2015 DevOps will evolve from a niche strategy employed by large cloud providers into a mainstream strategy employed by 20% of Global 2000 organizations.
As a side note, Doozer's internal processes have been very much dev-ops like for years and years. This comes from our Java application development and deployment models and philosophical approach to making build-release really simple, non-disruptive and easy to roll-out and roll-back.