What is DevOps?
Breaking Silos in the Software Engineering Workplace
What is this “DevOps” thing I keep hearing about?
The term DevOps has been thrown around the internet for quite some time now without any concrete definition. What is it exactly? Is it a software tool? A new coding language? Although a plethora of definitions exist, the common denominator amongst them all is that DevOps is more of a culture and methodology than a particular “thing”. For example, Amazon Web Services defines DevOps as:
“DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.”
Why should I care about DevOps?
We can all agree that software plays a vastly different role in today’s business world than it did back in the 90s. It doesn’t merely support a business, but rather it becomes an integral component of every part of that business. As the role of software has changed in the last two decades, so too has the process of building and delivering it. In today’s world, it is essential to implement DevOps practices to accelerate software delivery, improve developer productivity, and enable technical innovation to drive tangible business improvements. The bottom line is that an organization that applies DevOps principles properly is able to compete more effectively in the market and stay ahead of the curve.
HealthyHabitz
To illustrate this example, let’s imagine a hypothetical situation involving a fictional firm; The HealthyHabitz Company. Last quarter, HealthyHabitz announced its plan to launch a mobile app to help its customers track their daily habits and drive healthier decision making. Let’s take a look at how the software delivery lifecycle for this new app would be handled 20 years ago vs how it is (and should be) handled today:
Then
The “Dev” (development) team will write the code; the “Ops” (operations) team will make sure the code gets to the customer. The Dev team finishes writing the application code and “tosses it over the fence” for the Ops team to figure out how to deploy it to production. This is very error-prone; the code that was running fine on a developer’s local setup all of a sudden is misbehaving live in production. So whose fault is it really?
This is an old-school style of software development where each team is siloed from the rest; working in complete isolation from the other teams. This creates friction and bottlenecks for delivering software products efficiently.
Now
HealthyHabitz embraces DevOps best practices and reaps the benefits. No longer are teams siloed from one another; instead they work in tandem. There is no “imaginary fence” to toss code over; developers take on more responsibility by learning how to handle operations involving their code. Operations teams learn about how the code they receive is built. In the end, both teams dip their feet into each the other’s waters and improve collaboration. Together, these teams learn how to automate processes that historically have been manual and slow.
How do I implement DevOps?
Implementing DevOps requires a change in culture and mindset. Rather than splitting Dev and Ops teams into silos, management should instead tightly integrate them so that everyone collectively has a bigger stake in the software development process. This integration optimizes both the productivity of developers and reliability of operations. By taking full ownership of their services, the teams now view the entire software development cycle as part of their responsibilities.
Enjoyed the story?
Feel free to check out one of my other posts “What is Docker?”
