Sunday, March 1, 2020

What characteristics of an app or protocol make them “wan friendly” or not?

So we have a big meeting with our developer team tomorrow, on Monday, and this is a big deal for us, because we’ve never really had that before. (We haven’t evolved yet into net dev or infrastructure as code, we’re very old school here.)

We’re going through Digital Transformation (I know... I can hear your eyes rolling from here) and part of that is making sure there’s a good User Experience (UX) with all of our new suite.

In the past a lot of our home brew apps have performed horribly over the wan. Add 60-80ms and the user experiences crazy wait times of 2-3 entire minutes for a transaction to finish. If it even does. This has caused a bitter Cold War between our teams where the dev team is screaming “network” and we’re screaming “application.”

Their argument has always been “well it works fine here. So something in the network between here and there is causing it.” Our argument has always been “but all the other apps work great at that location. It’s only this app that sucks.”

When you look at the traffic in wireshark the apps server basically sends thousands and thousands of “tiny packets” to the client. Packets that are mostly header and just a few bytes of data. It’s not efficient. It takes far too long to do anything.

Anyway our CTO has mostly sided with the devs. Which has of course led to nothing getting fixed.

So we finally pushed back hard enough to land this meeting tomorrow and I’m actually very excited about it and optimistic. We plan on reviewing the pcaps with them and showing them what’s going on and why things are taking so long.

But I just wanted to ask the experts here: what other characteristics make an app perform very poorly over the wan? Likewise SQL and SMB are said to be very bad over the wan. Why?

What would you tell a dev to make their apps wan friendlier that you would word it in “dev speak” so they understand it? Because ours has told us before they don’t know what we’re talking about.



No comments:

Post a Comment