Puppet + Diaxon: Getting to the next stage of DevOps evolution
Download as PPTX, PDF0 likes635 views
The document presents insights on successfully starting, scaling, and evolving DevOps practices, derived from the 2018 State of DevOps Survey involving over 3,000 respondents. Key findings emphasize the importance of cross-team collaboration, automation, and starting with practices nearest to production for effective DevOps transformation across five evolutionary stages. It also highlights common approaches to implementing DevOps and the significance of understanding business requirements and architecture in shaping the journey towards success.
Puppet + Diaxon: Getting to the next stage of DevOps evolution
- 1. How to start, scale and succeed Presented by Nigel Kersten, Michael Stahnke and Peter Bestel
- 2. About the authors Alanna Brown @alannapb Nigel Kersten @nigelkersten Michael Stahnke @stahnma Andi Mann @andimann
- 3. Today’s speakers Nigel Kersten Puppet @nigelkersten Michael Stahnke Puppet @stahnma Peter Bestel Diaxion linkedin.com/in/peterbestel/
- 5. 2018 State of DevOps Survey ● 3,000+ respondents ● Better global representation ● Translated in French, German, Japanese and Malay 5 Survey responses by region Over the past 7 years, we’ve gathered 30,000+ responses from around the world, making the State of DevOps Report the largest and most comprehensive study on the topic of DevOps.
- 7. We want to hear from you! ● How did you expand DevOps success beyond a single team? What worked and what didn’t? ● How do you collaborate with ITSM and ITIL in this new DevOps world? ● What’s hard with about automating incident response in your organization? ● How did you get executive buy-in? If you’re an executive, what do you need to know to support your team as they adopt DevOps practices? ● How do you make sure your organization is doing monitoring and alerting the right way?
- 8. Key findings 8 ● In a DevOps evolution, there are many paths to success, but even more that lead to failure. ● Executives have a rosier view of their DevOps progress than the teams they manage. ● Start with the practices that are closest to production; then address processes that happen earlier in the software delivery cycle. ● Cross-team sharing is the key to scaling DevOps success. ● Automating security policy configurations is mission-critical to reaching the highest levels of DevOps evolution.
- 9. In a DevOps evolution, there are many paths to success, but even more that lead to failure. 9
- 10. 5 Stages of DevOps Evolution
- 11. 5 Stages of DevOps Evolution 11 Stage 1: Normalization Application development teams use version control Teams deploy on a standard set of operating systems Stage 2: Standardization Teams deploy on a single standard operating system Build on a standard set of technology Stage 3: Expansion Individuals can do work without manual approval outside team Deployment patterns for building apps/services are reused * Infrastructure changes are tested before deploying to production Stage 4: Automated Infrastructure Delivery System configurations are automated Provisioning is automated * System configs are in version control * Infrastructure teams use version control * Application configs are in version control * Security policy configs are automated Stage 5: Self-service Incident responses are automated Resources available via self-service * Applications are rearchitected based on business needs * Security teams are involved in technology design and deployment Stage 0 Monitoring and alerting are configurable by the team operating the service Reuse deployment patterns for building applications or services Reuse testing patterns for building applications or services Teams contribute improvements to tooling provided by other teams Configurations are managed by a configuration management tool * These practices are highly correlated with the stage.
- 12. Stage 0: Build the Foundation 12 • Monitoring and alerting are configurable by the team operating the service • Reuse deployment patterns for building applications or services • Reuse testing patterns for building applications or services • Teams contribute improvements to tooling provided by other teams • Configurations are managed by a configuration management tool
- 13. Stage 0: Monitoring and alerting are configurable by team operating the service 24xmore likely to always enable configuration of monitoring and alerting
- 14. Stage 0: Reuse deployment patterns for building applications or services 23xmore likely to always reuse deployment patterns for building applications or services
- 15. Stage 0: Reuse testing patterns for building applications or services 44xmore likely to always reuse testing patterns for building applications or services
- 16. Stage 0: Configurations managed by configuration management tool 27xmore likely to always manage configurations using a configuration management tool
- 17. Stage 0: Contribute to other teams’ tooling 44xmore likely to always contribute to other teams’ tooling
- 18. Stage 1: Normalize the Technology Stack 18 Stage Defining Practices Contributors to Success ● Application development teams use version control ● Deploy on a standard set of operating systems ● Build on a standard set of technologies ● Put application configurations in version control ● Test infrastructure changes before deploying to production ● Source code is available to other teams 1
- 19. Stage 2: Standardize and Reduce Variability 19 Stage Defining Practices Contributors to Success ● Deploy on a single standard operating system ● Build on a standard set of technologies. ● Reuse deployment patterns for building applications and services ● Re-architect applications based on business needs ● Put system configurations in version control 2
- 20. Stage 3: Expand DevOps Practices 20 Stage Defining Practices Contributors to Success ● Individuals can do work without manual approval outside team ● Reuse deployment patterns for building applications and services ● Infrastructure changes are tested before deploying to production* ● Individuals accomplish changes without significant wait times ● Post-incident reviews occur and results are shared ● Build on a standard set of technologies ● Teams use continuous integration ● Infrastructure teams use version control ● Service changes can be made during business hours 3
- 21. Stage 4: Automate Infrastructure Delivery 21 Stage Defining Practices Contributors to Success ● Automate system configurations ● Automate provisioning ● Application configurations are in version control* ● Automate security policy configurations ● Resources made available via self service 4
- 22. Stage 5: Provide Self-Service Capabilities 22 Stage Defining Practices Contributors to Success ● Incident responses are automated ● Resources available via self- service ● Re-architect applications based on business needs* ● Security teams are involved in technology design and deployment* ● Security policy configurations are automated ● Application developers deploy testing environments on their own ● Success metrics for projects are visible ● Experiences and lessons are shared externally ● Provisioning is automated 5
- 24. Cross-team sharing is the key to scaling DevOps success. 24
- 25. Sharing and DevOps evolution
- 26. Executives have a rosier view of DevOps progress than the teams below them. 26
- 28. Start with the practices that are closest to production, then address processes that happen earlier in the software delivery cycle. 28
- 29. Automating security policy configurations is a critical practice at the highest levels of DevOps evolution. 29
- 30. DevOps Ingredients DevOps enablement involves: We all need to be on the same journey for it to work, we need to constantly question the “why do we do it that way” and consider “how can it be done” to enable the realisation of the business outcome to realise the business benefit that we anchor the program around. DevOps Transformation People ProcessTechnology
- 31. What are the common approaches to DevOps • DevOps seems to be implemented in one of three ways. Each can be successful but this does depend on the organisation maturity and leadership across a number of aspects • However one approach is seen as the most successful The directive – we now do DevOps Everyone does DevOps Incremental DevOps* • Top down directive • Large project • Large change • Agilifall • High failure rate • Takes a long time • Cost upfront • Mandate to do leads to free for all • Everyone does it differently • Multiple approaches • Not optimised for the whole • Multiple tools • Expensive in the long term • Lack of experience and total capability • Start small • Just in time & incremental tools • Choose for success • Bring one dev & selected ops team together • Most successful • Can be frustrating for others not involved • Success breeds success Diaxion’s Approach
- 32. Customer to Customer delivery – process map – DevOps needs to consider Requirements & Architecture Business requirements Operations requirements Architecture requirements Security requirements Process architecture System architecture & design Security Build & procurement Software development Infrastructure provisioned & configure Database & packages build Process build – business and technology Environment definition Security validation Integration and acceptance Functional integration Process integration Operations integration Functional QA User QA Security scanning Production delivery Operations validation Change delivery Deployment Application support Business support Infrastructure support Customer acceptance Release Customer Request Who is the customer that represents business value creation Customer enabled Able to deliver to the business Approvedproject Deliveredvalue It is important to process map the business outcome from the real customers perspective
- 33. Diaxion – Our Approach to Incremental DevOps Roadmap Identify, automation, integration and tool chain requirements Optimise the process maps Process map to the user stories Identify user stories for the business outcomes Identify business outcomes & “what’s in it for me” for each group aligned to business outcome
- 34. • DevOps Target State / Target state Operating model • Process mapping and optimisation • DevOps Kickstart • DevOps Health Check • DevOps professional services / development • DevOps mentoring Sydney Office Ph: +61 (0)2 9043 9200 Melbourne Office Ph: +61 (0)3 9036 8900 Sales information – sales@diaxion.com Diaxion DevOps Services
- 35. Questions 35