DevOps Explained (Finally)
Let’s begin with what DevOps isn’t. It is not a programming language, software brand, or trending buzzword. Instead, think of it as a way for tech companies to smooth out digital product releases. Let’s break it down further.
The name gives it away. DevOps = Development + Operations. Each side of the equation has a distinct role. Development is made up of teams who write the code, build new products, and do most of the testing. IT Operations is tasked with managing the servers and hosting, and handling capacity issues like scalability and bandwidth, security, and backup systems.
But it hasn’t always been a perfect marriage.
Our Divided Past
To understand how DevOps got to where it is today, let’s look at how development and operations teams used to do things. It wasn’t pretty. In most cases the two operated in silos with a nice thick wall between them. Each department had its own processes, standardizations, and toolsets.
Before cloud providers like AWS and Azure and hosting companies like WP Engine and Pantheon came along, IT operations teams mostly managed hardware themselves. Team members were expected to handle things like server purchasing, set up, and configuration along with the deployment of applications.
Back then, overseeing hardware was a highly complex undertaking. This explains why operations teams would keep a close eye on the number of applications being released at any given time. If a development team wanted to roll out a new feature for an internal software application or website, they knew they’d probably have to wait until the next month’s scheduled deployment.
Fast-forward to today and a whole new set of operational challenges. Instead of managing actual hardware, operations teams have to stay on top of an evolving array of cloud-based services, tools, and updates. So, while software can be deployed far more quickly than before, standardizing tasks, tools, and processes across development and operations has become a serious challenge.
To Infinity and Beyond
Back to those silos. The old hard-stop pass, throw-it-over-the-wall days of yore created a lot of friction between development and operations teams. For example, a developer would deliver code that renders perfectly, only to have it blow up the moment operations attempted to deploy it. The same holds true today. If the development environment differs even slightly from the production environment, errors occur. Keep in mind these differences can be as simple as running older and newer versions of the very same app.
DevOps is a way to finally break down the silos and getting everyone on the same page. This is best expressed by the infinity symbol that comes up when you Google the term. At its core DevOps is all about removing the rough edges and creating smooth loops that extend from development to operations teams and back again.
To get a better sense of the distinct roles development and operations are responsible for, there are two key phrases to consider: “In-development” and “In-production.” Though they sound the same, they are very different.
- In-development is the stage before an application goes public. Here, development teams build and test (using dummy data) digital products in a nice little bubble.
- In-production encompasses the actual public-facing release. Once an update or new application is packaged and released from development, operations deploys the code to live databases and API’s (along with some additional testing and error reporting).
Working As One
A core principle of DevOps is to create an identical development and production environment. Sound simple? Think again. Pulling this off requires a highly orchestrated system of tools, software, automation, code configuration standards, and monitoring, testing and error reporting processes. It also takes strong communication between development and operational teams. With silos out of the picture, teams are able to deliver products and updates more frequently, and with fewer hiccups and side-glances between teams.
Before DevOps, deployments occurred monthly or even bi-monthly. Releases were often large, which meant greater potential for error, and more time troubleshooting due to the volume of code being deployed. With DevOps, smaller blocks of code can be released more frequently, thus minimizing the probability of errors.
Knowing the advantages of DevOps, you’d think everyone would be on board. Unfortunately, this isn’t the case. While many software companies toss the term around, it’s hard to find it actually in practice. At Lelander, we embrace the concept so much, we’ve built our company around the principle. Ongoing problem-solving, open discussion, and seamless handoffs are part of our DNA. And that’s because it works.
Ready To Experience Devops Firsthand?
This article only scratches the surface of DevOps. To see just how smoothly your next application can be developed, tested and deployed, reach out to Lelander. Our team would love to sit down and discuss your next project.