The hype surrounding cloud computing promises substantial cost savings and faster time to market simply by moving apps to the cloud. But are these promises oversimplifying what it really takes to reap the benefits of the cloud?

The power of cloud economics is elasticity—the ability to selectively pay for resources only when necessary, scaling infrastructure on demand. When achieved, cloud elasticity provides important benefits, allowing enterprises to conserve budgets, quickly deploy and scale applications, and pay only for the infrastructure they use.

But to get elasticity, you must design for it, and this is harder than it seems. Because most enterprises’ application architectures aren’t designed to take advantage of cloud’s elastic infrastructure, they miss out on achieving the level of availability, performance and scale they desire. Elastic architecture requires real-time application load monitoring, scalable application components, and real-time automation, while most firms are still distributing resources statically, manually provisioning resources, and using architectures with built-in bottlenecks.

These architectural issues are a big reason why few business applications have made the jump to cloud. Most developers are simply adapting their conventional application architectures out of necessity, missing the benefits of elasticity. Even architects who attempt to build elastic applications within the limits of special-purpose APIs do not achieve the full power of elasticity, often failing to capture all three of the dimensions necessary for a truly elastic architecture: transactions, services and data.

The bottom line is that today’s approaches to elastic applications leave much to be desired for developers hoping to fully exploit the capabilities of cloud. The solution, of course, is to design applications that are fully elastic with the ability to adjust infrastructure resources to accommodate varied workloads while maintaining reliability and performance. Unfortunately, today this requires sophisticated developers who can design their own elastic application infrastructure and applications.

Bringing elastic applications to a broader community will require the industry to productize these elastic design patterns, simplifying the art of elastic architecture with the science of a platform, an elastic application platform (EAP). EAPs will provide tools, frameworks and services that automate the complex aspects of elasticity, normalizing the development of elastic applications, something that is decidedly not the norm today.

EAPs will provide development, runtime and operations management services, making several categories of services available to all developers:

Data Services support elastic data—and sometimes code, too. The data layer of an EAP provides data storage, retrieval and integrity services, and in some cases support for special-purpose code. Developers can use familiar file and Standard Query Language (SQL) abstractions as well as NoSQL approaches like key-value stores. In-memory, as well as elastic database options, will provide developers with new ways to balance data consistency and availability.

Computing services provide containers for elastic code execution. The computing services layer of an EAP executes code in the programming model chosen by the developer, and it may support elastic data. This layer is independent of operating system, language, application topology and, ideally, the development framework. Because the data layer can run code and the computing layer can contain data, they have an overlapping architecture to support the wide range of application design patterns that occur in cloud apps.

Interaction services manage channels and touchpoints. The mobile apps imperative is driving the need for interactions as a large portion of apps for iOS and Android have implemented server processing in the cloud. This creates a need for identity management and authentication, rendering content to a variety of channels and data aggregation services. Some EAPs will provide these interaction services, while others will rely on third-party products.

Development tools speed delivery of elastic applications. EAPs will provide or support varying development tools and frameworks. While some will invest in new development abstractions, others will focus on providing runtime services that work with existing development environments. Versions of popular frameworks, including .NET, Spring and Rails, will likely address EAP services.

EAP’s services allow elastic applications to run transparently without intervention from developers or administrators, distributing transactions, services and data across necessary resources, while avoiding bottlenecks that disrupt availability, performance and scale. In order to sustain performance, the EAP must monitor applications and address problems by automatically provisioning or de-provisioning computing resources.

Examples of EAPs can already be seen among currently available products for both public and private clouds, including some of the most popular platform-as-a-service offerings, but only a handful of these are as forward-thinking or as complete as they could be. By 2012, adoption of EAP will begin in earnest, with large organizations using EAPs out of necessity for both internal and public cloud deployments.

For all the attention cloud computing receives, we are just now understanding how to apply it to business applications. Begin by analyzing your business requirements for elasticity, then define your elastic application requirements and add elastic extensions to existing applications, eventually defining your elastic application platform. The cloud is here to stay, giving application development professionals who know how to design for it a definite advantage.

John Rymer is a vice president and principal analyst, and Mike Gualtieri is a principal analyst, at Forrester Research, where they serve Application Development and Delivery Professionals.