July 19th, 2012 by James Knight
In my last post I promised some details on RTD hardware requirements and components, so let’s take a look at the components that live in the RTD black box shown in my previous posts.
Realistically, the minimum RTD setup in production is likely to be as below:
Decision Service provides the real-time recommendations to the calling application. So in our product example, we might pass in the customer number to the decision service via the Java Smart Client, which would then return a recommended product or products. The learning server maintains the analytical self-learning models. Decision Center provides a web interface that allows users to access the information within RTD, enabling them to see which particular product recommendations have been successful and the correlations that RTD is using to make decisions.
RTD is easy to scale as and when you need to, so you can grow the environment as use cases grow. In terms of a production implementation running a number of RTD solutions in a high transaction environment, you’re likely to have a RTD environment similar to the below in order to provide performance and high availability.
In the diagram above we have three Decision Service machines, so if one was to go down you still have two to provide the required performance, critical for a system that could be making real-time decisions to customers on your website. We also have a second Learning Server in place to take over if there is any problem with the current active box.
There are other things you can do to provide back-up in the event of RTD failure. In our product recommendation example, we could have default recommendations at the front end that display if RTD does not return a recommendation for any reason. What’s interesting here is that when RTD first goes live, people are happy with defaults and RTD is not seen as mission critical as a website will still be up even if RTD is down, but as people see the results from RTD they soon become very unhappy if defaults are shown. Fortunately, RTD is robust and this isn’t something you’ll expect to encounter.
The hardware required for the machines in the above diagrams is nothing special and doesn’t cost a fortune, with server specifications as follows:
2+GHz CPU, 2GB RAM, 2 or more processors recommended, hard disk – 20GB plus space for log files.
Hopefully, this post makes it clear that you don’t need a huge infrastructure to support a RTD implementation. You don’t necessary even have to create your own internal environment in order to provide solutions through RTD. Other options would be to use a cloud based or externally hosted RTD environment.
In my next post, we’ll take a look at timescales and resource requirements for a RTD implementation based around the product recommendation example.