Applications running on traditional bare metal servers in local data centers generally have linear rules for performance optimization: the slowest step in an application determines the speed of the application, and optimizing that step will speed up performance. If your CPU is spiking, add another processor. If disk I/O slows down your application, optimize the application’s I/O, or get faster drives.
Unfortunately, these rules can be obscured when the same application is transferred to a Public Cloud. Performance will vary depending on the options you’ve chosen for your instance, and on the underlying performance optimizations implemented by the vendor. An InfoWorld comparison test of 8 Public Cloud vendors found that similar offerings from different vendors had significantly different performance on benchmark tests, and a later, more in-depth test on Amazon’s EC2 cloud found significant performance issues when the proper sizing was not chosen for a Cloud.
On top of that, Cloud instances configured to automatically scale up resource use in response to performance slowdowns can cover up problems with application design or configuration – leading to a situation where applications fail regardless of the resources they’re given.
Performance testing before full scale implementation can provide the opportunity to benchmark your application, and determine the effects of resource allocation, application performance tuning, and overall application design before you rely on it to scale up automatically when you go live. In the best case scenario you would be able to experiment with scaling your application on one vendor, and then extrapolate those results to other vendors and look for the best deal. However, there is no apples-to-apples comparison between Cloud vendor offerings, so the results of Cloud performance testing will be unique to each vendor. The number of vendors you test will vary depending on time, budget, and how many make your CIO’s shortlist.
However, Public Cloud performance doesn’t end with optimizing your application in the Cloud – there are several additional performance factors that are not present in locally hosted applications:
1) Network Latency
Every I/O operation has some latency, however small that may be. Moving an application from a local LAN based server to a remote internet accessed server will increase the amount of network latency for an application. For web sites that were already being accessed by the public over the internet, this might not be in issue – in point of fact, if your Cloud vendor has a better network infrastructure, it could work in your favor.
2) Noisy Neighbors
From the Cloud vendor’s perspective your server instances are Virtual Machines (VMs) on a host that is shared with multiple other VMs. Cloud vendors have strict software protocols to make sure that each instance has its allocated resources, and is strictly segregated from other instances on the same host. That being said, it is possible that another Instance’s need for additional resources could cause a slowdown on your server until the resources are redistributed appropriately. InfoWorld’s EC2 test showed significant degradation in performance during periods of time when the EC2 hardware was heavily used.
3) Vendor Outages
Hidden though it may be, clouds are still built on hardware, and hardware fails. The data centers hosting the hardware are subject to natural disasters. The operators in the data centers can, and do, make mistakes. If your servers are at your site, you can troubleshoot a problem, correct it, and take steps to make sure it doesn’t happen again. If your servers are in a remotely hosted location, you rely on the vendor to manage problems, and, hopefully make sure they don’t happen again. About all you can do in the event of a vendor outage is to try to determine what went wrong, make sure you receive whatever benefits you are due from your SLA, and, if it happens too often, make plans to port your application elsewhere.
In the next part of this series we’ll look at reasons why you may not want to use the Cloud.
Additional Posts in our Considering the Cloud series: