Bursting The Developer’s Bubble On The Path To DevOpsSeptember 24, 2020
Elik co-founded BigPanda with a vision for enabling companies to pursue fully autonomous IT operations.
Organizations that remain competitive are those that are willing and able to adapt quickly, and for many, that means transitioning toward a DevOps operational model. In simple terms, DevOps essentially means software developers are responsible for operating the applications they develop instead of a centralized IT operations group, such as a network operations center (NOC), for example.
In my past, I have led a development team and later made the transition to lead an IT operations department. This can’t be overstated: The difference between these two environments is night and day. Getting to a point where application developers can truly own the operation of their applications and start thinking about it as IT operations people do is a very big shift. With this in mind, I understand why many companies are struggling to get there and why it takes a long time to do so.
In the end, the traditional developer’s main focus is code, which is the heart of any application. The developer’s general day-to-day consists of opening their code editor, authoring code, compiling it and testing it. Once a version of the application is ready, they package the code and hand it over to IT operations to actually deploy and operate it. This is where the traditional developer’s job is done. In many ways, the integrated development environment defines the traditional boundaries of their world.
Code Doesn’t Exist In A Vacuum
While this sounds solid on the surface, there is clearly a huge ecosystem of other factors that surround code. First, code runs within an operating system, and that operating system is often hosted in a virtual machine (VM). The VM typically runs in a physical server, which, in turn, is connected to network and storage devices — all of which run within a data center. This creates a large web of system components that can affect the performance and uptime of an application just as much as its code does. Unfortunately, many developers have a very shallow understanding of these components.
There is another aspect as well: how code is delivered to production on an ongoing basis. How do you make sure changes happen with little or no downtime for your users? For most organizations, this is a complex process involving many moving parts. So when we go back to the idea of developers not only owning the application code but also operating it, we must understand that they first need to vastly expand their current view of the world. We need to accept that it’s going to be a long uphill battle to get there.
In the traditional model, developers are somewhat cushioned. They’re in a bubble, so to speak, and in order for them to move to the DevOps model, they need to burst that bubble and expand their scope. Developers need to be aware of all of the moving parts in this ecosystem that surrounds their codebase.
Transparency, Tools And Personalization
One of the major keys to understanding these moving parts is transparency. How do you gradually get your average developer to start thinking about this full ecosystem — exposing them to signals from the many different tiers of the stack, including the network, virtualization, cloud and storage? I advise leaders to start by ensuring there is one tool that consolidates all monitoring data across the stack and requiring that developers have full access to that tool. Revealing to developers the entire ecosystem in which their code runs can quickly burst the “developer bubble” described above.
The second major key is that most developers, by nature, are tools-driven. For DevOps, this means tools that enable CI/CD, on-call rotation, real-time chat and event management. The sooner you equip your developers with the right tools to support a DevOps model, the easier your organization’s journey should be. In my view, organizations that establish SRE functions or centralized “tools teams” are doing it right.
My team works with one of the largest SaaS vendors in the world. Initially, it implemented event management just for its NOC, with 30 people using the tool. When the enterprise shifted toward a DevOps model, it started creating dedicated dashboards for application teams to give them access to all of the alerts, topology and change data from across the stack. The teams actually enjoyed getting visibility to all of this data, especially since it was already normalized into a consistent language and correlated to reduce noise. Eighteen months later, that company had more than 900 employees using the tool regularly.
Another thing to consider is personalization. Centralized IT operations teams have a horizontal view of an organization’s infrastructure. They see operational data across all of the different teams and business units, which results in hundreds of thousands — if not millions — of different events and signals they have to track on a daily basis. In contrast, a single development team only cares about the part of the infrastructure that affects their applications. They need a verticalized view that concentrates on specific business services but does so across all layers of the stack.
In my experience, the path to DevOps is a challenging one for most enterprises, but it can also be immensely rewarding. The right mindset around transparency, tooling and personalization can get you far.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?