Ed Brill

Post a Comment

1. 1  Henry Ferlauto  | 11/8/2010 11:30:13 AM

   I hope IBM's marketing department is paying attention. "Rolling Migration" is one of those great euphemistic marketing terms that brilliantly mask the underlying hard work.

   I wonder if the airline industry could adopt a term like "delayed departure and aircraft migration" for when your flight is delayed, you miss a connecting flight, and are forced to stay in the connecting city overnight.

1. 2  Mark Lepisto  | 11/8/2010 11:54:48 AM

   @2/@6 The beauty of Domino is that you had a choice - upgrade or migrate - heck change operating systems. But I take issue with the idea that you had to "upgrade everybody at once". I in-place upgraded all my servers to Domino 8.5 months before we upgraded the first user. And then we upgraded a pilot group, let them hammer on the system for a while, and then migrated the rest of the company over about 6 months. Notes 7.X with a 7.X mail template works fine on an 8.5 server, users didn't even know the servers had been upgraded. Try that on Exchange - oh yeah, you can't. It's tragic that Exchange admins don't even have an option.

1. 3  Mark  | 11/8/2010 1:08:54 PM

   @4 We are in the middle of a Notes-to-Exchange migration, and we ultimately had to move the Exchange 2010 mailbox servers to physical machines. Clustered mailboxes do not play nice with VMWare and NetApp.

1. 4  Darren http://www.dadams.co.uk | 11/10/2010 4:33:35 PM

   Indeed Ed, talk about spin...

   "Doing this in a backwards compatible way often leads to substantial compromises that leads to a more expensive and less reliable TCO".

   So basically Microsoft put their customers through challenging migration-style upgrades because they want to keep the TCO down. Okay. There you go kids, backwards compatibility, the scourge of IT. There was me thinking Domino added huge value with it's backwards compatibility. So wrong all these years.

   "The migration model is well suited to most organizations because..." - sorry, have to stop that one there because I'm not going to believe whatever words follow.

   "In major releases we tend to make substantial changes to our architecture" ... because they're trying to plug holes?

   Finally, I like the way the blog entries end with "- Perry", like we'd be unsure about who was authoring a blog named 'Ask Perry'. Nice personal touch.

1. 5  Lisa Duke http://www.simplified-tech.com | 11/10/2010 6:04:24 PM

   Ed, I guess if IBM is on the Smarter Planet then we all know which other planet Microsoft is one. ;)

1. 6  Ed Brill http://www.edbrill.com | 11/11/2010 5:57:56 AM
   
   

   A number of comments seem to have disappeared... I can't restore them easily but here they are concatenated.

   I still find the comments on the Microsoft site more entertaining than those here...

   and no response from Perry :-)

   Is this a problem in virtual (VMware) world?

   Pete

   ---

   @5 When you're upgrading and have to deal with the different versions of Domino, Notes, iNotes and the template it isn't that simple.

   ---

   We're in the process of a Domino upgrade and I deliberately picked a migration for some of the reasons outlined here. In particular, an in-place upgrade means that I have to upgrade everyone at once. For a major version upgrade that's more risk than I want - I know that there will be bugs, and I want to use a trial group to catch these.

   ---

   Please don't use the word 'migrate' in a Domino context; Nothing that difficult exists in our world. The hardest thing we ever have to do is 'move' a user to a new server.

   Register Server. Install OS. Install Domino. Start Domino. Answer Questions. Run.

   Click user(s). Choose 'MOVE'. Choose server. Click Ok.

   Done.

   M$ would have you believe that's how simple it is in the Exchange world. It isn't. That's why Exchange's docco and forums are littered with the word 'Migration' for each new release.

   'MOVES' are simple, ask any mom who's ever hired a u-haul truck, 'MIGRATIONS' aren't, ask any whale that's ever dodged Orca's on the way to the Arctic.

   ---

   #2 Mark: At least with Domino you can choose which path leaves you comfortable. For example, I know some clients who had contingency plans to downgrade a server in-place (by delaying the upgrades to On Disk Structure) if they needed to. But if you have another server handy, there's no reason why you shouldn't use it as part of your Domino upgrade. Choice. It's a good thing. But remember: for the Microsoft upgrade, you wouldn't need just one new server, you'd need one for each of the (many) server roles.

   #1 Peter: The attitude on the Planet Microsoft (taken directly from Perry Clarke's comments) is that the new version will have new features that will demand replaced hardware. (Unlike Domino which reduces the server hardware demands with 8.5 significantly.) In a Virtual world, you've simply added another layer to worry about. They want you to have brand new CPUs underneath your email baby, so instead of simply installing Windows on that new hardware, you're going to have to install the VM infrastructure as well. So the virtual world only complicates things.

   ---

   First up : STORAGE

   While I agree that 64 bit can lead to some significant performance increases over 32 bit (because MS screwed up the subsystems) but then saying that to disks would need to be changed every 3-5 years is pretty absurd. Not because they don't but because chances are you are on a SAN. That is in no way connected to the "speed" and "advances" in CPU. The two should be upgradable with little consequence to each other.

   Then, the "difficulty with converting to new formats"? Eh? We call that compact -c.

   Next : ROLES

   "The protocols tend to change between releases"? Wow. If that really is the case then MS are doing something wrong. Ask the IBM Blade guys how many times they have changes the back planes on their chassis. Also for "backward compatibility" talk to the Windows Server teams. They do a pretty good job.

   If you are changing protocols at each major release then you are not thinking stuff through.

   You would think that the way MS force you to increase your server count they sold hardware.

   Still I don't necessarily disagree that server hardware has 1 3-5 yes life span, so if they just said that was the whole reason they would get a whole lot less flak.

   ---

   @5 Mat,

   I used the word "migrate" purely because, as Mark says, of mail templates. We may be able to move someone quickly from server to server, but it's important to remember that Domino separates function from data store in a way that Exchange doesn't.

   For example, if you were upgrading users from R6/7 to R8.x and wanted to use the new out of office agent, then a move to a new server may be a more appealing way of organising this. But the move user AdminP task won't do the whole job - you'll need to upgrade the mail template, and may have other changes (such as policies) that you want to change too, because a new interface on the desktop is often a good time to make other changes as well. A new server may be a more convenient way, on the whole, of managing this.

   But with Domino, as has been said, we have that choice.

   @7 Darren,

   MS doesn't sell hardware. They sell something much more profitable - software licenses for a Server Operating System. And User Licences. I deliberately shied away from mentioning that in my first response, but I must admit I've always thought it most convenient for Microsoft that they manage to do with 2 or 3 Windows servers what everyone else can do with 1 {Windows|Linux|Unix} server.

   Case in point? Sharepoint, OCS/Lync. Plenty of servers in there, and whether you buy hardware or use a VM you can be sure that Microsoft gets their share of the pie...

   I agree that the protocol excuse is rather poor though. As you say, they can do it with other products - if their protocols are that badly designed that they can't do multiple versions concurrently, then it's not something that they should be airing in public!

   ---

   @1 Peter,

   Exchange 2010 is, as far as I can see, supported on VMWare. So in theory, this shouldn't be an issue.

   In practice, I'm not sure I'd want more than two mail servers - regardless of product - on a VM instance at any one time.

   It's been my experience that whilst CPU performance is fine on a VMware, disk I/O performance takes a pretty major hit.

   That can be worked around by using a SAN for storage (if the SAN is supported on both the VM software and for your messaging product) - but it complicates things because you lose some advantages of the VMWare infrastructure (you can't move to another VMware host unless it has the SAN connection too!).

   In a nutshell, I see VMs as being ideal for CPU intensive or low disk I/O activities. But higher disk I/O - as with an RDBMS server or a mail server - are less useful on a VMware machine.

   And this seems to be inherent to any VM solution. I had the same in VirtualBox and in Microsoft's Virtual Server - CPU is just fine, but disk I/O sucks and to get it to a point where it's not useless you have to use raw disks (and lose the benefits of virtual disks) or a SAN.

   So the bottom line is that this isn't any better in a virtual world. You're still looking at an Exchange migration - sorry, upgrade - requiring twice the licenses, twice the storage (unless you want to be constantly tweaking throughout the project) and twice the effort of Domino's simple and reliable in-place upgrade.

   And I doubt that anyone who doesn't leave spur marks on the carpet when they walk into the office wouldn't also want twice the hardware too, VMware or not. You don't want to be the guy who finds out that halfway through your migration you need to buy more VMware boxes to cope with the load...

   You could build new Domino servers and migrate, as Mark @2 has done too. You have that option in Domino. But most organisations choose an in-place upgrade, as it's been proven to be reliable and robust over the years.

   The only advantage that I can see the Exchange model having is that it allows you to better isolate and test for possible faults with third-party add-ins for compliance archiving/virus scanning etc.

   Which is nice, but bitter experience tells me it's no better than a lab machine. Most problems with such add-ins don't show themselves until two days after all 2,000 users are on the server, at which point they make themselves known with a bang... :-(