Consolidating email on the Pod
In the long run it's those other capabilities that could make consolidating to Domino a good idea for your organization - because you'll be able to do stuff, like deploy multiple portals concurrently or skip the Active Directory, Exchange, and Outlook upgrades coming with the next Microsoft server release, that just aren't practical in the traditional Microsoft client-server world.
From a quick and dirty porting perspective, however, Domino's simplest use is as the core element in a Microsoft Exchange replacement scenario aimed at consolidating multiple Windows based Exchange servers on one larger machine. The key to this is that you don't have to change all your Outlook clients to do it - according to IBM's features support comparison almost everything Outlook can do in an all Microsoft environment is now also fully supported in Domino.
Domino runs on just about everything too: meaning that your consolidation options include servers running major Windows variants, zOS, Linux, Solaris, and even AIX.
My hypothetical Sun pod, regular readers will recall, costs around 80K and includes the rack, oversize UPS, network gear, disk arrays, and at least one 16GB or larger T2000 processor. That gives it the throughput and reliability needed for the heart of a corporate messaging system - but the question for today is whether or not the T2000 hardware is a good choice for the job?
There's a very interesting three part series by IBM's Lotus performance team: ( Lotus Domino 7 server performance) that bears on this. Look at their stuff closely and you should conclude that the typical Domino server workload is a pretty good fit for the UltraSPARC T1 - high on I/O, heavy on context switching, naturally multi-threaded, and low on floating point demand.
By happy co-incidence, two of the latest filings with the Notes Benchmarking group, notesbench.org, offer just the comparison we need. The most recent of these features a four way, eight core, 3.0Ghz Xeon from HP running Windows/XP Server while the older, from last November, features a pre-release 32GB T2000 running Solaris 10 from Sun.
The results are extremely close. The eight core Xeon achieved a notesmark score of 15,395; the Sun T2000 reached 16,061. HP recorded an average response time of 0.434 seconds; Sun an average of 0.400 seconds. HP's listed total cost was $79,281 or $4.97 per notesmark; Sun's $82,860 or $5.16 per notesmark.
Be aware, however, that HP's pricing is highly suspect. For example, HP's on-line pricing as of February 12/06 puts the basic eight core, 8GB, 580DL/G3 at $36,313, not the $28,044 claimed in Appendix G of the detailed costing report. Similarly HP counts the cost for only four Domino licenses despite having eight cores -contravening IBM's stated policy on licensing cores as processors.
Make the obvious corrections and Sun looks about 15% cheaper than HP before consideration of things like the additional 1,200 watts needed to run the HP. The real zinger lies in something that isn't obvious at all: these results were obtained before ZFS was integrated into Solaris 10 for SPARC - meaning that the same test done today would be a few thousand bucks cheaper and likely to produce a higher notesmark count.
Becoming an expert with Domino is not trivial, but the defining issue in moving from Microsoft Exchange on a bunch of Windows servers to Domino on one UltraSPARC T1 pod isn't technical. It's networking bandwidth: if your Exchange servers aren't centralized now you'll need to spend a lot of effort making sure that the bandwidth your users need to access the Domino server is in place and tested before proceeding.
In my experience most Windows services consolidation projects fail to adequately account for the network consequences of several thousand users doing something at about the same time - in this case checking their email on arriving at work, on returning from scheduled breaks like lunch or coffee, and just before going home. The network may not be your responsibility, and the local network guru may be assuring you that all will be well, but users - and ultimately your bosses - will hold you responsible if your change to the email system causes delay for them.
Bottom line: test the bandwidth, and if it isn't there, abandon the project.
If the network isn't a constraint you probably won't run into anything else that qualifies as show stopper - or even much of a challenge.
A few years ago, for example, when IBM's Redbook: Migrating from Microsoft Exchange 5.5 to Lotus Notes and Domino 6, was written in 2002/3, this wasn't true. At that time probably 90% or more of the complexity in making the transition work was accounted for by the need to run the old and the new systems concurrently during a transition period.
Today, however, that co-existence period is usually unnecessary, and the job comes down to ensuring that your directory services set-up will survive the switch and then using the tools Lotus provides to migrate your user ids and their mail boxes, calendars and folders over a weekend.
Give this simplification a cursory look and you're likely to conclude that it's largely due to Domino's new abilities to let you continue using OutLook clients, and that certainly reduces user hassles and saves you from having to deploy a Notes client, but the big change is more subtle.
What's happened is that hardware change has outpaced growth in file sizes, script complexity, and user numbers -meaning that what took more than a day to do on a Sun 450 five years ago now runs in less than an hour on the T2000.
Five years ago the time needed to run scripts moving a large number of user accounts meant that you couldn't do it in the usual Sunday morning window - and were therefore forced to piecemeal the change and thus to undertake a risky co-existence period. Today you can shutdown Exchange at 2:00AM on Sunday, and have users logging into their new Domino accounts by 8:00.
And there are free ginzu knives too - or, at least, a second hardware corolary: everything, except the core processor, in that pod is redundant - and the processor has a long list of RAS features built in. As a result you can think seriously about skipping failover: not a big deal with Domino, but a nice option in terms of cost saving for both set-up and run-time.
But remember that other Murphy's law: and don't try to go live on Monday with your first attempt at this. Instead, do a few dry runs to make sure that everything works - and even then ensure you have a rollback ready because something will go wrong.