DevOps Overview: Rethinking How Development and Operations Work

Software development has been quickly growing in complexity — even since software became an actual thing that we could utilize, back in the era of the first electronic devices. With this increased complexity, we realized that we had to rethink our approach to development; we needed to develop smarter and more efficiently — and so DevOps was born.

Nowadays, software is much more than “a neat little code block that performs a single task” — it encompasses various aspects related to building, testing, and releasing the end product.

In this article, we will examine the intricacies of the DevOps approach: why is it vital for today’s software development, which tools are being used, what are the use cases of various companies that utilize DevOps — and which learning resources you can use to become more knowledgeable in this area.

OK, so what is DevOps?

As the name suggests, it has something to do with Development and Operations. Indeed, we can define this term as follows:

DevOps is a system of software development practices which incorporates both software development and IT operations.

Another important part of the definition is the function:

DevOps is designed to decrease the systems development life cycle, all the while paying close attention to business objectives to deliver product features and updates.

This definition holds a few key terms that we can examine to better understand the overall structure of DevOps:

• Practices: These aren’t rules set in stone; rather; these are simply patterns that the development community considers beneficial (similar to design patterns)
• Information-technology operations: These are the processes that ensure that the product (its right features, to be precise) is delivered to customers, all the while maintaining the competitive cost and high quality.
• Systems development life cycle: The progression of an information system (planning → analysis → design → implementation → maintenance → → → planning… )
• Business objectives: Naturally, both the management and the shareholders are expecting the company to improve.

Even though there aren’t any strict guidelines in the form of “Do X and avoid Y to achieve Z”, DevOps is still a very complex and wide approach. People in the developer community call it a “movement” and a “philosophy”, but our experience tells us that the word “culture” fits best. With “What” out of the way, we can ask now ask “Why”; that is, why is the DevOps approach considered beneficial?

How does it work?

The answer to this question lies in the problem that many software companies are facing: development and operation teams are isolated from each other. Even though the cross-team collaboration between these professionals is essential, they often have to work separately, so when the dev team introduces a new feature, they require instant feedback from the ops team — otherwise, it may be hard for them to understand whether this particular feature was successful or not.

DevOps aims to address this problem by uniting developers and operations pros into a single team — it doesn’t have to be a strictly defined in-company unit with a bastion of managers overseeing it; the main goal is to ensure communication and collaboration between these two groups.

The engineers, therefore, work in a way that allows them to broaden their skillset, following the application lifecycle in its entirety. Some companies prefer to add quality assurance and security teams to the mix, allowing for even closer integration — this variation is called “DevSecOps.”

While some business processes have historically been slow, DevOps-centric teams can now automate them with special technology stacks.

Benefits

All in all, adopting the DevOps approach is a serious undertaking — it’s not as simple as telling your team “Alright guys, everyone head on to docker.com and download it, we’re a modern company now!” — instead, you have to rethink and re-examine a great deal of your business processes and operations to find the bottlenecks, gaps, and problems. This may take weeks and months, so why are more and more companies deciding to try DevOps in their workflow?

Reliability: Software updates can be delivered more reliably. DevOps-like practices including continuous integration and continuous delivery allow testing if the particular update is safe and works correctly.

Speed: Both the dev and ops team can operate faster, all the while achieving the same (if not better) results. Microservices, for instance, can help to divide the development process into distinct parts, signifying where the responsibilities of the given team start and end. Here’s our recent article covering how micro-frontends, a subclass of microservices, can help you do that.

Scale: As DevOps puts great focus automation and reliability, scaling applications becomes easier; approaches like “infrastructure as code” play a big role as well.

Security: Thanks to configuration management, automated security policies, and fine-tuned control over deployment, all the while maintaining great software security.

Those companies who adopted the DevOps approach report that their business process has indeed improved: time to market has become shorter, product quality has improved, releases have become more stable, and product team efficiency and productivity have increased — we’ll examine this in more detail in the “Use cases” section below.

Functions and responsibilities

It might seem that the goals of DevOps are too wide and abstract, something in the lines of “well, just software development better.” In reality, however, the goals of DevOps engineers are clear: track the throughput and stability metrics and improve them accordingly. Throughput, for instance, correlates with deployment frequency and lead time; stability is tied to the recovery mean time.

The goals, therefore, can be summarized like this:

• Decrease time to market “(the time span it takes the given product to go from conception to being available for sale)”
• Make deployment more frequent.
• Decrease the number of errors, bugs, and failures in new releases.
• Make lead time between bug/error/failure fixes shorter.
• Decrease the meantime to recover after crashing or any other unexpected situation.

Speaking in more general terms, DevOps engineers aim to automate and program operational processes and maintain their predictability, efficiency, and security.

How Netflix does it

As DevOps isn’t a strictly defined system, various tech companies fine-tune it to fit their own style and work processes — and these “remixes” work really well, with Netflix’s use case being a prime example. As told by Dave Hahn, a core member of the company’s Site Reliability Engineering team in his talk How Netflix Thinks of DevOps, they encourage their engineers to follow these dos and don’ts:

• Don’t build systems that say “No” to the engineers — Do offer freedom and responsibility. In Netflix, every engineer has access to the production environment, so the overall motto becomes “Hire smart people and get out of their way.” With talented engineers at the helm of the creative process, Netflix aims to eliminate any guardrails or procedures that attempt to micromanage their professionals; instead, the company grants the freedom to make bold decisions and carry the responsibility for them. On the surface, this might seem like a nightmare scenario
• Don’t strive for 100% uptime at all costs — Do dare to innovate. Although 100% uptime is crucial in areas like healthcare and finance, Netflix realizes that a few hours of its service being down won’t send civilization back to the Stone Age. Its engineers like to innovate and push the technology to its limit — and the price they pay is sometimes things break down and fall apart. Errors and bugs are arguably a natural part of any software,
• Don’t idolize process and procedures — Do provide context to keep everyone in the loop.. As the company grows larger, it gets more and more tempting to abandon the liberal work approach in favor of a bureaucratic one, treating every employee as a replaceable cog that performs a single function. In such an environment, however, everything falls onto the manager to decide — and the professionals are robbed of the opportunity to innovate. To avoid this, the company tells its employees everything they need to know about the business processes, helping them appreciate why a particular decision is made.

Netflix’s use case shows: DevOps doesn’t only include technical aspects (e.g. tools) or financial goals; it also governs the company’s mentality and attitude towards their own work. Putting a great focus on freedom and creativity, the company creates a motto that governs how all Netflix engineering teams work: “We don’t do DevOps — we do culture.”

Ironically enough, the end result of their culture does seem like your typical DevOps, but Dave Hahn reiterates that culture reigns supreme; this means that you cannot expect to solve company problems by throwing DevOps at them.

Here’s the important takeaway: a problem with company culture is far more important than the lack of a cool modern system like DevOps or Agile. These systems come and go; the company culture stays and can define whether the company makes it to the top or flops.

The most important tools for DevOps engineers

Just like the concepts like continuous integration/development, work tools are the essence of the DevOps philosophy. There are a plethora of tools which can truly maximize the impact of this approach, so let’s look at some of them:

• GitHub needs no introduction — it’s the household name for version control software which allows for easy in-team collaboration and rapid code iterations (an alternative is BitBucket)
  
• Nagios and Phantom ensure software security via monitoring tools, performance charts, and alerts.
  
• Slack, although not directly related to software development, is still essential: it’s “the” tool for in-team communication and collaboration. Slack’s true power lies in its bot ecosystem — developers can create various bots with functionality almost equal to that of real software and use them in the app itself.
  
• Jenkins excels at helping to automate the software’s entire build cycle. Thanks to the instant feedback interface it offers, developers can quickly notice if a particular change is looking to cause some problems.
  
• Docker manages containerization, allowing the developer to safely package, deploy, and run the software in any environment they want.
  
• Sentry helps to find bugs and track errors; it offers software development kits that developers can use to fine-tune the check-ups of the programming languages/environments they’re using.

Due to the wide range of functions and tasks, DevOps practitioners use “toolchains” — tools that are grouped into categories based on their

Controversies and criticism

Naturally, not everybody in the developer community shares a passion for DevOps.

Many critics point out that there is no data-based evidence that DevOps is indeed effective. This point is highlighted by the fact that the academic literature has yet to provide sufficient proof for DevOps’ positive impact. Although it can be argued that DevOps is too “transcendent” (i.e.deeply integrated into the very nature of the given software company), it does seem strange that

In the Definition section, we mentioned that, ironically enough, DevOps are similar to design patterns — they’re both sets of practices. Here’s yet another similarity: they’re both prone to be mis- and overused which introduces overhead and unnecessary complexity instead of eliminating them. DevOps isn’t the silver bullet — but some developers apply it in the wrong situations.

A striking example would be trying to utilize it with legacy software systems which just cannot offer the same automation tools as modern systems. Obviously, “rethinking the work approach with DevOps” becomes much harder in this environment.

Learning resources

At this point in the article, you’re probably itching to become proficient in this area. Here’s the good news: you can get a good introduction to the DevOps world through these books.

The Phoenix Project tells a story about a fictional company that has a critical project — codenamed “Phoenix Project” — over-budget and behind schedule. The story’s protagonist, Bill, is tasked with fixing everything in just 90 days — otherwise, his entire team will be outsourced. This would be a nightmare scenario for most managers, but Bill takes a creative approach and notices that the IT sphere is really similar to a manufacturing plant in the ways they’re organized. He then uses this knowledge to reimagine everything he’s ever known about his work — chances are you’ll also come up with a few neat ideas to improve your company.

The DevOps Handbook is heavily tied to “The Phoenix Project” and acts as a “practical” sequel to the latter work. While its predecessor was a fictional story, this book puts a greater focus on real-world examples and clear instructions. It examines the use cases of Google, Amazon, Facebook, Etsy, and Netflix to try and see the patterns these tech giants deem beneficial.

Google’s websites and services are incredibly reliable — and wouldn’t it be great if the people at Google’s Site Reliability Engineering team explained how they achieve these results? It would be great indeed — so those Googlers wrote 2 books about it!

Last but not least, check the DevOps roadmap out (and open an issue if you don’t agree with the paths suggested there).

The added benefit of reading these books is a deeper understanding of how to organize work processes in an efficient way — your company doesn’t even have to be explicitly DevOps-oriented.

Conclusion

Even though the term “DevOps”itself is relatively new in the developer community, the underlying principles behind this system have always helped us build great software. These principles can be applied in your workflow ass well, so make sure to try at least hem during your next project! 🙂