I may as well have titled this post "I KNEW IT!", as it was my first reaction.

The rather excellent You Had Me At EHLO blog has a good article on Exchange 2010 losing Single Instance Storage (SIS). 

 

First up, and almost as an aside, I've been saying for years that the sweet spot for Exchange is around 100 users.  Maybe 250 at a push.  Its design always felt like that was the sweet spot - as if someone had wanted to build a new MS Mail server, then suddenly realised that maybe they should scale it up. 

  "Exchange 4.0 (and, to a certain extent, Exchange 5.0 and Exchange 5.5) was really designed as a departmental solution."

Couldn't agree more.  It's been crippled by design since day one, and whilst it has improved, it's still crippled by some of those early design decisions.

 

You should go and read that article for some very interesting thoughts from the Exchange Team on storage.

It's an article article full of nice little asides like the quote I chose above.  And like SIS not being something you should factor into capacity planning.  Which isn't news to anyone who had studied Exchange properly, but will probably be news to some of Microsoft's salespeople, PR people, and many of their MVP's and MCSEs out there in the community.

(It's also not a very well written article in a couple of places.  Apparently the Exchange ESE database schema has remained relatively the same for 19 years, but then with Exchange Server 2000....  Wait?  Someone was running Exchange Server in 1981?  Gosh.)

 

But what I really want to talk about is that SIS is gone, and that attachments aren't single instanced either.

 

FORWARDS, TO THE PAST!

 

Microsoft have instead given you compression.  IBM gave us design element and database compression in R8, so the compression bits they talk about aren't very interesting - we have direct comparisons.  In fact, I recently saved around 25% on four archive servers just by implementing R8's compression.  25% may not sound like much, but 25% of ~750Gb is a nice chunk of disk to have back.

 

Anyway, what's really interesting is the strategic directions at play here: 

Microsoft:  Disk is cheap, buy as much as possible and use Retention Policies to keep things under control.

IBM: Disk is cheap, but let's try and use it more efficiently.  Downtime for expanding later can be expensive, after all.

 

It's nice that Microsoft has retention policies, and IBM's policy so far has been to leave that to 3rd party products.  (You can set up automated archiving if you like, which is a crude retention policy, I suppose.) 

 

But I don't buy that storage is cheap.  Even with a SAN to make it cheap to manage, you have to cut the storage, present it, expand volumes - all of which have risk, and the usual way of mitigating that risk is to shut services down whilst you expand your storage.  The individual platters may be cheap, but unless you're 100 users or smaller then there will be costs associated with extending storage.  Not using a SAN?  Well, expanding that RAID array may be even more expensive in downtime and have even higher risks...

And I don't buy that this is all in the name of performance, either.  From Domino 6 to 7, and then from Domino 7 to 8, IBM have optimised their NSF structure and software engine without significant on-disk space increase.  I know that the two aren't really directly comparable, but...  Was ESE really that badly architected that it needed such drastic changes to get better performance?  And wasn't the move to 64-bit with Exchange 2007 supposed to give better performance?  Was that not enough?

 

So strategically, this is becoming an interesting role reversal.  Microsoft is moving Exchange Server to a place where its storage layer can be criticised for exactly what they used to criticise Lotus Domino Server for.  Meanwhile, IBM is giving you more options - you can carry on as you were, or you can have some single-instancing and compression to help you manage storage capacities. 

What makes it really bad for Microsoft is that there is now no defence.  Their best shot is just saying "storage is cheap, and this gives us better performance" - which means IBM can say "Yep, and that benefits us too, and we also have the options there if you want them - at no cost."

 

I've always felt suspicious and somewhat used when Microsoft do their "What we sold you last time is crap, buy this new one which is Not Crap!" dance.

And in a way, the blog entry is not the most interesting thing.  The most interesting thing is the complete lack of cognitive dissonance in some of the comments.  A was good, B was bad.  Now A is bad, B is good.  And nobody's questioning the sudden reversal.  They're just applauding, like the Emperor's new clothes are the best they've seen yet...

Anyone care to take a bet that in a year's time we'll be hearing all our old criticisms of Exchange SIS being rephrased and bounced back at DAOS?

 

IdeaJam rocks.

Not only is it great software, but the idea of hosting a free version so that people can suggest improvements for Domino & Notes is a cunning way of testing the software to death, too!

 

I've decided that I'll submit a few ideas over the next few months.  I have loads of them, but will have to trickle them out.  I'll highlight them here when I come to them.

 

However, when browsing the various Ideas that others have submitted, I often find myself thinking "good idea, wrong way to do it".  It felt, at first, a little rude to turn up to someone's party (well, Idea) and say that I had a better one somewhere else...  But I'm over that, and will be doing it with gay abandon from now on.

 

The first candidate is this idea from Criag Wiseman:

 

It's an excellent idea.  But I wondered - why is the database unavailable, yet the server still responding?  Craig wants to address this from the client end, but can we improve this on the server side to help?

Yes, we can:

 

I'm not planning on discussing all of my IdeaJam ideas here.  That's why IdeaJam has comments, after all!  But I may pimp out some Ideas from time to time, or just comment on the background of an Idea.

 

It's all grist for the mill, after all...

I've been trying to write that.  Really I have.  It's just not happening.  Or, more accurately, it's happening too many times.

My first draft may have been a bit disparaging.  But I  cleaned that up, and managed to make it a more positive tone.

The problem has been that I've kept re-writing it to try and avoid blaming it on politics within Microsoft.  I wanted to keep it on a technical level, rather than speculate too much about the internals of a company I don't actually work for.

It's been very hard.  My current draft is still not something I'm happy with, and I won't publish it until I'm happy with it.

 

So apologies for anyone who was waiting.  It will come along, but frankly this has just consumed all the energy and time I had for this blog, and I've now realised that I need to put this one aside and get something else out of the door occasionally.

 

This has been really frustrating for me.  Especially as it's put me in a "writing about databases" kind of mindset, and left me solidifying ideas for improvements to NSF.  They're just coalescing, trying to distract me from the ESE writing, and generally not helping.

 

*sighs*

 

My brain is full, and planning permission for an extension has been turned down...

 

Here's an interesting article on using Outlook from orbit.

In a nutshell, they build an OST for Outlook on the ground, copy it up to a fileshare on the Shuttle, where the astronauts then use it to handle their email.  The saved OST (presumably with mail in an Outbox) is then copied down and handled elsewhere.

 

In one sense, this is a wonderful hack.  A glorious kludge that gets people their email in adverse conditions.

 

In another, this is ludicrous.  It's forcing Outlook to do things it was never designed to do, and has all kinds of issues because of this.

 

Frankly, I can think of better ways of working remotely.  Naturally, my first suggestion would be Notes - just replicate, baby!

But then, there may be latency issues - which would mean that the fewer actual TCP requests, the better.

Replication may be efficient, but there are many small requests in there, so high latency would suck.  Given the potential for loss of signal too, replication is probably better than POP3/IMAP over the link, but not as good as a file copy - because if you copy one big file, then just about every packet in the send/recieve is nice and full.

(Even copying many small files via rsync/robocopy will generate many small findfirst/findnext requests to the filesystems, so is probably not good.)

 

Given that's the case, set up a little SMTP/POP3 server.  Connect Outlook to that, and work locally within the Shuttle.  Then you can sync with the ground by using tar/gzip on the POP3 server files and the SMTP server queues.  It'll likely transfer a lot more data in a much smaller file than an OST, too.

 

Aw, heck.  There are loads of ways to do this.  After all, UUCP and FidoNet had this licked years ago in the days when everyone used text consoles, and graphical interfaces were a pipedream.

 

But copying an OST - well, it smacks of the kind of rush project that everyone dreads, the "temporary fix" that becomes permanent.

 

NASA IT - not somewhere I'd like to do messaging right now!

 

If you're going to note something, then note it well.

 

So I apologise for the sudden rush of blog entries, but this 20th "birthday" of Notes is something which should be handled properly.

A 20th birthday requires a decent dram, at the very least.  And it just so happens that one of my favourite drams of late is also 20 years old...

 

Well, it'd be rude not to, wouldn't it?

 

Pittyvaich "Limited Edition" 20yo

A limited release of only 6000 bottles, each bottle individually numbered. Bottled at 57.5% abv.

Pittyvaich was built in 1975, to supply the Bells blend.  Closed in 1993, but mothballed and used for some odd experiements (including, it is rumoured, making gin!).  This distillery does not have a high profile, and not many bottlings of it have been made available commercially.

 

Nose: Light oranges, pineapple, grass, perhaps a metallic note. With water, the metallic note disappears and a trace of soft supple leather emerges.

Body: Crisp. sharp, zesty and clean.  Fresh green apples, more oranges.  A light cereal note, somewhat biscuit-like.  Also a little acidic.  With water, the green apples slide into the background and the cereal and orange notes come forwards.

Finish: Zinc, salt.  Quite sharp, but lingers and slowly lets out more of that sweet orange note that was present in the body.  With water, a little spice joins the orange note - perhaps cardamom?

Conclusion: A fine, potent and robust dram.  Amazingly youthful for a 20yo whisky.  It's great at its natural strength, yet incredibly potent.  But if you want to add water, it'll work with it all the way down - it keeps changing and shifting its balance of flavours without ever actually losing its core character.

A truly fine whisky...

 

Let's just remind us why I'm on this fine dram:

Lotus Notes & Domino 8.5 (General availability)

A general release of 145 million licenses sold to date.  Initial release in 1989, but new releases have been available roughly every 2.5 years.

Still in production, with no signs of going away (despite the competition's best hopes!).  We were unable to measure the strength of this release, as it broke our gauging equipment - something stronger is now on order.

 

Purpose: Defines "groupware", but with hints of email communications, collaborative working, remote working and replicated distribution of data.  After time, adds in some further abilities for connecting people.

Capabilities: Email, discussion, workflow, replication and mutiple platforms are all in the early impressions.  After time it reveals stronger development capabilities, web serving, SMTP mail, integrated instant messaging, and a strong platform for composite applications.

Impact: Lower total costs of ownership than competitors and yet also greater capabilities.  After time, flexibility and rapid development shows a real benefit.

Conclusion: Twenty years has matured this nicely, and yet it's not stood still and shows no signs of premature ageing - nor has it lost sight of its core strengths whilst adding in newer capabilities.  It's always capable of surprising you, and with a recent investment in a new production platform it will probably continue to do so even more.

Truly fine software...

 

 

Here's to Twenty.  A good age for whisky.  A good age for software.  Just don't mix the two in a production environment, folks!

 

	Articles
	Blog entries
	Comments