<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=752538731515435&amp;ev=PageView&amp;noscript=1">

It Doesn't Matter What Industry You're In. You Need DevOps.

There is an unplanned outage and your company's most important application has gone down. It's taking forever to come online again. When you ask your IT department what's going on and when your application is going to be up and running, all you seem to hear is blame. The development team is mad at the operations team. The operations people are mad at the development people. Everything seems to be someone else's fault.

But you don't care because your app is down and your customers cannot engage your business.

You just want everyone to settle down and do their jobs.

Here's the thing, though: everyone in IT is doing their job. They want to fix the problem quickly, but they can’t, because your business's culture doesn't let them.

You need DevOps.


What is DevOps?


If you're not in the technology industry or in an IT department, your eyes may glaze over when you hear the term DevOps.

On its face, however, DevOps — which is just a combination of the words "Development" and "Operations" — is a simple concept: the unification of engineers who had traditionally been isolated in their own teams.

In a DevOps model, development and operations teams are no longer siloed. In many cases, those teams are merged into one team of engineers who work across the whole application lifecycle.

This approach is built on Agile principles and are similar to those used by Scrum in software development. While Scrum uses a self-governing team of engineers who work in short sprints to build software, DevOps extends that approach past development, into operations and to a company's application infrastructure as a whole.

Sometimes Quality Assurance and Security Analysts are brought into the team as well. In any case, the engineers in a unified team stop specializing and instead develop a range of skills. Because the walls between teams are broken down, processes become transparent and people learn. Engineers better learn how a system works once applications are deployed and operations staff better understand the operational needs of a system because they're working closely with engineers.

That range of skills and knowledge is important; in a non-DevOps world, knowledge is tribal. In a small company, if someone is out on vacation and there's a problem, business grinds to a halt. A team that subscribes to the DevOps model solves that problem by making the same knowledge available to everyone on the team.

So, if your app has a problem and it's the middle of vacation season? No worries — whoever is working knows how to fix it. And, thanks to another mainstay of DevOps, that person will probably be able to fix the problem quickly.

Teamwork is great, but it's not enough.DevOps-Teamwork

Even the most cooperative, in-sync, talented team can't perform tasks with perfect speed and accuracy.

That's why teams that have implemented DevOps almost always automate processes that historically have been manual and slow: creating deployment artifacts, for example.

Why? Well, automation makes things easier. If you automate compiling and deployment, people on the team are freed up to work on higher-order tasks. Automation also reduces human error and, relatedly, financial and opportunity cost. Automated functions also provide a receipt of sorts because good automation should be self-documenting. Automated scripts provide a single, always up-to-date source of truth about a business's process. Engineers can review the code to see what should be happening and debug why the application is no longer working.

Who Needs DevOps?

You do.

According to Puppet Labs' State of DevOps 2017 report, DevOps teams are most prevalent in the technology industry, but that should not be the case. Other industries need DevOps as well.

Case in point: a couple of years ago Jewelers Mutual, a Wisconsin-based insurer of jewelry and jewelers, frustrated that their team was not able to quickly respond to change, surveyed their developers to find out what they spent most of their time on.

The survey showed developers spent 60 percent of their time troubleshooting environmental issues.

So Jewelers Mutual changed its approach, automating building its environments for reproducibility and automating deployments. Now, developers no longer waste as much time trying to code around the limitations of their unique environments, and the company has been seeing value — instead of one big monthly release, the Jewelers Mutual does one or two releases every week.

Any company that's developed or run its own applications needs DevOps. Even a one-person start-up should be doing DevOps, by creating automated tests and writing infrastructure as code to make processes both faster and more transparent because hey — what if you're successful and have to hire someone else some day?

In short, you need DevOps.

You Need Just One Thing to Get Started with DevOps

It may sound like you need to overhaul your entire organization to implement DevOps, but that’s not the case. You can start small — by automating one thing, or perhaps a few engineers with an interest in DevOps might put together a proof of concept project.

If those engineers don't exist at your organization, you can always demonstrate your leadership's willingness to invest in DevOps by bringing in an outside expert.

At Omni, for example, we can educate your staff about DevOps, and also help you create proof of concept projects so that our clients can experience the benefits of DevOps on a small scale before committing to an overhaul of the organization's development process.

You may be ready to put DevOps into action at your organization, but you cannot start right away without one thing: buy-in.

DevOps is not a thing. It's not even a process. It's a culture. Committing to DevOps means breaking down silos across an organization and involving everyone in development, operations, QA, and even security in the same process. Everyone has to agree to participate, but that buy-in absolutely needs to include the leadership of an organization.

And the next time your application goes down, there will be a lot less blame to throw around. After all, it's hard to point fingers when everyone is on the same team.

Ready to get started? Contact us today.


VenDiagram image: Rajiv.Pant [CC BY 3.0 (https://creativecommons.org/licenses/by/3.0)], from Wikimedia Commons
Fistbump Image: 
Photo by rawpixel.com from Pexels

Mathew Peterson

About Author Mathew Peterson

Mathew Peterson is a former Solutions Consultant with Omni. Many of his projects revolved around infrastructure: he troubleshooted infrastructure issues, consulted on AWS cloud platform and developed Terraform to manage cloud infrastructure.


Omni’s blog is intended for informational purposes only. Any views or opinions expressed on this site belong to the authors, and do not represent those held by people or organizations with which Omni is affiliated, unless explicitly stated.

Although we try to the best of our ability to make sure the content of this blog is original, accurate and up-to-date, we make no claims of complete accuracy or completeness of the information on this site/s to which we link. Omni is not liable for any unintended errors or omissions, or for any losses, injuries, or damages from the display or use of this information. We encourage readers to conduct additional research before making decisions based on the information in this blog.