VictorOps is now Splunk On-Call! Learn More.
If you look up DevOps on Google, you’ll find all kinds of articles and guides for being a DevOps engineer or building a DevOps team. But, DevOps isn’t a particular skillset or team structure, it’s a mindset – a methodology for improving the collaboration, speed and resilience of IT operations and software engineering teams. The word is a literal combination of development and operations – metaphorically showcasing the meaning of DevOps – a tightened relationship between the two teams.
But, as DevOps has grown and changed, we’re realizing its implications go further than software developers and IT teams. DevOps principles are leading to improved business processes and are also influencing efficiency across the rest of the business teams. In a highly complex, technology-driven world, DevOps is helping people across entire businesses to create value quickly and drive results – keeping customers and employees happy.
Frustration between software engineers and IT operations existed since the beginning of computerized systems. But, it wasn’t until Patrick Debois encountered his own frustrations with the relationship between system administrators and developers that solutions began to sprout up. In 2008, at Toronto’s Agile Conference, a software developer named Andrew Shafer was set to hold a session called, “Agile Infrastructure.” Patrick Debois was at this conference and decided to attend the session – but Shafer didn’t even attend his own session due to a lack of interest from the community.
But, Debois later found Shafer in the hallway where they talked about the idea of Agile infrastructure. Shortly after this conversation they formed the Agile Systems Administration Group. Then, in 2009, Debois watched a talk from John Allspaw and Paul Hammond from Flickr about facilitating better cooperation between developers and operations teams. It was just a few months later that Patrick Debois held the first DevOpsDays event in Belgium. And, as the post-event conversations continued on Twitter, they shortened the event name to a hashtag, #DevOps – creating the name of the movement that has persisted ever since. (New Relic)
“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.” (AWS)
This DevOps definition from AWS is an excellent overview of everything needed to truly implement DevOps. An effective DevOps culture isn’t a byproduct of one single thing – it’s a culmination of numerous practices and tools. Below, we’ll talk about the six key DevOps philosophies and practices every team should keep in mind when making organizational decisions.
In DevOps, IT teams should get more exposure to systems in development and software engineers should get more exposure to systems in production. By stepping slightly into each other’s realms of expertise, both developers and operations professionals learn more about the services they support. In 2019, developers don’t simply throw code to IT without any configuration or deployment instructions.
The process is becoming highly collaborative and the skillsets between IT operations and developers are becoming more and more blurred. With IT input throughout the development and release process, alongside developer expertise added to operations and incident management, the team can deploy new services and recover from production incidents faster. Exposure in DevOps is much like the common proverb, “Practice makes perfect.” When issues are escalated from IT operations to a software developer, the developer is better equipped to handle the issue by understanding the complete context of the creation and implementation of a service or feature.
With deeper exposure comes greater accountability for the services. In DevOps, accountability for service reliability doesn’t rest solely on the shoulders of IT operations. Developers will also take on-call responsibilities and respond to issues in real-time. They take accountability for the code they write and the services they deploy – developers don’t force IT to try and remediate problems for them. Accountability for reliable customer experiences and uptime is shared across all of the teams. Everyone across the business needs to take ownership of the services they build and maintain while building out channels for collaboration when necessary.
With greater workflow transparency and visibility into operations, developers can better plan out their delivery pipeline. They can see exactly what’s happening in production and write code to support changes to production. Also, the IT operations team can see exactly what’s coming through the CI/CD pipeline and react accordingly. Transparency into internal processes as well as system health will help development and operations teams work better together – before, during and after deployments. A blameless culture of DevOps transparency leads to deeper collaboration, allows teams to find areas for improvement and communicate value to the entire business.
Simple task and workflow automation is a staple of DevOps. Automation allows for teams to deploy services faster, identify issues quickly and resolve incidents in real-time. As DevOps-oriented teams automate mundane processes and configurations, they’re allowed to spend more time strategically building new products and services. Then, if anything goes wrong in production, alert automation and improved communication methods will allow teams to swarm an issue – sometimes fixing the problem before it can even affect customers.
A good way to find areas for automation in DevOps is to value stream map your delivery process and incident management lifecycle. Integrating automation into key human workflows will drastically improve the speed at which you deliver services while reducing the time it takes to recover from downtime.
Collaboration is essential to a powerful DevOps culture because it needs to spread across all of the core philosophies of DevOps. With improved collaboration comes better exposure, accountability, transparency and workflow automation. Also, because every team is built differently, there isn’t one way to improve collaboration across people, teams and business units. Most teams improve collaboration through a combination of organizational restructures, improved communication tools and the implementation of ChatOps automation.
ChatOps is an excellent method for combining workflow transparency, automation and human collaboration in a holistic way. ChatOps tools and practices allow DevOps teams to run commands, scripts and chat with colleagues in a single location to quickly identify incidents and remediate them. Team building exercises can also help coworkers get acquainted with each other, learn how different personalities can work together and drive efficient outcomes in software delivery and incident response.
Continuous improvement is at the core of all DevOps principles. A true DevOps mindset relies on a team that’s constantly willing to try new things, learn and improve. Continuous improvement in DevOps relates to all of the five practices listed above – constant optimization of collaboration, transparency, exposure, accountability and automation within your processes will lead to highly efficient teams. And, continuous improvement leads to better customer experiences while simultaneously building a more humane culture for employees.
DevOps combines the best from Agile software development and the IT Infrastructure Library (ITIL) principles. Instead of allowing IT to make slow, perfect deployments or allowing developers to run rampant and release code at will, DevOps strikes the perfect balance. It allows you to continuously deliver and take on some risk with deployments because there’s a solid plan in place for incident recovery. A good relationship between developers and IT reduces bottlenecks and allows for code to be written and successfully released quickly. Then, if something goes wrong, the team has a plan in place to quickly resolve the problem.
It isn’t a question of Agile vs. DevOps, it’s a question of how you integrate Agile into your DevOps practices. By improving collaboration and allowing IT operations to take on more of a development mindset for release management and incident management, teams can constantly deliver value to customers in a reliable fashion.
When looking around the internet, you’ll find a number of misconceptions about DevOps. Many people think of it as a way to give more responsibility to fewer people or assign DevOps work to a single person or team. But, a true DevOps-centric team doesn’t give more responsibility to fewer people. If anything, a DevOps culture is supposed to take some of the pressure off of people who are handling issues they didn’t even cause – or had potentially never even seen before. So, we wanted to cover a few of the most common DevOps misconceptions we’ve seen:
As I mentioned above, DevOps isn’t a tool or a process. The DevOps methodology is all about shifting an organization’s mindset. Individual’s roles on the team don’t need to be changed and tools don’t have to be used to implement DevOps. While tools and processes can help you facilitate a DevOps-oriented culture, DevOps itself isn’t a tool or process.
There’s a misconception that you need to be a sysadmin and a software developer to work in a DevOps team. But, that shouldn’t be the case. In our DevOps Hiring Guide, we talk about the concept of looking for t-shaped people in a DevOps organization – someone who’s highly skilled in a specific area but has a broad understanding of multiple other concepts. This is because the engineering and IT teams can still be broken down however you need them broken down. But, the individuals need to be able to collaborate across departments and find solutions together. A front-end web developer won’t need to know the ins and outs about configuration management – but they’ll need to understand how their code should be served to the IT team so it plays nice with the IT infrastructure that’s currently set up.
A DevOps engineer isn’t a specific role. You can be a data engineer, front-end developer, back-end developer, etc. who’s part of a DevOps-focused team, but you shouldn’t assign people as dedicated DevOps engineers. If you created a singular DevOps team, you’re creating yet another silo between IT operations and software development – causing more complications with collaboration and transparency.
Many larger organizations think DevOps is only for smaller teams. But, there are a number of large organizations leading the way with continuous integration and delivery at scale. Especially in a world of microservices architectures and highly distributed systems, teams that break down silos and execute well with DevOps will set themselves apart from the competition and drive business value faster. For some examples, check out this article about some larger teams that have done well with DevOps adoption.
While we talk a lot about some great ways to think about implementing DevOps – there isn’t one way to “do DevOps.” It’s a combination of decisions about how you can constantly improve the way technology, processes and people work together. The more your team buys into the DevOps mindset over time, the better your team becomes at identifying areas for improvement and taking action to remediate problems.
A DevOps methodology will help you ship reliable code to production faster – but when something goes wrong, it’s greatly beneficial to incident management as well. A DevOps team can better plan ahead and build a collaborative incident response plan in case of any incidents in production. So, with a solid incident response plan, developers and sysadmins feel better about rapidly deploying new features and services. By analyzing historical incidents in production, DevOps teams can proactively find ways to identify issues and respond faster.
With a more reliable system and delivery pipeline, the engineering and IT teams will get better at communicating with the business teams. They’ll be able to accurately set customer expectations and deliver new services in a timely manner. Then, sales and customer success teams will be equipped with the knowledge they need to go into the field, close new deals and retain current customers. DevOps leads to reliable technical applications and infrastructure but it also leads to a trustworthy business team that customers enjoy interacting with.
Don’t stop implementing DevOps once you’ve done it with IT operations and software developers. Think about how you’ve approached workflows in IT and engineering and how you can apply them to business teams. How can marketing benefit from knowing when features will be released sooner? What can the sales team say to prospects who are eager about an upcoming feature? Think of DevOps as a way to communicate value and execute on projects faster across the entire business – not just engineering and IT.
We hope this brief DevOps tutorial was helpful. When you start looking into adopting DevOps at your own organization, these are some of the things you need to keep in mind. How do you improve collaboration and transparency across workflows from product development to deployment? What happens after code is shipped to production? Who owns the process for assigning alerts to the right person/team and fixing issues in production?
Much of DevOps is about asking questions of your organization and taking steps to improve. Start implementing a DevOps process on your own team to drive value from marketing to IT operations, improve customer experiences and make employees happier.
Learn more about DevOps collaboration and transparency in the incident management lifecycle in our recent free eBook, Why DevOps Matters. You’ll find out exactly how DevOps-focused teams are shipping code faster and reducing incident recovery time.