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. There's a well-known case study where DevOps was critical to the project's success. I'm talking about HealthCare.gov, which was created to help certain people in the US get insurance. The problem was that there was a short timeframe to sign up. The project was launched on time but the site was constantly down because the IT staff didn't anticipate the huge wave of traffic. There are a lot of video-talks and blog posts about what went wrong and how the IT staff fixed it, in case you want to know more details. 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. A platform as a service (PaaS) then came out called Cloud.gov which any government agency can use because it's FedRAMP authorized. That means if someone uses this platform, they will be compliant with all the regulations. DevOps has also helped the UK government. 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. The staff at HP ended up implementing continuous integration (CI). Martin Fowler has given talks about CI in which he asks the audience these three questions:

• 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!

One of the first times DevOps started to get attention was back in 2009. John Allspaw and Paul Hammond from Flickr gave a talk at a conference on how developers and operations were working together to deliver software. They said they were doing ten deployments a day—back then that was a crazy thing to even think was possible. Organizations didn't deploy that often, and that's still the case even now. Everyone is trying to release more frequently. Flickr implemented DevOps before the term and its practices became popular. But bigger companies like Etsy, Netflix, and Amazon are also doing several deployments per day by practicing DevOps. There are many blogs and talks out there saying that Amazon deploys, on average, every 11.7 seconds. 11.7 seconds! That's a lot! But DevOps isn't just about deployments, even though that's a key metric that indicates how an organization is doing on its DevOps journey. Last year, InfoQ released an eMag about scaling DevOps. There are some pretty awesome case studies about how big companies have implemented DevOps in their organization. For example, they talk about how Microsoft is practicing DevOps across the entire organization. There's also a review of Gary Gruver's book, "Start and Scaling DevOps in the Enterprise," which is a manual that he's used in workshops when doing consulting for big companies. Big companies, or "unicorns" as Gene Kim calls them, are applying DevOps to deliver better software more rapidly.

In the startup world, DevOps is not just easier to adopt but it's also necessary. A startup is always going to be iterating the product, so they need to deliver to customers quickly. Adopting DevOps will allow startups to run experiments because the company will be able to deploy in as little as a few minutes. One startup where DevOps has worked is Alterbooth. Some startups have even opted for adopting DevOps from the very beginning. 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.