% fortune -ae paul murphy

Simple cost/benefit and the systems upgrade

Lets start with yesterday's low end example: you have a Sun 490 from a few years ago (4 x 1.8Ghz USIV, 16GB, 2 x 146GB) that's still under support. It works, but it's obsolete - and support costs are outrageous: your predecessor signed up for full 24 x 7 Gold level support at pretty much $8,000 per year - about 10% of the nominal list price when he bought it.

A new Sun 4240 with eight AMD cores at 2.7Ghz will cost you about one year's support if you want the 16GB configuration with 584GB of internal disk, or 18 months of support if you want the 64GB version with 2.3TB of disk - and they both come with full three year warranties, a free OpenSolaris license, and the option of running Linux if you want to.

Assuming that the application is portable, this seems like a no brainer, doesn't it?

Yes and No - As discussed yesterday there are less directly tangible, but more important, issues at stake than simply money - and there are also other options.

If, for example, you're reasonably confident your staff can handle it, there's nothing wrong with going self-insured on hardware support: buy another 490 on the used market (about one year's support money for a mid range unit, at the asking price, from my friends at New Jersey's AnySystem.com); get it prepped in case of emergency, and stop paying Sun. This works: one of my former clients has a mission critical application running under Solaris 2.7 on a pair of 450s - and hasn't paid a cent in support since 2003 because he has a ready to go replacement sitting in a closet.

So lets consider a bigger customer: this one has two IBM p690s (128GB, 24 x 1.2Ghz, upgraded from the p680s first installed) and an IBM external disk store (DS6800FC, 16TB) they're also paying for support on but aren't actually using for the Sybase/ERP application the two 690s are dedicated to.

Sybase doesn't run all that well on the p690s (for disk I/O, multi-board SMP access, and context switching reasons) but runs reasonably well on Sun's "coolthreads" machines. As a result someone willing to pay Sybase license fees on the T5440s could expect to get comparable or better performance out of a pair of Sun 5440s running against a 7420 disk server at a combined total cost, including three year warranty upgrades to "gold" support, of only about eight months of support - and that's at list.

Notice two things about this:

1. that I said "expect to get" rather than "will get" because Sybase ASE is still primarily a PC style stored procedure execution engine and what you saw in actual implementations on coolthreads machines prior to the latest in ZFS flash cache servers was that overall throughput increased relative to Power or Xeon infrastructures, but long stored procedures typically took longer. My guess is that long procedures now go much faster because of the ZFS/Cache technology, but I have no way of testing this.

   Since the code on these particular machines is mostly SQL renditions of COBOL procedures from the original D&B code base I'd expect that the overwhelming majority of users would see significant performance improvements from this change - with most going from average two second response times per client form line to continuous operation (no user visible response lag). If, however, some do see reports that now take more than a couple of minutes get a bit slower you can expect them to scream bloody murder - while the majority will, of course, never even notice that their service has improved.

2. In this particular case Sybase licensing fees are likely to be a non issue because the original sales order specifies license portability to either Sun or HP hardware at no cost. In general, however, Sybase is pricing itself out of the Sun market by at least nominally sticking to the rule that one core equals one CPU for licensing purposes - meaning that a license set for a four way T2 machine with a live replication backup will run well north of a million bucks at list. The MySQL migration tool, in contrast, is free - as is the database product.

More subtly, if you've fallen (as these guys did) for SQL data inversion for an off line datawarehouse, the people who manage that mess will soon be trying to lynch you in public because it will turn out that many of the timestamps they rely on are somewhat artificial and (assuming your ERP/SCM operations run 24 x 7) the new times won't sync perfectly with the old ones - thus introducing a discontinuity into many of their "cockpit" graphs.

Still, we're talking full replacement with new gear including three years of gold warranty support for the price of eight months of the current support on archaic gear - and he can probably sell parts from his p690s for more than the cost of the Sun gear. So, again, it's got to be a no brainer, right?

Yes and no. As I mentioned Monday, the people who put this in, or at least started the process, made just about every possible bad decision: from agreeing to having consultants customize the code to picking a best of breed application architecture, they loaded this thing for failure. And fail it did - in the sense that it took years to do weeks worth of work and they not only very nearly bankrupted the company getting it implemented, but placed the company in a near permanent IT lockdown because users see any move to make changes as an immediate and serious threat to stability.

So should he make the change? Eventually he'll have to: but my advice is that he first line up another job and only then propose a staged transition based on running the two systems in parallel while the IBM stuff is still under support - meaning that he can't use operating savings to finance the change because he won't get them until at least a year into the process - and, by then, he should be well into stage two: finding some better software.

So what's the bottom line on the two cases? On the money, the change argument works for both - as I think it probably works for most people in comparable positions - but money isn't typically the determining factor. Fear is.