james kahn's scratchpad
a blog on technology – cloud computing, software and strategy

I’ve been pretty quiet on the blog recently, but very busy elsewhere. At Idea 11 we have released a new white paper on implementing Citrix XenApp. Check it out if interested.

A video of my talk from Ignite Brisbane is online. Watch it here.

Ignite is a short presentation format where you have 5 minutes to talk on a topic, with 20 slides that auto-advance every 15 seconds. It’s fun, interesting – and not to mention a very different presentation format to the 30 – 60 minute talks I’ve done previously.

There are far too many guides on the net about running multiple versions of IE on the same machine. And most of them are a pain in the ass to set up.

Here’s something I bumped into today: Spoon’s Browser Sandbox. Spoon have a plugin that can launch all sorts of applications from your browser. It streams virtualised application packages to your PC through the browser. A couple of clicks and IE6 – or any other application they have in their portal – will launch.

This is probably the single best use of application virtualisation that I’ve seen in the wild. It’s the kind of “just works” technology I love. Great for web developers or occasional hacks (I’m in the latter category).

And just for the hell of it – here is a screenshot of Firefox (running natively), IE8 (running in a Windows VM via VMware Fusion) and IE6 (running in the VM with Spoon) all on my MacBook Pro:

I download and play with a fair amount of iPhone applications, but I only stick with a few in the long run. The few that I use all the time are NetNewsWire, RunKeeper Pro, and Pocket Weather AU. I’ve found a new application for that list – Instapaper.

The idea behind Instapaper is to mark web pages when you’re at your computer so that you can read them offline on your iPhone when you might have a few minutes to kill. You add a “Read Later” link – which Instapaper supplies – to bookmarks toolbar in your browser. Whenever you’re at a page that you’d like to save to read later you hit the “Read Later” bookmark. Instapaper then saves that page to your reading list.

When you’re away from your computer, run the Instapaper app on your iPhone and Instapaper grabs your reading list and formats it nicely to read on the iPhone. Pick an article and start reading. If you’re interrupted Instapaper will remember your place. Nice little touches like that make it a pleasure to use.

It’s a simple concept that is done very well. The whole process just gets out of the way and lets you do what you wanted to – read.

To IT engineers: Please, please, PLEASE stop overengineering environments that don’t need to be so complex.

Before you create a dozen 40GB LUNs for VMware RDMs for “performance” on a 60 user site, before you change the default Citrix XML port because you think it will make it easier to track the traffic, before you tweak and change every setting – please stop and think: “Does this have any additional benefit or am I doing this because I think I should?”

Hint: The answer is usually no, it doesn’t have any additional benefit. So don’t do it.

The premier event for virtualization in Australia & NZ  is VMware Forum, held at the Sydney Convention & Exhibition Centre.  This year it is over two days, the 27th and 28th of October.

I have a speaking spot and will be covering the Vizioncore view of the future that we introduced at VMworld – the Analyze to Automate story.

Would be great to see you there.  Come along to my speaking session and come and say hi at the Vizioncore booth.

- James

Continuing on from my previous post on why you should buy software rather than build it yourself – there are many situations where it makes more sense to build software yourself rather than buy it.

I should also add a caveat to my last post – while I talked about build vs buy, supported open source software certainly fits into the buy category, even though you may not exchange money for it. (Yes, I’m a closet open source fan – I ran Linux on my main desktop for five years.)

On to the list – when it makes more sense to program something yourself.

#1 – If it’s throw-away

If you need to automate something very quickly – as part of a migration, or a personal administrative task – write a script or small program to do it.  Over the years I’ve written a number of small scripts and programs to help me with PC annoyances day-to-day.  My favourite was a small Java program I wrote to count unique strings in Filemon logs to help troubleshoot a file server I/O problem.

#2 – If you’re in the technology business

If your business is software, technology, or the web (which is really just software), build it yourself.  Duh.

#3 – If it’s your business at stake

Contrasting from the previous point, if your business isn’t software, but you have a software component which is your competitive advantage in business, I’m of the opinion that this should be built and maintained in house.  Your competitive advantage is so crucial to your business that it doesn’t make sense to trust a third party who isn’t as highly vested in it as you.  I’m not talking about IT infrastructure here – email, file sharing and backup are critical to a business, but aren’t a competitive advantage.  I’m talking about software which controls some critical aspect of business operations.  Examples? The booking, tracking and scheduling system of a courier company or the order processing system for a pizza company.  Sometimes you can start with an off-the-shelf package, but it makes sense to have the skills in house.

#4 – To scratch an itch

While I’ve been talking primarily about business in these two blog posts, we’re all people.  Sometimes we want to write a program to learn something, because we’re bored, because it’s fun, or to prove we can.  To improve our skills, or because it’s a challenge.  You don’t need a reason at all to write software for your own purposes.  As well as being fun, I think it sharpens the mind.

I hope you’ve enjoyed reading these blog posts.

I had an interesting conversation with a German gentleman over at VMworld in San Francisco.

For one reason or another I was manning the vReplicator booth at the Vizioncore stand.  The German bloke (who I shall call “G”) strolled up, and asked what vReplicator could do.  After giving him a high-level view of what it does – software-based replication – G challenged me:

Why should I buy your product when I can just build this?

G further explained how he would build it.  He would use a cron job on the source ESX host to snapshot the VM and run an rsync command to synchronize the disks.  He’d also transpose the virtual machine name in the .vmx file.  That would give him replication.

I mentioned to G that if he could build virtual machine replication software, by all means, do!  Of course, there are a few extra things that vReplicator does that you would really want for a DR solution – VMotion awareness, vCenter-as-source, disk skipping, network/drive mapping, failover, failover testing and reporting to name a few.  After going through this and showing him a demo of the super-easy user interface, G walked away a very interested man.  Quite the opposite to how he was initially.  Great.

The whole experience got me thinking on why you should buy when you can build.  There are some obvious reasons from the above story – and some not so obvious.  This is about software in general – not just my employer’s.

#1: A problem is often more complex than it first appears.

In this case, what G thought could be accomplished by a simple script, has many hidden characteristics that require a more robust engine.  Some of the things vReplicator does – VMotion tracking, for example – could not be technically possible (within reason!) with a script that runs on each ESX host.

#2: Don’t underestimate ease-of-use.

If a software package is going to be used, it needs to be easy to use.  Features need to be accessible, and configuration needs to be guided so that first-time users can easily understand how to configure and use the software to a basic level.  Can a person with adequate sysadmin skills just pick up and use the software with minimal training?  Or do you need to go on a week long training course?  Or even worse, do they need to read the code to understand what is going on?  People use Microsoft Word rather than TeX for a reason.

#3: If you build it, it is yours.  Forever.

If G went ahead and built his replication script, and gradually added functionality to it, he would eventually become the only person who understood how it worked well enough to modify and maintain it.  Even if he wanted to move on to another job, they would call him back if they needed something changed, or something broke.  Contrast this with a software vendor, where if you have a problem, you call support.  I am very familiar with this: in a previous job I wrote some complex database integration scripts to merge customer information between multiple databases, and have been back twice to modify this for newer versions of their software.

#4: It will cost you more to build than to buy

Probably one of the most significant reasons to buy rather than build is that it will actually cost you more to build than to buy. Software of non-trivial complexity usually takes a large number of programmer hours to build.  The economics of the licensed software industry are built around economies of scale – build something complex, and sell it many times.  Software costs much more to build than the license cost you are paying; the reason you get it for an affordable price is due to the fact that you aren’t the only customer.  This is common to all licensed software.

Of course, there are situations where you would want to build rather than buy – where you need some specific software that is core to the function of your business, or if your business is software!

Apparently you’re supposed to get smarter as you get older.  I think I am, if only because I’m becoming quicker to accept new technology before its use is immediately obvious.  You only need to look at an old blog post of mine to gather this.

Some (not so) new technologies I was initially blasé about:

• RSS – back when all I read was Slashdot and a couple of other news sites, RSS seemed pointless.  Now, it would be hard to imagine how I keep on top of around 100 blogs that I read regularly without wasting reams of time visiting the sites and re-reading the same information.
• Virtual Desktop Infrastructure – why use VDI when you can set up Citrix Presentation Server (XenApp) for lower TCO?  Turns out that if you don’t have CCIA level knowledge of Citrix, setting it up is a pain in the ass.  Maybe that’s why Citrix consulting companies that actually knew what they’re doing did so well.
• GMail – and other web applications.  Why use some boring web interface when I can have a rich client installed?  Turns out that the browser is just getting better and better, and Google Gears for offline access is just magic.

As it turns out, I’m being much less of a cynic, and much more of a dreamer when it comes to new technology. Just because technology isn’t totally game-changing, doesn’t mean that it isn’t awesome, and won’t change your life for the better in little ways if you use it.

Some things that I’m really excited about at the moment:

• Amazon S3 – super cheap online storage as a service.  Forget about building economies of scale in your own lower-tier storage infrastructure and use Amazon’s.
• Mobile devices – mostly the iPhone.  I’ve had a data-enabled smartphone for years, but none have changed the way I use the phone until the iPhone.  Work, play, fitness – I use it all the time.  I don’t think we’ve seen anything near the end of this yet.  Apple has found the recipe for the ultimate convergence device and others are starting to follow.
• Ruby on Rails.  Unbelievably flexible web-based application platform that makes rapid web site/web application building easy.  Twitter was built with this, and most of the new web startups are using it.  That’s got to tell you something.

These technologies have all happened in the last few years, and I think they’ll shape how we interact with technology over the next few.  I don’t think any will be majorly game changing directly.  They’ll affect the industry in more subtle ways.