Want to move from Ops to DevOps? Here is what you should know.
Tags: devops, kubernetes, docker, agile
Published: 2020-10-06 08:04:35

The DevOps approach has increased in popularity among software teams to move ahead in a competitive market and efficiently deliver innovative products. If you’ve already read [The Phoenix Project](https://itrevolution.com/the-phoenix-project/), you have some idea of how the transition from Ops to DevOps looks like, in this case, when an American tech company decides to do it. 

Today, many companies decide to go down this road. Software teams believe that DevOps can save them a lot of effort and allow them to focus on the actual product. Why is this? What are the benefits of moving from Ops to DevOps? Well, first things first. 

# What is DevOps?

DevOps is a set of practices that encourages **an agile mindset** to improve the software delivery process’s speed and quality. In previous methodologies, such as waterfall, development, and operations teams were considered separate, each with their given tasks and responsible for only one part of the delivery process. With this model, the development and operations teams are regarded as interdependent across the entire software application life cycle, working closely together.

Before DevOps, traditional models involve a flow of a defined set of phases where the output of one stage is the next step’s input. This makes all phases dependent on each other, making delivering new features and fixing bugs take longer and be more costly. 

The key elements of DevOps key elements are collaboration, automation, continuous integration, continuous delivery, testing, and monitoring. 

![devops](https://mk0microtica2di3k2co.kinstacdn.com/wp-content/uploads/2020/09/devops-venn-diagram.png)
<figcaption>Source: https://commons.wikimedia.org/w/index.php?curid=20202905</figcaption>

Find the most common DevOps myths busted [in this article](https://microtica.com/7-devops-myths-busted/?utm_source=devto&utm_medium=referral_link&utm_campaign=from_ops_to_devops).

# DevOps benefits 

One of the most significant benefits of DevOps is that it provides **short and fast feedback loops**. This enables businesses to quickly identify their mistakes and understand what their customers want and need. It also allows them to ship features really fast. Furthermore, it leads to greater efficiency and better software.

Another benefit of DevOps is delivering more **quality products and fewer failures**. One of the key ways to determine the software’s quality is the number of defects in it. According to a [survey conducted by CA Technologies](https://docs.broadcom.com/doc/accelerating-velocity-and-customer-value-with-agile-and-devops-research-paper), adopting DevOps and Agile methodologies has a tremendous positive impact, improving the quality of development processes (number of defects) by 41%. Surely enough, the **collaboration between development and operations teams** has a lot to do with improving the quality of a product. 

Adopting DevOps can contribute to a stable and **well-balanced working environment**. Tensions and stress around release time can disrupt the stability in the team and decrease their productivity. 

Automating repetitive tasks leaves **more room for innovation** for the team. Moreover, automation and monitoring can be implemented at every stage of the software development process. From integration, testing, and releasing to deployment and infrastructure management.

When done right, DevOps helps **cut down the production and non-production costs** of your business. Maintenance, staff, quality costs, and much more can be reduced, making companies work faster and more profitably.

![devops benefits](https://mk0microtica2di3k2co.kinstacdn.com/wp-content/uploads/2020/09/devops-benefits-1536x804.png)

# How is DevOps different from traditional Ops?

When development and operations teams are separate, which is the case in traditional Ops, each team takes care of their part of the delivery – developers develop, and then operations operate. In other words, IT Ops have one objective: to make sure everything is running smoothly in production. They ensure that resources are available and function at peak performance. They provide a **reliable and optimized infrastructure**, which means ensuring as little change as possible to guarantee it. 

Instead, DevOps encourages these teams to come together, understand each other’s tasks and concerns, and have a view of the big picture at all times.   According to an [IT Ops/DevOps Productivity Report](https://www.slideshare.net/ZeroTurnaround/traditional-it-ops-vs-dev-ops-devops-days-ignite-talk-by-oliver-white), **DevOps teams spend 21% less time putting out “fires” on a weekly basis.** They also spend less time on administrative support due to a higher level of automation and self-service tools. With this extra time, teams can work on improving infrastructure, innovating, and self-improvement.

# Mindset switch
One of the first steps in moving from IT Ops to DevOps is to understand that **you’re in control of the entire delivery process.** IT Ops have the responsibility of ensuring the system’s stability and reliability, making sure there are fewer changes, reduced variables, and there are end-user processes in place. 

But in DevOps, this mindset doesn’t work. The engineers now become the steering wheel of the organization. They **build automation, improve application delivery, find new ways to ensure security,** and are **comfortable with failure and mistakes.** 

*In DevOps, decision-making is closer to the team that is actually doing the work.*

# Infrastructure

The infrastructure setup used to be a few scripts that automate some parts of the process but need to be triggered manually. This took a lot of time to complete and produced numerous errors that could have been avoided. 

In DevOps, **ops work is way beyond scripting**. It’s actually coding—infrastructure itself has become code. Building and configuring cloud infrastructure via code. It’s a switch from “server thinking” to “service thinking,” the kind most developers have. Infrastructure as code enables you to define how an infrastructure component should look like. The logic on how to provision it is bundled within the component. [You need to define a pipeline](https://microtica.com/how-to-create-simple-ci-cd-pipeline/?utm_source=devto&utm_medium=referral_link&utm_campaign=from_ops_to_devops) for the steps that this component should take to be ready for deployment. 

To become an infrastructure coder, rather than an infrastructure administrator, you need to be thinking about workloads and services instead of servers.  

# Automation is key

In traditional IT practices, the automation part is about creating consistency and documenting everything and reducing variables. Documentation is essential, but it should never slow down automation or, worse, be an excuse for not automating. 

Manual work and repetitive tasks are always error-prone. Doing the same configurations over and over again or can become really uninteresting and inefficient. 

Automation is part of every phase of the development cycle. From code commit, to build triggering, carrying out unit testing, packaging, deploying to environments, verification, smoke, acceptance tests to final deployment to production. 

**[Automating infrastructure setup](https://microtica.com/start-creating-infrastructure-on-aws-like-a-pro/?utm_source=devto&utm_medium=referral_link&utm_campaign=from_ops_to_devops), configuring environments,** and **deploying software** are the key benefits of DevOps. This helps deliver features in hours, from code to production, and get faster product feedback. 

# Failure and mistakes
DevOps embraces the Fail Early philosophy. In traditional IT environments, failure is not an option. You do anything to avoid the risk of loss: introduce meetings, processes, approvals… 

In DevOps, **failure is part of the game**. It’s inevitable. You can control failure if you fail small and early, which makes it possible to recover fast. The discussion of failure is vital as it’s an opportunity to learn. What went wrong is even more important than what went right. DevOps is a culture of no blame.

DevOps practices support this culture, starting with test-driven development, small batch deployments, automation.

![devops gif](https://mk0microtica2di3k2co.kinstacdn.com/wp-content/uploads/2020/09/developer-bug.gif)

# Increased visibility 
Traditional IT companies have processes and limitations over who sees what. Having access to monitoring was considered as a huge liability. 

In DevOps, **everyone must have access and visibility to the software**. This helps developers stay ahead of issues, better issue detection, and resolution. Application logging should be combined with environment logging so that developers understand how applications work in different environments. 

Access to monitoring helps the team identify failure points, improve automation, and software quality. 

# Tooling

The best allies of DevOps are the tools that bring efficiency. In the entire software delivery cycle, you need multiple components to achieve automation: 

- Collaboration tools: like communication chats and knowledge sharing 
- Build tools: source control management, continuous integration, database management
- Testing tools
- Deploy tools, configuration management, artifact management, orchestration, and scheduling
- Monitoring tools, logging, and business intelligence

Learning all these different tools can be challenging by itself, but you also need to make sure the tools chosen are compatible. 

[Automation tools](https://microtica.com/?utm_source=devto&utm_medium=referral_link&utm_campaign=from_ops_to_devops) are designed to **support release velocity and application quality**. They will help you to quickly and painlessly revert any unwanted changes. If a change happens outside the code, tools will revert the change and maintain your servers in a stable state.

# Getting started
DevOps doesn’t have a simple guide. It should definitely begin by improving communication and collaboration between development and operation teams. This will help them better understand the requirements and each other’s tasks so that they can work together toward a common goal. Ops engineers already have the capabilities to use tools, build automation, and support environments. They need **a mindset switch** and **focus on the [continuous development](https://microtica.com/cracking-the-continuous-deployment-code/?utm_source=devto&utm_medium=referral_link&utm_campaign=from_ops_to_devops) approach**.

*Start small and scale up gradually over time.* It is always safer to incorporate the DevOps culture into a small team and observe the achievements. Learn from this process to tweak and adjust the structure and methods of the company. This is how you’ll find the right balance for your business.