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:
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:
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.
Xobni is an awesome plug-in for Outlook that adds social networking, statistics, and a very fast, useful search function.
A few months ago, I filled out a survey for them, so they sent me a T-shirt. Today, unannounced, another T-shirt landed in my mailbox! No idea why. Maybe they’re re-branding from brown to black, so needed to send me a different colour? Do I now have the only two Xobni T-shirts in Australia?
I’ve written a blog post for the Vizioncore corporate blog on identifying and resolving CPU contention issues on a VMware ESX environment with vFoglight. Check it out here.
The vReplicator Best Practices guide has been updated to v1.2 and is available from the Vizioncore vReplicator product page. Enjoy.
Recently I wrote a best practices guide on using Vizioncore vReplicator for disaster recovery. In case you missed it, it’s linked from this post on the Vizioncore blog.
I’m currently working on a minor update which adds more information in certain areas.
After upgrading from an iPhone 3G:
Edit: Voice Control actually really sucks. I can’t see myself using this. It only does what I expect around 25% of the time.
My LinkedIn Profile
My Twitter Profile