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!
My LinkedIn Profile
My Twitter Profile