What is DevOps?

It’s a buzzword, to be sure. It’s a practice. It’s a process. It’s a culture. It’s a tool set. It’s all of those things, and more. Sometimes, its definition will change depending on who you ask and what problems their organization faces. What never changes? That the ultimate aim of DevOps is to help organizations deliver higher quality software products faster.

In the traditional software development process, developers write code and hand it off to IT operators to run. However, both development and IT operations teams wanted to simplify this handoff. This is how DevOps practices emerged. Just as the Agile manifesto challenged traditional software development methods, the DevOps movement challenged how teams were releasing that software. And out of these basic ideas, we have witnessed revolutionary shifts in technologies and cultures that have impacted how we design, build, and manage software today.

How it Works

DevOps in practice works at addressing two areas:

1. Organizational culture, and
2. The product pipeline itself.

Changing Organizational Culture
The term “DevOps” itself is a combination of “development” and “operations.” In traditional organizational structures, these two disciplines rarely, if ever, communicate with each other. DevOps breaks down the silos of these two disciplines. As DevOps practices have matured, teams operating within this framework seek to break down silos across ALL disciplines who contribute to building software products. This includes designers, security engineers, architects, data science analysts, and more. Anyone who is involved in the product lifecycle, from ideation to production and beyond. Changing organizational culture is the first (and usually the hardest) step.

Optimizing the Product Pipeline Process
Since DevOps practices help teams deliver higher quality software products faster, optimizing the product pipeline process encompasses everything from ideation to managing and monitoring the product in production. DevOps seeks to raise effectiveness and efficiencies in all areas.

Here are some ways that DevOps practices can improve the product pipeline:

• Increased revenue
• Lower operational and overhead cost
• Significantly shorter time-to-market
• Improved customer satisfaction
• Better product quality
• Improved productivity and efficiency
• Increased collaboration and employee satisfaction
• Improved security integration

Putting it Into Practice

So, what are some practical steps that an organization can take to begin benefiting from DevOps? In this section we’ve listed some of the core tenants of any DevOps strategy, what they are, and why they’re important. The ideas we’ll be covering here are:

1. Collaborating and Sharing Knowledge
2. Identifying and Simplifying Processes
3. Automating Processes
4. Monitoring Success and Failures

Collaborating and Sharing Knowledge

No one is going to have all the answers. Even if someone does, no company can leverage their time and resources effectively if only one or a handful of people hold the keys to the knowledge safe. For anything to be scalable beyond a single human’s effort, other team members need to have the knowledge too. This way, they can repeat the process independently.

A good starting place for building or revamping a knowledge base is to start with a list of questions to answer. Every team has their own set of questions they need answered to do their jobs appropriately. Gathering all those questions in a centralized location can lay the foundation for documentation that teams find useful. Collaboration can start to come into play as we work with each team to start answering those questions.

One way we’ve found to be effective at getting team members to provide us with their lists of questions is asking them “If we told you that we needed to you to perform task X right now, what questions immediately pop into your head?”

For a more concrete example, at ITX, each product we build is unique in the services it provides and the challenges it confronts (and solves). Still, despite their uniqueness, they all share certain commonalties—questions we know we must answer for every project. Questions like:

• Where will we store the source code?
• How will we deploy the product locally?
• How will we deploy the code?
• What resources does this code need to run in production?
• Where will our application logs live and how will we access them?
• What security concerns do we have?
• What kind of metrics should we be collecting?

Developing a knowledge-sharing culture is the first step because every step after it only works if there’s a successful strategy in place to teach people how to use it. What we build might be a unique snowflake. The way we build doesn’t have to be.

Identifying and Simplifying Processes

To address a product pipeline from ideation to management and monitoring in production, a clear picture of that pipeline is essential. To create that picture, multiple disciplines need to work together to identify the many steps involved along the way. This can turn into a marvelous exercise in identifying gaps and unnecessary complexities. It’s only when you can see the big picture from start to finish that the holes become apparent; it’s unlikely that you’ll notice a puzzle piece is missing if you haven’t put together most of the puzzle.

Identifying and simplifying processes is also a crucial first step to automating anything for one simple reason: you can’t automate what doesn’t exist. If you don’t know what your process is, you’re going to have a very difficult time programming something to run it for you.

Let’s say you know that you want to automate the build process for your application. Do you know at what point in the process the automation gets triggered? Will it happen every time a developer commits any type of code to your repository? Does code need to be reviewed and approved first? How will code be reviewed and approved?

When you’re considering automating deployments, do you know what your rollback strategy will be if something goes wrong? How do deployments get triggered? Who needs to be notified? How will they be notified?

Likewise with simplification, the only thing worse than attempting to work with an overly complex process is attempting to automate an overly complex process. More complexities mean more potential points of failure. That means more time spent troubleshooting your automation tools than benefiting from them.

Take the time to ensure your processes are as clean as you can before trying to automate them. Trust us.

Automating Processes

Now for the really cool part. This is where the hard work of getting different teams talking to each other starts to pay off. Now you take elements from all those disciplines and apply it to the kind of work that everyone likes to brag about.

Developers can work with IT operators to set up servers and jobs that let them scan their code for quality issues or build their software automatically from source code. Security teams can set and enforce standards with Static Application Security Testing (SAST) tools. You can start putting checkpoints in place that no longer rely as much on human interactions, which means you can begin to reduce bottlenecks and opportunities for human error.

Of course, this is not an overnight shift. While there are countless tools in place to support these endeavors, you still need to link these tools to support your specific project needs. That still takes time. And often a LOT of trial and error.

Monitoring

The next step—metrics. How do you know your app is working? How do you know when something goes wrong? What about the times when you’re not allowed to access your production environment for security and/or compliance reasons?

We often use the word “launch” to talk about deploying our applications to production. If we continue that analogy, when NASA launches a probe to Mars, they’re operating under the assumption that they’re never going to be able to touch that machine again. They need to include all required tools to understand the probe’s health and performance before it makes its way to the stars.

We know that factors outside our control may impact how the application is running. By keeping a watchful eye on the output, you can remain vigilant with minimum effort. The minute something isn’t running as it should, you can move into action with a problem-solution mindset.

In Summary

Implementing DevOps practices throughout an entire organization is difficult, and it takes time. But we believe that the effort and investment is ultimately worth it. The proof, as they say, is in the pudding. Building higher quality products faster means everyone wins.

---

ITX has DevOps expertise ready to bring you and your product to the next level. Let us help uncover what hinderances are keeping the world from experiencing your next big product.

---