
The remaining tips were cited by roughly two-thirds of the enterprises. Tip number three is to look especially at applications whose users are widely dispersed. And by “widely” here, they mean on different continents, not just different neighborhoods. The reason is that quality of experience and even availability can be compromised when work has to transit a lot of networks just to get to where it’s processed. This can lead to user dissatisfaction, and dispersing resources closer to the users may be the only solution. If an enterprise doesn’t already have their own data center located close to each user concentration, chances are that putting a new hosting point in themselves couldn’t achieve reasonable economy of scale in capex, power and cooling, and operations costs. The cloud would be cheaper.
A qualifying comment here is to take great care in evaluating the real impact of dispersion of application users. In some cases, there may not be enough of a difference in QoE or availability to require dispersing hosting points, and in fact it may be that where the application is hosted isn’t even the problem. “The cloud may look like the easy way out,” one enterprise said, “but it may not be the economical way.” See where your QoE issues really lie before you go to the cloud’s distributed hosting to fix them.
Tip four is to examine the user-to-application interaction model carefully, to see if there’s a large non-transactional component. Mission-critical business systems, and business core databases, are almost always in the data center. The stuff that changes them are the transactions that add, update, and delete records. If an application’s user interaction is tightly coupled to the creation of transactions, then its processing is tied to those data center resources. That makes it harder to move the user-interface piece to the cloud and gain any economies. On the other hand, if there’s a lot of user back-and-forth that doesn’t involve access to those core resources, then there’s a good chance that the interaction piece can be hosted in the cloud at reasonable cost.
A tip to figure out whether this point applies is to look at what data is actually provided to the user during the pre-transaction piece of the interaction. If most of the data has to come from the core database, then pushing it into the cloud for review can create skyrocketing and highly variable data transfer costs. If a summary product or other database can be hosted in the cloud, then that cost can be predicted and managed.
Choose applications wisely
The final tip, I think, is perhaps the most obvious but also perhaps the most important. It’s best to focus on applications that need changing for some other reason. Some enterprises say to focus on applications already scheduled for change, some say that it’s broader than that. How much money can you save by redoing an application? It depends on how certain you are of both current costs and expected costs, and how risky the disruption is. In most cases, it’s possible to get an accurate current cost for an application, but future costs? You should expect to project orderly growth into current-cost estimates and do the same for the cloud costs. But whatever the cost comparison, enterprises point out that there’s always a risk in making any change to an important application, and moving it into (or out of) the cloud is surely a significant change.
The take from these super-succeeders, cloud-wise, is that the cloud is valuable because it’s very different from the data center, and dangerous for the same reason. You can’t assume that what works in one will work as well in the other, or work at all. It’s best to get things right from the start, but the group agrees that pilot testing to validate the financial assumptions can still save you, and your budget, by giving you an early out. Everything isn’t moving to the cloud, they say, because the cloud isn’t best for everything. Write that on your whiteboard before every cloud meeting you schedule, and add that maybe it’s time to get your head into the clouds rather than out of them.