devops patterns at the rational user group uk
TRANSCRIPT
© 2015 IBM Corporation
IBM Presentation Template
Daniel Breston Chief of DevOps Ranger4
25 Nov 2015
Document number
© 2015 IBM Corporation
© 2015 IBM Corporation
© 2015 IBM Corporation
‘“Organisations, and large enterprises in particular, want to attract and retain good talent but if they’re viewed as fuddy-duddy, they won’t appeal to or keep the cool kids. And there’s real demand for this kind of expertise.”
Jay LymanResearch Manager at 451 Research
But that’s not to say that everything will be rosy in the garden when adopting a DevOps approach. The key challenge, for many, is change management and simply getting staff to buy into the concept, mainly on the operations side as this is predominantly a grassroots developer’s movement.’
© 2015 IBM Corporation
‘DevOps will shift from being a niche approach to application development and deployment and move into the mainstream over the next 12 months or so, according to Gartner.
In fact, so appealing will this grassroots philosophy prove to be that it will be taken up by a quarter of Global 2000 organisations, creating a software tools market forecast to leap in size by 21.1% from $1.9bn last year to $2.3bn in 2015, the market researcher believes.’
Cath EverettComputerWeekly.com
© 2015 IBM Corporation
The Things that Drive DevOpsI’m all about
change
I’m in charge of stability
Development Operations
CONFLICT
© 2015 IBM Corporation
Don’t fight stupid -Make more awesome
(Jesse’s rule)
© 2015 IBM Corporation
People
Process
Tools
© 2015 IBM Corporation
Organisations
Interactions
Automation
© 2015 IBM Corporation
Organisations:Team Structures
© 2015 IBM Corporation
“Traditional” IT
CIOHead of Development Head of Operations
PMO/BAs Dev DBAs
The rest of the business
Test Security Release SupportInfrastructure
Silos, hand offs and a ‘wall of confusion’
© 2015 IBM Corporation
What’s DIFFERENT about DevOps?
© 2015 IBM Corporation
DevOps Starts
CIOHead of Development Head of Operations
PMO/BAs Dev DBAs
The rest of the business
Test Security Release SupportInfrastructure
DevOps often starts as grassroots thinking and can start anywhere
© 2015 IBM Corporation
DevOps Spreads
CIOHead of Development Head of Operations
PMO/BAs Dev DBAs Test Security Release SupportInfrastructure
THE BUSINESS
For DevOps to make advances, executive sponsorship and increasing engagementwith the rest of the business needs to happen
© 2015 IBM Corporation
Organisational Change
CIOHead of Development Head of Operations
Product A Product B Product C Product D Security Release SupportInfrastructure
THE BUSINESS
Product E Product F Product G Product H
Product Owners
Arranging teams around product is a common initial step, not without its challenges.
© 2015 IBM Corporation
Organisational Change
CIOHead of Development Head of Operations
Product A Product B Product C Product D Security Release SupportInfrastructure
THE BUSINESS
Arranging teams around product is a common initial step, not without its challenges.
Product E Product F Product G Product H
Testers
© 2015 IBM Corporation
Organisational Change
CIOHead of Development Head of Operations
Product A Product B Product C Product D Security Release SupportInfrastructure
THE BUSINESS
Product E Product F Product G Product H
Developers
Arranging teams around product is a common initial step, not without its challenges.
© 2015 IBM Corporation
Organisational Change
CIOChange Run
Product A Product B Product C Product D Security Release SupportInfrastructure
THE BUSINESS
Renaming teams can support change. Some organisations build DevOps teams…
Product E Product F Product G Product H
© 2015 IBM Corporation
Organisational Change
CIOChange Run
Product A Product B Product C Product D
THE BUSINESS
Renaming teams can support change. Some organisations build DevOps teams…
Product E Product F Product G Product H
Security Release SupportInfrastructureDevOps
© 2015 IBM Corporation
Organisational Change
CIOChange Run
Product A Product B Product C Product D
THE BUSINESS
Antipattern?
Product E Product F Product G Product H
Security Release SupportInfrastructureDevOps
© 2015 IBM Corporation
Organisational Change
CIOChange Run
Product A Product B Product C Product D Security Release SupportInfrastructure
THE BUSINESS
Others embed Operations into the product development teams
Product E Product F Product G Product H
© 2015 IBM Corporation
Organisational Change
CIOChange Run
Product A Product B Product C Product D
THE BUSINESS
Others embed Operations into the product development teams
Product E Product F Product G
Security Release SupportInfrastructure
Product H
© 2015 IBM Corporation
DevOps Proliferates
CIOChange Run
Product A Product B Product C Product D
THE BUSINESS
DevOps is an evolutionary and transformational movement
Product E Product F Product G
Security Release SupportInfrastructure
Product H
© 2015 IBM Corporation
DevOps Nirvana
CIOCustomer Innovation Management
Product A Product B Product C Product D
IT IS the business. Everyone is on board with the DevOps way of thinking.
Product F Product G Product H Product I
Product E
Product J
The Board
Dashboards and automation alignment
© 2015 IBM Corporation
“If you can’t change the people, change
the people.”
© 2015 IBM Corporation
Reading Recommendation‘Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long’
by David Rock
© 2015 IBM Corporation
Interactions:Collaboration & Integration
© 2015 IBM Corporation
Value & Principles
• Focus on people• Embrace change and experimentationCulture• “Continuous Delivery”• “Infrastructure as Code”
• Focus on producing value for the end user• Small batch sizes
• Measure everything• Show the improvement
• Open information sharing• Collaboration and communication
Automation
Lean
Metrics
Sharing
© 2015 IBM Corporation
Typology of Organisational Culture (Westrum, 1994)
PathologicalPower-oriented
BureaucraticRule-oriented
GenerativePerformance-oriented
Low cooperation Modest cooperation High cooperationMessengers shot Messengers neglected Messengers trainedResponsibility shirked Narrow responsibilities Risks are sharedBridging discouraged Bridging tolerated Bridging encouragedFailure leads to scapegoating
Failure leads to justice Failure leads to inquiry
Novelty crushed Novelty leads to problems
Novelty implemented
Which column do you fit in?
© 2015 IBM Corporation
How to Create a Generative CultureCharacteristics of a Generative Culture
DevOps Practices
High cooperation Cross-functional Teams. Many organisations create cross-functional teams that include representatives from each functional area of the software delivery process. This allows everyone to share the responsibility for building, deploying and maintaining a product.
Messengers trained Blameless Postmortems. By removing blame, you remove fear, you enable teams to more effectively surface problems and solve them. Mistakes happen. Holding blameless postmortems is a valuable way to learn from mistakes.
Risks are shared Shared responsibility. Quality, availability, reliability and security are everyone’s job. One way to improve the quality of your services is to ensure that devs share responsibility for maintaining their code in production. The improvement in collaboration that comes from sharing responsibility inherently reduces risk. With more eyes on the software delivery process, it’s a given that some errors in process or planning will be avoided. Automation reduces risk and, with the right tool choice, can enable collaboration.
Bridging encouraged Breaking Down Silos. In addition to creating cross-functional teams, techniques for breaking down silos can include co-locating ops with the dev team, including ops in planning throughout the software delivery lifecycle, and implementing ChatOps*.
Failure leads to inquiry Blameless Postmortems. Our response to failure shapes the culture of an organisation. The more you focus on the conditions in which failures happen, as opposed to blaming individuals for failures, the closer you’ll get to creating a generative culture.
Novelty implemented Experimentation Time. Giving employees freedom to explore new ideas can lead to great outcomes. Some companies give engineers time each week for experimentation. Others host internal hack days or mini-conferences to share ideas and collaborate. This is how many new features and products have originated, and it shows how much value employees can generate for an organisation when they are released from habitual pathways and repetitive tasks.* Jesse Newland, “ChatOps at GitHub” March 26, 2013
© 2015 IBM Corporation
Our kind of IT
Just-in-time means that customer delight is directly transmitted to those who are making the product.
Don’t measure me on cost or traditional
IT metrics, but on the metrics of the
business.
Jim FowlerCIO, GE Capital
Taiichi OhnoTHE LEAN MAN
© 2015 IBM Corporation
DevOps Maturity
1
5
4
3
2
Optimising DevOps
Managed DevOps
Starting DevOps
Fundamental DevOps
Not started DevOps
DevOps DONE – fine tuning and tied tightly to business goals.
Automated build, cross-functional teams, product-focused, cultural change happening
Thinking about cultural change, starting to write scripts, looking at test automation
Outages, war-rooms, blame, unplanned work, delays and defects.
Happy people with integrated toolchain to pre-empt failure, automate test and deployment –
Continuous Delivery
© 2015 IBM Corporation
Practice Culture Automation Lean Measurement Sharing
Level 4: Optimising
Desired elements of the culture are identified,
ingrained and sustainable – “ the way we work here”
Continually enhancing the employee and customer
experience.
Self-service automation, self-learning using analytics
and self-remediation
Autonomous habitFull empowermentExternal learning
Measure to customer valueEffective knowledge
sharing and individual empowerment
Level 3: AdoptedCulture viewed as an asset
to be managed.Ability to adapt to changing
business needs.
Collect and analyse metrics of the automated process
and measure against business goals
Driven deploymentMajority involvement
X-process learning
Monitor using business and end-user context
Collaboration based processes are measured to
identify bottlenecks and inefficiencies
Level 2: Sustainable
Cultural traits that support business strategies have
been identified.Ability to analyse trends in culture and predict issues.
Central automated processes across the application lifecycle
Goal orientatedSelected teams
Value stream learning
Monitor resources consistently
Collaboration, shared decision making and
accountability
Level 1: In Transition
Aware of aspects in culture that may help or hinder.
Programs implemented to address specific issues.
Silo’d automation, no central infrastructure
Formal structureOnly specialistsTeam learning
Measure to project metricsManaged Communication,
some shared decision making
Level 0: Impeded
Culture developed organically
Lack of awareness as to how culture is impacting
day-to-day business. Culture misaligned to goals
No automationReactive approach
Little/no involvementAd-hoc learning
No monitoring or metrics collection
Poor, ad-hoc communication and
coordination
© 2015 IBM Corporation
Requirements Management Maturity
Level 1 Level 2 Level 3 Level 4 Level 5Written Requirements
Organized Structured Traced Integrated
Documented and shared, regular collaboration between teams, backup and restore enabled
Formatted consistently, stored and secured. Version tracked and easily accessible to those with rights
Types (e.g. functional/non-functional) are specified. Attributes and prioritization is applied. Querying and filtering is possible.
Determine and track requirements relationships, has a hierachy of requirements: user needs, features and use cases. Coverage analysis reports implemented.
Requirements management fully integrated with software development environment: used directly in design, development, change tracking, testing and PM.
© 2015 IBM Corporation
Release and Deployment Management Maturity
Level 1 Level 2 Level 3 Level 4 Level 5Manual Packaged Scripted Complex On DemandBespoke, unpractised process. Authorization and sign off incidental. Roll back via back up copy or scripts.
Some packages (e.g. MSIs) and scripts. Release authorization considered.
Multiple scripts allowing automation. Can deploy to multiple parts of route to live. Possible roll back through redeployment. Some version control.
Can deploy composite applications. Role based security available. Multiple platforms services through single interface.
Push button deployments when code is ready – continuous delivery and deployment achieved. Full auditability and compliance.
© 2015 IBM Corporation
Reading Recommendation‘Reinventing Organisations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness’
by Ken Wilber and Frederic Laloux
© 2015 IBM Corporation
Automation:Rigour and ruggedness
© 2015 IBM Corporation
Shift Left
Continuous Delivery Lean Management
Continuous integrationAutomated
testingDeployment automation
Version control
Limit WIPUse visual displays
Use monitoring tools to make
business decisions
© 2015 IBM Corporation
“The number of issues we had from production emergencies that were triggered by an ops
change essentially went to zero.
Because we were able to roll changes out in an automated fashion, and then test those changes
in the various environments, by the time code got to production, it had been through three other
environments – dev, integration, customer test – before it got to production.”
Jez MillerPuppet Labs 2015 State of DevOps Report
© 2015 IBM Corporation
Dev
route to live
Test QA Prod
© 2015 IBM Corporation
Dev
route to live
Test QA Prod
Deploy your application at any time, at high speed
© 2015 IBM Corporation
Dev
route to live
Test QA Prod
Deploy your application at any time, at high speed
!
Be pre-emptively alerted to performance issues/outages
© 2015 IBM Corporation
Dev
route to live
Test QA Prod
Deploy your application at any time, at high speed
Be pre-emptively alerted to performance issues/outages
Redeploy last known working version instantly, fix, test, redeploy
© 2015 IBM Corporation
Be DevOpstastic