Building a Demo Server - Part 1 Designing The Server
Introduction
Ahh, the demo server. If your company is selling things, you probably will get asked to setup a system that allows the sales people to demonstrate your products without affecting live or production systems. Sort of a playground where salespeople and customers can make changes, try out the system and simulate any customizations you offer for potential customers or clients.
Now I know that some of you will setup accounts on your live server and allow customers to experiment there. You may have designed your system from the ground up to allow for demo capabilities. I applaud you, and will include these types of features in my future systems, but I have inherited a few systems over the years where this was not really permitted for a variety of reasons (I'll explain below). This series chronicles some of my challenges and decisions regarding my final solution.
I'm making notes as I design and implement the solution, so hopefully this will give some insight into how I build a solution and allow others to comment and critique. Since this article will not likely be released until the solution is implemented, I won't be able to incorporate feedback into the design, but I welcome your notes and comments and may modify my solution based on those comments.
Why not use the live system?
In my present job we have a couple of reasons why the live system cannot be used. The main reason is that we have a fairly integrated system with regards to moving information to downstream systems, like accounting, CRM, etc. The management doesn't want the any of this information moving downstream. Now we could add flags to various tables to prevent these feeds, but at the time when a demo system was required, this would have required quite a bit of work to modify systems and the resources were not available.
The second reason is also a reason why my previous employer also wanted a second system: load. The sales people want to be able to use this system at most anytime and allow it to perform in a manner that shows potential clients that our service is reliable. To do this, they need to be able to schedule a demo and ensure that there is not any other load on the system.
I've needed demo systems at each of my last few jobs and the reasons have always been similar. The impact of these demos might affect a live system. Or the live system might affect the demo. Not sure which is worse, but neither looks good, especially in front of a client.
Which Server?
Once you've agreed that a new server is needed, the next step if to pick a server. I've seen different choices, usually some spare server that is lying around. However, keep a few things in mind.
A demo server is the first view of your system that a potential customer sees. Not a client, not a customer, not someone who is paying you, but someone you WANT to pay you. Make this a good look. Using a spare server is fine, but I'd be sure that it's not last years model. Not an old desktop that isn't being used. Be smart and pay some money up front for a nice server that helps to sell your product. Nothing like seeing a demo run really slow and excuses from the salesperson that it's "only a demo server". This is important. Remember the sizzle sells the steak, and speed can sell your product.
Lots of people are tempted to drop the database on a development server. Not a bad idea, but this suffers from the same problems as using the live system. Load.
All it takes is one developer running a cross join on your largest tables at the wrong moment to kill the server. And a demo.
You may be budget constrained, but ask yourself how much that $4000 you're saving is really worth. do yourself a favor, choose a system that is similar to the production system. Buy RAID controllers, lots of memory and tune this server to run as well as or better than the production system. Personally, I'd classify this as a production system and treat it as such.
Choosing a server is usually the easy part. Buy a decent server, set it up and start running demos. However there are other things to think about. I'll tackle looking at data quality and freshness in part II of this series.
As always, I welcome feedback for this article (use the 'Your Opinion' tab below) and please take
the time to rate this article.
Steve Jones
©dkRanch.net December 2001