There’s no shortage of conversation online about DevOps. If you search Youtube for DevOps videos, there are millions of results! It seems every B2B technology company has at least one blog about DevOps on their site– and now we do too.
With so much discussion on this topic, one might expect wide adoption of DevOps. But this is not necessarily the case.
Our clients have varying levels of understanding and practice of DevOps principles. For some who are building a new product or rebuilding an existing product, we may be the first to introduce DevOps principles to their development team. Other companies believe they are already using DevOps practices, but their development team’s reality looks much different. There are also many misconceptions about DevOps, which means companies aren’t gaining its full benefits.
What are these misconceptions? How do you know if you are doing DevOps “right”? What does having a DevOps practice really mean? Let’s dive in…
The roots of DevOps misconceptions
In the early days in the computer industry, it was expensive to create software for two reasons: the infrastructure and the process for writing code. Companies were protective of their infrastructure; broken code could be a threat to the stability of infrastructure important to other parts of the business. Safeguarding their investment required rigor and discipline in the change management process. The goal of protecting shared infrastructure was critical, and this led to lengthy – and costly – software development processes. Companies embarked on projects following the waterfall model of development. These projects attempted to plan for all needs ahead of time and to rigorously test systems before introducing them into shared infrastructure.
Development organizations identified specific people to manage changes to the infrastructure. This group of employees, the Operations team, was the gatekeeper. Once the development team completed the code, the Operations team needed to verify that it was safe for the infrastructure. Operations alone knew how the infrastructure worked and took the code the last mile from the developer to the world. This approach led to slower and more expensive development cycles due to the handoffs between the two teams, but it was justified to ensure the stability of shared infrastructure.
The Internet motivated software development companies to work differently. Developers had access to new tools to test and release their code and they adopted agile development processes which made code changes much quicker. This brave new world of development made it possible for developers to interact with infrastructure in a fundamentally different way.
The infrastructure also changed. Companies no longer needed expensive infrastructure to host all software systems. Every project could lease its own cloud-based infrastructure for short durations to develop and test software and dedicated infrastructure could be devoted to each project in production at low cost. Developers could acquire and configure infrastructure by simply writing and executing code. DevOps evolved as a set of practices to take advantage of the changes in development and in infrastructure.
DevOps in name only
So why does this history matter?
The first common misconception is that DevOps is a specific role: that it’s one person or a team. Sound familiar? Companies who haven’t truly made the leap to DevOps often hire someone as the “DevOps” manager and replicate the historical division of responsibilities between developers and operations staff. In this model, one person is in charge of the infrastructure and holds the keys to the automation and code that makes sure the products get from the developers’ computers to launching on the internet. If that person or team is busy and can’t make it happen, they are the bottleneck and the product doesn’t launch.
Operations doesn’t need to be one person or one team anymore, but can be part of the development team’s skills and responsibilities. Developers can learn about the infrastructure and write code for both the product and infrastructure. This shift works well with an agile development approach and benefits their organization. Modern DevOps practices help you launch products more quickly. If any developer on the team can build, test, and then release code, teams can work quickly to get new products or features to market. They don’t have to wait for the Operations team or a DevOps manager.
Building the foundation for DevOps
The second common misconception about DevOps is that transitioning to DevOps is mainly about re-organizing resources. When organizations buy into the DevOps philosophy, they are often eager to take advantage of the increased speed to market. They are ready to turn the switch and start following its practices. They often miss what makes the move to DevOps successful. It requires more than just combining the Operations and Development teams into one team.
When Operations and Development teams have been siloed, developers may not know the architecture of the production environment. They first must learn how production works and how they can write code and build automation for that environment. We’ve encountered companies whose Development and Operations teams hadn’t built a shared understanding of the production infrastructure. When this disconnect happens, developers make assumptions about how production works. The Operations team must then rework code, or build accommodations to make the code that worked on a developer's laptop function in real production infrastructure.
When transitioning from a traditional Development and Operation model to DevOps, leadership needs to enable and support shared ownership of and knowledge about the production environment. As the two teams join forces, these learning moments can come during sprint reviews and demos. Dedicated time can be built into a schedule for walkthroughs and cross-training. No matter the process, Development and Operations need to build a shared foundation of knowledge first.
Making the transition to DevOps
After working with clients to build new digital products, Presence often helps them develop their internal teams to support the product going forward. We may help them identify and hire resources, as well as train their existing resources in new languages, processes, and frameworks for development. DevOps is a perfect example of one of these practices that clients can incorporate as a new approach to development.
DevOps is as much of a culture change as a procedure change. Organizations need to build a structure and mindset that supports DevOps. From a process perspective, shared code and architecture reviews can ensure knowledge about infrastructure is regularly disseminated. From a resource perspective, developers need to have access to documentation and training on operations and infrastructure. Software and techniques for managing infrastructure need to be shared with the development team so that developers learn and apply their knowledge appropriately for their role and skill level.
Once these pieces are in place, keep your eye out for developers who are champions of DevOps. They will help identify when additional training and support is needed and encourage the team to continue to expand their DevOps practice. For example, on a recent project, one of our client’s developers proactively recognized that he needed to understand how the production environment worked to effectively build a new piece of functionality. He learned about it, built and then deployed the new feature using this new knowledge of the infrastructure.
If you are looking to build a digital solution and empower your internal team to support the product with modern DevOps practices, reach out to us to learn more.