Is Client/Server Really Dead?

the-empty-string asks: "Technology fads come and go, but sometimes they do leave behind real systems supporting real business processes. There was a time when 'client/server' was all the rage, and today there are thousands of such systems still in use, happily serving HR departments, providing inventory management, or tracking complex production processes. These days, after 'reusable components', 'three-tier', 'J2EE', and other resume-enhancing keywords, the magic phrase is 'Web services'. Consequently, many companies think they must scrape their existing client/server applications, in order to "move them to the Web". While the advantages of exposing functionality to the outside world are beyond debate, does this mean perfectly good and working applications must be abandoned only because they are client/server, or do they still have a useful role to play? Also, what is the migration strategy you would recommend to your boss or your customer, when these systems have to be replaced no matter what?"

Comments

Re:The client's someone eles's problem

[anonymous cupboard]

Um, which browser?:

1. IE (which version?)
2. Netscape (which version?)
3. Mozilla (not the same as Netscape and also with version problems)
4. Opera
5. ...

You have to QA against each, then there is the Java Runtime, then the OS and the OS version. This, I guarantee you isn't nice.

And then the browser may also be used for general Internet access so requires a quick mandatory update because of the latest security hole. Your only real hope is to differentiate the version of the browser use for application access (and thus has been QAed) from the version used for general purpose work.

Trashing useful apps for buzzwords sake?

[ToadSprocket]

does this mean perfectly good and working applications must be abandoned only because they are client/server, or do they still have a useful role to play?
Depends on where you work and how much influence you have. If management where I work had a say, yea we would get rid of our client/server apps that work perfectly well and go to the newest buzzword compliant kid on the block. (Mind you, we would also go without a pilot or any load testing either, because that's all unnecessary you see, according to management). I still think that you use the best tool for the job, regardless. The end user doesn't give a crap how he gets his info, as long as it's fast and reliable. If you can fit into that model, then more power to a client/server app.

Of course, they also don't give a crap about scalability, but that's because they don't have to deal with it either.

Buzzword Bullshit

[renehollan]

Ya know, that's all it is: bull shit, crapped out by marketting types to sell the "next greatest thing".

Certainly, there are a variaty of ways to distribute an application, when you start to have real compute power at the human end of things, but they're all variations on a distributed processing theme, conveniently placing a "tier" at an architectural point with clean, simple, and few interactions with components at another tier. Hence, three-tier and n-tier applications: they're just particular distributed "sweet spots" particularly appropriate for certain large classes of applications.

In the old days, if we even considered such distributed systems (requiring a PC on a desk, instead of just a terminal), we coded all the protocols, marshelling schemes, and so forth ourselves -- it was an in-house thing. So, yeah, all such distributed applications look the same, from that perspective, the way that all large C or C++ applications "look the same", if well-designed.

But, as particular distributed mechanisms meet large "sweet spots", such as a web browser/server split, they're pushed as the definitive "answer" to man-machine interaction.

And, just as quickly, or shortly thereafter, the shorcomings of a particular popular distributed architecture split become apparent, and the next "model" is pushed as the definitive "answer". The fact that it is tuned to a different class of problems is generally lost on those flogging it, and those buying it. The rest of us just kind of look at it and say, "yeah, so?" -- after filtering through the buzzword muck.

Now it is true, that, as client-server models (and all of these are just that, really) mature and are pushed into use, they are strained to the limits of their scalability, and two-tier architectures give way to three-tier architectures, and so on. So the new tunings offered by the "latest" architectural split does serve to solve new problems, but that in no way invalidates the fact that the "old" architectures did a splendid job of serving to solve the "old" problems.

The frustrating thing, from the perspective of someone like me, having worked with all sorts of distributed systems for close to 20 years, is the notion that one such architecture is sufficiently different from another that the "old skills" are now obsolete: client-server techniques do not transfer to three-tier architectures do not transfer to, what's the buzzword?, oh, yeah, "Web Services".

While the interfaces are new, and the implementations of the various components need to be picked up, a seasoned architect will look at them an say, "yup, that should scale the way we need". However, there is this notion that this can not happen quickly, and new "experts" need to be hired to replace the "old" experts.

Funny, most places don't get rid of their "if statement" C++ programmers when they need "while" statement-, or golly gee, "function call"-programmers. Understanding of standards particular to a given architectural model may be important, but it's such a small part of rolling out a working system, that any competent software engineer can deal with them.

Don't make the mistake a former employer of mine made: contracting out some servlet code to "Java experts"... that had no clue about threading issues because, while they "learned Java", they knew nothing about multitasking issues. Hint: those that understand the latter generally adapt to a different language faster than those that know a single language adapt to other than basic computer concepts. And so it is with buzzwords designed to obscure the obvious.