Someone left the following comment on one of my blog posts:
There is a paradigm shift that I don’t think most application developers understand. In a traditional enterprise model, the network is built around the application requirements, now we are saying the application has to build around the network.
I would say there’s no paradigm shift – developers of well-performing applications were always aware of laws of physics.
Honestly, I don’t know when the shift from “we have to use the resources that are available” to “we can do whatever we find the most expedient and blame someone else if things don’t work out” happened as I was off the grid for a few years, but I was definitely surprised when coming back and encountering the servers-following-the-sun madness. After all, if a car manufacturer would claim the roads have to be resurfaced every time they launch a new car to adapt the roads to the flashy new tires they used on the car, they wouldn’t be in business for long.
However, that doesn’t mean the application developers have to know the innards of networking technologies. The anonymous commenter continued:
I have so far seen a set of developers who can’t understand the current dozen choices we give for Load Balancer options and can’t correctly communicate their security needs.
Ahem. Why do you need a dozen choices for load balancers? That unique snowflake mentality makes the network more complex than necessary, and permanently increases your costs. How about sitting down with the developers, documenting the development environment they plan to use, developing a working load balancer (or firewall) configuration while the application developers are still working on the application, and using it as a standardized template from that point onwards.
Finally, continuing with the comment anonymous made:
In my experience developers don’t understand the difference between latency and bandwidth, and are amazed that their application works better on their workstation with a smaller CPU, but with local web, DB and app services, then it does when they split these services across the pond, I just don’t understand how we can bridge that gap anytime soon.
This one is easy to solve – all you need is fifteen minutes analyzing browser waterfall diagrams with them, and there’s probably something in Wireshark that could do the same thing for TCP sessions so they can see how individual components of their application interact.
Insert artificial latency and traffic shaping (WANem is a pretty good tool) and show them how that affects their application’s traffic flows. I’m positive most good developers wouldn’t mind knowing how TCP and HTTP really work (after all, over 45000 people have already registered for my Udemy course).