There are days when the jargon coming out of container land makes your head spin. With each new capability or feature offered by related solutions – service mesh, orchestrators, registries – seems to mandate a new term or phrase. That phrase often makes sense to DevOps but evokes a squinty, confused expression from NetOps.
Kind of like the one you make when I ask where the nearest bubbler is. You call it a water fountain. In Wisconsin, we call it a bubbler. Same thing, different term.
It turns out that a lot of the ‘new’ capabilities and features related to scaling containers internally and in multi-cloud scenarios are really just water fountains that DevOps is calling a bubbler. This clash of colloquialisms can cause friction with NetOps as containers continue to move into the mainstream unabated. Even if container clusters maintain an isolated, mini-cloud like existence in production, there are still points of contact with the corporate network over which NetOps continues to reign. And invariably NetOps and DevOps are going to have to work together to scale those clusters securely in a multi-cloud world.
Ingress Controller
Latency-Aware Load Balancing
Multi-Cluster Ingress
These aren’t the only terms to crop up, nor are they the last. They are the most relevant in terms of functionality and capabilities “in the network” being subsumed by DevOps. Some of these will need the attention of NetOps as they move into production environments (like Multi-Cluster Ingress) and others will not – latency-aware load balancing inside container environments is likely to remain the purview of DevOps, though its good to have an understanding during discussions on improving performance or availability.
There’s a cultural component to DevOps that’s often overlooked or outright ignored. As the movement continues to make its mark on NetOps and traditional network operations slowly but surely adopts its principles to achieve an agile network, communication becomes critical. That means finding common ground. Understanding each other’s jargon can be a good first step toward building the more collaborative culture necessary to ensure that application deployments are as fast, secure, and reliable as their delivery.