When it comes to vendor recommendations for implementing their products, there tend to be two camps: people who ignore them and people who follow them religiously. Either way can often cause issues. The recommendations are obviously there for a reason and there is clearly a purpose to them, but they should be weighed for their relevance and application to your environment.
These are different from requirements, which are what you have to have to run the technology in question. Recommendations are supposed to be guidelines for optimum functionality, but sometimes recommendations are set for only a single type or size of environments, and don’t apply to a large portion of the market.
There are certain healthcare and database applications out there that don’t provide an actual minimum requirement or reasonable recommendations. For example, some of the very popular applications will just say, “to run our app, you need 15 servers, each with 16 processors and 96GB of RAM” with no context for the size of the customer or their environmental workload. With no recommendations for smaller environments, you’re left with either buying a massive amount of hardware just for one application, or you’re left without a key application that would help your business function. In this case, running the applications with a reasonable amount of hardware based on the smaller size of the environment would make more sense than following the recommendation.
On the other hand, sometimes people will completely ignore recommendations and they’ll end up with a drastically undersized environment and then be forced to buy a lot of equipment halfway through a project. This can cause delays and cost overages and throw the entire project off schedule and budget. For example, implementing a new database software but only having three 7200 RPM drives that might only provide a tenth the necessary performance.
If a vendor is going to make just one recommendation for their product, it is usually going to be based on a large customer’s environment. They have much more to lose from a large customer implementation going poorly than they do from a small customer oversizing their environment.
So, sizing your environment around your product requires some context around the recommendations. Take them seriously, but think of them in terms of the size of your environment relative to the size of potential other implementations. We’ve had customers come to us after grossly oversizing their environments by following a particular database vendor’s recommendation. We’ve also had customers who were in a bind because they completely ignored their vendor’s recommendations and had massive performance issues because their environment was undersized. In other words, just keep an eye on the practicality of your vendors’ recommendations in terms of your environment, because as we all know, each one is unique.