2011-06-20

Best practices: not always the best choice

Most vendors have well defined 'Best Practices' for how to deploy/use/support their products that are a great starting point, but there are many times where sticking to them as an only practice will get you in trouble.  'Best Practices' are typically aimed at a hypothetical 'typical' environment which most do not match even if they are close. While the 'Best Practice' may work well for a given environment, if is not likely to be the optimum.
Ex.1) Microsoft Exchange 2007 has a best practice that assumes about 1000 end users and therefor recommends deploying each component on 7 separate servers. If you were to try to sell that to a small 12 person company, you'd likely be shown the door very quickly as that is an impossible investment for most companies that size. For organizations under 100, a single server will do just fine, and the only reason that isn't front and center of that best practice is that Microsoft would love the extra revenue of the server licenses as would the hardware vendors. 
Ex.2) Cisco router sizing guides show what should work for given sizes of typical networks, which is great if your network is typical. But if you add in site to site data replication between multiple VPNed sites, the 'Best Practice' routers can become sufficiently overwhelmed as to interrupt those data replications. In one case I was involved with one  install project where 4 sites were replicating to each other for backup and disaster recovery purposes (tape backup at one site covered all 4). The first router guy I was using kept insisting the connection drops were not the fault of the routers even though they were clearly getting saturated. In the end we had to drop some of the higher end fancy firewall filtering to keep the data flowing. After that, I refuse to use that particular router guy.
Another catch with 'best practices' is that they can change. I once had to migrate an entire cluster off of one SAN to another simply because the SAN vendor found that their original best practice had 'issues' and this client encountered those 'issues' requiring a total flush to fix.  The new SAN was built to the newer best practices and the vendor was made to provide the new SAN in exchange for the old one.
So when you see a best practice, try to find out their assumptions before using. Then you can knowledgeably use that best practice as a starting point, modifying it to best suit your environment.