The Scales of Justice

A couple of decades ago I accepted the reality that my sojourn into the field of freelance photography was, in fact, merely a desert. I wouldn't be the next Ernst Haas. By a somewhat circuitous route, I ended up in the world of RS/6000, AIX, and Progress. The Progress database wasn't (still isn't near as I can tell) particularly relational or even SQL: applications were almost always run through its BASIC-ish 4GL, rather than through its primitive SQL parser. Lots of FOR loops.

I am reminded of this because of this post on simple-talk. A cautionary tale for all those devs out there who dream of Facebook size web apps.

The particular note of reminder was the architecture of Progress: it was client/server in a box. Specifically, C/S in one address space. The engine/parser had one block of memory, and each connection/client got a smallish patch, all under control of the engine. This client patch was attached to the RS-232 wire to a VT-Xxx terminal. Such a design today would be derided, of course. Of course, HTTP these days is being used as RS-232 twixt some web server and some browser over a wire a tad longer, but still just a wire. Not that the young-uns have any idea.

A system that was originally fine-tuned, compact, simple and efficient was inadvertently turned into a 'finely-tuned' system as slow and cumbersome as a tuna in the net, and as lively as tinned tuna. Beyond all the incautious design choices, and the additional mistakes made along the way, I think there's a noticeable moral in this software horror story. These days, scalability is better achieved with a super-optimized and compact single tier web application that is then deployed to some cloud infrastructure. When, and if, it faces high traffic levels, it can then be promptly fine-tuned to cope with the traffic levels it faces.

There's no place like home. Click those ruby slippers together and get the hell back there.