Most enterprises are in the process of rethinking what they do in the cloud, according to what I read and what I hear directly from enterprises. Why? Because they’ve experienced higher-than-expected costs, some so high they’ve had to move some of their cloud applications back into the data center. But a small group of enterprises – less than 10% among those who chatted with me – seem to have gotten it right from the first. What tips does this group offer to others less fortunate, and what can we learn from those who seem to know the ins and outs of the cloud the best? A lot.
The number one tip – shared by every one of the enterprises who reported no need to revise their cloud strategies – is to build your applications only on basic services unless your early design shows that’s not possible. Use IaaS/VMs instead of containers when you can, opt for containers instead of serverless, use dedicated and not usage-priced facilities, and bring your own middleware to the cloud rather than use cloud-provider web services. Most of our arch-successes did this from the start, but the 10% or so who admittedly followed the hype trail realized their error quickly.
These enterprises point out that most of the value-add cloud provider features add value in the development period and subtract money from your budget forever after. One said that, in their experience, even if you had to license middleware features to host them in your IaaS VMs, the annual cost was half that of using provider tools. It can be even lower if you can use open-source software directly. Be sure you have the necessary staff skills for that, though.
A corollary to this point is: Don’t chase new cloud features and change applications that are working. The enterprises in this group found that the great majority of new features and capabilities added ongoing cloud service costs without improving the applications’ quality of experience or availability. One enterprise that didn’t follow this rule said: “We redid one application twice in two years, and both times it increased our annual cloud costs. And everywhere the users saw any change, they didn’t like it.” That echoes a view a CIO offered me decades ago. “The worst possible project to propose is a conversion. It’s all cost and no benefit,” he said. “The best you can hope for is that nobody ever knows you did anything.”
Consider workload variability, end-user locations and access requirements
The second most cited tip (by over 80% of the cloud-expert enterprises) relates to picking applications to move to the cloud. The tip is to look for applications that show a lot of workload variability over time. More than 80% of enterprises have told me that if you look at the cost of a VM in the cloud versus one in the data center, assuming a consistent workload, the data center is going to be anywhere from 25% to 40% cheaper. On the other hand, if you look at applications where the ratio between peak resource needs and average needs is roughly 2:1, the costs equalize because the data center resources are, on the average, partly wasted. At 2.5:1, the cloud is cheaper enough to meet CIO ROI guidelines.
The cloud, these tipsters say, is an economy-of-scale game. The value is highest where enterprises’ own data center economies are the weakest, which is where there’s a lot of load variability. In the cloud, one user’s peak can fit into another’s valley, evening out total work and raising the efficiency of the resource pool to the point where it can be priced better than could be achieved in house.
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.
Source:: Network World