There are common mistakes many organizations make when they deploy apps in clouds. The obvious ones usually center on app performance, app security and tools to monitor virtual environments. But there are other common mistakes that occur as well.
The mistakes associated with application deployment
Organizations fail to do the upfront planning required to determine which apps are good candidates for cloud deployment.
Apps requiring big iron, apps running on UNIX clusters, and many legacy apps running on mainframes aren't meant to be moved into the cloud. Some of these apps are complex, and deployment in x86-based hardware and software virtual environments may require re-architecting or rewriting the apps. If the deployment cloud happens to be a public cloud, then apps with high security requirements may not be good candidates.
Organizations fail to pick the correct cloud model, private or public, for app deployment.
Apps can be deployed in private clouds or public clouds. Private clouds are on-premises clouds under the control of the IT organization that created them. They have more similarities with the traditional data center (they are on-premises, under the control of IT, do not have some of the security issues of public clouds, etc.) than do public clouds.
Public clouds are off-premises. The infrastructure of a public cloud is determined by the cloud provider and may present a much different look and feel than the traditional data center, or even a private, on-premises cloud. The mistake that organizations make is failing to determine which apps are good fits for public clouds and which are better suited to private clouds. Another common mistake is failing to determine the costs, long term and short term, in deploying apps in each cloud model.
Organizations tend to focus on "migrating" servers to the cloud versus deploying apps in the cloud.
When organizations decide to move from the traditional data center to a private cloud, the motivation is frequently server consolidation, which leads to improved server utilization and reduction in capital and operating expenses. This should not be the focus. The focus should be on deploying apps in the cloud. By focusing on app deployment, enterprises will gain insight into the makeup of an app and the management tools needed by the app in a cloud environment. This mistake fosters a number of other common mistakes.
Failing to plan for changes in app performance in the cloud
Deploying an app in a cloud may result in a performance level that is lower than in the traditional data center because of the differences between the two. Organization administrators usually focus on CPU power, memory, disk storage, etc. when they think of app performance. In the traditional data center, the app is probably the only app running on a server. The app is tuned on that server to reach an acceptable performance level using physical server monitoring tools.
When an app is deployed in a cloud, it shares physical CPUs, physical memory, etc., on a single virtual host server with several other apps in a virtual environment created by hypervisor software such as VMware ESXi or Xen. These apps are simultaneously contending for the physical resources of the virtual host server. Performance tuning for the app in the cloud begins in this new ecosystem.
Before an app is deployed in a cloud, you should create a baseline performance for the app that is satisfactory for fulfilling business needs. When the app is deployed in the cloud, you should examine its performance and compare it against the baseline performance, making adjustments until an acceptable performance level in the cloud is reached. To do this type of performance analysis, you will need performance monitoring tools that work in virtual environments.
Failure to understand that new tools are needed to monitor app performance, security and network traffic
Some organizations fail to understand that tools that worked in the traditional physical environment are not sufficient for the virtual environment of a cloud. Monitoring tools help answer questions such as: What is the performance of an app? Is an app gaining access to compute and storage bandwidth when needed? What is the response time from storage devices that an app accesses? Is my app being protected from intruders?
Virtualization has added a layer of abstraction to traditional monitoring. You can no longer monitor performance just by looking at physical devices. Network operations teams have struggled to look through this abstraction to determine what is actually happening at both the virtual and physical levels.
Because lots of traffic occurs within a hypervisor without making it to the physical network, you need tools designed to work in virtual environments. Physical-based monitoring tools do not see the traffic flowing among virtual elements such as virtual servers, virtual routers, virtual switches, etc. Monitoring app performance and the performance of resources that surround and interact with an app in a cloud environment requires new tools designed for virtual environments. The same can be said for app security. Tools such as Catbird Network's vSecurity are available for addressing security concerns by monitoring the traffic on virtual networks.
Failure to understand how an app fits into the big picture of cloud computing
When an app is deployed in a cloud, just about everything associated with that app is different. The performance is different, the monitoring tools are different, security is different, system management tools used to manage virtual servers are different, and the act of deploying an app is different. These differences place a strain on the organization whose job is to manage the cloud, requiring changes to traditional processes for deploying and managing apps in a cloud environment.
Cloud vendor selection usually implies an infrastructure and ecosystem that can have a large effect on the deployment of apps in a cloud. Proper selection of vendor(s) and virtualization software, such as hypervisors, involves understanding how an app fits into the big picture of cloud computing, and determines, to a great extent, whether or not you can move apps between private and public clouds to take advantage of the hybrid cloud model.
This was first published in July 2012