When discussing DevOps it’s natural to focus the attention on the one operations team that focuses on application infrastructure. But when you start digging in to DevOps and its applicability to all four operations groups you’ll find that technological shifts in the network – like software-defined networks (SDN) – are just as important to the overall success of DevOps-related initiatives as the spread of software-defined operations going on across the application infrastructure.
One of the intersections of network and app infrastructure operations is around speed. Not just speed of deployment of services supporting applications, which is critical, but also the resulting speed of the application itself. Application performance management (APM) is a less often mentioned concern of those looking at DevOps but it is one with which developers and app infrastructure operations alike are very interested in not just monitoring and measuring but improving.
But here’s the thing: the relationship between the app infrastructure and the network are intertwined when it comes to application performance. Measuring and monitoring in the app infrastructure is all well and good, but it is impacted by network performance. And vice versa. Technically speaking, the app infrastructure folks are going to end up tweaking things like TCP; changing window sizes and timeouts in order to improve poorly performing apps. And they should, as TCP is highly tunable and one of the primary means of changing the performance behavior of an application.
But tweaking TCP has an impact on network performance. TCP is a reliable transport protocol, meaning its particular about thinks like packet order and its very responsible about making sure each and every packet is received. When one isn’t, it resends it. And resends it. And resends it. Retransmit storms contribute to the congestion of the network, which in turn contributes to the need to retransmit, which in turn… well, I think you see the Catch-22 here. While the app infrastructure team is pointing fingers at network operations, the network operations team is pointing fingers at the app infrastructure team.
Both are equally responsible for the problem.
SDN promises, in part, to address the problems associated with speed. Both speed of service deployment (through operationalization) as well as speed of delivery, i.e. application performance. SDN will, ostensibly, provide the means to both recognize application specific performance requirements and adjust, as necessary, the delivery of application data through the network in order to meet those requirements. But what it also implies is the ability to provide visibility into the reason why new routes were necessary. There are plenty of reasons an application might initiate a retransmission storm and some of them are related to the application platform (TCP problems), others to the client or the Internet itself, and still others to the network. Being able to quickly identify what is causing a degradation in application performance gives everyone the ability to react and resolve the problem faster.
That goes to MTTR (mean-time to resolution), a key DevOps-related metric.
But for all that to happen, there has to be some collaboration (sharing) going on between network and app infrastructure operations. There has to be less finger pointing and more question asking going on between the two, and the sharing of collected performance data across the entire application delivery chain – from network to platform to the app itself. SDN provides a means through which such measurements can be obtained and shared with other systems – and teams. This ability is important. Puppet Labs 2014 State of DevOps Report named it a “top practice” correlated with MTTR, and CA’s latest report indicated 19% of organizations adopting DevOps have experienced “Improved quality and performance of our deployed applications.”
Monitoring and measuring application performance is a key component of DevOps, and yet a significant portion of that performance is dependent on and related to the network. Which means app infrastructure operations can’t measure or address poor performance without understanding the network’s contribution to the whole.
SDN “apps” can be one way in which app infrastructure and network operations can gain insight into how apps are performing and how the network is impacting that performance – for good or bad. Whether it’s simply having the data to share or providing an interface into the network to gather the data, SDN has the potential to enable greater collaboration across network and app infrastructure teams.
That makes it an excellent player in the wider ecosystem of tools and frameworks that support the need for monitoring and measurement associated with DevOps initiatives.
