Every company’s journey to adopt a DevOps culture is different. What works for one company might not work for another company, especially because DevOps is not opinionated. There are many different definitions of what DevOps is and what it’s not—not to mention that you can find derivative terms such as DevSecOps or BizDevOps. Having a lot of options doesn’t do any good for someone who wants to start transforming a company by adopting a DevOps culture.
Even technologically, every so often we see that a new framework, tool, or paradigm comes out. If you take a look at the CNCF landscape, you get overwhelmed by the number of tools you have available. Having an opinionated software helps to alleviate the burden and reduce the cognitive load of where to start. In today’s post, I’ll discuss the importance of opinionated software and how it could drive a successful DevOps transformation. Also, I include a few recommended practices you can implement no matter where you are in your DevOps journey.
What Is Opinionated Software and Why Is It Important?
To start, let me use the definition of opinionated software from Stuart Eccles, CTO at Made by Many:
Opinionated software is a software product that believes a certain way of approaching a business process is inherently better and provides software crafted around that approach.
In his article, Eccles said that in the past, the norm was to create software designed to automate human manual labor. However, he said companies are now “using opinion as a competitive advantage.” What if we use the same approach for adopting a DevOps culture? As I said before, for newcomers, the vast variety of options available for tools, practices, and processes that the DevOps movement has influenced can be overwhelming.
An excellent example of why opinions are important is site reliability engineering (SRE). SRE is an “opinionated concrete implementation of DevOps principles,” according to Dave Rensin. For instance, DevOps began with the intention of removing silos between developers and operations. However, SRE goes one step further by providing developers and operations with the same set of tools. In other words, opinionated software is driving the adoption of better practices across the whole company.
So, let me share a few practices to achieve a successful DevOps transformation for which opinionated software is vital.
1. Analyze Your Current Path to Production
One of the first things you need to do in your DevOps journey is to determine where your biggest bottleneck is.
As the theory of constraints dictates, once you’ve found the bottleneck, you systematically improve that constraint until it’s no longer a limiting factor. But you need to identify the limiting factor first! If you’re not in a leadership position, you can apply the same principle in your daily work. Get together with your teammates and find a way to make your path to production smoother.
A widespread practice among DevOps proponents is to start drawing a value stream map (VSM). A VSM is simply a map of all the steps involved (i.e., the pipeline) to deliver an idea to the production environment. These ideas could be a bug, a new feature, or an improvement to the software that a customer is using. To have a full perspective of the pipeline, you need to gather (ideally in the same room) everyone who is involved in the process of shipping an idea to the customer’s hands. You don’t need the whole company in one place. You only need representatives of different departments, like people from development, operations, and product. Everyone’s opinion matters, and that’s what makes the process better.
An outcome of this practice should be the skeleton of a continuous delivery pipeline. You don’t need to fix all bottlenecks at the beginning. One of the core principles of DevOps is to have a continuous improvement mindset. So, once you’ve found a constraint, you exploit it, and then you find the next one and repeat the process.
2. Implement Continuous Delivery Practices
Once you’ve found which constraint you want to exploit, it’s time to get technical. For instance, is it common that in a deployment to production, an old bug comes back? Perhaps not the whole team knew about a recent manual configuration change in the servers. A recommended practice to reduce these types of problems is to use version control systems such as Git to manage your infrastructure with manifest files—also known as infrastructure as code. Once you have the desired state in Git, these manifests become the only source of truth. The end goal should be to promote changes to production, even emergency fixes, and automatically push that change through a continuous delivery pipeline.
When I talk about a continuous delivery pipeline, I mean to have the machinery to be ready all the time to ship software, even if it’s incomplete. I know it sounds weird, but this is key if you want to decouple a deployment with a release. Moreover, being always ready makes it easier to push an emergency change through the pipeline without having to do it manually.
But how can you always be ready? Well, a common practice is to use feature flags. What it means is that you wrap every new change you include in the application with an if statement. You could control when the new change or feature is ready for customers and toggle it when you need to.
These are two basic but compelling examples of how you could build an opinionated software. Keep in mind that architecture influences your ability to ship software faster. So, you need to have a decoupled architecture that is elastic and fault-tolerant at the same time. Otherwise, it is harder to ship continuously and in small batches.
For another set of practices like continuous integration, trunk-based development, or testing, you can take a look at the Google Cloud’s DevOps landing page. Or I recommend you read The DevOps Handbook.
3. Assume Failures Are Going to Happen
In this new world of cloud and Kubernetes, expecting failures in a service should be normal. However, I’ve seen many applications go down because their dependencies are not working. Netflix understands this pattern very well, and proof of that is their Chaos Monkey project, in which they intentionally bring parts of the system down. Werner Vogles, CTO at AWS, has a famous saying: “Everything fails all the time.” Also, one of the key tenets in SRE is the error budget, which is the practice Google uses to embrace risk.
What I’m trying to say is that the software we build should have an opinion on how to treat failures. This opinion influences how, as a company, you deal with downtimes; how much risk you’re willing to take in every deployment or release; or how much time you dedicate to testing. For instance, you could create ephemeral or preview environments before merging a pull request.
Adopting the mindset of embracing risk impacts the culture. A healthy way of facing this reality is to foster a blameless culture. Forget about individuals; instead focus on the process and tooling. View every downtime as a learning opportunity, not as a way to find who’s guilty. Gene Kim, founder of Tripwire, refers to this principle as psychological safety, which is part of the five ideals from his book The Unicorn Project.
4. Focus on Your Customer Needs
Perhaps this might sound obvious, but the book I mentioned above, The Unicorn Project, reminds us that a focus on customers is crucial. In the book, Kim presented this ideal with an example of a company that has a payroll system. A payroll system is mission-critical, but customers don’t pay for that. Customers pay for what you have to offer them, which is your competitive advantage. So that should be your focus.
What does all of this have to do with DevOps? Well, many companies have done well in a DevOps transformation from the technical perspective. But they’re not operating anymore because no customers were willing to pay for what they had to offer. Want an example? From his experience at InfoQ, Patrick Debois talked about how DevOps could influence other departments such as legacy, marketing, or finance.
So, how do you know where you need to focus? You need to measure your progress based on customer feedback. You can emit metrics from the delivery pipeline to get feedback after every release. It doesn’t matter how fast you can ship software if clients are not using it. To start, you could measure things like release frequency, lead time, failed deployments, and mean time to recover. Then, make decisions on where to focus next based on the results.
A Driver for DevOps Transformation
Are these four practices enough? No, but they’re a good start. It’s impossible to dive deep into the details of what you could do to have a successful DevOps transformation in a single post. But what I was trying to say is how opinionated software can make a big difference.
When you’re starting your DevOps journey, you don’t begin transforming the whole company at once. You start with a meaningful part of the entire system, and then you replicate the lessons learned across the entire company. For instance, you might have learned that feature flags improve the team’s productivity. Or perhaps you learned that a particular platform could help you to influence how you build software.
For example, Paul Ingles said this about when his company was starting with Kubernetes:
We didn’t change our organization because we wanted to use Kubernetes, we used Kubernetes because we wanted to change our organization.
That’s an excellent example of how software influenced the company’s culture.
Christian Meléndezis a technologist that started as a software developer and has more recently become a cloud architect focused on implementing continuous delivery pipelines with applications in several flavors, including .NET, Node.js, and Java, often using Docker containers.