You are here

Why cloud isn't always the best answer: 4 myths and misconceptions

public://pictures/labat.jpeg
Jerome Labat, Chief Technology Officer, Micro Focus

Cloud technology is truly transformative, and most businesses—73% of them, according to IDG—rely on the cloud to some extent today. Some business models wouldn't even be possible without the cloud, and a serious consideration of cloud technology is almost essential when any new tech product is being planned.

The cloud has immense value, especially when you're trying to transform IT while running the business, but it isn't the answer to everything. Nonetheless, all too frequently people rush to anoint the cloud as the answer to every technological problem—no matter what.

That’s a mistake, and technology leaders should think hard about whether the cloud is the right fit for each use case. To aid with that calculus, consider these four myths and misconceptions that persist around cloud. Each statement may be valid in some cases, but none is universally true all the time.

[ Enterprise Service Management brings innovation to the enterprise. Learn more in TechBeacon's new ESM guide. Plus: Get the 2019 Forrester Wave for ESM. ]

1. The cloud is cheaper

The cloud's reputation of offering outstanding performance at a low cost has cemented its place in the mind of many a developer, but in reality the cloud isn't always the cheapest option.

Consider licensing, for example. If you're migrating an application from the data center to the cloud, your operating system licenses probably won't transfer with it. It's great to be able to spin up a Linux server on AWS at the push of a button, but few take the time in advance to find out whether that action includes the hidden cost of having to pay for a license for the operating system on top of the cloud service fees.

Even though you've already paid for that Linux license once, you may well find yourself paying for the same software again.

The cloud also has a way of seducing developers into consuming more of its services than they initially expect. By design, cloud services can be spun up as needed, and since per-instance costs are very small, many developers don't see the entirety of what they're consuming from a cost perspective.

A rate of 11 cents per hour sounds unfathomably tiny, a rounding error that no one in accounting will even care about. But I can tell you from experience that those fees add up faster than you think, and dev teams just aren't trained to keep their eyes on these costs.

I've seen a product team budget one project at $30,000 per year for cloud services, only to see actual usage quickly drive costs to 10 times that amount.

Issues like this can rapidly and radically change the profit model of a new product—and can often drive product teams back to the affordability of the data center.

Best practice: First, understand the fine print. Cloud service fees are rarely all-inclusive, and hidden fees lurk under almost every action you can take. With regard to software licensing, you might be able to save money by installing software you've already paid for on a cloud platform, rather than using the service's (admittedly more convenient) one-button install.

And in all cases where the cloud is involved, financial oversight and monitoring are critical. Control who has access to these decisions, and work to automate their control and governance so you aren't taken by surprise when the bill arrives.

2. The cloud is easier to set up

Today's cloud is a modernized version of the software stack, and every cloud service is unique. While it may be easy to master the process of spinning up one application on one service—say, Kubernetes on Google Cloud—the process will likely be entirely different on another cloud service. Kubernetes on AWS and Kubernetes on Azure are very different experiences.

What is simple in the case of a single application on a single cloud service becomes far more complex once you start setting up multiple apps on multiple clouds, a situation that is becoming the norm for most enterprises.

On top of that add the other layers that have to be set up to monitor, govern, and secure each of these, plus the multicloud tools required to keep everything in sync. What might start off sounding like a simple cloud infrastructure can quickly become exponentially more difficult to deal with.

Best practice: Moving workloads to the cloud should be treated like any traditional data center migration and consolidation problem. Take an inventory of your portfolio on an application-by-application basis and ask yourself whether each can be rehosted, migrated, or rewritten. Can you use your existing infrastructure (which has already been paid for) more efficiently?

This is a complex but necessary analysis that you should do before making any decisions as to where to host an application. And be sure to account for the cost and complexity of operations and management in your analysis.

[ Learn how to transform your IT with AIOps in TechBeacon's guide. Plus: Download the analyst paper on how AI is changing the role of IT. ]

3. The cloud is easier to use and manage

As with setup, actually using and managing a single cloud-based application may be simple; that’s how the cloud was designed, after all. But interacting with several dozen applications in a multicloud environment is not so simple, and once you start managing a variety of monitoring tools and security consoles, the job can become overwhelming.

Over time, you may end up spending more time managing your cloud infrastructure than you do running real workloads on it.

Best practice: Think about the orchestration of your services and applications from the beginning. Leverage predefined setups and known constructs provided within the cloud service that are more easily managed; the more you customize, the harder it will be to manage them. And be sure to embrace automation tools when managing your cloud environments, or your IT shop will struggle.

4. You can always move to another cloud service

If you don't like AWS, you can just move to Azure, right? In most cases, that's not realistic. Lock-in is a very real problem, and moving from one cloud service to another often means starting from scratch. Once you've developed an application for one cloud stack, you're often stuck with that specific architecture.

It's similar to a Windows vs. Linux issue. Choosing an operating system necessitates making all manner of secondary choices to go along with it. For example, you'll have to make decisions around security, storage, and supporting applications, all of which tie back to your choice of operating system.

The same problem exists on the cloud. Even if you do move a single application to another cloud service, the management layers that surround that application greatly increase the overall complexity you ultimately have to deal with.

Best practice: Once you're locked in, unlocking yourself can be thorny. Pay careful attention to the pros and cons of various cloud platforms before you begin developing on them, and avoid custom tooling as much as possible.

As you work to develop products on any given cloud platform, keep in mind that any work done will probably have to be repeated if you want to move those products elsewhere. If a mountain of custom development work appears on the horizon, that's the time to confirm that you're on the right platform.

Start from a service delivery perspective

If your IT organization has not transformed itself and moved from a project view to a service delivery view, all of the above becomes more difficult. It's important to look at problems not as one-off projects but rather through the lens of a service provider. 

That means looking holistically across people, process, and technology to provide frictionless, affordable solutions for the business's internal customers. At the same time, it's important to carefully fit the right technology solution to the challenge at hand. Once you've done so, it may be evident that the cloud is not your best choice.

[ Learn how robotic process automation (RPA) can pay off—if you first tackle underlying problems. See TechBeacon's guide. Plus: Get the white paper on enterprise requirements. ]