No one likes hardware; they only like what they can do with it. And I say this as a geek who has built plenty of PCs in my house, including a Hackintosh. What kind of sick weirdo builds their own Mac? Well, you know what? That Hackintosh illustrates the perils of hardware in three ways.
Hardware gets marked up
The first peril of hardware is why I did this: Apple’s crazy markup on hardware. Why did I go through the difficulty of finding and buying components that were compatible with MacOS? Why did I go through the rigmarole necessary to fool the MacOS installer into installing on something that wasn’t a real Mac?
I wanted to run MacOS on a server powerful enough to run Adobe Premier Pro well, and the MacPro I wanted was something like $4-5000. But I could build a Hackintosh for around $1500, so I did.
This is why storage customers revolted against traditional proprietary storage vendors in favor of software-defined startups that allowed them to use off-the-shelf hardware that wasn’t ridiculously marked up. People started realizing that hardware is hardware, and rarely is hardware special enough to warrant a huge markup.
Hardware must be maintained
Hardware breaks. Power supplies die, disks stop spinning, and fans stop blowing. This is why every production piece of hardware typically comes with a service agreement specifying how quickly the vendor should respond when a problem occurs.
At no time is this peril more acute than the last few weeks. The spectre of the Spectre and Meltdown vulnerabilities is wreaking havoc on hardware land. First Intel came out with a new microcode version to address the vulnerabilities, then Microsoft, RedHat, and other Linux vendors came out with OS patches. Then people that installed them started seeing spontaneous reboots. So they all started pulling their patches, and Microsoft even released an out-of-band update that disabled the microcode patches if you installed them. It’s been a tough couple of weeks for those that must maintain hardware.
Meanwhile customers who are using services like Salesfore.com, Office365, Gmail, and yes, the Druva Cloud Platform, didn’t have to worry about maintaining the hardware underneath those systems. The service providers had plenty of work to do, for sure. The cloud is not magic. There is no such thing as the cloud; it’s only someone else’s datacenter. But people who were using true cloud services simply didn’t have to worry about maintaining the hardware behind the services they were using.
This brings me to the point of the companies in the data protection space who have now certified that their product runs in AWS. Yes, this allows them to say that they work “in the cloud.” But it’s important to distinguish this from a cloud service offering, where hardware is not your problem. Customers of such backup solutions that are “running in the cloud” are having just as many problems with their cloud backup servers as they are with their onsite servers. Because even virtual hardware has to be maintained. It may be someone else’s hardware (i.e. you don’t own the server your cloud VM is running on), but you still have to maintain it.
Hardware is a capital expense
The Hackintosh I built was only $1500, but what if it had been $100,000? Hardware of all kinds requires a significant amount of capital outlay. Maybe you can finance it and maybe you need to come up with the actual cash to buy it outright. Either way, it’s going to stay on your books for years.
Capital expenses can be really difficult to get approved. I remember working at a place where every single item over $1,000 was a capital expense, and getting capital expenses approved took months – even years. I remember doing all sorts of things to work around that issue.
Real hardware also exists. If you bought it for a project that changed directions, you’re stuck with that hardware. If your project needs faster hardware, you have to upgrade – leaving the old hardware in the dust (literally). This is perhaps the most compelling thing about moving apps to the cloud. If you change your mind, you just delete the VM.
The hardware isn’t important – the service is
This brings me full circle. The hardware isn’t what’s important; the service is what’s important. Consider my opening story of the Hackintosh. My need was to edit video. The solution to that need was Adobe Premiere Pro – which I already owned. But I owned the MacOS version, so I needed a Mac. I couldn’t afford a MacPro, so I built one. (I just found out the Hackintosh I built is running fine, BTW.)
But what if I was able to find a cloud service to do my video editing? Yes, I realize there are rules of physics that might get in my way, since raw video can be huge. But just work with me. What if I could meet all of my business needs with a service that runs in the cloud?
Would I need the Mac? Would I need the Hackintosh? Would I need Premiere Pro? No, i wouldn’t. A Chromebook would probably do just fine.
But if I went to Apple and told them my business requirements, their answer to my questions would most certainly be a MacPro. That’s what happens when you ask a hardware vendor to help solve your problem. It’s like going into a hardware store and telling him you need a place to live. The first thing they’re going to do is sell you a hammer, nails, and wood. Because that’s what they sell.
Why would you want hardware?
This entire blog post was inspired by another blog post by a blogger and writer I respect. The title also started with “The Perils of…” He used the hammer analogy, too. He suggested that you shouldn’t go to vendors who just sell “backup,” as there is an entire continuum of data protection requirements not met by that term. I agree with that part. The days of backup only are over.
But then he suggested that his company, a very large hardware and software vendor, was the right way to go because they sell all types of solutions. That’s where I’m going to have to disagree. Because almost all of their solutions are just more hardware & software. Hardware & software get marked up. It has to be maintained. And hardware is a large capital investment. Why would you want to do any of that if you could meet your data protection needs with a service where none of that is an issue? Just a thought.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.