Five Big Myths About Managing Applications in the Cloud

Five written as a cloudSay the word ‘cloud’ and the energy in the room instantly increases. People move to the edge of their chairs.  Eyes light up and more often than not, lively conversation ensues.

This excitement is not unfounded. Cloud computing is one of the biggest things to disrupt  the IT industry in decades; and a delivery model that is fundamentally changing the way companies consume and deliver services.

As adoption increases, more enterprises are bursting environments on the fly, adding the capacity they need, then spinning them down when the peak subsides. They’re increasing memory, storage and processing power in hours and developing new apps to run in this leveraged wonder of the IT world.

Yet, as savvy as cloud users are today, one critical area remains incredibly misunderstood: corporate custom applications management and support.

The problem? No one’s really talking about what it takes to handle custom business applications in the cloud environment. In fact, the topic rarely comes up until long after the new cloud infrastructure is in place.

This exclusion is not a blatant oversight but a misconception that applications management in the cloud is a no-brainer.  That, once the infrastructure provisioning process is figured out, and security issues are taken care of, everything else will fall in to place.

In most cases, that notion couldn’t be further from the truth.

In this article, we’re separating the fact from fiction—highlighting the five most common myths about managing custom applications in the cloud—and then shedding some light on the realities.

It’s definitely a topic worth talking about.

Myth #1:  Standing Up Existing Custom Applications is as Speedy as Provisioning Infrastructure

 If you’re talking about one of those “cheese stands alone,” isolated applications that never has to communicate beyond its own system boundaries, this statement can be true.

But, if you’re talking about an application that requires interconnectivity with other applications or databases outside the server domain to get its job done, then some additional, back-end work is in order. Connectivity is certainly possible and viable in the cloud, but it’s just not automatic. You have to build in time for modifications, much like you would in a traditional environment.

You also need network connectivity between monitoring tools and notification agents for event management, a strategy for release management and a process for support.

Without planning for these modifications up front, your critical applications won’t be able to support your business completely, and your company won’t realize the full benefits of your new cloud environment.

Myth #2: Applications Running in the Cloud Have Instant Mobile Access and Scalability

So, we love cloud because it gives us anytime, anywhere access. It’s the environment for the connected world, right? Well, for the most part, that’s true.

But, just moving an application to cloud doesn’t give it instant mobility. You have to modify it first—a process that requires the same amount of time as a standard app modification in a traditional environment—with time built in for testing.


The same is true with scalability. Although the infrastructure itself is scalable, your custom applications won’t automatically scale on demand or increase performance. The key is identifying up front why you’re moving specific applications to cloud and what benefits you hope to gain; then modify those applications so they can deliver the scalability or performance you need.

Myth #3: Change Management is Faster in the Cloud

 The truth is, the actual steps and processes required for applications change management in a cloud environment are the same as those used in a traditional environment, so changes to existing apps won’t happen any faster. Depending on whether you’re using a public or private cloud, and the communication method or scheduling process defined in your cloud service agreement, changes to existing applications may actually be a little more complex in the cloud.

Typically, private clouds provide more customized change windows to align schedules with client needs. Public clouds are more likely to publish their own change schedules for clients to work around.

In any case, it’s imperative that the type of change environment is identified and communicated to the support staff up front, either through a published change schedule or through client change control boards. This open communication enables the applications support staff to analyze the changes, their times and the impacts on other applications and changes in that environment.

Myth #4:  Running Applications in the Cloud is Always Less Expensive

Here’s the thing: you can get a great value by buying in bulk at your neighborhood warehouse store and an enviable per-unit price.  But, if you’re not going to consume that 5-pound bag of broccoli florets before it expires, or use that flatbed of toothpaste before you do, you won’t realize the value. You won’t save money if you buy more than you actually need.

The same is true with cloud.

Cloud offers outstanding flexibility, scalability and rapid provisioning. But, if you don’t really need all of those benefits, then you might end up paying more just to have functionality that you might never utilize.

For example, if you’re a manufacturing company test running a line that rarely changes and functions at 85 percent capacity, there’s no good reason to move to cloud, unless it’s time for a hardware refresh or you anticipate a dramatic uptick in user numbers due to acquisition.

If you’re doing batch processing in the middle of the night and already scaled to capacity, you won’t gain much by moving to cloud. In fact, you might be paying more for flexibility and scalability that you don’t really need.

Conversely, if you’re running a mobile application and standing up a new test environment every time a new device or software version comes out, you’ll use all the benefits that cloud provides and save money and time in the process.

The key here is to work with an experienced cloud partner who understands both infrastructure and applications management to help you assess where cloud brings you the most benefit—and where it could actually cost you more.

Myth #5: The Time to Talk About Applications Management Is After We Get the Cloud Infrastructure in Place   

It’s a simple fact: without proper planning, migrating applications to the cloud could be disruptive unless you factor in time for modifications and nail down the best approach for service restoration, support and handling new releases up front. Otherwise, applications management could become a bottleneck in bursting cloud environments. Although provisioning is automatic, for many applications, the process for tailoring those environments is still highly manual—no matter what provider partner you engage.

Bring applications management into the cloud conversation early on to minimize unexpected issues and recognize the benefits of your cloud migration more quickly.

The Reality:  Applications Management is Just as Vital in the Cloud

Although infrastructure, security and apps development take the spotlight on most IT agendas, well-planned applications management can make or break a successful move to cloud. The best approach is partnering with a provider who has broad experience in providing cloud environments, modernizing applications to take advantage of new methods and technologies, and supporting applications across a wide range of technologies and industries.

Just as important, get the applications management conversation started early. Bring your application team in on the initial discussions, and engage your provider’s applications management experts from the onset. Do this, and you’ll see real benefits and get more value from your move to cloud.

Post a Comment

Your email address will not be published.

( required )

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>