I was at Network Worlds ONX (SDN) conference and I heard for
the nth time that network engineers need to learn how to communicate with our
application developer partners.
Learn WHAT, never seems to be answered. So I came to the
conclusion I would need to figure this out myself.
Clearly we are going to have to speak some common language
and develop a way to map the design of an application into network characteristic
we can provision (QoS, load balancing, security, traffic engineering etc.).
I think the knowledge is there (and been there for a while)
so looking at the ancient texts may give me some answers
My first stop is the classic 8 myths of distributed
computing
- The network is reliable.
- Latency is zero.
- Bandwidth
is infinite.
- The
network is secure.
- Topology doesn't change.
- There is
one administrator.
- Transport
cost is zero.
- The
network is homogeneous
See below for some links. We can now begin a discussion as
to did the application developer make any of these assumptions and are any of these
issues in your network.
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
http://java.sys-con.com/node/38665
I also remembered that there are a number of different
interaction models for applications
RPC: Short message the application is waiting for a response
so latency important
Message queuing: I send a message and check back later, latency
not as important
File transfer: a 1 way transmission care about available
bandwidth and is the application written to consume the bandwidth.
Email?
Streaming
Not sure if data base calls are the same as RPC or
different.
The point is that the interaction model between application components
is key to what demands the application will have upon the network. So
understanding the interaction models and mapping them to the sorts of network
services are required to make those applications work seems a good place to
start.
I am not sure if I need to go into the types of SOA, SOAP,
XML etc. I am hoping that people smarter than me can begin to describe what the
right information we need to have as network engineers.