What is DevOps and how do you begin to adopt it in your organization? Much like the cloud, if you ask 10 people to define DevOps, you’ll get 10 different answers.

At Rhythmic, we view DevOps as a culture that aligns different teams working together cross-functionally, supported by strong tools and processes to maintain high quality. There are plenty more rigorous, even exotic definitions, but we feel these simple principles capture what matters most.

DevOps only matters if it produces results

The most important thing DevOps produces is shared accountability between teams, a joint engagement. Development (henceforth known as Dev) and Operations (which we’ll refer to as Ops) teams have been pitted against each other for decades, creating unnecessary friction that counter-intuitively drove organizations toward larger and larger releases. After all, if it’s going to be so painful, we shouldn’t do it as often, right?

Historically, the conversation near release time goes something like this:

Dev: We’re two months behind schedule, but here’s our code. We need you to figure out how to get it working, and by the way, it needs to be deployed this week.

Ops: Your failure to plan does not constitute my emergency. We don’t have the capacity to support this.

Some Manager: We’ll have to do our best to figure it out and clean up the mess later.

By the time it gets to this point, neither party is wrong, but the opportunity to avoid the outcome was missed months ago. Disaster was inevitable, but the business still needs to release software to survive. DevOps solves this problem by getting everybody (product management, Dev, Ops and security) working together on Day One. There’s shared understanding, shared ownership and no surprises.

In a healthy DevOps environment, if development is behind, the whole team is behind — and everybody is working to fix it. And because the releases are smaller and more frequent, small delays do not cascade into huge delays. DevOps produces higher-quality software that makes it to customers sooner — allowing them to provide feedback and shape your product far sooner than was possible before.

Small Batch Size is King

The heart of DevOps is the idea that insisting upon delivering giant batches of functionality delays value to the customer unnecessarily. This decreases quality because 1) you’re making a ton of changes at once, and that’s always risky, and 2) the odds that you’ve precisely identified what you needed to build nine months ago when you first sat down at the design table are low. DevOps changes that, saying, “Let’s work in small batches. Let’s release frequently, and let’s be flexible to change because we know that there’s going to need to be change.”

A mature DevOps organization releases software frequently, with a manageable number of changes. Smaller releases allow you to release continuously internally — and even externally — with arbitrary development environments to support the team.

Speed = Security + Quality

Speed is the cardinal objective of DevOps, getting functionality to end users faster to gain feedback and better target releases. With these improvements come a host of benefits. It would be easy to assume that a slower pace would be better for security, but by making small changes and putting them out there, it is much easier to incorporate security into every release cycle.

As a result of moving faster and releasing more frequently, you increase rather than decrease quality. You get to deliver value more often, and you get to deliver a higher quality output than you would otherwise. Incremental improvements are made possible, allowing technical debt to gradually be retired instead of accumulated.

Loosely Coupled Systems, Tightly Coupled Teams

Traditionally, software has been built as one big black box, filled with thousands of intricate dependencies. Such systems are fragile when changes are made, as it can be difficult to know the ramifications. As software “ages,” many things that appear broken are actually that way for a reason, which no one remembers anymore. When software becomes this brittle, releasing more frequently can create significant problems.

DevOps breaks software into dozens (or more) smaller black boxes, each making well-defined agreements with each other about how they will behave. Within these boxes, anything can happen, so long as each box continues to process inputs and outputs the same. Software built like this is called loosely coupled, and it is the backbone of a great DevOps infrastructure. Of course, by making many more boxes, communication becomes essential. Teams must have great communication, not just from Dev to Ops, but between the teams responsible for each box.

Structuring your DevOps around loosely coupled systems and tightly coupled teams gives you the ability to make changes to that system whenever you want without having to fear that you’ve affected the systems around you. A sense of empowerment among your teams is frequently the result, and greater levels of productivity follow. Key attributes of loosely coupled systems include a rich set of automated tests, great documentation, and the ability to deploy continuously and automatically, all with a light footprint.

DevOps at Rhythmic

DevOps drives how we run our own systems and deliver service to our clients. But truly effective DevOps is also flexible, understanding that not every system, team and client must be true to the principles of DevOps. Great DevOps teams recognize that each system is different and support both highly automated, light touch systems alongside hairy black boxes.

Understanding this, we have adopted a varied toolset consisting of dozens of open source and home-grown tools, from the popular (Terraform, Ansible) to the emergent that our teams have proven to be useful. Together, these allow us to achieve complex infrastructures, all fully described through Infrastructure as Code (IaC) and ready for high levels of automation, instrumentation and observability. We understand that DevOps is a journey, not a destination. As a result, our teams, tooling and infrastructure are all set up to meet clients where they are and create an environment that fosters gradual improvement.