The Problem With Food and Technology
If you are curious about the food that you eat a couple of books that I’d recommend are The Omnivore’s Dilemma and In Defense of Food both by Michael Pollan. One of the key pieces of advice to his readers is “Eat food. Not too much. Mostly plants.” Admittedly, I don’t follow that advice but it sounds reasonable. The other interesting point in his books is how we have arrived at so much highly processed food. As Michael explains it this is because the food chain wants to grow more than the 1% per year population growth and therefore by processing the food more they can charge more and achieve faster growth. The result is not only higher prices but food with much higher caloric values. This “value add” by the members of the food chain reminded me of technology vendors.
A product (hardware or software) perhaps starts out as a unique technology that is innovative and sells because of this. Over time this product becomes less unique and eventually commoditized, everyone sells essentially the same product only differentiated by price. High tech companies generally don’t like selling commodity products because the profit margins continue to get squeezed each year. The way to prevent this is to add features to the product, sort of like making highly processed food products. The more “value” the vendor adds the more they can keep the price high. What we as the consumers are left with is highly processed products that are not what they were originally designed for.
What’s the problem you say? What’s the harm in a piece of network gear that does it all? It routes, load balances, firewalls, manages sessions, and even can have business logic. The problem is that it was more than likely designed to do one of those things and when the vendor sells it to us as a “do everything” panacea we’re setting ourselves up for problems. This is not to say that it’s never okay to dual use hardware or software or that you can’t use added features of a vendor’s product. What we do say is that the more you rely on these the more you are tied to this vendor and the more likely you are to have problems with that product.
We have a term that we use with our customers to explain this, we call it “purpose driven hardware/software”. The general principle is to use the hardware or software for its original purpose, a load balancer as a load balancer and a database as a database. Use an X, Y, or Z axis split to scale your database, don’t rely on a vendor for scale. Following this principle will 1) allow you to remain vendor agnostic, achieving the best pricing 2) rely on yourself for scaling not a vendor who may or may not release the next version/bug fix when you need to scale and 3) simplify your architecture which leads to less human error when everyone understands how the system works.