Advanced Distributed Systems Design with SOA, part 2 of N

(This is part 2 of my notes from the ADSD-SOA course. You'll find part 1 here.)

Due to the fallacies we have already discussed, whenever possible, favor in-process execution over remote procedure calls. An in-process call, takes about 10 microseconds to execute. A Remote Procedure Call over the Local Area Network, takes somewhere between 500 microseconds to 1 millisecond, i.e. 50 - 100 times slower than the in-process one. When we step out into a Wide Area Network, we end up with call times of about 50 milliseconds. That is another 50 times slower. Now, imagine that we have a remote object on which we read or write a couple of properties. Not scared yet? What if we put the calls in a loop.

But we don't write code like this, right? Enter Inversion of Control and Dependency Injection. IoC is great, don't get me wrong. However, a caveat of this technology, is that you do not know whether or not your service is local or remote. In fact, that's one of its value propositions. But how can you build a high-performance system without knowing this? When you run local tests on your computer, everything will run fast ... but in the real world? You won't know until you try. Hopefully, that is done before you hit production.

Fallacy 3: Latency isn't a problem

An in-procedure call is a thousands of times faster than a remote call, so we want to rely on such local calls as often as we can. However, when we need to cross the network, we want to bring as much data as we might need with us (so that we don't have to cross the network so often). In ORM speak, this is called eager fetching.

Often times, your performance problems can be solved by your deployment model. Deploy things together that belong together, to reduce latency. As an example: Instead of deploying letting one part of the system call another part of the system over a WebAPI / WCF to, say, perform a calculation, deploy the shared library to that other part of the system where it makes sense.

More servers are not always better. Sometimes, it can be worse as more servers may increase contention on a shared resource. Try instead to reduce the amount of remote calls.

"There are only so many things you can sweep under the rug - latency, availability - before it becomes a bulge."

It's not a shortcoming in the technology's that things do not work. These fallacies were written in the late 70s on Sun's network based file system (imagine how popular these guys were when they wrote them!).

"You can't fight with gravity ... well, not for very long anyway". Eventually the laws of physics will win. You cannot ignore latency.

Fallacy 4: Bandwidth isn't a problem

We have pretty good tools these days for measuring latency. Bandwidth, however, is another story. "Giga" sounds like an awful lot - it sounds like such a big measurement that we don't have to worry about bandwidth at all! However, remember that we - in networking - talk about bits not bytes: 1 Gigabit is 128 MB. Right there, we "lost" a lot, didn't we? Add to that downstream layers and you will end up with 40% utilization of your bits. At raw TCP, you get about 50 MB/s throughput of a Gigabit connection. HTTP brings it down further. Then, you have text serialization...

An average code base has about 20-25 MB/s systems throughput. And remember: It's not only your system that is using those lines! You also have people e-mailing large power point presentations, e-mails with cats ... One of the great things about the cloud and cloud hosting, is that it highlights the cost of the bandwidth - it's expensive!

Code packaging is often more impactful than the code itself. Vertical slices matter.

You can have more than one network at at time (plus virtual networks). You can decide which systems communicate where. A high-priority network and a low priority one. Your system administrator can configure these things.

Networking has gone through the equivialent of Morse's law, but in reverse.

-

(Coming up next: Topology won't change & the Admin will know what to do)