Avalon on XP
Jet And E12
A few months ago, I had a rant here about the fact that Microsoft’s storage strategy was in tatters. The delays in WinFS, the unknown status of WinFS for Servers, the acknowledgement that the forthcoming Data Protection Server is just fine if your definition of ‘data’ is limited to stuff held in the file system, and that it will have no idea about SQL data or Exchange Server in its first release. Well now, there’s a final bombshell.
At the recent IT Forum held in Copenhagen, I had a series of meetings with some trusted senior Microsoft people – I’ll keep them anonymous to spare their blushes – at which I managed, through a process of digging and asking nasty questions, to establish a few things about the next version of Exchange Server. First, it’s no longer codenamed Kodiak – its new name is E12. Second, although it’s been developed to run on top of the forthcoming SQL Server 2005 ‘Yukon’ release, it’s also been developed on top of the existing Exchange Server ‘Jet’ engine. And as far as I can tell, the decision has been made to release E12 for the Jet engine, not for SQL Server.
There are several reasons for this – first, the Exchange Server team wants to have a beta product out in March with a product release later in the year. Given that, the ongoing delays of SQL Server makes it very risky to bring such a huge product as Exchange Server to market on a brand-new database engine. This is a perfectly logical point of view of course. In addition, we’re not sure about the performance of SQL Server when hosting Exchange Server-style data. I’m told by one source that in the benchmarking tests conducted last April, Jet was still ahead of SQL Server in terms of performance. Another source told me that this was only to be expected, because at that point the performance testing had mostly been focused on the RDBMS parts of the SQL Engine, and that considerable tuning had taken place since then on the semi-structured data parts, which include the very areas that Exchange Server would use heavily.
I’m not sure what to make of all this. On the one hand I can see lots of good reasons why the Exchange Server team would prefer to take a careful migration approach, and to ensure that E12’s engineering time and effort is focused on the immediate needs of the Exchange Server user community. Given that point of view, sticking with Jet for one more revision is the sensible, considered solution. On the other hand, I can’t disguise my disappointment. First of all, it blows a hole through what little remains of Microsoft’s long-term storage technology strategy. Second, it means it will be another two years or so before we can really make use of the Exchange Server store in a distributed and joined-up information-mining environment. Worst of all, it clearly shows that Microsoft doesn’t really grasp the simple nature of the problem that’s facing the IT director today.
In a modern Windows network there are four different data platforms that need to be looked after: the file system, Active Directory, SQL RDBMS and Exchange Server. Each of these needs its own backup, disaster-recovery and archiving procedures. That tots up to four times three, in fact no less than 12 quite distinct and different data-management problems that need to be pondered, solutions found, systems tested and staff trained for. Reducing that count by just one platform would knock down the number from 12 to nine in one swoop.
Now we know that Microsoft is considering putting Active Directory onto the small-footprint ‘MSDE’ SQL Server engine for the R2 release of Windows Server 2003 due late next year. So that’s potentially one platform down, although it isn’t a terribly important one due to the fully distributed nature of Active Directory – you’re pretty unlikely to lose all the Active Directory boxes in your infrastructure in one go. Putting Exchange Server onto SQL Server would have taken out a second, reducing the problem space to just two platforms – the file system and SQL store.