If you’ve had the opportunity to participate in an engagement with us you know that we tend to utilize the Socratic method of asking questions. And, it’s not uncommon for us to hear a company explain how they plan to utilizing a particular vendor’s feature to scale. For databases this is often clustering. We believe relying on a vendor to scale violates several of our architectural and scalability principles. Let us explain a couple of our more significant concerns with this practice of relying on a vendor.
First and foremost you should want the fate of your company, your team, and your career in your own hands. Do not look for vendors to relieve you of this burden. As a CTO if the vendor you vetted and selected fails, causing downtime for your business, your are just as responsible as if you had written every line of code. And if it is significant or frequent enough you should expect to be relieved of your position. All code has bugs, even vendor provided code, and personally I would rather have the source code to fix it rather than have to rely on a vendor to find the problem and provide me with a patch. This statement should not be taken to imply that you should do everything yourself such as writing your own database. Use vendors for things that they can do better than you and that are not part of your core competency. See our post on build vs buy for the four question to answer when making this decision.
With scalability, as with many other things in life, simple is better. The more complex you make your system to provide scalability the more you are likely to suffer from availability issues. More complex systems are more difficult and more costly to maintain. Clustering technologies are much more complex than straightforward log shipping for creating read replicas.
One of our beliefs, and should be one of yours also, is that it is most cost effective to be vendor neutral. Locking yourself into a single vendor, whether hardware or software, gives them the upper hand in negotiations. If you don’t think the sales rep knows this, ask yourself why they are willing to throw in some of these features at such an initially steep discount. The reason is that they can make up for it next year when you have to renegotiate.
If these concerns resonate with you, check out our database scalability cube post for ideas on how to design a scaling strategy that you can own, is relatively simple, and is vendor agnostic.
