A lot of very different definitions of “DevOps” float around the internet, many of which focus really heavily on goal-setting and culture. Sure, all these principles are important, but they’ve kind of become buzzwords. Instead of delving into details, bloggers can just vaguely circle around the DevOps “culture,” go into zero depth and post something completely devoid of meaning ahead of schedule for a bit of extra traffic. It’s a shame, too, since the entire point of DevOps is to mix the development and operations teams, not to set them apart with wonky culture fabrications.
DevOps does, of course, need the right culture, but that’s not what DevOps is all about. DevOps is all about breaking down the wall between developers (the “Dev”) and IT Operations (the “Ops”). Granted, this process requires a cultural shift and strong goals, but those abstract ideas aren’t everything to DevOps. At its core, DevOps is much more about project management, automation, and, most importantly, feedback. Culture is important, but it only scratches the surface.
As app developers, we have a unique insight into how DevOps works. To us, it’s not just a buzzword; it’s a super cool development strategy. That’s why we’re going to clear up some of this DevOps mess: to help people understand what DevOps is, how it compares to all those other crazy development strategies (Agile, CI/CD, etc), and how you can use it to improve your products.
Defining DevOps for App Development
Unlike Agile, there isn’t a DevOps Manifesto (which is part of the reason it’s turned into a buzzword), but we can still put together a pretty solid definition using some software development history. Scotch tells us that as recently as the late 2010s, many organizations had separate development and operations teams. The developers wrote the code and sent it off to operations. Then, operations managed the execution. This got pretty messy pretty fast. Operations wanted to keep code mostly stagnant for a more stable environment, but development wanted to ship changes quickly to start building out new features. Those counteractive goals need to be carefully balanced, and putting one team in charge of each one isn’t the best way to do it.
That’s how we got DevOps: by combining the “Dev” and the “Ops” in one neat-and-tidy package. In a nutshell, DevOps puts the code-writers and the code-publishers in the same room so they can take notes and make changes super quickly. This is super effective because it turns two linear processes into a single cyclical one.
Instead of two separate processes for “Dev” and “Ops,” we link them together into one cycle.
Pretty simple, right?
However, this definition sounds an awful lot like all those other fast-paced development processes out there. What makes DevOps unique? How does it differ from Agile, Scrum, Continuous Delivery, and all those other whacky options?
DevOps vs Agile
Agile is all about putting new versions in front of the client; DevOps is all about using deployed code to plan the new stuff you’re developing.
Agile development is made of things called “sprints.” In a sprint, you get requirements, you design and develop a piece of the solution, then you test it with your audience. That way, if you’re on the wrong track, you’ll find out in a week or two instead of during launch.
Sprints are awesome! We use Agile sprints all the time for pretty much everything: agile development, agile design, agile QA, and more. It’s the single best way to build a product that the customer wants. When you share your results with the audience after each sprint, you can iterate more accurately and build something much more in-line with their desires.
DevOps seems really similar to Agile development (especially because of the circular graphics), but it works in a different way. While Agile puts code and designs in front of the client for review, DevOps publishes code quickly to help plan the next round of coding.
In fact, you can even use DevOps and Agile at the same time. At each step in the agile process, you would have several smaller sprints. Of course, this is a lot harder to illustrate.
This is actually an extremely effective strategy we’ll talk about in greater length later in the article.
But what about Continuous Delivery? What’s the difference?
DevOps vs Continuous Integration / Continuous Delivery
Continuous integration and continuous delivery (often abbreviated CI/CD) is very closely related to DevOps but, again, is not the same thing.
CI/CD is a fast-paced strategy for implementing your code. Continuous integration is all about writing your code so it can be launched at any time. Continuous delivery is all about making tiny updates to your code as frequently as possible instead of doing one big occasional update (check out our handy beginner’s guide to continuous delivery). That seems an awful lot like DevOps, but it’s not exactly the same.
The most obvious difference is that CI/CD is very automation-focused. Sure, DevOps can (and should) be heavily automated, but continuous delivery is synonymous with automation. After all, isn’t the best way to update as frequently as possible to automate your delivery?
Automated processes for deploying your code are called CI/CD pipelines, and they’re often mapped like this graphic from DZone.
Those steps seem familiar, don’t they? That’s because your CI/CD can become part of the DevOps cycle. In fact, many DevOps charts include them, such as this one from intland.
It includes Continuous Integration right there in the middle.
Theoretically, you could put DevOps, Agile, and CI/CD all on the same graphic, but there would be so much going on that it would be tricky to draw. Instead, people tend to map it out like this graphic from DZone.
Agile optimizes the software-making part of the process with lots of iterations and feedback. Continuous integration takes each iteration and integrates it into the system. Continuous delivery adds the release into the mix, while continuous deployment automates the, well, deployment. DevOps links everything back together at the beginning by using operation data to dictate the next wave of changes.
Now, it becomes clearer that all these processes sound similar because they all have very similar goals: to speed up development. But why use DevOps in the first place, and what else can it do other than speed things up?
Benefits of DevOps in App Development
DevOps is built for efficiency, but that’s far from the only benefit. Depending upon how you apply it, your company can benefit in several different ways. Your infrastructure will become more reliable, secure, and performant, while your team becomes more innovative, cooperative, and scale-minded.
Need some proof? That’s understandable. Most DevOps blogs list a bunch of benefits without much evidence. That’s why we’ve taken a look at some super well-made case studies (courteous of Chris Riley at PagerDuty): to identify the biggest benefits of DevOps using cold, hard evidence.
Everyone talks about how DevOps makes everything faster and more reliable, but did you know it also makes the entire process more secure?
Forter demonstrated this extra security when they implemented DevOps strategies. To bolster their automated CI/CD pipelines, they put a lot of time and money into their incident management systems, which could repair a lot of issues for them. By merging operations and development, they built exactly the systems they needed to succeed, resulting in breathtaking security and reliability.
But security isn’t the only boon. Surprisingly, performance improves, too.
Turnitin demonstrates that your system performs better with DevOps. They implemented a system to track and respond to traffic spikes, helping their system handle any number of users. This automated process only exists because Turnitin allowed operations to dictate what gets developed next, resulting in much better software that responds to system needs.
In case performance and reliability aren’t enough, DevOps promises to improve your scalability.
Netflix is the king of DevOps, and that’s part of what helped them rise to power. Their system needs to handle massive amounts of traffic, so scalability is at the center of everything they do. That’s why Netflix went all-in with DevOps. They built and modified their Cassandra system on AWS, using operations to dictate development. This process enabled them to scale exponentially–even in terms of AWS.
While DevOps is not right for everyone, it can be useful for agencies like us. We’re always refining and improving our processes to give customers the best possible experience; however, we do keep some things consistent. At all levels, we try to employ an agile process. We run sprints for everything from development to design and get as much feedback as we can. Of course, we can’t apply DevOps on a small scale, since it encompasses the entire development process, but we embody it in everything we do. Our back-end engineers set goals and priorities based entirely on operations data and customer feedback. You can read more about our app development process here, read some of our case studies, or check out this video.
Every business is different, so our best strategy may not be your best strategy. The best way to find a DevOps strategy that works for you is to experiment. Start with a looser version of Agile or Scrum, then integrate CI/CD and DevOps. Like app development, processes need to be iterated. Continuously integrate not just your software, but your processes. Make changes, test them, and watch your team grow and evolve.