When you're in High School, learning the ropes of Linux or OS/400 or whatever else, IT seems like it would be a pretty relaxing career. Sitting in a comfy office with terminals connected to powerful and largely self-sufficient machines in a nice, cool, datacenter, responding at your leisure to respectful requests for features from users... what's not to like? Sadly, the truth isn't like that. It isn't even close.
There are three big IT Scenarios that will result in hell for you, the chipper young IT girl: the Upgrade, the New Installation, and the Awful Legacy System. The Upgrade and the New Installation are closely related, while the more distinct Awful Legacy System can occasionally make the Upgrade necessary or even a good thing. Sooner or later, every installation of any size - even ones with a few dozen users - will go through one, two, or even all three of these situations.
If you're really unlucky, or maybe just desperate for work, you'll find yourself in the middle of the New Installation. If you get off easy, your employer wants something simple that can be handled by LAMP, or perhaps Windows Server and Active Directory, with minimal customization and commodity hardware. Ultimately, of course, this will probably evolve into an Awful Legacy System, but in the mean time, your job is easy and the system can hopefully be set up and tested in a few days. If your employer has higher requirements for reliability or performance, it's your lucky day: you get the rare and lovely opportunity to talk to one of the three Big UNIX Vendors, Oracle, HP, and IBM.
What a lot of armchair sysadmins on forums miss is that technologically, for most applications, these guys are roughly interchangeable. Yes, Power7 is faster than Itanium, and Itanium is faster than SPARC, but the extent that it matters in the real world is relatively minimal. Most of the tradeoffs here are financial. For instance, IBM licenses software per core, rather than per socket like HP; that means that in the money saved from licensing by going HP, you could potentially get a 64-socket Superdome (HP's high-end) instead of a 32-socket 795 (IBM's high-end). You can also ignore the list prices these companies have posted, since they exist almost purely so that the sales rep can give you 80% off of the list price and talk about what a great discount he's getting you. Ignore anything you find on the Internet, and instead ask each sales rep these questions.
- How much will the system cost, from start to finish, to acquire? Include software, hardware, and services. Do not let the rep bullshit you.
- What are the industry-standard benchmark results for the type of application you wish to run on the system? If you're running an enterprise Java application, demand SPARCjbb. If it's a database server, tell the vendor you want a TPC-C or TPC-H result for the type of system they're trying to sell you. If it's technical computing, check SPECcpu2006. Do not allow the vendor to try to present some kind of proprietary benchmark - both IBM and Oracle are notorious for this.
- Ask to see a roadmap for at least the next five years. Look over it very carefully, since on UNIX systems vendor lock-in is a huge factor.
After you've done this, figure out a quick price/performance estimate for each, and calculate how much having each system on a service contract for the next five years will cost. Go with the cheapest.
The Upgrade is the least fun, especially since it can bring along its friend, the Migration To Another Platform, if you weren't careful enough during the New Installation or if the vendor did something unpredictable. The Upgrade involves a lot of the same things as the New Installation, except you have an application that needs to be ported, and user data, and users that will get very, very upset if there's any downtime. You'll soon find that C is not really a portable language, and that even Java has its own bizarre porting difficulties. Auxiliary stuff - libraries, database components, native routines - will need to be ported, and frequently this is not easy. If you're sticking to the same platform, but a newer box, you can sometimes do an automated migration (HP-UX is exceptionally good at this), but most of the time you won't be so lucky. Even once you're congratulating yourself on getting your PA-RISC/HP-UX application running on SPARC/Solaris, it's not really time to celebrate; in five minutes a user will call and start complaining about how it's running painfully slow, much more so than before, which shouldn't even be possible. Then you get to dig through logs and source code, figure out why, and fix it.
Sometimes, you'll be job-hunting. You'll see a promising post - maybe it will say "Active Directory admin for small network needed," or perhaps "Looking for a laid-back HP-UX guru." Horrors lurk within such things. The interview will go well, you'll sit in your new office, and a higher-up will casually mention that there are no Group Policy Objects and all users are managed with scripts in their Startup folder. The scripts are esoteric and the guy who actually knows how they work left a year earlier. The sinking feeling in your stomach confirms it - you have entered the land of the Awful Legacy System! Meanwhile, users will be sending emails demanding that you pick up their computers (1.8GHz Pentium 4, 256MB RAM) and fix them because Vista is running slow. As you frantically try to get the Active Directory configuration into something resembling usable, calls will start coming in about how a legacy application you've never touched and never been told about isn't working right. "What's the error message?" you ask. "I don't remember," they answer. Things go nowhere good from here.
When I entered the workforce, I thought IT seemed like the coolest thing ever. I survived a year of it with a degree of sanity and without my love of computers burned out, and now I've found my true calling: software development. It taught me skills that I wouldn't trade for anything, but I am never, ever going back to anything resembling a sysadmin job.