What is DevOps?

The primary goal behind uniting the processes and partnership between software developers and IT operators is to achieve an environment in which software is constantly being improved. How does DevOps achieve this? It begins by recognizing that with DevOps it really does take a village.

What’s the big deal about DevOps? Much more than meets the eye.

When you begin by recognizing that DevOps is a partnering of software developers with the system operators who will run their software you start to realize that this is about collaboration, but to fully appreciate the desired outcome of DevOps you need to examine the entire process, which is quick.

It Begins with Need

As with all software development, it all begins with developing a deep understanding of the user community’s needs. The development team collects input, analyzes it, and proposes a solution. So far, nothing new.

But when the development team begins to code subtle differences begin to show up. The developers don’t seem as concerned with developing a complete solution that is as close to perfect as possible. Their goal just seems to be something that works. Sounds a little like the Agile Manifesto we recently discussed here in this blog; working software over comprehensive documentation.

The software is far more modular than before. Instead of monolithic blocks of code, the applications are built with microservices in containers that can be quickly transported around the cloud. The good news here is that different teams in the development group can make changes to their segment of the code without really impacting anyone else.

Often companies approach the cloud with a lift and shift mentality. Simply put, taking virtual machines running on-premises and moving them to the cloud as hosted VMs. While this is a significant first step, the IT staff still has to manage the entire stack from the Operating System up. Once comfortable with this type of Infrastructure as Service (IaaS) migration, companies should then begin to look at ways to offload some administrative overhead by leveraging both Platform and Software as a Service offering (PaaS & SaaS). For example, instead of deploying VMs and installing a hosting platform such as IIS and then deploying the code to the web app in an IaaS model (thus managing the OS/IIS application/Code and all patching.) Instead, they could deploy a PaaS web app allowing the provider to manage the OS and application tier while simply focusing on code.

Part of the DevOps methodology encourages the developers and the operators to use the same processes and tools, so when the handover of the first version happens it’s quick. Users get right down to work, often spending very little time on user acceptance testing (UAT).

Then It All Takes Off

Here’s where the fundamental DevOps process departs dramatically from “the usual.”

The operators immediately begin asking for feedback from the users, documenting their problems and requests thoroughly. At first stunned, the users find themselves encouraged by how concerned the IT department is in their satisfaction.

The operators immediately convey the feedback back to the development team which wastes no time coding changes, fixes, and additions. Still, they’re not looking for perfection, just better working software.

The developers once again handoff the changes in record time and the operators just as rapidly deploy the updated code. Guess what they do next!!

It’s Iterative!!!

Yes, they immediately solicit feedback from the users, documenting it carefully.

Yes, they then convey the new feedback back to the developers.

Yes, the developers immediately begin coding new changes and…

Yes, the entire cycle repeats.

Improvement

The DevOps cycle iteratively repeats and repeats and each time it does the software gets better. Better as defined by those who use the software. Who better?

In other words, the continuous development being continuously deployed creates constant improvement, and that’s what CI/CD means. Continuous improvement through continuous development and deployment. Feedback from users leads to better code, and better, and better, and better.

Instead of upgrades coming once every six months or so, companies like Amazon are releasing new upgrades at the rate of 30 or more per day.

Depends Upon Participation

Whenever you want something to move fast you need to remove all obstacles and anything else that might slow down the process. Assuming that the developers and the operators are all committed to DevOps principles, the only other component of the process that might engender latency is the user community.

The user community or communities may encompass all departments of the company. This means that everyone must be successfully encouraged to enthusiastically cooperate and participate in providing their feedback rapidly. Loosely defined, that’s called a culture change. And culture is among the hardest things to change in any company.

It Takes a Village

From the moment a company decides to undertake a DevOps initiative those leading the process must immediately recognize that it will take a village, perhaps their entire “village”, to create the cultural change needed to willingly and enthusiastically share feedback more frequently than they ever have before. The reward will be better software than they’ve ever used before, software developed specifically to fulfill their expectations, and that continuously improves to help them be more productive and more efficient than ever before.