What is a Unitasker?
One of my favorite hobbies is cooking—I’ve blogged about how project planning isn’t that different from planning a dinner party. I am pretty into the technical side of cooking—one of ethos I try to follow in equipping my kitchen is to avoid the dreaded “unitasker” syndrome. For a tool to makes its way into my kitchen, it needs to either be versatile, or do what it does incredibly well. A good example of a bad unitasker is the Margarita Maker—I already have two other tools (a cocktail shaker and a blender) which could accomplish the task of making a margarita, so why do I need a specialized appliance that doesn’t really do anything else? My knives and my Vita-Prep do a lot of things really well—not just one thing. So why am I writing about this on my database blog? We have the same phenomenon going on in IT right now.
The Bad Old Days
Back in the bad old days, servers were really expensive, and came with even more expensive support contracts. This was especially true if you were on the dark side and managed UNIX servers which required RISC based hardware. In their time these servers brought really outstanding performance, but they also came with hefty vendor lock in. You paid for your O/S support from the hardware vendor and you had to buy any additional spare parts through the vendor. In 2009, which really isn’t that long ago, my former company had to pay $36,000 to put 16 GB of memory into a mid-range UNIX server. We could have purchased the same exact memory for the same vendors’ x64 server for about $2000. Support on those 4 servers was also north of $200k/yr. By now most enterprises have seen the light and are using commodity hardware—running some combination Linux and Windows as their application stack demands. The amount of hardware that can be purchased for $10,000 now completely floors me (I spec’ed some servers in this price range with 8 really fast cores and 256 GB of RAM the other week). So now that hardware is cheaper (and service on those commodity servers is really minimal–< $1000/yr in most cases) the margins of the hardware manufacturers are way down—so where do they make up that margin? Margarita machines, er hardware appliances.
The first exposure I had to dedicated computing platforms was when I worked in pharmaceutical manufacturing—the appliances in questions were hardened physically and protected against extreme conditions. Also, they were easy to deal with from a validation perspective. So these devices made sense—and since they more along the lines of workstations, they didn’t really affect our IT buying. The first big splashy product launch of an appliance I came across was Exadata—the HP Oracle Database Machine (this was prior to Oracle’s acquisition of Sun). The original specs for this machine really targeted large data warehouse environments (it’s still pretty good at that), but the sales and marketing folks came in, Oracle bought Sun, and now we have ads on the front of the Wall Street Journal proclaiming “the World’s Fastest Database Machine”. It’s really not—see my friend Kevin Closson’s blog if you are really interested.
Microsoft introduced a similar product with Parallel Data Warehouse in 2010. The Microsoft product is slightly different as the hardware is purchased through a hardware vendor, as opposed to the database vendor. SAP has their own offering with the BW accelerator—designed to speed memory processing of large data warehouse queries. One difference between these two products and Oracle’s is the option for different hardware vendors. There are numerous other appliances from numerous vendors. In the big data space, numerous vendors have solutions for Hadoop.
What Do Appliances Have in Common?
Some things are different, but most of the appliances I’ve seen have the following things in common:
- Purchased as a whole unit, typically in half rack or whole rack configuration
- A large upfront cost, either directly to the vendor, or to a third party consulting partner, to “configure” the appliance for your environment
- Ongoing support costs that are much higher than on commodity hardware
- An expansion plan that consists of—buy another really expensive appliance, with all of the above costs
- Sales reps from major vendors seem heavily incentivized to sell them, even where they don’t fit—so be wary
I’ve been trashing these appliances throughout this post, but they do have some benefits. If you have the right type of workload (and from a database perspective this tends to be a large data warehouse) and more importantly, a singular workload (not mixed OLTP/DW) these machines can really offer some great performance gains, at the cost of flexibility and lots of money.
Things to Think About
I work for a large enterprise, we buy a whole lot of servers (this means our server costs are really low), and we have a couple of appliances. The appliances don’t fit well into our monitoring and standards, and when workloads get onto them they tend to get stuck there. Appliances represent the ultimate case of vendor lock-in to me.
While there can be performance gains, the main reason I see for these appliances is for hardware vendors to recoup some of the lost profit margin I mentioned above. The best example I’ve seen is with Hadoop—which was basically designed around cheap, commodity hardware. Every major HW vendor now has some sort of an appliance for Hadoop, which costs a ton more than building your own, with no real functionality improvements.
So think long and hard when your friendly sales rep or VP/CIO tries to convince you that an appliance is the solution that will resolve all of your data problems.