Infrastructure must balance between applications and the network because otherwise werewolves would cease to exist. In science we're taught that gravity is the law. As it relates to us living here on earth (I can't speak for all you displaced aliens, sorry) there are two gravitational forces at work: the earth and the moon. The earth's gravity, of course, keeps us grounded. It's foundational. Without it, we're kind of up a creek (or an atmosphere, as it were) without a paddle.
The moon's gravitational pull is a bit different in that's it's pulling in the opposite direction. It's pulling upwards whereas the earth's gravity pulls us downward.
Both of these forces are equally important. The loss of either would be devastating. I'm sure there's a made for SyFy movie about that happening. There's a made for SyFy movie about every disastrous scenario we can think of, after all. Just think of what would happen to the werewolves - especially the sparkly ones in teenage novels - if the moon disappeared.
Yeah, they might disappear too.
The data center, too, has two equally important gravitational forces and they, like the moon and the earth, are pulling in opposite directions. The data center needs both too, because we don't want werewolves to disappear.
Why yes, mixing metaphors and creating non-sequitors amuses me, why do you ask?
In the data center, Devops is being acted on by two gravitational forces: the network and the application.
The network naturally pulls devops downward. All the myriad infrastructure necessary to support and deliver an application ultimately require networking. But devops is, at its heart and soul, concerned about enabling continuous delivery of applications. And it is the application that pulls devops upward, toward the higher layers of the stack.
That means the growing number of "devops" focused infrastructure - think application and API proxies, for example - must recognize their role as an infrastructure (network) component while simultaneously exhibiting affinity for the applications it will be servicing.
Not only does the network need to accommodate the application, but it also needs to accommodate the folks who deploy and manage the application. To do that, infrastructure components must become more attuned to the needs of applications and their owners; the network needs application affinity.
As Andi Mann is wont to say, "Devops is people." Ultimately any "network" tool that's designed for devops has to balance between the gravitational forces at work from both the network and the application and offer to devops both the power of the network without requiring certification in twenty or so TLA protocols. It needs to focus on the people, not the product.
It needs to fall somewhere between a "network thing" and an "application." That doesn't mean less networking or network-related capabilities, but it does mean moving toward a more application-like model in which the networking complexity is not exposed. What is exposed to devops and developers, for that matter, is a more application-like approach to deploying and managing infrastructure services. Services like SSL termination, URI rewriting, virtual hosting, caching, etc... are exposed via APIs or a method that's much less complex than existing command line "fire up vi or emacs and edit this file" mechanisms.
These platforms need to be more agile, more scriptable, more programmatic. They need to be more like an application and less like a networking device trying to be software. These platforms need to enable devops to ultimately build devops services that imbue the "network" with the flexibility that comes only from being programmatic. Need to extend the "network" so it routes application requests based on user identity or referring application? A proper devops platform enables that "network application" to be developed, deployed and managed as a service.
That means not only a less complex configuration model, but a programmatic interface that enables devops to extend services into the network to continuously deliver applications.
A platform that can programmatically modify its behavior based on context - real time data about the client, the network, the application, and the request itself - must have application affinity; it must enable direct access to delivery services so that "configuration" can be modified in real-time. If your platform of choice includes the directive "now save and restart so the new configuration is loaded" then it's not programmable, it's not dynamic, it's not enabling continuous delivery the way devops is going to need continuous delivery enabled.
* There are differing opinions on how the loss of the moon would effect human beings. That it would have an effect on the oceans and the rotation of the earth and its orbit is fairly well established,but the actual impact on human beings directly is highly disputed. Unless you're a werewolf. If you're a werewolf, it's bad, period.