Networking in the Age of Containers

Over the past few years, as virtualization and now containerization have increased the density of apps on any given piece of hardware, we’ve become obsessed with the challenge of managing east-west traffic instead of north-south traffic.

For those who are still somewhat light on their data center traffic patterns, let’s recap: North-south is user-to-app or client-to-server or in-and-out of the data center. East-west is server-to-server, app-to-app, service-to-service or simply within the data center.

North-south traffic patterns are impacted by increasing users and apps and things. The more user-app connections required, the more north south traffic you’re going to see. East-west traffic is affected by application architectures and infrastructure technology. When you combine technologies like virtualization and containers with emerging architectures such as microservices, you wind up with an exponential increase in the number of “apps” or “services” that must communicate with each other across the data center.

Basically, the more distributed an application architecture and its infrastructure become, the more east-west traffic you’re going to see.

Compounding this increase is the trend toward “right-sizing” apps. Rather than capacity planning being based on growth projections, capacity is based on what’s needed now, plus a little more. Because of maturing technologies like auto-scaling, we’re able to more efficiently use resources, leaving less compute and network resources sitting idle; consuming budget without producing commensurate value. This is one of the benefits of private cloud, by the way; the ability to better take advantage of resources that would otherwise remain wastefully idle by providing service-oriented provisioning and management that enables real-time usage of resources.

But I digress. The point was that east-west traffic is increasing thanks to architectures and technologies at a rate that likely surpasses that of the north-south increases.

Now, every significant shift in application architectures and technology over the past twenty years has resulted in an equal reaction in “the network.” That’s because the network is responsible for managing traffic no matter what direction it’s going. East-west, north-south, doesn’t matter. Whether virtual or physical, there’s networking involved in making sure traffic gets from where it is to where it needs to be.

The question now, as we’re seeing even greater increases in east-west traffic thanks to the decomposition of applications due to microservices is how should the network respond? More precisely, how should the services in the network respond so as to provide the critical functions (availability, security, optimization) that are required to deliver apps to users or, increasingly, to other apps?

IMPACT ONE: MOVING TO THE APP 

Quite clearly the first answer to this question is that application-affine services must move closer to the app. They can’t remain out there, at the edge of the north-south pattern, and provide services for apps primarily consuming them in an east-west pattern. That’s inefficient use of network resources and the impact of the routing patterns that causes induces latency in application communication. This is where we start to hear terms like “tromboning” and “hairpinning” of traffic patterns that describe a route through the network that requires leaving a machine, traversing the network northward, then returning to the same machine. That latency translates into real business costs in terms of reduced productivity (‘bear with me, my ‘computer’ is slow today’) and increased abandonment of shopping carts and web apps by consumers. That’s what we want to avoid; if the traffic is going east-west, then the services should be in that data path.

IMPACT TWO: OPERATIONAL COMPATIBILITY 

The second answer is that these services like load balancing and web app security must be deployable in operationally compatible formats. In other words, we aren’t going to drop network hardware in front of every app (or microservice) that pops up. So the platforms upon which these services are provided must be virtualized or containerized in order to be operationally compatible with emerging architectures and technologies. They must also be programmatic, providing APIs and templates that enable a DevOps-oriented approach to provisioning and management. Services, whether application or network, need to be orchestratable. SDN, if it can integrate with the tools and frameworks that dominate infrastructure and application operations’ environments, can address this need as well. 

IMPACT THREE: ARCHITECTURE IS CRITICAL

The third answer is that architecture becomes even more important than ever before. Just because one can deploy a networking service on the same host as its application doesn’t necessarily mean it should be deployed there. Depending on what it is and what its interaction with other services (and instances of services) will be, placement becomes a serious issue to consider. Poorly architected load balancing , for example, can result in terrifying traffic patterns that incur unnecessary latency; latency that is directly translatable into business profit – or loss. Any failure (hardware, software, network, storage) in this scenario on the host on which the services are deployed results  in downtime (and ugly downtime, at that) because the services responsible for making sure the apps are available is down, too. In a highly decomposed application architecture (microservices) this could be disastrous if the dependencies on these apps is high.

Careful consideration (architecture) is required to ensure that best practices regarding performance and availability are not ignored by the lure of the most obvious (and easiest) answer.

NETWORKING REMAINS AN EXERCISE IN ARCHITECTURE

Networking is and continues to be an architectural effort. It isn’t just about form factors, that’s just a way to get network resources where you need them faster and more efficiently. It’s about placement of those resources and how it impacts everything upstream in the stack: the network services, the app services, app performance, and ultimately business success – or failure.

Networking in the age of containers and virtualization and cloud is as much about architecture as it is about operations.