Getty Images/iStockphoto
Is cloud repatriation the only answer?
Cloud repatriation should be a last resort, not a repudiation of the cloud. Do you know how to fully optimize cloud workloads to avoid costly in-house investment?
There is a lot of talk about cloud repatriation, in which organizations move a workload from the cloud to an on-premises data center. But repatriation doesn't happen often.
According to Andover Intel research, only about 9% of enterprises said they've moved any applications out of the cloud. Additionally, less than 3% see any reason for cloud repatriation other than cost, although over half expressed some disappointment with cloud costs.
The cloud is nimble, elastic, resilient and sometimes cheaper than building a data center resource pool for peak demands. But hosting certain data in the cloud can create data sovereignty issues. Enterprises that move data from a secure store into the cloud can also generate huge transit costs that make the application impossible to justify.
To create effective applications and avoid cloud repatriation, organizations and developers must prioritize the following:
- Hold databases and transaction processing in the data center.
- Support the GUI and browsing activity in the cloud.
- Deliver positive UX at a fair price.
While the cloud isn't the cheapest place to host all applications, it isn't always the most expensive. Enterprises can optimize cloud usage and avoid cloud repatriation through planning carefully and exploring issues beyond cost. By doing so, they can usually find a better strategy than cloud repatriation for a problematic application.
Rethink costs
When surveyed, enterprises say that high cloud costs usually stem from the following three factors:
- Wrong cloud services or tools.
- Flawed application load estimates that lead to unnecessary scalability.
- Developers designing applications without understanding where the cloud saves money.
Dramatic changes in application load or usage often justify the cloud. But enterprises can struggle to put that knowledge into practice.
It's possible to address the first two factors by replanning and selecting better tools and designs. For example, serverless cloud features might become too costly as applications use more of them. In this instance, consider switching to containers or VMs.
The third factor is the reason for most cases of cloud repatriation. Often, repatriation is the wrong decision.
Consider the cost of a server in a data center that has a relatively stable utilization around 70%. It is likely cheaper to continue to run the server than to convert to cloud hosting. If a server -- or a pool of servers -- runs below 30% utilization but holds capacity available for sudden increases in application load, it is almost always cheaper to move its applications to the cloud. This distinction can help enterprises manage the three considerations above.
Prioritize the GUI
The key factor in cloud application design should be a commitment to creating an effective GUI.
The GUI represents the way users obtain and use information. Users have become accustomed to both online information browsing and attractive, functional UX. As a result, the amount of information consumed before and after transaction generation increases. This highlights the importance of how the information appears. Many factors drive users to online information, and most of them don't create as large an increase in transactions as they do in activity overall.
Most applications have a functional division between UI and transaction processing. Transaction processing is the component that processes orders, takes deposits and authorizes payments. It interacts with databases and, for data protection reasons, is usually kept in the data center. It's also predictable in terms of load. Companies typically know the usage patterns for the commercial activity these transactions represent.
UX requirements drive most application changes and offer the most variability in load. This can make UX ideal for cloud hosting. However, it's important to consider the data requirements, including sovereignty, and the transition point between the GUI and transaction processing portions.
Avoid GUI design pitfalls
The biggest mistake companies make with GUI modernization is having their cloud component browse a data center database when a transaction is being contemplated. A customer might look at dozens of products before buying one. If users pull all the product data from the data center, the cloud provider's traffic charges cause costs to explode. Consider moving noncritical data, such as product descriptions and prices, to the cloud for storage. This can lower costs versus storing all the data in the data center. It also makes the application more responsive.
The best approach to planning what should be in the cloud versus returned to the data center is to draw out each possible workflow from user to database. Determine the minimum and maximum potential load for each. The benefits of the cloud's elastic expansion are limited where there is little variability. For flows that show considerable variability, see what data can be cloud-hosted. This reduces cloud-to-data center traffic not associated with a transaction.
Another mistake is to have the cloud request an entire record when a user only needs one field. Let's return to the product sales GUI example. Assume it's important to show all available stock. Rather than having the entire product record exchanged with the cloud -- and paying for the exchange -- have the data center and cloud only exchange product ID and stock information. This also works when pricing is confidential.
Generally, the product information, specifications and so forth are many times larger than any data elements subject to sovereignty. This means a change to the core transaction processing application, but it makes the GUI piece in the cloud much more economical. It also eliminates the need to pull everything back into the data center.
Tom Nolle is founder and principal analyst at Andover Intel, a consulting and analysis firm that looks at evolving technologies and applications first from the perspective of the buyer and the buyer's needs. By background, Nolle is a programmer, software architect, and manager of software and network products. He has provided consulting services and technology analysis for decades.
