Cloud application performance management: Doing the job right
A comprehensive collection of articles, videos and more, hand-picked by our editors
Most thoughtful IT professionals understand that to tap cloud computing's full potential, they need to focus on...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
using applications that have been specifically designed for the cloud's features and capabilities. That means they've got to deal with issues such as application performance management (APM) in a cloud-specific way.
Cloud APM requires first designing cloud applications and planning cloud deployments to control performance. Next comes runtime adaptation of cloud component performance, which can involve both cloud-hosted and edge-connected APM elements. Finally, you'll need to integrate all of that into a cloud-based performance management architecture.
Battling workflow bottlenecks, taking the RESTful approach
The difference between deploying a cloud-specific application and migrating a conventionally designed application into the cloud lies in the ability to reflect cloud characteristics in application design. Experience shows that a good cloud-specific application starts with a componentization model that facilitates replication of components to accommodate workloads.
As most IT architects know, certain places in application workflows are likely to become bottlenecks. If you can replicate and load-balance the portions of application logic supporting these key places, you can significantly improve performance. When designing a cloud-specific application, it's important to separate these bottleneck functions into components.
The next design step: Ensuring that replicable components are designed with RESTful interfaces or that they have some database-driven back-end state recovery process, rather than being written using stateful logic. A component that maintains internal processing data from step to step in a transaction can't be replicated easily or load-balanced using simple tools.
When designing a cloud-specific application, it's important to separate bottleneck functions into components.
By making sure that every component can obtain its processing state with each new message, you'll ensure that runtime increases (and decreases) in the number of instances of a critical component that can be adapted to current application load. That will do more for response time than any other step you can take.
But having replicable components doesn't achieve replication at runtime, of course. Where components can be replicated for performance or availability management, it's important to deploy those components behind an elastic load-balancing function that can not only divide work among available instances of these critical components, but also spawn new instances or retire old ones if the load changes.
If the cloud application is based on message-bus/service-bus software, this may be built into the bus architecture. If not, most cloud operating systems and many virtual-network architectures for the cloud will include load balancing.
Distributing loads and hosting locations
Depending on the scope of the cloud resource pool and the distribution of application users, it can be difficult to position load-balancing functions in a way that avoids "hairpin" routes of network traffic from the user through the load balancer and then to the component instance.
If there's a single WAN gateway for traffic into the cloud, you should position the load balancer near the gateway. If not, you'll likely find that there's an optimum load-balance location for the expected distribution of users and possible component hosting locations.
Obviously, you can't move users around at will. So you may find it helpful to control the distribution of hosting locations when new copies of critical components are instantiated to avoid creating inefficient traffic flows. Those measures are harder to employ and control because they require optimization levels in hosting locations that aren't normally provided in software tools for cloud deployment. You may need to incorporate special facilities to support this capability in the applications themselves.
Traditional cloud APM mechanisms nearly always employ some form of application delivery control, the optimization of traffic to insure application quality of experience (QoE). Today, these are regularly applied both at the point of user connection and in the data center. Typically, they include prioritizing traffic to avoid delays and compression of information to improve the effective capacity of connections by reducing the number of bits exchanged.
It's nearly always possible to use end-to-end application development controller (ADC) facilities in the cloud if the host/application side is software-supported rather than appliance-supported; you can't easily install your own devices in the cloud provider's network.
Just make sure that you can combine the ADC facility into the machine image or template with the application for loading onto the cloud, and that a compressed data stream from a user-end ADC element can be load-balanced to any arbitrary copy of the application components. Be aware that some compression processes introduce stateful behavior, which will cause problems with applications that instantiate additional copies of components to improve performance.
Hosting tools in the cloud; avoiding a performance pitfall
It may be possible to host APM tools in the cloud itself rather than adding them to each application. A "virtual ADC" application could act as a gateway for user transactions, a point where traffic was uncompressed and then routed (load-balanced) to the correct component.
If you adopt that strategy, be sure that you host the virtual ADC on a cloud resource whose performance and availability are suitable to its mission. Because this function is in the flow of all application traffic, it will be a single point of congestion and failure. The virtual ADC model works best where an application's performance is limited by processing requirements in the application, rather than by the traffic-handling capacity of components.
A final point of consideration for cloud APM: the potential performance trap inherent in overlay virtual networking. Cloud-specific applications are likely to have multiple components, instantiate components for performance improvements and carefully manage locations and connections among application components.
Overlay virtual networks often simplify these network issues, typically by disguising the dependence between virtual paths and physical network resources. Any cloud-specific application will need network quality of service (QoS) assurances as a part of performance management, and you can't achieve that if you can't link virtual network connections to real network paths whose traffic can be managed to provide the requisite QoS. Taking care here will preserve all the good things that cloud APM can deliver.