I've matured enough in my career that I don't generally spout off against Microsoft unless there's a really good reason.
I have a really good reason.
The company I work for uses Exchange server to handle their mail. I don't use Windows, so I don't use Outlook. I use Thunderbird, which is an excellent mail client. The problem is that Thunderbird doesn't directly support any of Microsoft's not-quite-standard ways of accessing Exchange server directly. So my company IT department, bowing to the inevitability of Linix and Mac OS users, has turned on IMAPS and smtp with ttl to support us non-Outlook users.
The problem is that the IMAPS implementation is horribly slow. I keep my email inbox trimmed to less than 100 messages. In order to do this, though, I have an Archive folder that has thousands of messages. Moving 50 messages from Inbox to Archive can take 3 minutes--an unacceptably long time. Moreover, opening the Archive folder can take more than 5 minutes, despite the fact that the folder index is locally cached.
These issues aside, though, it's the sheer inconsitency of the performance that drives me truly insane. Usually, mail flows into the Inbox just as you would expect--a new message arrives, you click it and you read it in the preview pane. Sometimes, though, you click it and the preview pane doesn't get updated. You have to click 'Get Mail' and have the message fetched again before it will really show up.
Because I manage people, our Oracle system sends me emails about their timecards. At the very bottom of these emails are handy links so that I can approve or reject a timecard without having to log on to the Oracle web interface. 75% of the time, the entire message cannot be retrieved from the server, and I can't see these buttons. Not 100% of the time, mind you--75% of the time. It's not like the message is significantly different from one time to the next--in fact, they're invariably exactly the same expect for dates (salaried employees).
There are numerous other headaches, all related to IMAPS and all truly annoying. I've never encountered this many annoyances when working with a bog standard (as defined by the IETF) IMAP or IMAPS server.
Tuesday, May 27, 2008
Monday, May 26, 2008
Virtually weird...
We're using virtual machines, created and managed by Virtual Box, to create a test environment. Rather than have multiple machines that mirror the multiple deployed machines, we're creating three machines on one hardware platform. It's a common model and an excellent example of how Virtual Box and tools like it can be used.
There's a lot of parading about with regards to virtual machines. There's a common belief that virtual machines are a panacea--a way to consolidate multiple pieces of hardware onto a single hardware platform. The battle cry is raised because this is seen as a way to save money by reducing the amount of hardware. Organizations are jumping on the bandwagon and joining the parade in droves. But does it all make sense?
There are certainly situations in which having virtual machines not only makes sense but saves money. The situation we're involved, for example, is a classic case: rather than replicate a bunch of deployed hardware, we're using virtual machines to replicate a deployed environment for experimenting and testing. Before jumping into virtual machines with both feet, though, you need to ask yourself a few questions:
1) What problem am I trying to solve? If it's money, realize that virtual machines may only give you the appearance of saving money. We'll get to the reason in a moment.
2) What am I expecting? If you're expecting multiple virtual machines to have bare metal performance, you're going to be disappointed. Set your expectations up front.
3) Do I have a battle plan? It's nice to think that installing Virtual Box or VMWare is the answer to all your problems, but you'd best be prepared for the eventuality that things aren't going to work out the way you think.
Saving money shouldn't be anywhere near the top of your list for implementing virtual machines. You need to have a hardware base that's highly available and extremely reliable, otherwise, you've just created a huge, single point of failure. You also need hardware that's powerful--more powerful than if you used a single machine. A single platform that will handle, for example, a web server vm and an SQL server vm would probably cost you more than two pieces of hardware capable of running each function at the required level. Furthermore, if you're going for reliability, you may want separate machines anyway--multiple web servers, for example, add a level of robustness that you simply won't get from multiple virtual machines.
Don't just join the parade cause it looks good and is going by. Think first, then join in. It is really a lot of fun.
There's a lot of parading about with regards to virtual machines. There's a common belief that virtual machines are a panacea--a way to consolidate multiple pieces of hardware onto a single hardware platform. The battle cry is raised because this is seen as a way to save money by reducing the amount of hardware. Organizations are jumping on the bandwagon and joining the parade in droves. But does it all make sense?
There are certainly situations in which having virtual machines not only makes sense but saves money. The situation we're involved, for example, is a classic case: rather than replicate a bunch of deployed hardware, we're using virtual machines to replicate a deployed environment for experimenting and testing. Before jumping into virtual machines with both feet, though, you need to ask yourself a few questions:
1) What problem am I trying to solve? If it's money, realize that virtual machines may only give you the appearance of saving money. We'll get to the reason in a moment.
2) What am I expecting? If you're expecting multiple virtual machines to have bare metal performance, you're going to be disappointed. Set your expectations up front.
3) Do I have a battle plan? It's nice to think that installing Virtual Box or VMWare is the answer to all your problems, but you'd best be prepared for the eventuality that things aren't going to work out the way you think.
Saving money shouldn't be anywhere near the top of your list for implementing virtual machines. You need to have a hardware base that's highly available and extremely reliable, otherwise, you've just created a huge, single point of failure. You also need hardware that's powerful--more powerful than if you used a single machine. A single platform that will handle, for example, a web server vm and an SQL server vm would probably cost you more than two pieces of hardware capable of running each function at the required level. Furthermore, if you're going for reliability, you may want separate machines anyway--multiple web servers, for example, add a level of robustness that you simply won't get from multiple virtual machines.
Don't just join the parade cause it looks good and is going by. Think first, then join in. It is really a lot of fun.
Subscribe to:
Posts (Atom)