When designing production environments, it’s often useful to separate reporting functionality to it’s own virtual machines/hardware. I have run into a few cases, where data anomalies can wreak havoc on production systems.
I generally try to set up slave databases that are replicated with the master, and point all reporting application servers to the slaves. This reduces the demand on the master database, thus leaving it free to deal with the actual production systems. Depending on the reporting demands, the number of nodes in the reporting cluster can always be adjusted. Many clients find that their reporting demands suddenly increase drastically due to changes in their business processes, so it’s good to have the flexibility to scale the reporting environment separately from the production systems.
One system I support found that there were huge production performance issues out of the blue. It turned out that one of their clients’ machines was hacked, and was scraping their site. This didn’t add huge demands to the production systems, but caused a incredible strain on the reporting system, as it was aggregating abnormal data. We found that the reports were putting huge strains on the same system that was trying to serve production. It is hard to sell a separate environment to many clients, as there is additional hardware costs, but if both reporting and production reside in the same environments, it’s difficult to adjust one or the other when changes to the business of client demand change.
In the long run, if you separate from the start, you will have the freedom to re-purpose virtual machines among the clusters of reporting and production systems, thus giving you the choice of what needs the most help with your given hardware configuration.
Related Services: Full Life Cycle Software Development
