As noted in the first article in this series, economics is a common language that can help IT defend its interests and values. It can also help technical teams clarify choices, such as whether public or private cloud resources are more costly, and at what point.
But when it comes to deciding whether to operate in the cloud, what type of cloud to use and how to manage your applications, it helps to get more granular. In practice, cloud economics is driven by application types, workloads, and related operations.
Classify and (maybe) migrate
A typical enterprise runs a hundred or more applications. Many are old and well-embedded, and some are mission-critical. Some are baked on premises. Others are built for the cloud. A good first step to any kind of economic analysis is to audit and classify them.
One simple but helpful framework is the Gartner bimodal model. Mode 1 apps (“optimized for areas that are more predictable and well-understood”) may or may not be migrated to the cloud. Some legacy apps can be cloud-enabled but not fully migrated. Some applications are stateful, which means they have dependency on the underlying hardware. These applications may have to be rewritten for the cloud. Which brings us to Mode 2 apps (“optimized for areas of uncertainty”). They tend to be cloud-native, where development and deployment is on the cloud and devops processes and container support is essential.
Now consider each individual app. What does it actually do? Is it moving massive or relatively small amounts of data? Is your data largely at rest? What kind of compute resources do you need? Have you broken the app down into microservices? What are your latency and performance requirements?
The analysis described in the first article indicates that the public cloud is less costly in scenarios involving 100 or fewer standard virtual machines. Above that threshold, a single tenant dedicated cloud (hybrid or private) tends to make more financial sense. But note that in practice each VM will have its own memory, storage, and compute configurations, each application its own profile, and each cloud service provider its own fee schedules.
If you have identified an app that can be migrated to the cloud, there are several options. A direct port (“lift and shift”) is the least costly but could have downtime. The other option is a logical migration, which requires more technical expertise but can avoid lengthy downtime. Companies also need to consider investing heavily in a full rewrite to make the application more stable and efficient for smoother operations and maintainability down the road.
Which app? Which cloud?
Now let’s consider some examples. The public cloud, with its flexible, high-compute capacity and pay-as-you-go model, could be appropriate for intensive and batch-based workloads, such as what you might find in life sciences. For a pharmaceutical company, two three-month long cycles of intense research would deliver a savings of six months, as compared to a full year of locked-down compute and storage. The company can shut down the resources as each cycle of research is completed and avoid incurring cost on resources not being used.
On the other hand, the mission-critical operations and stable requirements associated with drug trials and manufacturing are well suited for a highly secure private cloud. That is also a good scenario for custom applications providing multiple years of traceability, to comply with stringent industry chain-of-custody regulations.
An app’s service architecture also matters. Compare an e-commerce and real estate app. One moves tremendous volumes of retail data across boundaries to a relatively small number of clients; the other transports small loads of property information to a much larger user base. The e-commerce app would incur more public cloud costs than the real estate tool.
Or take an artificial intelligence app that collects massive amounts of data and then runs them through algorithmic processing. In always-on collect mode, you will achieve faster and better performance in private clouds. Batch mode, on-demand processing, however, is better suited for the public cloud. As the saying goes, “Own the base, rent the spike.”
Cloud application management
A key challenge of enterprise applications is simply managing them. Among the hundred or more applications at any given enterprise, how many go unused? SaaS is especially prone to being overprovisioned. And once apps are deployed in the cloud, how many resources does it take to keep them running and secure?
There are good reasons to be building cloud-native apps as loosely coupled services. But there are always trade-offs. Are you recognizing the costs of devops or container support? How are you monitoring these microservices? (Or monitoring the monitors?)
Costs can add up in development. Take the proliferation of instances. In a common occurence, a developer or team will deploy public cloud-based infrastructure and begin building an app, only to have that work sidelined when a project of higher priority shows up. Over time, these incomplete projects can turn into hidden technical debt. If numbering above the public/private inflection point, they represent an additional opportunity cost associated with not using a private development sandbox.
For your app only
Cloud economics intersects with applications at several points. For a thorough analysis, first audit and classify your apps. Those eligible for migration may incur upfront porting or refactoring costs. Whether it makes more economic sense to deploy an app in the public or private cloud depends on a number of variables, including scale, function, architecture, performance requirements, and workloads.
Applications and compute instances that are poorly managed or languish unused are another reminder that economic insights can help IT manage its operations and accomplish key business goals.
This article is published as part of the IDG Contributor Network. Want to Join?