This content is part of the Essential Guide: Guide to SOA and the cloud
Manage Learn to apply best practices and optimize your operations.

Designing apps for optimal cloud performance control

A workflow and componentization analysis needs to be conducted prior to engaging in any cloud-optimized app design project.

From the early days of the cloud the focus has been on moving apps, which is logical given that the cloud was a new compute option. Over time, more enterprises have realized that the best cloud apps might be ones never executed for the data center. With that realization, planners and architects have been looking at designing apps for optimum cloud performance. 

What IT professionals have found is that it's critical to:

  • Look at workflows and componentization models first
  • Identify logical bottlenecks early in the planning process
  • Take full advantage of platform services from cloud providers
  • Build in monitoring and APM elements from the start

The benefits of cloud computing, the things that differentiate it from legacy data center computing, focus on elasticity and agility. Software architects know these are also attributes of componentized design of apps. However, every architect also knows componentization can be taken too far, to a point where workflows incur excessive overhead simply navigating from step to step. Thus, architects should realize any cloud-optimized app design needs to start with a workflow and componentization analysis.

businessman hand point to virtual button as cloud network concept

Enterprise architecture documents should provide cloud architects with a business-level picture of workflows. Where such foundation data isn't available, it should be developed by looking at the target application as a closed loop to turn worker input or requests into output. This high-level flow will be dissected into component workflows by the high-level software design process.

Roadmap for designing apps

Generally, the goal of designing apps for the cloud is to think of all apps as being a virtual-graphical user interface front-end process built on Web principles, supporting online transaction processing component flows from an intermediary data model. That model accomplishes two critical cloud goals: Create device independence and worker customization outside the app development process, and use proven Web techniques to allow front-end components of the app to scale with work volume. 

Build in performance management and monitoring capabilities at the design level.

The first step in designing apps for cloud performance control is to impose this model at the high level. The next plan of action is to look at the OLTP side of the app, the work needed to translate a general logical request into general, format-elastic, output.

This process will divide naturally into steps, many of which are related to getting or updating information. Each of the steps and their associated components will be bound by or be performance-limited by some specific resource set. To optimize cloud performance, three issues about this binding need to be addressed:

  • Can its work input or output be optimized?
  • Can its internal operation be accelerated?
  • Can it be replicated to enhance workflow processing?

At the design level, optimizing the component's I/O will normally mean controlling the amount of information that must flow in and out. That means taking care not to overgeneralize component workflows by pushing more data across a workflow than the component actually needs. It's tempting to create a big data element for a single transaction and pass it all along the workflow, but it's better not to move things that the component doesn't need or use.

The internal processing needs of components are related to the work transformation they're expected to provide. For processing, that's core to the functional mission of the component. The goal is to make the operation dependent on local resources where possible. 

If a reference table can be replicated without excessive cost, do so rather than create a central database that will have to be connected to its component users via the network. The value of local storage can often be enhanced by grouping components that have common data dependence into a single component or putting them adjacent in the workflow so that it's easier to optimize their connection. 

Always avoid mixing formatting and processing steps in the same component, because it can limit options for performance enhancement by component replication. It's harder to do that if the component is accessing what might have to be a shared data resource.

Components in a workflow that can't easily be replicated to improve throughput are natural bottlenecks that should be addressed at the design level. There are many ways to improve component-level performance by optimizing the ways critical resources can be used. 

Things to watch for

Look for cases where multiple components access the same database at different points for different information -- it may be better to get all the information on the first access. Also, be wary of componentization models with many workflow steps; performance for agility may be traded in a way that will be risky when application pieces are moved to the cloud.

Another thing to watch for is the opportunity to use a platform service from a cloud provider. Most large cloud providers offer cloud database management system services, workflow management and distributed workflow processing. These tools are often useful near the boundary between the Web front-end and the OLTP portions of apps.

Be aware that the aforementioned tools are often available only in the public cloud and only from some providers. Apps need to be customized to cloud platforms in order for them to be used effectively.

The final point is to build in performance management and monitoring capabilities at the design level.  Horizontal scaling, or even the use of tiered storage, can be optimized if the components are aware of performance enhancement mechanisms and can check to see when they're needed and how they should be coordinated. It's very hard to add throughput-enhancing options down the road without major surgery.

Performance in the cloud is more variable than that of the data center because details of resource assignment are unknown and can't be influenced. It's better to build performance enhancement and management concepts into the app from the start to avoid regretting not including them in the first place.

About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.

Follow us on Twitter @SearchSOA and like us on Facebook.

Next Steps

Top missteps in cloud app deployment

Designing apps with security in mind

How to develop mobile apps for the cloud

Dig Deeper on Distributed application architecture

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Do you think it's important to design apps with the cloud in mind?
Yes - if there's any chance you're going to migrate to the cloud, it only makes sense to think ahead so you're not spending further resources on redesign/optimization down the line.