> I'm wondering about this. I'm a z/OS person with some Linux knowledge. > But we don't run Linux on z around here. In the Windows world, the > mantra is generally "One server, one function". On z/OS it is the > opposite of "one server, lots of functions". How does Linux, in general, > stack up on this scale? It is better to have multiple guests, each doing > a specific job. Or is it better to have multiple functions in a single > guest? Yeah, I know, "it depends!". I am fairly sure that if a Linux > system is very busy, that it would be better for it to be "stand alone". > But is the same true of low activity functions? No, I don't have any > examples of a "low activity function", maybe simple email.
IMHO, it's more a matter of how difficult configuration management and tooling are in the different environments. z/OS has good configuration management tools that make it fairly easy to maintain multiple applications and configurations and keep it all straight. Linux (and most Unixes, other than AIX) isn't nearly as well developed in that regard, so it tends to be easier to separate the apps onto separate boxes rather than sort out all the details that may not be well documented or supported. I think the physical box cost is no longer the issue; it's the human cost of managing the configuration over time that tends not to get the attention it deserves. We're also seeing the actual marginal cost of the environmentals finally get some fair consideration now as well, so that may drive a different discussion than in the past. > Also, what do ya'll think of VMWare's "appliance" philosophy? I.e. > instead of having a generalized Linux (or other) system which can do > many things, each "appliance" does one thing and is specialized to do > that only. When you want to upgrade, you replace the entire appliance, > OS and application, as a single "black box". It's hardly a new idea. VMS was shipped as total replacement for decades, allowing generations of people (grad students everywhere) to manage pretty sophisticated environments without dedicated IT skills. You were pretty much told to keep your stuff off the system disk and have a additional disk volume handy to use to clone your boot disk, overwrite it with the new service, and boot from the alternate to put the service into production, and that's what people did. We did manage to get to the moon with only a few mishaps, so obviously space science thinks the model works. 8-) Separation of vendor code and user data is always good design, and providing a pre-tuned, preconfigured system is an very viable attempt to address some of those configuration management tooling problems. It also tends to discourage local tinkering if you know the next version will destroy those mods, which also makes support simpler if you can eliminate variations in configuration (eg you always know what OS, what patch levels, what software, etc, etc). Personally, I like that model very much. It's a lot simpler to maintain, and all the responsibility is on the vendor to make things work properly (as defined by what the application is supposed to provide). It does put the onus on developers to properly separate code and data, but quite frankly, that's overdue anyway. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
