World Class On-Call & Alerting - Free 14 Day Trial: Start Here.
About five years ago, “DevOps engineer” appeared as a regular job title. Since then, activity around recruiting and transitioning existing roles of IT and Quality Engineering into DevOps has been phenomenal. The transition is not a direct move, and there are several considerations to making it a successful role change.
Without further ado, here are the top 5 tips for making the move from IT Ops to DevOps:
Besides end-user support, IT Ops has always had the responsibility of ensuring stability and verifying that networks and systems were safe and secure. To be successful at this, they had to make sure changes were minimized, variables reduced, and consistent end-user processes were in place. It also meant they could lock down everything not directly related to the organization’s daily activity.
In DevOps, this mindset doesn’t work. Instead of regulating, DevOps engineers are stewards of release management and development teams. Their job is to do what they can to build automation and not get in the way of application delivery. They’re motivated to find ways to ensure security and resilience without becoming prohibitive, all while being comfortable with failure and mistakes. In DevOps, no one is waiting for a service ticket. They’re thinking in advance about what they need for development and how to make things stable and secure.
Part of the evolution of DevOps came directly from IT, in the form of ITSM / ITIL (IT service management / IT Infrastructure Library) practices, and infrastructure as code. But, when IT built these practices, they did it based on a very different mindset: to create consistency, automate the creation of documentation and reduce variables.
The practices became an IT monarchy, where sysadmins kept powerful tools to themselves for fear of being unregulated, sprawling infrastructure and ungated orchestration. This is the documentation and compliance mindset.
In DevOps, compliance and documentation are important but should never inhibit automation or be an excuse for not automating. Successful DevOps environments will automate any task repeated more than twice because release velocity is only as fast as the slowest element in the delivery chain. DevOps is all about supporting release velocity without sacrificing reliability.
In the early days of IT, visibility was akin to liability. Even within IT teams, silos were created that limited who could see what and when. But, in DevOps, especially as the concept of shift-left gains popularity with development teams, visibility is a key to success. While visibility still supports issue remediation and detection of potential issues, it also helps developers get ahead of issues by giving them visibility into how applications run in various environments.
This means developers need access to monitoring; even to security analytics. The other essential reason for visibility is because, without it, communication is tough. If you become a gatekeeper of information that could potentially help the rest of the team improve automation and application quality, or resolve issues, you are not a steward.
Application users are not typically IT Ops users. Corporate end-users do not behave like application users. Users of your company’s app are much more critical. They won’t just do what they’re told and you don’t have direct interaction with them as individuals. Your interaction is with your software and your concern is its uptime.
DevOps teams need to embrace the fact that their customers are end-users external to the organization and, in most cases, all they want is functionality. Thus, the job of a DevOps-minded engineer is to support getting quality functionality into the end-user’s hands as quickly as possible.
You’re probably familiar with tooling such as monitoring and incident management which is fantastic because you have a good sense of the mechanics for the key parts of the delivery chain. What you might not realize, however, is that the use case is different. In IT, tooling was often rooted in prevention and tracking.
But, in DevOps, tooling is always configured to support release velocity and application quality. This means some of the tools might be configured differently. For example, providing more context in alerting or monitoring things outside of the normal IT infrastructure.
As you can see, the tips are less about tactics and more about a mindset shift toward DevOps collaboration. That’s because if you’re coming from IT Ops, you are already capable of using the tools, building automation, and technically supporting the environment. What you have to consider are the elements of culture and communication, which are different between DevOps and IT Ops.
Adopting DevOps can lead to faster delivery of reliable services while simultaneously improving incident management processes. Download our free eBook, Why DevOps Matters, to learn more about the benefits of establishing your own culture of DevOps.
Chris Riley (@HoardingInfo) is a technologist who has spent 15 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling. In addition to being an industry analyst, he is a regular author, speaker, and evangelist in the areas of DevOps, BigData, and IT. Chris believes the biggest challenges faced in the tech market are not tools, but rather people and planning.