We should teach the network how to serve the applications. Really?
In a recent blog post Marten Terpstra wrote:
We are teaching our applications how to behave uniformly. Or normal. And that's not normal. We should teaching the network how to serve the applications instead. However demanding or quirky they decide to be.
That’s definitely a noble engineering goal, the “only” problem is that I don’t know many customers who would be willing to foot the bill.
There was a car manufacturer that used that same motto – they would do whatever to please the customer, regardless of how demanding they were.
Source: Wikipedia
Guess what – they were bought by Volkswagen. In the meantime, what most travelers are willing to pay for is this:
Source: Wikipedia
Coming back to networking – ATM’s goal was to provide individual applications with whatever QoS they needed ... and if you've been in this industry long enough you know how well that ended. Solving application problems (or behavior) within the network is as expensive as building custom-tailored cars. No wonder everyone claims networking is overpriced.
We as network engineer maybe should be careful not to overvalue ourselves to the point of being neo-luddites.
The point I'm trying to make is that it's wrong to try to solve the application problems with networking kludges - you always get hurt in the long term.
We should be meeting "application needs" with flexible "network solutions".
Historically it hasn't been possible to find anyone who knew what the network needs of an application really were until after it was live on the network already built based on guesses of needs. If the needs didn't match the guesses there were only 2 options 1) Hardware level redesign or 2) the aforementioned 'kludge' And even when the kludges worked they were just as inflexible to changes in application need as the original design guess.
Then some kludges become over hyped fads.
I see a future where applications can be monitored and the network can respond to these applications even down to the layer 1 level. There are many computer models in other industries and I don't see anything about a network that makes them harder to then model bridges or weather. It just hasn't been done before because the network was so static at a physical level and the applications were dynamic. In such a world it was good enough to guess and over build.
We're not there today. But I think we are starting to see beginnings of this. We're getting to the point that automation in both network and applications are becoming cheap enough to where they can respond to each other, if we just had the right models behind them.
I'm a network engineer today, but if I see automation headed my way, I best understand it, so I'm on the right side when the smoke clears.
(I should probably say at this point my opinions probably do NOT reflect those of my employer)
I could not have said it better than John's response.
Every demand based system in the world has a model of the needed demand. Some crude, some very sophisticated. We can do so much better than throwing bandwidth and even distribution of traffic at the problem. There is no reason the network needs to be as static as plumbing. We have L1, L2 and L3 abilities to direct traffic (heck we use them today, but only in the most simplistic way). And it does not have to be more expensive at all. Just smarter.
My point being, our networks should definitely be smarter, flexible and more dynamic than they are today. But we can never truly meet every applications needs at once and will have to still make compromises and set priorities. But we can get closer ;)
Cheers,
Andrew
And because every network is different, every application mix is different, the user's requirements are different, we need to create a solution that can dynamically adjust to what is best given the resources and needs.
http://www.networkworld.com/community/blog/battle-hypervisor-switch-and-future-networking
How agnostic is the network supposed to be or can it? Are we evolving further where the “plumbing” acts on intelligence in the packet(supplied from the app.) to enhance the app.(network inspects) or is the plumbing overlaid with the ability to act on the app. (in plumbing OS/ASIC or SDN magic) to enhance the app’s service without app level inspection? Another view is does the app. “pop” in the plumbing’s acting upon inspection element or does the plumbing just inspect the apps flow/stream to then “pop” in the data element for the rest of the plumbing to act upon to enhance the app’s service? Then is the app’s services enhanced hop by hop or pre planned/provisioned end to end for flow at ingress(again in plumbing at ASIC or SDN magic).
“The point I'm trying to make is that it's wrong to try to solve the application problems with networking kludges - you always get hurt in the long term.”
Ding a winter! LOL…
One old adage I used to state in the early days was "are you designing your applications around the network or designing your network around your applications? DNP and SCADA type protocols come to mind when used in IP networks.
Philosophical tug always…
Regards…