Agenda insert will go here Contents Introduction 3 5 Stages of DevOps Evolution 5 Stage 1: Normalizing 7 Stage 2: Standardizing 13 Stage 3: Expanding DevOps practices 19 Stage 4: A utomate infrastructure delivery 25 Stage 5: Provide self‑service capabilities 31 5 Foundational DevOps Practices 37
Introduction We’ve seen rapid adoption of DevOps practices over the past few years. If you’re like most of the organizations we work with, you have pockets of success — a team that’s successfully automating infrastructure delivery, and maybe a team or two that has automated the end-to-end deployment of a service. It’s time for the next step — You want to replicate that success across more teams, but you’re not sure how. This is the year to scale your success, no matter where you are in your DevOps journey. In this workshop, we’ll cover our findings from the 2018 State of DevOps Report, including the five stages of DevOps evolution and the key practices in each stage that help you get to the next stage. We’ll also look at the five foundational practices that have a big impact on the entire evolutionary journey and evolve with you. This workshop includes demos of specific use cases that help you get started with automation and scale your infrastructure delivery. 3
01 Normalize the technology stack 02 Standardize and reduce variability 03 04 Expand Automate DevOps infrastructure practices delivery 05 Provide self-service capabilities 4
5 Stages of DevOps Evolution The DevOps evolutionary journey is comprised of five key stages. It’s important to remember that these stages are not linear. Most of the organizations we surveyed employed a smattering of practices across all stages. However, a successful DevOps initiative isn’t defined by the quantity of practices being employed within an organization; it’s about how well those practices are coordinated across multiple teams in alignment with business needs. 5
6
Stage 1: Normalizing This stage is a period of normalization during which organizations focus on reducing complexity throughout the stack. Stage 1 is an important precursor to the next stage which focuses on making deliberate business choices about the technologies that they plan to use in the future. 7
Stage 1: Normalizing Defining practices • Application development teams use version control. • Teams deploy on a standard set of operating systems. Practices that contribute to success • 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. 8
Questions to ask • Which version control systems are being used? Can one version control system meet the needs of most of your teams? • How many operating system versions exist? Which versions are one-offs? Which versions can be consolidated? • How many types of similar technologies are being used (databases, message queues, etc.)? Which technologies can be consolidated to meet 80% of your needs? • How do you assess new technologies before adding them to the production lifecycle? Do you have clear guidelines for introducing new technologies (i.e., production vs. product incubations)? • Are application configurations in version control? • Are you testing infrastructure changes before deploying to production? • Is source code made available to other teams? 9
NOTES 10
NOTES 11
NOTES 12
NOTES 13
14
Stage 2: Standardizing This is a continuation of Stage 1 where organizations start to “place bets” on the technologies they’ll use in the future. This stage is critical to ensuring the success of future stages because it enables teams to optimize for the “80 percent cases”, make a real dent in technical debt and lay the foundation for scaling DevOps practices more broadly. 15
Stage 2: Standardizing Defining practices • Build on a standard set of technologies. • Teams deploy on a single standard operating system. Practices that contribute to success • Deployment patterns for building applications and services are reused. • Rearchitect applications based on business needs. • Put system configurations in version control. 16
Questions to ask • Can you further reduce the number of operating system versions in use? Can you reduce variability of compute resources running on the same OS, i.e., do you have the same set of patches, update levels, BIOS/firmware, etc.? • Which database systems, message queues, logging aggregation utilities, monitoring tools, key value stores, etc. can be consolidated? • Which teams have solid deployment patterns? Are those patterns being reused? • Are system configurations in version control? If you’re not using a configuration management system, can you start by putting your scripts in version control? • Based on your standardization efforts, do you need to rearchitect applications to meet your new standards? 17
NOTES 18
NOTES 19
NOTES 20
NOTES 21
22
Stage 3: Expanding DevOps practices Stage 3 is when DevOps practices spread beyond the Dev and Ops teams. At this point, there’s enough trust built up amongst teams for bureaucratic red tape to be reassessed. This is often a make or break stage in the DevOps evolutionary journey because until the core practices in this stage are established, it’s difficult to get a handle on the fun work that comes next. 23
Stage 3: Expanding DevOps Practices Defining practices • Individuals can do work without manual approval from outside the team. • Deployment patterns for building applications and services are reused. • Infrastructure changes are tested before deploying to production. Practices that contribute to success • Individuals can make changes without significant wait times. • Service changes can be made during business hours. • Post-incident reviews occur and results are shared. • Teams build on a standard set of technologies. • Teams use continuous integration. • Infrastructure teams use version control. 24
Questions to ask • Which processes require manual approval and why? How can you establish a track record of success to build trust and remove bureaucratic red tape? • Which teams are successfully deploying and can their deployment patterns be reused? • Do you have everything you need to produce a build under version control, including application code, infrastructure code, deployment scripts, test scripts, VM templates, third party libraries, database schemas, etc.? • How are you testing infrastructure changes before deploying to production? • Why do certain wait times exist and are they still necessary? • Which services changes are being made outside business hours and why? • How often do you hold post-incident reviews, who participates, and who is informed? 25
NOTES 26
NOTES 27
NOTES 28
NOTES 29
30
Stage 4: Automate infrastructure delivery Although the practices in Stage 4 are what we typically think of as the beginning of a DevOps initiative, success in this stage is predicated on the hard work done in the previous three stages. This is where infrastructure teams begin automating for their own purposes and to bring greater agility and value to the entire business. 31
Stage 4: Automate infrastructure delivery Defining practices • System configurations are automated. • Provisioning is automated. • Application configurations are in version control. • Infrastructure teams use version control. Practices that contribute to success • Security policy configurations are automated. • Resources made available via self-service. 32
Questions to ask • Have you automated the setup of local development environments so that they’re consistent with your testing and production environments? • Have you created a method for organizing and classifying your servers by technical or business function (servers for apps, databases, ERP, etc.). Include details about the different configurations of services (e.g., App A and App B may require different Tomcat versions and configurations). • Have you defined phases for your infrastructure as code roll out (e.g., baseline OS configurations; critical services: NTP, SSH, DNS, Sudo, Firewall, Task Scheduler; middleware configurations: web, app, and database servers; security and compliance policies)? • Which pieces of your infrastructure deployments will be automated (provisioning new hosts with base OS, standard operating environment, application‑specific requirements, entire application, etc.)? • Have you established an internal process for other teams that need to interact with infrastructure code (ideally, everyone should have access to the codebase, and a few knowledgeable people should have rights to merge change)? 33
NOTES 34
NOTES 35
NOTES 36
NOTES 37
38
Stage 5: Provide self‑service capabilities With trust amongst teams and automated infrastructure delivery well established, organizations can build upon that foundation to improve responsiveness to internal customers by providing self‑service capabilities. 39
Stage 5: Provide self‑service capabilities Defining practices • Incident responses are automated. • Resources available via self-service. • Rearchitect applications based on business needs. • Security teams are involved in technology design and deployment. Practices that contribute to success • Security policy configurations are automated. • Applications developer deploy testing environments on their own. • Success metrics for projects are visible. • Provisioning is automated. 40
Questions to ask • How long does it take to detect, identify and remediate a critical incident? Which pieces of the remediation process are being done manually? Are there manual handoffs that slow incident response? • Are teams building self-service systems for themselves or for other teams? • Which applications are in need of re-architecting? • Are security teams involved early in the software development process (conducting security review for all major feature, providing input during software demos, etc., testing security requirements, creating consumable artifacts for dev and ops teams, etc.)? • Is there a standard way for app developers to deploy testing environments on their own? • Are security policy configurations automated? • Are there automated mechanisms to share metrics broadly? 41
NOTES 42
NOTES 43
NOTES 44
NOTES 45
Monitoring and alerting are configurable by the team operating the service Deployment patterns for building applications or services are reused Testing patterns for building applications or services are reused Teams contribute improvements to tooling provided by other teams Configurations are managed by a configuration management tool 46
5 Foundational DevOps Practices Analysis of the data from the 2018 State of DevOps survey revealed the foundational practices that successful teams employ. These practices correlate so strongly with DevOps success, we’ve determined they are essential at every stage of DevOps development. In other words, the practices that must be adopted at any given stage in order to progress to the next stage remain important even for those organizations that have evolved the furthest on their DevOps journey, and that have already showed the most success. Each foundational practice can be described in a sentence: • Monitoring and alerting are configurable by the team operating the service. • Deployment patterns for building applications or services are reused. • Testing patterns for building applications or services are reused. • Teams contribute improvements to tooling provided by other teams. • Configurations are managed by a configuration management tool. 47
When we examined each of these practices more closely, we found that highly evolved organizations were much more likely to always be using these practices throughout the evolutionary journey than the less-evolved organizations (see The evolutionary scale). What we take from our findings is that the foundational practices listed above are integral to DevOps, and critical for DevOps success. Monitoring and alerting are configurable by the team operating the service. Monitoring and alerting are key to sharing information about how systems and applications are running, and getting everyone to a common understanding that is vital for making improvements, whether within a single team and function or across multiple teams and functions. Deployment patterns and testing patterns for building applications or services are reused. Sharing successful patterns across different applications or services often means sharing across different teams, establishing agreed-upon ways of working that provide a foundation for further improvements. 48
Teams contribute improvements to tooling provided by other teams. This form of sharing promotes more discussion between teams around priorities and plans for further improvements in tooling, process and measurement. Configurations are managed by a configuration management tool. A configuration management tool enables development, security and other teams outside Ops to contribute changes to system and application configurations. This makes operability and security a shared responsibility across the business. 49
NOTES 50
Search
