IT Leaders Need to Engage in and Embrace DevOps

IT practitioners are a hands-on kind of lot. DevOps as a cultural transformation is often not tangible enough for those who are tasked with deploying apps into production and maintaining their availability, security, and performance. But the reality is that the cultural shift – the breaking down of inter- and intra-group silos – must happen, and happen sooner rather than later. 

This is particularly true when it comes to the impact emerging trends and architectures have on the network.

Many network-focused leaders and practitioners aren’t paying as much attention to the changing app architecture landscape. The move toward APIs and microservices, for example, is rarely something we really discuss in networking land aside from the fact that our infrastructure, too, has an API. Because, SDN (or SDDC).

But they need to be aware of these changes and how they will (not if, but will) impact the network and the delivery of those applications to demanding consumers and coworkers. Even what appears to be a wholly application architecture decision can turn out to have a significant impact on not only network architecture but network performance and requirements. The decision whether to go with multi-tenant or single-tenant microservices, for example, significantly impacts network services from security to basic routing and switching. Failure to recognize architectural decisions regarding the use of HTTP/2 or HTTP/1 in conjunction with microservices can cause significant issues in the network and drag down performance.

Developers have a growing awareness of the impact of their architectures inside and outside their domain. Service latency (the time it takes two services to communicate over the network) is a well-understood problem in a highly distributed application architecture. What developers aren’t aware of is how the network (and its stack of services) can assist in mitigating the negative impact on performance (and resiliency) of such an environment. 

That’s what networkers know.

The problem is that networkers aren’t involved until eleventy-billion microservices are being pushed into production. They weren’t consulted, and to make suggestions at the point they are engaged potentially means significant rework in the services or application. Even a simple change interpolating scalability into the network rather than internal to the app becomes a nightmare. But had the services been architected with network scalability in mind, well, this would be a smooth operation.

But they weren’t, and those 9 out of 10 executives feeling pressure to get apps out the door faster? They’re feeling even more pressured because it takes time to make the kind of changes necessary to the network to deliver that many interconnected, interrelated, interdependent services.

There are four ops in IT: infrastructure, network, storage, and security. And all four silos (or towers if you prefer a more medieval metaphor) must build bridges between each of the others that foster collaboration and communication earlier in the development cycle. Collaboration on architectural choices should be made during design not deployment. And that collaboration may need to be initiated by leaders who have the visibility into each organization to know when new technology and architectures are being considered.

DevOps isn’t just about automation – that’s a tool and a technique to achieve a goal. Automation can play a significant role in reducing the burden on those tasked with deploying the services necessary to deploy and deliver apps so that it frees up experts across all four operational domains. Frees them up to engage in greater collaboration – sharing – between orgs in order to improve the scale, performance, and security of the applications central to the rising app economy.

Business success – and growth – depends on collaboration across IT not just in the trenches, but at the leadership table.