Is DevOps Really for All Types of Organizations?

DevOps has become a very popular practice in the software industry, and the reason is that people are delivering better software more quickly. It's standard nowadays to hear that some companies are doing hundreds — or even more — deployments per day.

Unfortunately, some organizations have tried to implement DevOps but are still struggling after developers are ready to ship code changes. Those organizations sometimes ask if DevOps is really for them, or they wonder if there's a magic wand out there that can make DevOps work for them. The truth is that DevOps really is for everyone, but it demands a lot of discipline and it takes time to see the benefits.

For this post, I have some case studies to prove that DevOps is for everyone. But let's start by talking about why some people think DevOps won't work in their organization.

There are some organizations that think DevOps won't work for them, either because they've already tried it or they've only heard about big companies like Netflix doing it. One of my previous supervisors told me that the company wouldn't continue doing DevOps. We were trying to deploy too quickly "without needing to," which he said could negatively affect the company's revenue. And to be honest, he said all this because we were having problems at the time trying to implement DevOps.

I highly recommend you watch a talk Jez Humble gave called "Continuous Delivery (CD) Sounds Great But It Won't Work Here." He listed some reasons that people give for why CD or DevOps doesn't work for everyone:

• The organization is regulated.
• They aren't building websites.
• There's too much legacy.
• The employees aren't smart enough.

Jez argued why those reasons weren't valid, especially the last one. He also said that this list is the result of either a highly-coupled architecture or a culture that sucks, perhaps because there's too much pressure on the employees and changing things is tedious. That might occur if the organization has accumulated too much technical debt to the point that it's time to pay it off all at once or start over.

It takes time to get DevOps right. If you're saying "it won't work here," it could be because you're giving up too fast. Whatever the case, let's take a look at some DevOps success stories in different types of organizations. Spoiler alert, it didn't happen overnight.

In several countries, the government is known for being a highly regulated institution. Because there's often a lot of paperwork that needs to be filed and procedures that need to be followed before any change can go live, some changes could take months to get released. But DevOps has worked in the government, despite all the regulations that could slow down the process.

DevOps worked after the initial launch because the project included automation for manual tasks that would have involved too many people to review every time there was a change.

I'm a DevOps enthusiast, so I'll continue to advocate for it. But if you have any doubts, DevOps has been proven to work for government agencies with a very high positive impact on the outcomes.

DevOps has worked for many internet software companies like websites, mobile apps, or APIs. If an application isn't being hosted on a web server, where else could it be hosted? In a printer! Well, the printer's firmware software. Yes, HP implemented DevOps for the firmware used in their HP Laserjet printers, and it made developers two to three times more productive.

HP had hundreds of developers working on their firmware, yet they were struggling to deliver new features. So they started to observe their process. It turned out that they were spending the majority of their time fixing merge code conflicts rather than adding new features, which is not surprising considering the large number of developers they had on the project. Integrating everyone's code was a lot of work.

• Are developers committing to mainline-trunk at least once a day?
• Do you have a solid battery of tests that you can trust?
• If there's a problem, do you fix production bugs within minutes?

If you answered "no" to even one of these questions, then you're not practicing CI.

CI fosters not using long-lived feature branches, having an automated set of tests that can catch any bug before going live, and applying a fix rapidly if something goes wrong. A bug fix could be as simple as modifying the code slightly or turning a feature flag off while you fix it. CI also implies that you treat all changes in the same way. So if it's an emergency, you wouldn't use shortcuts or do things manually.

You can see here how DevOps has worked for non-traditional software applications, like printer firmware software. But that's not all!

Big companies, or "unicorns" as Gene Kim calls them, are applying DevOps to deliver better software more rapidly.

DevOps in startups is a no-brainer. I mean, there aren't many people that need to agree on how to do things. It's actually pretty common now for developers to release their own code changes. They depend on a variety of tools, technologies, and frameworks that will let them iterate more quickly.

Startups will always choose the simplest option to achieve their goals. They won't decide to use infrastructure as a service (IaaS), but rather platform as a service (PaaS) or even software as a service (Saas). Instead of having to install, configure, and operate a Jenkins cluster, they'll use the SaaS offering from Drone or Visual Studio Team Services (VSTS). They'll choose cloud and not on-prem. Github or Gitlab instead of self-hosting a Git server even if it's on the cloud.

Startups will implement DevOps to avoid having to deal with too many things at one time, especially when it comes to deployments. Small companies benefit when they can release promptly, quickly, and securely. It allows them to test their ideas more frequently.

It doesn't matter if you are in a regulated environment like government agencies or public companies. Neither does the size of the organization or the fact that you're not creating websites. DevOps is for you. But you need to embrace a change in culture, team structure, and tooling.

If you're not getting the benefits of DevOps, seeing it successfully implemented in other companies won't help you to keep trying. But you have to fail many times if you want to succeed at something. We wouldn't have light if Edison had given up in his first ten experiments- he succeeded after trying ten thousand times.

DevOps is possible for all types of organizations when you treat infrastructure as a product rather than an afterthought once you've finished developing the application. I highly recommend you check out The DevOps Handbook, which contains a ton of case studies that could help you in your DevOps journey. You can find some of them here.