Dispelling 3 Myths of Cloud Application Migrations

While cloud migrations are often needed, misconceptions abound. Jason Cumberland of Dimension Data explains three of the most common misconceptions about moving from a dedicated server deployment to a cloud environment.

Jason Cumberland is vice president of SaaS Solutions for Dimension Data, a $5.8 billion global ICT solutions and services provider.

JASON CUMBERLANDDimension Data

Migrating a traditional application to the cloud isn't always as complex as it appears. Here are three of the most common misconceptions about moving from a dedicated server deployment to a cloud environment.

Myth 1: The cloud won’t support networking for multi-tier applications.

While software-defined networking (SDN) is undoubtedly white-hot in IT, the reality is that it's still a developing and unproven technology among enterprise buyers. One hurdle is the unforeseen risks associated with new concepts, such as security groups that are usurping traditional enterprise security rules and firewall designs. For companies delivering SaaS or other enterprise applications, clients are likely to be uncomfortable with the security delivered through these designs. Case in point, this August Amazon Web Services’ security group policies resulted in virtual machine connectivity losses, among other glitches. For end-users in industries such as banking, financial services and healthcare, this kind of concept and security risk can be a deal-breaker.

Moreover, any application written more than two or three years ago was almost certainly written to operate in a traditional 3-tier architecture with separate network segments for web, application and database servers. Generally, each of these tiers has its own firewall rules and load balancing profiles. Re-architecting all of this to function in a flat network can be a multi-year endeavor that isn’t worth the cost, when you consider that there are already cloud environments today that support a traditional network architecture.

Lastly, many cloud vendors have chosen to implement a Layer 3 network topology, which leads to significantly lower performance than a traditional Layer 2, hardware-based network with reserved performance for each segment of the network. Is your application used to operating at wireline speeds and latency? What happens if you migrate that application to a cloud delivering 1/4 to 1/3 of Gigabit wireline speeds?

If you're considering the move, you have two options: rewrite the application to deal with varying degrees of network latency and throughput, or choose a provider who is able to deliver this performance as a part of their standard platform.

Myth 2: My database won’t run in the cloud.

One to two years ago, the belief that databases couldn't perform well in the public cloud was still valid, but much has changed in a short period of time. A handful of cloud providers now offer high-performance database options in the cloud. There are several ways to deliver databases in the cloud. Tiered storage offerings provide three disk speed options, with the highest tier designed specifically for transactional databases.

Companies like Zadara Storage even allow Microsoft SQL clustering in the cloud, which, in addition to enabling failover clustering, allows 100 percent customizable RAID storage options (from SATA to SSD, RAID 1 to 10, and most other options in-between). An experienced service provider can easily build an integration path for dedicated physical servers into cloud environments when neither of the previous two options are ideal.

Myth 3: The cloud isn’t reliable enough for my application.

Despite what the market may want you to believe, all cloud platforms are not inherently unreliable, and your application does not have to be designed to treat every server as disposable. It is not necessary to design for the fact that on any given server deployment, you might be allocated a "bad" VM, which you should automatically detect, delete, and replace with a properly performing machine.

Maybe this doesn’t have to be so hard. Enterprises often fear that they are not ready for cloud because they haven't yet re-architected their applications to account for these perceived shortcomings in the public cloud. While these problems do exist on some platforms, they are not prevalent everywhere. Given the massive costs of an application re-write, vendor and platform selection are critical to ensure that your chosen platform supports the current state of your application without months or years of work required to make the leap.