Users and providers of cloud services experience cloud computing in different ways. Some much-hyped features of cloud computing are of greater value to cloud providers than to users.

• Hosted Web services can be experienced as cloud computing, but they'll prove more expensive and less flexible than genuine cloud services.
• Instant cloud elasticity is of value not only to applications with volatile demand (e-commerce), but also to traditional applications, with planned periods of activity and pause (day/night or holiday/other).
• Cloud elasticity is a direct value to cloud service providers. They may pass savings on to users, making cloud services less expensive than comparable on-premises or hosted services, but they may also choose not to, making cloud computing expensive over time, compared to on-premises deployments.
• Productivity and ease of access and use, not cost savings, will be the key benefits of public cloud computing.

• To offload the burden of managing data centers, look to cloud system infrastructure providers as the new emerging alternative, with potentially the greatest flexibility and best costs.
• To acquire software solutions, evaluate cloud services (and traditional packaged applications) based on current functional and business merits, not merely on cloud-computing promise.
• To build and deliver a business application in limited time, consider the "shared-everything" application platform as a service (APaaS), as well as traditional development options.
• IT organizations should begin interacting with cloud services from third parties, but most should not expect to use cloud computing for core business applications in the next 12 to 24 months.

The proponents of cloud computing often define the "new new" of this phenomenon as elastic scalability or multitenancy. However, these notions are usually not well-defined, and users are left wondering which is which, how they can know whether the service they are considering has these characteristics and why they need to care if they do. ("A software function available off a public source is a service, so why care about anything else?")

To answer this question, we look into the fundamentals of scalability, elasticity and multitenancy of business applications, with the aim of discovering the benefits, costs and relevance of each.

When a provider of a service looks at its technology, it sees the internal anatomy of the service: the hosting hardware, the operating system, the management and security layers, the data storage spaces, the application infrastructure (such as platforms, composition and integration tools, business process management, SOA governance, and others), and the business application code. The provider sees the application's front-end technology and its back end. To a service provider, the selection, ownership and architecture of each of these layers is critical — they determine the scalability of the application, the costs of its operations and its ability to adjust to changing user requirements (agility).

IT vendors are not the only providers of cloud services. Some business organizations (enterprises) that manage data or services that may be useful to other organizations or consumers will, over time, expose some of their software solutions to the outside world, thus becoming cloud providers, potentially turning their IT organizations from cost centers to profit centers.

When consumers (users) of a service look at a service, they only see the interface — the external edge of the service. The details of its internal architecture are not immediately apparent or important. However, making an uninformed selection of a service is a short-sited and potentially costly approach. The internal characteristics of the service-enabling technology will determine the long-term ability of the service to reduce costs, scale and adjust as the business contexts change.

• A dedicated hosted service and an elastic multitenant service may look and cost the same at the start; however, over time, they will impose different degrees of burden of change and costs on their users.
• A tactical cloud-user view is concerned with the functionality and current characteristics of the service, but a strategic view must also include a degree of insight into the internal architecture behind the service interface.

Also note that most application developers (users of APaaS services) will not become experts in building elastic solutions; rather, they will rely on the underlying platform technology to embed this and other expected cloud characteristics into the applications. Choosing a platform with advanced cloud-enabling capabilities will ensure that developers have the opportunity to build advanced cloud applications. Ignoring the internal architecture of the platform might place the expensive burden of cloud engineering on the application developer.

Scalability of business applications has to do with the ability of the application platform to respond to increasing (or decreasing) workloads without application redesign or redeployment.

Simple scalability is concerned with one application at a time, and typically only with the support for increasing demands. There are two recognized strategies of scaling an application through hardware:

• "Scale up" (vertical scalability) is the reference to scaling by increasing the computing power of the hardware platform where the application is deployed. Mainframe is the typical platform suitable for scaling up because of its massive power, although scale-up is also possible in modern, multicore processor architectures.
• "Scale out" (horizontal, linear scalability) refers to scaling by adding more machines. To be able to use the scale-out method, the application infrastructure (platform) and the application must be able to take advantage of the additional machines as they become available. If the application (or application platform) is not designed to scale out, to "spread over" additional machines, then adding the machines will not improve performance or throughput of the application.

For real-time scale out, the platform and the application must be able to incorporate new machines as they become available — automatically, without manual input and without disruption to its running transactions.

Manual scaling requires human intervention, configuration and, often, a restart of the live application system.

The cloud-computing providers typically use a massive scale-out model (also known as grid). Therefore, application scalability in the cloud requires that the application platform and the application be designed to run on a changing number of underlying machines. Automatic scalability requires additional design for triggering the scale changes, and for automatic extension of application functionality over newly added machines. The more the application platform manages the logistics of the scalability, the less the developers of the business application must be aware of it. However the most-advanced results are achieved when both the application platform and the application code are designed for cloud-style horizontal scalability.

Users that are looking to gain the scalability advantage from cloud computing must ensure that their applications and application platforms are designed for horizontal scalability. Service providers offering guarantees of scalability must be careful to price their services in a way that covers the required capital investment to deliver on these commitments. Simple scalability guarantees might require proactive investment, and results in increased costs of business for both providers and users.

Elasticity refers to the ability of the application environment to both increase and decrease its computing capacity in response to changing demand, reuse of the resources that are freed up when demand decreases and the billing of users in proportion to real use of resources. It is scalability in both directions (see "Cloud Services Elasticity Is About Capacity, Not Just Load"). It may be controlled automatically or manually. Automatic elasticity implies that the changing requirements are detected automatically, and additional capacity is provided to the application as needed, and removed when no longer needed. The freed capacity can then be used elsewhere. Elastic environment can balance the use of resources among players of multiple types: applications, jobs, paying customers or enterprises (tenants). This achieves better resource utilization and lower operational costs per transaction per player. When there is only one player (application, tenant), elasticity becomes academic (freeing the resources is pointless if there is no one else that would use them). When multiple players share common resources, elasticity can be beneficial to all. The participants in elastic scalability see their computing environment as a shared pool or resources.

It is also notable that elastic environments can be automatically resilient — the loss of a resource is automatically compensated by adding a new one. Applications that are designed or configured for replication of their content get the full advantage of this added benefit of elasticity.

Sharing resources in response to demand (elasticity) is not entirely new. Multitasking operating systems allocate resources to tasks, as demanded, and time-sharing mainframe models partition the mainframe resources among regions (Sysplex and CICSplex are examples of mainframe clusters of shared resources). In most such scenarios, increments of elasticity are either very small (individual task) or very large (whole regions), and the allocated resources are determined by configuration, not by real-time changing demand. The real-time bidirectional elastic scalability and application-level granularity of managed resources are the major differentiators of modern cloud computing from its predecessors.

Gartner's definition of cloud computing requires elasticity, although this view is not universal. IBM, for example, seems to have positioned any resource pooling as cloud-computing style. Its recent WebSphere CloudBurst Appliance offering is an example of such a strategy. Some other private cloud offerings similarly focus on pooling resources, not on their elastic allocation.

Although useful, especially to users looking to continue on the path of improved resource utilization beyond virtualization, basic pooling of resources alone will not deliver all potential cloud benefits.

• Users looking to reduce costs by using cloud computing may have an opportunity to do so by engaging in elastic sharing of resources and paying for resources in proportion to use. However, the cloud providers may not pass enough savings to users to achieve long-term cost reductions. Some users might prefer a fixed cost of computing (for budgeting or other reasons), and, in that case, should not count on significant cost savings.
• Cloud service providers will benefit greatly from enabling internal resource elasticity — allowing the same resources to be reused across their multiple (many) users, tenants and applications, thus increasing resource utilization and decreasing capital costs per serviced transaction. The added level of resilience in the cloud environment improves the availability measure of the environment as well.

Elastic scalability deployed in the way that sharing of resources occurs between multiple tenants is multitenancy.

There can be tenant enterprises (multiple organizations signing up to use the same cloud application) or tenant applications (different applications sharing underlying resources of application and system infrastructure).

To illustrate, the allocation and sharing of resources in a multitenant-enterprise environment occurs between tenant instances of an application. An application service provider registers a customer (tenant) that customizes the application, thus creating a distinct instance. This application instance is accessed by users registered by the tenant organization, and is invisible to other tenants. The controlling platform provides computing resources to each application instance to meet the expected performance characteristics, as needed. The service provider tracks resource usage per tenant and charges them in some proportion to use, as agreed on.

The application instances can be logical — in a shared-everything multitenancy environment (see "Reference Architecture for Multitenancy: Enterprise Computing 'in the Cloud'") or physical — in a shared-hardware multitenancy environment (see Figure 1). Each tenant operates in its application instance, and the resources are given to or taken from these instances, as needed, by the controlling elasticity layer. That can be a multitenant software-as-a-service (SaaS)/cloud-enabled application platform (SEAP), such as technology in Force.com (see "Introducing SaaS-Enabled Application Platforms: Features, Roles and Futures"), or a dynamic virtualization layer such as that offered by Elastra or RightScale.

Shared-hardware multitenancy is achieved by multiple tenants sharing only the pool of virtual machines. Shared-everything multitenancy is achieved by the use of an SEAP that coordinates allocation of database and processing resources to tenants. The shared-hardware model has a minimal scope of sharing (hardware only, using operating system virtualization). The increment of elasticity here is coarse (the whole virtual machine), but it does not require modifications to the software stack above it. Traditional application platforms and applications can be ported to shared-hardware multitenancy with minimal or no change.

The shared-everything model is more advanced in terms of its scope of elasticity, because the tenants share the full underlying software stack; however, it is also more disruptive in terms of its programming standards, because the underlying platform technology must be SaaS/cloud-enabled to support multitenancy. While the shared-hardware model depends on virtualization, the shared-everything model does not require it (and does not incur its overhead), because the resources are managed and balanced at a higher level.

Although the cost of shared-everything elasticity is disruptive (with a required transition of applications to a new platform model), its progressive differentiating characteristics include:

• A single platform technology stack shared by thousands of application instances can dramatically reduce the total resource consumption (a benefit to the provider that may be passed to users through reduced transaction costs).
• Adding a new tenant may not require any resource provisioning, as the tenant is joining a shared-everything stack from hardware all the way to the application (a benefit to the user in the time to solution).
• Version control for the application infrastructure and the application is much simplified, given that all tenants use one and the same instance of the platform and the application, and versioning occurs only once, not once for each tenant stack (a benefit for provider and user, in reducing versioning costs).
• If metadata is used to encode the business logic of the application, then customization per tenant does not require any new configuration, database allocation or software packaging, even when customization is as deep as adding new data-intensive functionality (a significant benefit to users in flexibility and productivity).
• Use of interpreted metadata, rather than compiled executables for application business logic, incurs overhead, which is the price of this benefit.
• Although metadata interpretation is not definitional to shared-everything multitenancy, it is common. It is difficult to implement automatic isolation and protection of tenants without controlling the application execution, and a metadata interpreter is a perfect answer to this challenge.
• Another advantage of interpreting metadata for application execution is that technical problems ("bugs") can be introduced by the interpreter, but not the application developers. Assuming that the expertise of programming and testing that goes into engineering of the interpreter is much higher than that available for application design — the overall environment may become a lot more technically reliable and predictable.
• The shared-everything application platform is designed to take advantage of all available systems infrastructure (compute and storage) and automatically scales horizontally in both directions (up and down) — not by adding or removing entire virtual machine stacks, but by managing internal resources of the application execution environment. A benefit to the provider is the escape from overhead of virtualization and multiple instances of the application container and database management system. A benefit to users is, within limits, consistent throughput and performance seamlessly responding to changes in demand.

Because the shared-everything model manages virtual tenant instances of applications, it has to provide for multitenant customization of the application, where multiple instances are distinct and isolated, yet all run in the same physical instance of the application. The best practice for achieving this is to use metadata to encode the application. When application business logic is encoded largely as metadata, its execution logic is interpreted at runtime, rather than compiled, which allows easy coexistence of partially customized versions of the same application. A side effect of the use of metadata to encode business logic is the improved productivity of initial development, and the subsequent change or customization of the application. Thus, although production productivity is not a definitional characteristic of cloud computing, the shared-everything model of cloud multitenancy is distinct from other application environments by its notably increased productivity. In fact, this substantial increase in productivity of business software engineering might turn out to be the more mainstream, attractive attribute of cloud computing than its core characteristic of elasticity or off-premises execution (see "APaaS: A Step to a 'Killer App' for Cloud Computing?").

Use of metadata for encoding application business logic also adds some performance overhead, which is the cost of improved productivity. Whether the cost is worth the benefit will depend on the type of application and will likely make shared-everything cloud computing less attractive to the most demanding advanced application projects.

• Users of applications that have a steady demand for resources are likely to get sufficient benefits from shared-hardware multitenancy. Users of applications that are more dynamic and require ongoing, fine-grained allocation and deallocation of resources will benefit from the elasticity of shared-everything multitenancy.
• The main relative benefit of the shared-hardware model is its backward compatibility. Consequently, the developer productivity in a shared-hardware environment is no different from the on-premises environment.
• Service providers will benefit from lower costs of application version control and support, tenant onboarding and management in the shared-everything model. Providers planning to port existing applications to cloud services will benefit from reuse of traditional application platforms and programming models using the shared-hardware model.
• Users and service providers looking for highly productive and flexible application engineering environment, and willing to adopt nonstandard programming to achieve this productivity, will benefit from the shared-everything implementation of cloud computing.

When selecting a software service, users are well-advised to be aware of the following spectrum of models that may be deployed by the provider to deliver service. Although all models provide some degree of "cloudiness" and are models of service delivery, the long-term implications of the internal model on cost, scalability and flexibility of the service can be vast.

These are dedicated resources, with full costs born by the user, scalability that is slow (hours, at best, but typically days or weeks) and expensive. Users retain near-full control of resources, despite delegating platform ownership responsibilities.

Applications are able to run on a small network of servers (a few dozen, at most) that are united by a single distributed instance of a "clustered edition" of an application server (AS) into a single AS cluster. The AS cluster can have some servers added to it with some additional configuration to the AS profile, and usually a restart of the system. Most current AS technologies support this capability. Its main objective: improved availability and throughput of the application.

Note that the AS clusters are not the clusters referred to in the system infrastructure space, where clusters are a kind of compute grid typically established for scientific, high-performance computing projects (see "How Cloud Computing Relates to Grid Computing").

Applications are able to run on a large network of servers (hundreds) easily extended without intruding on the running applications. Most current AS technologies do not support this capability, but all advanced extreme transaction processing (XTP) platforms do. Its main objective: resilience, throughput and automatic scalability at minimal costs.

Note that the XTP grid is not the grid referred to in the system infrastructure space, where a grid is designed for parallel processing with the objective of high performance, not high throughput. The system infrastructure grid is typically established for scientific, high-performance computing projects, and is a special kind of system infrastructure cluster (see "The Evolution of Grid Computing"):

Adding or replacing machines requires manual intervention, typically with some disruption to running software.

The addition, removal and replacement of machines, beyond physical procurement, happens automatically and without disruption to running software.

Computing resources are pooled and allocated/deallocated to different projects or running application instances as needed, without a disruption to the running system. Its main objective: maximize resource utilization, reduce costs.

The allocation and deallocation of resources is unintrusive and automatic, based on monitoring of performance and preset policies. Its main objective: uninterrupted business in a volatile context at a use-base cost.

Computing resources are shared among instances of applications dedicated to tenants (enterprises). Its main objective: reduce redundancy, version proliferation for providers, cost for providers and users.

The shared resources are the machines; the software stack from the virtual operating system (virtual machine) and up is dedicated to the application or tenant, and each tenant has a separate stack of software from the operating system and through the customized application instance. Its main objective: increase hardware utilization, reduce costs.

The shared resource is the application platform (container, AS); each tenant has its own logical or physical database instance, but all tenants share one instance of the AS. The AS manages tenant isolation (it must be so equipped, and is referred to as an SEAP). Its main objective: reduce application platform license costs; reduce redundancy and idling of application platform resources.

The shared resource is the application platform and the application database management system — all tenant application instances run in one physical instance of the application, application platform and database; everything is shared (as the name implies). Its main objective: eliminate redundancy; minimize resource idling, costs and burdens of versioning.

All the above models of software architecture carry a degree of "cloudiness," and many may be experienced at first glance as cloud services. Each may be the right approach, depending on the project objectives. Yet, only all of these capabilities together have the potential to transcend their initial objectives of savings and consolidation, and deliver the "unintended consequence" of a new high-agility, high-productivity, resilient and always-on enterprise IT.

There are multiple technology models used to enable software services (cloud or not), from hosted services of websites to Web applications to hosted virtualized machine pools to multitenant platform software stacks to applications that are custom-designed to include multitenancy. All such services might look and cost the same at the start, but each will have a different pattern of use and total cost of ownership, when you take into account the changing use patterns and business requirements over time.

Users planning short-term, experimental use of cloud-style software services may concentrate their selection research on the business functionality of the service and its current business and technical merits. Users contemplating a strategic, long-term commitment to a cloud-style service are well-advised to take a strategic approach to selecting such a service, and to start by understanding the trade-offs of different models of internal design of such services.

Independent application software vendors can migrate to cloud service offerings quickly and inexpensively by using the shared-hardware model. However, those vendors should realize that shared hardware is a kind of a "screen scraping" approach, migrating the old way of computing to a new context. As such, it has limited long-term prospects, despite its apparent low-cost immediate benefits. Independent software vendors are well-advised to plan a transition to a genuine shared-everything application platform for the next generation of their cloud services.

"Who's Who in Application Platforms for Cloud Computing: The Cloud Specialists"

"Who's Who in Application Platforms for Cloud Computing: The Enterprise Generalists"

"Trends in Platform Middleware, 2009: Facing the Cloud Upheaval"

"APaaS: A Step to a 'Killer App' for Cloud Computing?"

"Application Infrastructure for Cloud Computing: An Emerging Market"

"Reference Architecture for Multitenancy: Enterprise Computing 'in the Cloud'"

"On Apples, Oranges, Amazon and Google"

"Key Issues for Cloud-Enabled Application Infrastructure, 2009"

"Who's Who in Distributed Caching Platforms: IBM, Microsoft and Oracle"

"How Cloud Computing Relates to Grid Computing"

"Three Levels of Elasticity for Cloud Computing Expand Provider Options"

"Cloud Services Elasticity Is About Capacity, Not Just Load"