Beware these pitfalls when moving enterprise applications to the public cloud

While the public cloud represents an opportunity for new cloud-native apps, organizations should tread carefully before placing traditional enterprise apps in the cloud.
Written by Keith Townsend, Contributor
Image: iStock
There are many advantages of the public cloud for cloud-native apps. The ability to adjust infrastructure based on business demand is a key advantage. Public cloud solutions make next generation web-scale applications such as Netflix possible. The pay-as-you-go nature of infrastructure as a service (IaaS) solutions enable startups such as Uber to entirely disrupt industries while keeping costs in check. The obvious question is, what are the downsides to moving an existing enterprise application to public cloud providers?

At the end of the day, isn't a virtual machine (VM) a virtual machine? Does it matter if your SAP NetWeaver instance is running in your on-premises virtualization cluster versus on Amazon's or Microsoft's cloud infrastructure? I'll take a look at some of the hidden challenges of moving traditional enterprise applications to the public cloud.

Reduced infrastructure visibility

Today, infrastructure teams begin monitoring applications at the infrastructure layers. Customers currently have mature network, storage and server monitoring solutions in place. These tools are finally to a point that event correlation is dependable. For example, storage array events detected via the monitoring tool can alert both the storage engineer and the Oracle DBA. The advanced notification allows the DBA to proactively adjust database settings based on storage performance.

Public cloud solutions do not provide this level of visibility to their customers. All of the components under the VM are abstracted. Customers must learn to monitor application and performance without direct insights into the underlying infrastructure. Instead of relying on infrastructure-specific data, infrastructure teams need to align with application teams to measure performance. Infrastructure management becomes verification of performance instead of monitoring for infrastructure health.

Redundancy design differences

Public cloud solutions were designed to run applications that handle failure. Traditional enterprise applications were designed to run on resilient infrastructures. I can't overstate the importance of this difference. Take Amazon Web Services (AWS) for example. AWS begins to provide credit for uptime measured at less than 99 percent. Netflix's Chaos Monkey is an example of a tool used to test for application-level efficiency. Chaos Monkey creates failures within a cloud-native application to test for resiliency.

Traditional enterprise applications rely on resilient infrastructure and infrastructure tests. For example, VMware and Microsoft environments rely on live migration technologies to guard against hardware failure. Many organizations rely on storage-based replication to protect persistent data such as databases. Enterprise infrastructures normally offer 99.9 percent or greater uptime service level agreements (SLAs) to their internal application owners.

It's not uncommon for infrastructure teams to fail entire storage array and network paths to test for infrastructure availability. Other than a notice for awareness, application support teams have little, if any, involvement in resiliency testing.

Workload portability complications

There are very few, if any, standards in public cloud computing. While converting a VM from one cloud provider's format to another can be simple, moving processes from one provider to another can be much more complicated.

Take network security, for example. The model for networking in VMware's vCloud Air is completely different from AWS. Without getting into the discussion of security tools, both services take a different high-level approach to networking and therefore security. vCloud Air enables layer-2 networking. This means each VM sees the Ethernet network. VMs can be grouped based on Ethernet security zones. This approach is very similar to traditional enterprise networks. AWS hides the layer-2 network from customers. AWS leverages IP-Tables to control VM-to-VM communication. So if two application servers need to communicate with each other, an implicit rule must be created within each instance to allow the communication.

Storage consumption shows a similar difference. AWS leverages its object-based S3 storage solution, while vCloud Air presents traditional block-level storage to its customers. The result is two different administrative models for consuming and managing cloud-based storage.

The difference in infrastructure interfaces adds complexity to workload migration. The friction results in lock-in to specific cloud providers. Comparing cloud providers is sometimes an apples-to-oranges comparison, but comparing traditional data center providers is simple. Data center managers can compare environment variables between data center providers as part of the selection criteria. Processes for interfacing with the infrastructure remain the same regardless of the provider of the physical data center.


The public cloud has many advantages for organizations looking to deploy cloud-native applications. However, I struggle to see the advantage of moving traditional enterprise applications to the public cloud. It's a horses-for-courses argument.

Editorial standards