In the age of digital transformation, organizations are striving to transform their infrastructure in order to improve their software delivery performance so that they can bring new products and ideas to market faster than ever before. Organizations are achieving these goals by embracing DevOps - but what exactly is DevOps? Let’s dive in.

The Definition

Depending on who you ask, DevOps can have many definitions and interpretations; a culture, a process, a practice, a toolset, or framework - in reality, it is all of these things. DevOps is the culture, set of technologies, and technical practices that enable Agile not only from a development perspective but also from an operations perspective. It focuses on the lead time from code commit to production release. DevOps seeks to optimize the value stream and have a continuous delivery of usable features and functionality provided to the end-user.

The Problem

Most organizations today believe they are already doing DevOps. They have automation, they have a CI/CD pipeline, they are getting faster with code deployments - but fall short when it comes to production. The result is 1 of 2 things; it either comes to (1) a screeching halt or (2) results in downtime and rollbacks.

The Great Wall

Do you wince when you hear the words "production deployment"? Does your development team know what software deployments are like? Are your deployments performed after hours? If you said "yes" to any of these, you are not alone. Deployment pain can be caused by manual changes or complex deployment processes, but often is the result of multiple handoffs between teams or silos. When DevOps was originally coined, the intent was to breakdown these silos and remove the proverbial ‘brick wall’ that stands between Development and Operations to create a culture that fosters trust, communication, and collaboration.

The Culture

Culture is the foundation for DevOps

Changing an organization's culture can be one of the most difficult challenges leadership faces, but in order to implement DevOps correctly, there’s nothing more important.

Building a foundation of trust, communication, and collaboration is needed to support the pillars of DevOps, namely: Flow, Feedback, and Continuous Learning.

From a business perspective:

Innovation → Digital Transformation → Cultural Transformation → DevOps → Continuous Learning

This cycle is a continuously repeating process. To achieve Innovation you need first to think about the Cultural Transformation that will enable DevOps and continuous learning. Then from there, see how you can change the steps in your process. The world is changing, technology and your business are changing, and you can always learn from the mistakes made during this journey.

"DevOps is the result of a healthy culture!"

A great example of an organization that does this well is Netflix. If you ask the folks at Netflix how they are doing DevOps, they will tell you that they are not doing DevOps. Rather, "DevOps is the result of a healthy culture!".

Their guiding principles are as follows:

  • Don't focus on uptime at all costs. Instead, focus on the velocity of innovation.
  • Don't focus on process and procedures. Instead, focus on trust in people and enablement.
  • Don't build systems that say no to developers and engineers. There is no such thing as "production access denied".

While this is easier said than done, especially in the financial and healthcare sectors, doing so with the correct monitoring, logging, and auditing procedures in place will give your teams freedom, responsibility, and ownership in the systems they build.

The Pillars

How can you implement and learn with your DevOps process?  While there are dozens of techniques and hundreds of tools for that, we're only going to talk about a few of them since it's impossible to cover them all in one post. With a solid cultural foundation in place, next focus on the pillars of Flow (to accelerate the delivery of work from business to the customer), Feedback (to create ever safer systems of work), and Continuous Learning (which fosters a high trust culture and enables experimentation of new ideas). Let’s dive a bit deeper into these principles:

Principles of Flow

One of the main things that you think of when someone talks about DevOps is Automation. This is something so important in the DevOps world that it's almost impossible to see a DevOps process without it. It's through automation that you get faster, and become more agile. The more you automate the faster you'll be. You should automate as much as you can like the CI/CD pipelines, tests, and security. You should also implement your Infrastructure as Code and strive to eliminate any manual ad-hoc tasks.

Any automation done well should enable fast flow from left to right by providing output to make work visible, breakdown tasks into batch sizes, and build in quality by preventing defects from being passed downstream. The goal is to decrease the amount of time required for changes to be deployed in production and to increase the reliability and quality of those services.

One of the Pitfalls in longer lead times is the large number of handoffs which we often see in a value stream. We must strive to reduce the number of handoffs by automating significant portions of work or by reorganizing and enabling teams such that they can deliver value to the customers themselves. Reducing lead times and increasing throughput is not a one-time effort but continual in identifying constraints within the system and optimizing it.

Principles of Feedback

Another important part of the DevOps process is Feedback. To build a high-quality product that meets customer needs, it is crucial to have a fast constant flow of feedback at all stages in the value stream. By seeing the problems as they occur and swarming them until effective countermeasures are in place, feedback loops are shortened and amplified.

Look at:

  • Aggregated logging, Monitoring, Alerting, Automated Recovery
  • Enabling fast feedback
  • Failing fast
  • Embracing failure
  • Monitoring
  • Centralized Logging - ELK, StackDriver, CloudWatch, Splunk, SumoLogic
  • Resource Monitoring - Zabbix, Nagios, Prometheus, DataDog
  • Application Monitoring - NewRelic, AppDynamics
  • Alerting - Email, Slack, PagerDuty, VictorOps

Another common Pitfall is to simply detect an issue when it happens, and then manually correct it. However, more is needed. The solution should be automated and a process should be put in place to ensure that the problem does not re-occur and prevent it from rippling downstream. Additionally, the issue should be communicated with all teams so that everyone understands and is aware of the problem.

"It is impossible for a developer to learn anything when someone yells at them for something they broke six months ago - that is why we need to provide feedback to everyone as quickly as possible, in minutes, not months." - Gary Gruver

Principles of Continuous Learning

The third pillar is that of Continuous Learning. This pillar seeks to enable the creation of a generative high trust culture that supports a dynamic, disciplined and scientific approach to experimentation and risk-taking. A Generative organization is characterized by actively seeking and sharing information to better enable the organization in achieving its mission; enabling fast, reliable continuous delivery of secure, high-quality software!

Experiment and learn from:

  • Blue/Green and Canary deployments, A/B testing
  • Error reduction, reducing toil
  • Service quality improvement

Remember that responsibilities are shared and whether you experience success or failure, learn from it! Reserve time to pay down technical debt, fix defects, refactor and improve problematic areas in code and infrastructure.

Sharing

Lastly, to encapsulate all of this, create a process in which new learnings that are discovered locally, can be shared with the rest of the organization. Convert tacit knowledge into explicit, codified knowledge so that it can become someone else’s expertise through practice.

Share:

  • Share both successes and failures between teams
  • Have cross-functional teams that can share knowledge across domains
  • Create cookbooks/templates, self-service platforms, deployment patterns

How to Get Started

It's never too late to start implementing DevOps best practices. A common misconception is that DevOps is suited for greenfield projects, however, it can be successfully implemented in brownfield projects as well.

Similar to following an Agile process, look to expand your DevOps operations across the organization in small incremental steps. Some ways to expand the support for DevOps include:

  • Find innovators and early adopters. Identify those who are respected and have a high degree of influence and can give credibility to the initiative.
  • Build critical mass. Work with teams who are receptive to new ideas and expand the coalition, generating more successes.
  • Identify the blockers. These are the high profile influential detractors who are likely to resist this effort. Tackle them after having made substantial gains in the organization.

What’s the best fit?

The best way to get started with DevOps depends on the size and maturity of your organization. If you are a small company that intends to grow fast you should definitely consider DevOps from the beginning. Alternatively, if you are a large company and you face the daunting problem of changing your company's already established culture, you could try to follow Google's strategy:

  • Start with small projects - a few small wins will prove to the rest of the organization that DevOps works
  • Apply DevOps best practices
  • Provide immersive training
  • Establish a no-blame culture
  • Build a culture that supports DevOps

Definitely consider DevOps if you have faced or are facing any of the following situations:

  • Low deployment frequency
  • Long lead times (codecommit to deployment)
  • High failure rates (build/deploys/bugs)
  • Quality/Security/Performance/Availability issues
  • Lots of manual tasks/operations
  • Lack of insight/monitoring/continuous feedback
  • Slow recovery rate/response/notification from various teams

The Evolution

Being innovative is not only about investing in sophisticated technologies, it’s about using technology as a path to deliver the solution that fits best with your organization's strategy, taking into account time, budget, and resource constraints. It's about being smart when using technology. A product or service is innovative if it stands out from the rest and makes your customer’s life easier. But how can you be innovative if everyone is already doing DevOps? As with any other technology, DevOps is evolving and there are new trends to consider. Tweaking and adapting your DevOps practice to best suit the needs of your company and culture as well as your clients will keep you ahead of the curve.

What differentiates a business from a high performing one is the ability to adapt to the constantly changing technological landscape. DevOps is no longer just development + operations, it's DevSecOps, MLOps, DataOps, DesignOps, IoTOps. It's XOps, the fusion of DevOps into other technological practices to improve the performance of software delivery in all verticals and so much more.

"DevOps is no longer a revolution; it's an evolution!"

Stay up to date on the latest in digital transformation and innovation by subscribing to our newsletter, here.