One of the biggest challenges to implementing DevOps is the proper organization of people to solve complex technical problems. I saw this when I worked at GitHub and talked to executives about moving to Git over SVN or implementing a collaboration platform to share code transparently across an organization. They all made the assumption that implementing a product or platform would be a forcing function to implement the culture changes necessary to implement Agile, DevOps, CI or CD. Unfortunately, this assumption led to a fragmentation in responsibilities because teams were not aligned in their outcomes and the technical capabilities required to bring about the change necessary to deliver applications consistently.
As we talk to customers, CD means different things to different people. The first discussion we have is comparing CI and CD. CI, or continuous integration, is the automation of packaging an application to prepare it for deployment. The output of a CI task was to create an artifact. CD, or continuous deployment, is the automation of taking that artifact and publishing it to a specific environment. CD, or continuous delivery, is the automation promoting an application between environments and wrapping the promotion process with decision support. There is a new term emerging in the market called Progressive Delivery that describes the ability to automate the infrastructure resources and application delivery as a single unit of work to reduce or eliminate the need for manual promotions through change review boards.
The discussion about which C they are talking about depends on their role and responsibilities.
AppDevs/QA - C stands for Continuous - AppDevs want the ability to deploy frequently. They are measured by the delivery of new functionality and the quality of that change as measured by a separate QA team. These teams expect to deliver changes into a DEV/QA environment 10s to 100s of times a day. This requires the most automation as the environments are normally ephemeral from database to application.
SREs - C stands for Consistent - SREs want the ability to build templates based on application type and deployment targets so they can build reusable modules in their tools. They are measured by the ability to seamlessly deliver applications to production with little or no manual intervention while maintaining service level indicators (SLI), service level objectives (SLO), and service level agreements (SLA). This requires deeper integration of third party products into the automation platform to generate data about policies, performance, and error rates to establish decision support criteria that can be represented in dashboards.
Operations - C stands for Control - Operations teams focused on providing infrastructure platforms that are the basis for SREs, AppDevs, and QA teams to consume. They want the ability to control the number of infrastructure targets that the above teams can consume while maintaining enough flexibility to allow teams to innovate. These teams are measured, unfortunately, on cost. This requires a platform that can support a mechanism of show-back/charge-back to teams to understand the actual cost to performance of pushing poor code into production as well as the cost to provide the flexibility for teams to have non-production environments that are not treated as ephemeral targets.
Security - C stands for Compliance - Security teams are focused on providing security standards to different teams. They take the infrastructure targets and application artifacts defined by the above teams and wrap them in security standards to allow the company to protect themselves from cyber attacks. This requires a platform that can look both proactively and reactively at best practices, traffic patterns and attack vectors with automation to roll back applications when they see anomalies. The platform should also support the ability to expose policy violations earlier in the development process to keep applications from being promoted that already violate security and compliance requirements.
Executives - C stands for Confidence - Executives are focused on allocating budget and resources to implement the right platform(s) for the company to maintain revenue targets, deliver innovative products and services as well as building confidence that the company can deliver on roadmap targets to be competitive. Most executives have relinquished the decision making process around what platform(s) are necessary to the people closer to maintaining compliance, control, and consistency to the continuous delivery of applications to the market. Ultimately, these platforms will provide an increase in revenue while maintaining or shrinking the costs necessary to deliver these applications at scale.
In conclusion, the most effective way to implement a DevOps culture is not by just implementing the right platform(s), but ensuring the platform generates the right data based on your role in the organization that can be used to automate decision making processes. This will reduce manual review processes and allow the flexibility to undo releases that put the company in a compromising position.
Top comments (0)