What Harry needs

Easier said than done. In his design and planning Harry needs to consider a few things. He needs...

• To make money quickly. Harry cannot afford large up-front costs, which he thinks is quite reasonable since resource usage will be low in the early days.
• Smooth growth and evolution. Harry cannot afford to rebuild his infrastructure every six months as demand grows.
• Managed services. He will look after the application-level, but someone more used to systems administration can worry about the low level details: disk space, uptime, backup, and so on.
• Flexible hosting. As demand fluctuates the hosted services will have to move closer to the players. If Japan takes off he needs to put servers there fast. He cannot realistically plan three months ahead.
• Scalable applications. His applications need to spread themselves out across several locations to cope with expected load. Harry does not want to implement each new setup again and again.
• More resources. Harry will want to expand his database, disk space and so on very quickly. He should be able to do this dynamically.
• Reliability. When Harry's game gets big, he doesn't want the whole thing to drop dead just because of a single failure. This can be expensive: either building it to be reliable to start with, or rebuilding when he can afford the extra hardware. Harry wants to build in reliability cheaply from the beginning, and then spend money only on the extra resources needed to deliver it.
• Adaptive applications. Harry's software must be able to upgrade and improve itself. If the game is used heavily in Australia then the database needs to start caching results locally. It must be able to intelligently add or drop functionality as it sees fit for that particular situation.
• Flexible applications. An application should be able to choose the right version of itself for the right environment. On a palm-top an application may have more intelligence but less connectivity than than the same application on a mobile phone. Some PCs have more disk space than others. Any application should be able to choose the right version of itself for that particular environment.
• Choice of vendors. Harry's applications must be able to switch service vendors (for storage, messaging gateways, hosting, etc) at will. He may find a better deal for a service, possibly just for one geographic location. There must always be choice, and a choice at design time is not good enough.
• Reasonable ASPs. Harry wants to find ASPs who can deliver exactly what he wants and no more. He does not want to have to pay for bundled services he will not use.
• Realistic costs. Harry wants to pay for the resources and services he uses. He does not want to have to pay large set up costs to ISPs and ASPs.
• Bank integration. Money will have to change hands, and will have to change hands between several banks. Harry does not want to have to sort that out. The banks can sort it out between themselves.