Slashdot Mirror
How Hard is it to Manage Different Unices?
vrmlguy asks: "Where I work has several Unix-based servers, all running the same vendor's OS. We are getting ready to buy another big server, and management wants to get bids from other vendors. However, our staff is only familar with our current vendor's OS. Yes, I know that any two flavors of Unix are more alike than not, and yes, I know about the Rosetta Stone for Unix that makes it easy to transfer skills. I want to know about the down-side: What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?"
Generally, this is not difficult to do, as long as your admins understand the bases of UNIX. (Vendor-centric admins sometimes don't, as they get dependent on their vendor's tools.)
The problems can arise with:
1. vendor-centric admins who aren't willing to learn
2. different service contracts creating differing expectations of uptime between systems
3. added costs from maintaining multiple service contracts and training on multiple platforms
4. finger-pointing, if the systems interact
5. rewriting in-house tools which are needed on the new platform, but were not written generically before
6. 3rd party licensing costs may differ (if you are licensing the same product on both OSs)
7. dilution of expertise, since your admins will have to be more generalists (this is often overbalanced by the expansion of perspective in problem-solving that comes from broader experience)
Other than that, I can't think of anything off the top of my head which would make this hard. Generally, it is not a problem to do.
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits
What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?
How much of a raise are you asking for?
-... ---
Statement of Bias: I "administer" several UNIX OS versions (Solaris, IRIX, Linux, occasional HP-UX), but in an isolated network with no outside connections (so very little emphasis on security).
Two factors come to mind:
No matter how close the systems are, you will still "loose" time to training (either formal or OJT) requirements for the new system. This may actually be a benefit for your staff (wider perspective, more to put on Resume).
Depending on how much focus is placed on security, you may end up doubling the time required to track vulnerabilities and install patches. Again, this may be an advantage as well since a single-os shop tends to have equal vulnerabilities on all systems. In a multi-os shop an attacker will have to work harder to get control of everything.
It is easist to manage servers from only one vender. Unix makes ti easy to transfer skills, but here is the contradiction: It is easier to manage servers from many different venders and versions, than to manage just one server that is different from the rest.
When you have all OSes the same it is easy because everything automaticly transfers. When all are different it is harder because you always have to remember the correct incarnation of each procedure, but because they are all different you get in the habbit of looking it up each time. When all are the same except for one machine you forget on that one machine that everything is different and you aply the wrong incarnation (ofte with disasterious results, see discussions of killall linux vs hpux on comp.risks) Because of this, the one different machine will get [invalid] complaints often due to these differences.
If you can't stick with one vender, then you should go with many so you are in the habbit of checking the differences. At the very least get some linux (debian, redhat, suse), and bsd (free, open, net) machines in house now, and use them for production. You need to make sure that your admins are used to subtile differences. The other alternative is to just stick with one vender, but not only do you pay more, but your admins become lower quality as they learn only one system. (think of it is a resume builder, you want different systems on your resume!)
The same principle applies to natural and computer languages - the more you know, the better you understand the fundamentals.
How about knowing multiple OSes is good for you? Same logic applies. I "speak" Windows, *nix, MacOS, IOS and even some VMS. Now, I'm not afraid of any computer - I know I can figure out what to do with minimal info available.
If everyone didn't care so much about what the OS was because they were afraid of something new and just chose the right tool for the job, "vendor lock-in" might go away. A whole lot more understanding would come about in the IT field, in any event.
Soko
"Depression is merely anger without enthusiasm." - Anonymous
Money.
You obviously already know that managing support contracts from multiple vendors is going to suck. I would also recommend taking a long hard look at ongoing support charges.
For example, we have both HP/UX and Sun platforms where I work. We have both servers and workstations. For the workstation support contracts on similarly sized machines, there was a world of difference in cost.
The annual fee for an HP C240 workstation was somewhere between $2500 and $3000. The same annual charge for a Sun Ultra of equal speed, was between $1000 and $1500. Multiply that by the number of workstaions you have to maintain, and it can add up very quickly.
The up front cost typically isn't where they get you. It's on the back end. I would research the back end on all of the platforms you are considering very carefully before making any final decisions.
Hope that helps a little.
I think if you were to ensure that all of your systems had the same shell installed or the same version of perl and selected modules you'd save alot of time.
UNIX/Linux Consulting
"What kind of unixes do you run?"
"Oh, we have both kinds. RedHat and Debian.
Hire better admins. They are out there, and a lot of them are unemployed right now. Any problem in an organization that persists past a few days or at most a few weeks is a management problem.
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits
It's always more effecient to stay with a single, homogeneous environment.
Hasn't the general consensus on slashdot been that a monoculture is a bad thing?
Microsoft uses the same reasoning (higher TOC) as a reason to move from whatever blend people use now to 100% Windows...
Seeing as how I'm a senior admin (who *can* script), in a team of 5, for a major transportation company, I wonder if you're my boss? *grin*
-- "Other than that, how was the play Mrs. Lincoln?"
Yeah, basic management is similar. HOWEVER: maintaining multi flavors of unix is quite expensive in terms of admin time and effort.
Think patches. Now you have to track multiple vendor advisories, handle patch management, what does the patch break, depend on, etc.
Next comes config changes. No longer can you write a simple script that makes the change on all boxes, you have to support multiple scripts, or write scripts to handle the ideosyncracies.
Third comes binary compatability. What I generally do is build a local set of binaries for all the specialized stuff. They can either be blasted across all systems or mounted via NFS. With multiple versions / flavors of the OS, work gets doubled, tripled, etc. What used to be a 2 hour task turns into a day long task.
Can't forget about security. What you do for one system you have to do differently for another. Different tools, binaries, rc scripts, etc.
The bottom line is that if you needed 4 people to support your current single OS environment, you may need 5 or 6 or even more when you go multi-platform.
I ran a shop where we supported Win98, NT4, Win2000, Solaris 7 & 8, RedHat Linux, FreeBSD, Macos9, MacOSX, and a smattering of other OS's for 500 users. This get's non-trivial Very fast.
1) You can install the same shell on just about all UNIX's. Most people where I am prefer tcsh as it has some nice features.
2) You can standardize on scripts, either use csh (blah) or sh. We prefer sh as it is found on just about EVERY unix (Sun, HP, AIX, BSD's, Linux).
3) Avoid vender extensions to the basic shell. HP has done some aweful things there in its bourne shell and they are not compatible with Sun and in some cases Linux either. I.E. Always use `cat foo` and not $(cat foo) in sh scripts. There are other things like that.
There are problems in supporting more than one UNIX, but there are also workarounds if you do it right.
Only 'flamers' flame!