Gartner Reference Architecture for Cloud-Enabled Application Platforms

Application servers (platforms) are a well-established technology category. The emergence of platform as a service (PaaS) – and with it, the new demands for cloud-worthy capabilities in platforms – is rewriting the priority lists of technical architectures and producing a new vendor race to leadership in cloud platforms.

• Cloud-enabled application platforms (CEAP) are, at their core, application servers extended with cloud-supporting functionality. They enable multitenancy at the container level.
• When a CEAP is deployed by a cloud service provider and offered as a service, we refer to the offering as an application platform as a service (APaaS). The reference architecture of a CEAP is also the reference architecture of the technology behind APaaS.
• The three key components of a CEAP are the extreme transaction processing (XTP) foundation attributes to support cloud-computing scale; cloud attributes, such as multitenancy to support the shared, one-to-many cloud use model; and application server functions, such as container and interoperability to support heterogeneous open access to and from its cloud services.
• APaaS is a component of the larger comprehensive PaaS. Over time, the leading CEAP/APaaS providers will expand to compete in the full PaaS market.

• CEAP/APaaS technology is in the early stages of development. Users should begin adoption gradually, with the understanding that the next three years will deliver substantial changes in technology, standards and vendor landscape. However, while there is a risk of getting into the new technology too soon and too much, there is also a risk of avoiding a fundamental new technology opportunity for too long. Most IT organizations doing application development should establish some experience with CEAP/APaaS in the next 12 months.
• Understanding the technology fundamentals of a CEAP/APaaS will enable the informed selection of providers, fit to the requirements of the project.

This document was revised on 7 July 2010. For more information, see the Corrections page on gartner.com.

Application infrastructure (also known as middleware) is the part of a software stack that underlies business application software and, in turn, layers over the system infrastructure software (see Figure 1). The key components of application infrastructure include application servers, database management systems (DBMSs), integration middleware and many others. The system infrastructure software interacts with hardware. It includes OSs, virtualization software, storage software and networking software. Business application software deliver the business function of IT to its business users. You will always know a business application software offering by the fact that it is used by the business users of IT, not by IT projects. Examples of business applications include ERP, CRM, e-mail and many others. Application infrastructure software is sold to IT projects to facilitate development, deployment and management of business application software. System infrastructure software wraps all hardware interactions and allows the application infrastructure (and, therefore, the applications) to be hardware-independent.

The cloud data center (the data center of a cloud service provider) shares fundamental architectural components of its software stack with any other data center (although it requires some capabilities that may not be relevant on-premises and some extra operational flexibility). In the cloud data center, as in a traditional enterprise data center the software stack also consists of system infrastructure layer that wraps the hardware interaction, the application infrastructure layer that serves as the foundation for business applications, and the business application software. All three layers, two layers or only one layer of the stack may be offered by the cloud service provider as a service. When offered as a service, the three layers are referred to as:

• System infrastructure services (or infrastructure as a service [IaaS])
• Application infrastructure services (or PaaS)
• Application services (or software as a service [SaaS])

Of the many technology components of an application infrastructure, application servers are among the most central. A basic application server consists of a runtime container to host the business logic of the application and provide some degree of access to and quality of service (QoS) of the executing application. Real application servers include a wealth of additional capabilities – for ease of programming, integration, composition, multichannel access, distributed computing, event processing, memory management and more. Often, the combination of an application server offering and its environment is referred to as an application platform to reflect the richness and completeness of its functional content. When offered as a turnkey ("retail") cloud service, an application platform is an APaaS. Just as on-premises – where application servers are combined with DBMSs, business process management systems (BPMSs), portals, enterprise service bus (ESB) suites and other application infrastructure products to form a comprehensive application infrastructure platform – "in the cloud," too, APaaS represents only part of the comprehensive application infrastructure suite (a PaaS).

There is, however, a key difference between the assembly of a comprehensive application infrastructure suite on-premises and in the cloud. On-premises, the many components of application infrastructure may be acquired from different vendors, but they end up deployed in one data center. In the cloud, different application infrastructure services offered by different providers are running in different data centers. In some cases, colocation (in the same data center) is essential for performance, integrity and other reasons (for example, the application execution container and the DBMS that hosts the application's core data must typically be colocated). In other cases, the colocation is less critical (for example, asynchronous application integration). However, in most cases, the performance of a comprehensive application infrastructure suite and its manageability are better when all components are in the same data center. Thus, while in traditional on-premises deployment, the best-of-breed assemblies of application infrastructure products are common, in the cloud, the more ambitious providers tend to assemble most of the application infrastructure suite in their own contexts over time (while smaller specialist providers tend to form colocated communities). With time, the leading providers of APaaS are likely to evolve into the providers of a comprehensive or topical PaaS suites as well.

The comprehensive PaaS suite would offer the complete application infrastructure selection – all colocated in the logical data center of the provider (a logical data center may, in fact, be distributed across multiple physical data centers). The topical PaaS suite would focus on a particular use scenario and offer the complete selection of technology services for that kind of effort (for example, an integration-focused PaaS suite, a business-process-management-focused PaaS suite, etc.). In the future, Users will tend to select comprehensive PaaS suites or topical PaaS suites (offered by a single large provider or a colocated community of smaller specialist providers), rather than depending on different independently located cloud providers for different basic application infrastructure services. Today, however, most cloud application infrastructure service offerings are focused on a limited service – a sign of the immaturity of the entire field.

APaaS is a service to its users; however, the providers of the APaaS service must deploy a relevant technology stack in a data center to offer the service. That technology is mostly that of an application server, but extended and modified to meet the requirements of cloud computing: shared multitenancy, fine-grained use metering, elastic horizontal scalability, etc.

Some of these cloud-enabling features of APaaS may be provided using advanced virtualization management at the system infrastructure level (the shared-hardware model of multitenancy, see "Reference Architecture for Multitenancy: Enterprise Computing 'in the Cloud'"). In that case, a nearly standard application server can be used as the technology base for the APaaS offering. However, the level of support for cloud-computing requirements, when using the shared-hardware model, is limited (including in granularity of resource increment, flexibility of customization, time to add a new tenant, and flexibility and granularity of use tracking and billing). Also the business application services that use shared-hardware model for multitenancy must be designed as stateless and horizontally autoscalable to exhibit elasticity (not default characteristics of most business application software). The shared-hardware style APaaS uses traditional application server technology and familiar programming models, but delivers limited cloud functionality.

More advanced is the model where multitenancy and other cloud requirements are supported in the application container itself (shared-container or shared-everything models of multitenancy). Such application platforms, enhanced internally to natively support the requirements of cloud computing, are CEAPs.

Some CEAPs are not sold commercially as products, but are used as the technology base of an APaaS offering by the APaaS provider (e.g., Force.com, App Engine). Other CEAPs are available as products for third parties to buy and deploy (e.g., Magic Software Enterprises, LongJump). Application independent software vendors (ISVs) may be interested in buying a CEAP as a product to port their business applications to them, then offer their applications as a service. Some IT organizations may also be interested in a CEAP as a product to form a private cloud environment. There, the emphasis may be more on tenant-applications than on-tenant organizations.

In the end, the purpose of a CEAP is to be the technology base for an APaaS. Thus, the reference architecture of a CEAP is also the reference architecture of the technology inside an APaaS.

The fundamental function and the core purpose of a CEAP is to be an application server, with the added requirement that the applications hosted on such an application server be offered as a cloud service. Most of the functionality expected of a traditional application server is still expected from a CEAP, plus the technology must be extended (or limited) to accommodate the use scenario of a cloud service deployment, including most notably – potential massive processing volumes, tenant isolation and dynamic resource sharing.

A CEAP does not operate in isolation. Like an application server, it uses the underlying system infrastructure (such as OS and networking functionality), a DBMS or file system for data persistence, and add-on tools, including those for security, management and development.

When an application server is deployed on-premises, all its add-on technologies are typically deployed in the same data center, owned and operated by the enterprise's IT. When a CEAP is deployed in the data center of a cloud service provider, the enterprise IT is granted access to it, but has no control over the deployment, location or choice of all surrounding technology. Yet, a CEAP usually cannot operate without a colocated DBMS or a file system, because most enterprise applications hosted by a CEAP require high-performance real-time access to their business data (some require relational data access, but that is not definitional or even prevailing in the cloud today). While a DBMS is not part of a CEAP, it is an integral part of its context (see figure 2). In fact, in some implementations, in order to deliver tenant-aware and multitenant-optimized query support against a shared DBMS, some of the functionality typically found in a DBMS is migrated to the CEAP. In those case the DBMS becomes merely an advanced storage medium. As natively-multitenant databases emerge, this may become a lesser requirement. On the other hand, the opportunity to optimize multitenant operations will, in the future, likely produce CEAP implementations that are fused with their own embedded database technology, delegating perhaps only storage to a separate software stack.

The relationship between the DBMS and the application execution container (application server) has always been tightly synergistic (note such products as IBM IMS, Oracle PL/SQL and Software AG Natural/ADABASE). This interdependence is carried to the cloud and is perhaps amplified there by the shared use of both, and the requirements of advanced performance.

Some other additional tools (such as management and security) are also essential, but may reside elsewhere (development is often on-premises, and management may cover both the cloud and on-premises resources and thus might reside in either place). Other application infrastructure capabilities (application integration, business process management, portal and others) are often used in conjunction with a CEAP (just as they are also used in conjunction with an application server in the traditional on-premises data center). In most cases, colocating these capabilities within a data center of the same cloud service provider would be a benefit in terms of performance and manageability. However, some such cloud services (especially application-integration-related services) are likely to emerge as separately offered cloud centers (a topical PaaS)

Typically, a CEAP is deployed over a cloud provider's system infrastructure layer and colocated with at least a DBMS or another form of data persistence technology. The technology of a deployed CEAP covers three key areas:

• Application server functionality
• Cloud-enabling functionality
• Scale-enabling XTP functionality (Cloud transaction processing [TP])

Real-world implementations of a CEAP target particular user requirements, and may be powered for the most-demanding project types or packaged for modest demands of smaller departmental application users. Many commercial instances of CEAP (and APaaS) will have only a subset of the functionality represented in the comprehensive CEAP/APaaS reference architecture depicted in Figure 2. This technical detail should be seen in that light; most of the described functionality is optional, although the more of it that is omitted, the less functionally capable is the resulting CEAP and APaaS, (although the less capable CEAP/APaaS may be less expensive and complex in learning and use, it might meet the requirements of some projects better than its more-advanced alternatives).

The primary role of the APaaS, enabled by its internal CEAP, is to host (and serve) the business logic of applications. Therefore, the execution containers and interoperability features are the key components of a CEAP (just as they are the key components of an application server). Advanced forms of execution containers provide management of memory, execution threads and priorities, error recovery, task integrity, replication and distribution of resources, effective use of external resource interfaces, they may support multiple programming models, some programmatic flow control, and advanced management and enterprise-class QoS capabilities (transactional integrity, continuous availability, real-time manageability, performance and security). All technical requirements of an advanced application server apply in the cloud context, and many are multiplied by the potentially massively greater demand for throughput, availability and integrity.

To facilitate greater agility in versioning of the platform technology and to ensure that version control in platform technology is minimally (if at all) intrusive on the running applications, advanced forms of CEAPs would also include the internal micro-kernel-style architecture (such as the one based on OSGi standard specifications). With such architecture (also a characteristic of advanced application servers), the CEAP can be upgraded with minimal disruption to operations of the APaaS – a notable advantage to customers.

Any systematically designed modern business application is designed to be open for integration and composition – typically, using the principles of service-oriented architecture (SOA). Therefore, another key application server capability of a CEAP is its support of interoperability. This includes programmatic access via multiple protocols and access patterns (Web services, XML/HTTP, events), as well as multichannel access from a variety of potential external devices, from servers and Web clients to cellular networks, voice response systems, e-mail, and other modern communication clients and methods. Advanced CEAP will be able to interoperate with the outside world using both request-driven and event-driven models of SOA, thus enabling both traditional request/reply and event processing application styles.

Although a CEAP is an application server, its key distinction is that it is designed to be deployed and used as a cloud APaaS.

Providers of APaaS may decide to use a regular application server and build all cloud characteristics into the application software itself (custom multitenancy model). They may also choose a regular application server and deploy it over cloud system infrastructure services (such as Amazon EC2). When combined with autoscaling capability, this model (shared-hardware multitenancy) can also produce a cloud APaaS. These scenarios preserve a familiar programming model for application developers, but require either major additional development effort and skills (custom multitenancy) or produce limited cloud characteristics (shared hardware).

The APaaS providers that choose to develop or buy a CEAP offer the more native cloud service with its cloud characteristics implemented in the middle layer: the container itself. This shared-container (or shared-everything) model of the internal APaaS architecture can offer a higher degree of elasticity and agility in the cloud-supporting features of the APaaS.

There are three core characteristics that represent the cloud-enabling functionality of a CEAP and APaaS:

• Multitenancy
• One-to-many service administration
• Metadata management

Multitenancy implies that the same physical instance of the application (and, therefore, of the underlying CEAP) is used to support execution of multiple instances of one (or several) applications, each as a separate logical tenant. Elastic multitenancy further implies that resource use by each tenant is tracked and adjusted as needed (the tenant may or may not be billed accordingly as well, depending on the pricing strategy of the provider).

Multiple tenant instances may represent multiple organizations contracting to use one application (a scenario common with cloud application services, such as salesforce.com CRM or Microsoft BPOS). Gartner identifies tenants in this scenario to be "tenant-enterprises," sharing the application. Multiple tenant instances may also be simply multiple applications sharing common resources (typical to consumer applications, like Google Apps). In this case, the sharing entities – the applications themselves – are identified as tenant-applications. Most enterprise-oriented CEAPs (such as one used by Force.com) are designed for use in a public cloud, serving large numbers of businesses and are geared toward tenant-enterprises. The consumer-oriented CEAPs (such as the one used in App Engine) are designed to serve large numbers of individuals using many applications and are geared toward tenant-applications.

To fully deliver elastic multitenancy, the CEAP must support the following characteristics (although not all are equally critical in all situations):

• Isolation of tenant data
• Isolation of tenant work space (memory)
• Isolation of tenant execution characteristics (performance, availability)
• Tenant-aware security, management, reporting
• Isolation of tenant customizations and extensions to business logic
• Tenant-aware application version control
• Tenant-aware error tracking and recovery
• Fine-grained tracking and recording of resource use
• Ability to allocate resources to tenants dynamically, as needed
• Horizontal scalability to support real-time addition of new tenants or users
• Redundancy to support transparent hot migration in event of resource failure

All these characteristics, if implemented, must apply to a single instance of the physical CEAP running one physical instance of an application with multiple contained logical application instances, each on behalf of a tenant that operates under the impression that it is the only user of the platform. (Large deployments will consist of multiple physical settings, but, still, each physical setting will support hundreds or thousands of logical tenant-instances.).Obviously, delivering such capabilities is a difficult challenge. Most CEAPs support these characteristics partially, and are improving over time. Just as it took many years (up to a decade, in some cases) to mature TP monitors and traditional application servers, it is likely to take a significant period of time before CEAP offerings are mature. Some early attempts at developing a CEAP aim at patching up some existing application server technology for cloud deployment. It is likely that, in the long term, leading CEAP implementations will be natively designed for multitenant cloud use.

While elastic multitenancy assures efficient use of shared resources, the tenants, in fact, do not necessarily benefit from it directly. They may benefit from reduced costs of operation, if the provider passes some of its savings to the customer. They may also benefit from elastic multitenancy if their application use pattern leads to occasional bursts of activity, requiring a spike in available computing resources. In normal day-to-day operation, however, the tenant organization expects to experience a multitenant environment as dedicated to itself, as if single-tenant.

The characteristic that most obviously differentiates a cloud APaaS from a hosted application server is its one-to-many, retail-style model of offering – in many cases (although not always), associated also with self-service operations logistics. To deliver this capability, the CEAP must be designed for the environment where new tenants are added automatically and in real time, with all business and technical arrangements also handled automatically. This includes the requirements for the following real-time, on-demand capabilities (the degree or criticality of these capabilities varies by use scenario):

• New tenant provisioning
• Allocation of a new application instance
• Application customization and extension opportunities
• Choices of pricing models
• Choices of SLA
• User registration and allocation of relevant resources
• Removal of users and tenants with managed release of all resources
• Version control process for the CEAP, with tenant or ISV scheduling flexibility
• Version control process for applications hosted by the CEAP, with tenant scheduling flexibility
• Self-service monitoring, tracking, contract entry, adjustment and exit
• Standard reusable business on-ramping/off-ramping process for all new and existing tenants
• Retail-style purchase of third-party application widgets or other reusable components enabling rapid application composition – an app store
• Programmatic access (via APIs) to manage all or most of the above functions

A one-to-many APaaS environment operates as a retail business; a standard set of services is offered to all comers, and both business and service characteristics are the same for all customers. The customers do not get to define their own service, but they also do not have to wait for service to be developed or to become available, because it is already there, ready to be initiated on-demand (for example, compare the use of a retail shoe store versus the use of a shoemaker).

The CEAP underlying a one-to-many APaaS, must allow on-demand expansion of a tenant base, allocation of logical instances of applications and databases, unintrusive and orderly platform and application version control, support of choices in SLAs and business models, The CEAP must support the management of a large community of tenants, allowing changes in workload from the addition of new tenants, removing tenants or changing their configurations – without reduction of service levels and while retaining uniformity in service to all tenants.

All application buyers, including the tenant-subscribers of application SaaS, begin their use of the application by customizing it and making plans for extensions over time. The ability of an application to be flexibly customized can make the difference between a popular and a failed business application offering. In a multitenant application SaaS environment, every tenant demands an ability to customize the application, while, in fact, all tenants may run in one physical instance of the application. The traditional customization and extension of applications through additional programming neither meets the tenants' expectations of cloud-style productivity, nor allows for flexibility in customizations. The issue is further complicated by the requirement to allow version changes to the application while retaining all the tenant customizations. While the on-premises deployed applications may stay on old versions of applications to preserve their changed or added business logic, in the cloud, simultaneously running many back versions of applications is counter to the whole model of cloud software management. It increases complexity and costs, and eliminates some key advantages of cloud use for the cloud providers.

Thus, in the cloud context, the ability to retain tenant-added or changed business logic while upgrading the application is nearly imperative. This objective is achieved by increasing the use of metadata in the encoding of the business logic of the application. When an application is executing not as an immutable compiled object code, but as a metadata sequence interpreted by the execution engine (interpreter), both the core application and the tenant-added business logic are metadata. Version coexistence and version control are both in the space of interpreting metadata; a new version or a custom extension, and are just a new path through metadata. Use of metadata also delivers a programming model that is highly productive and typically model-driven.

Not all business application logic can be modeled into metadata. Some more-advanced algorithms and processing models require a direct third-generation language (3GL)—style coding. An advanced CEAP combines the ability to process metadata-based business logic and to incorporate some object-coded business logic.

A metadata-driven CEAP is, in fact, an interpreter of encoded business logic, not unlike the Java Virtual Machine (JVM) – that is, an interpreter of byte-code. Clearly, design of such an execution engine cannot be accomplished by simply patching the existing application servers. This is the difference between Microsoft's Windows Azure and its "xRM," and it is also the distinction between Force.com and VMforce, running in the future side by side in salesforce.com's data center.

The XTP characteristics of a CEAP are required to support potentially massive and fluctuating demands for computing power in a cloud deployment context (the cloud TP environment). Even if many of the tenants are small organizations, when tens of thousands of such organizations sign up as tenants and share the computing resources of the provider, the demand for computing resources can be massive.

XTP technology has been initially developed to cover special cases of enterprise e-commerce and consumer computing that require ultra-high-end performance and availability, but cannot be implemented on mainframes or on TP platforms, such as Java Platform, Enterprise Edition (Java EE) or .NET servers, for cost, skills or technical reasons. The XTP technology platforms were thus designed to deliver performance, integrity, continuous availability and elastic scalability – at and beyond the levels of mainframe multiplexes – using mostly the ubiquitous commodity hardware and system software facilities. This model fits perfectly the requirements of cloud-computing providers as well; XTP platform design principles have become a common foundation in most high-end cloud service offerings. XTP-style architectures and XTP-enabling technologies are used "under the covers" of many cloud services, SaaS applications, social networks and other offerings.

In the cloud context, where a successful service provider may have to support tens of thousands of tenants, each with possibly thousands of users, the ability to scale and retain the highest levels of availability are imperative. XTP characteristics are, therefore, the key cloud-enabling requirements for APaaS and CEAP.

Some of the XTP functionality (such as elastic-grid management) can be also derived from the underlying system infrastructure layer, and some CEAP implementations do so. However, XTP principles implemented in the middleware layer tend to provide a tighter integration with the execution of the rest of the CEAP technology, and thus provide greater platform cohesion for the APaaS. Moreover, XTP middleware, delivered as part of the CEAP, supports elasticity at a much finer, application-component-level granularity than is achievable through system infrastructure layer virtualization. XTP middleware enables dynamic instantiation and deinstantiation of individual application components (for example, those implementing a certain business transaction), as needed, to meet certain SLA requirements. Managed OS virtualization on the other hand, enables dynamic instantiation and deinstantiation only of the entire application stack (including the underlying platform middleware). Thus, implementing XTP characteristics at the middle layer typically offer improved flexibility and resource optimization, compared with elasticity features delivered via managed OS virtualization in the underlying system infrastructure layer. However, these benefits come at the cost of a more complex platform middleware infrastructure.

Over time, the virtualization software in the system infrastructure layer will become more flexible, and the ability to dynamically add or remove resources of a virtual machine (VM) will allow much greater flexibility in delivering elasticity through advanced OS virtualization. Implementing such elasticity in the container XTP section or via system infrastructure will remain an option available to CEAP designers. However. the requirement to deliver XTP capabilities, one way or another, will remain an imperative for most cloud platform offerings.

Dynamic allocation of resources is a key pattern in delivering cloud elasticity and multitenancy. In a CEAP, it can occur at the higher levels of the container by allocating additional memory, threads, priority, database or network connections to individual tenant processes. With this approach. all physical system resources are permanently allocated to the container, which then applies fine-grain performance tracking and resource allocation to tenant processes, as needed. The physical system resources permanently allocated to containers in this scenario usually do not require virtualization.

The dynamic allocation of resources can also be implemented at the lower levels of the container, where segments of application or whole new instances of the application (including the underlying physical or virtual system resources) are allocated on behalf of the tenant to meet performance, throughput and availability requirements of the tenant through horizontal scaling. In this scenario. not only might the multiple tenants sharing a container experience elastic resource access (if provided by the container design), but also multiple running container instances as well exchange resources as needed (in larger-grain increments). This larger-scale dynamic allocation of resources is the function of tera-architecture.

Tera-architecture elastically manages applications (or application segments) and manages continuous availability. Tera-architecture can require the system infrastructure underneath to allocate/deallocate a VM and itself allocates/deallocates logical resources (e.g., applications or application segments) on the available VMs.

In an advanced SaaS environment, every tenant requires explicitly or implicitly agreed-on QoSs (performance, throughput, availability) to be constant, no matter how many users within the same tenant, or across multiple tenants, are actually using the application and also in case of systems or application failures. Therefore, at any given time, the SaaS provider must be able to allocate the computing resources required to meet tenants' (and users within tenants') QoS expectations. In a cloud/SaaS context, this is typically not achieved by allocating to each tenant a dedicated set of physical or virtualized computing resources (CPUs, memory, storage, etc.), but by sharing a common pool of resources across multiple tenants (barring regulatory or other special requirements). The assumption is that not all the users of all the tenants will be active at the same time, but that, while some tenants experience a "peak" in workload, others will be in a "valley" of little or no workload. On the basis of these assumptions, the SaaS provider can deploy only a portion of the physical resources theoretically needed to support the worst-case scenario of all tenants generating maximum workload at the same time. Therefore, the provider must be able to dynamically allocate more of the available resources to certain tenants when needed, and reallocate those same resources to other tenants looking for more power or experiencing system failures, when required and possible. This way, the provider optimizes its infrastructure costs, while providing clients a QoS that is similar (or, in some cases, even superior) to the one achievable by allocating a dedicated infrastructure to each tenant. Depending on the nature of the provider's business, the infrastructure optimization can be marginal if peaks and valleys of different tenants are roughly in sync, but can be notable if these peaks and valleys are significantly out of phase (for example, if the provider serves clients in different time zones). In any case, the provider must assume a certain degree of extra redundancy to support failovers of resources.

Although some peaks and valleys in workload can be predicted in advance, often they happen unexpectedly. If they could be predicted (that is, it is known when they will occur and how long they will last), then it would be feasible to reallocate resources across tenants manually (assuming the reallocation process could be implemented in a matter of minutes), however this may lead to degradation of QoS if a reallocation is required to manage failovers. But when it comes to managing unexpected or rapidly fluctuating peaks and valleys of workloads across tenants or when providing ultra high availability is a key requirement, the reallocation of resources must take place very rapidly (in a matter of seconds or minutes) to actually deliver the expected benefits to both tenants (constant QoS, even in the case of escalating workloads and system failures) and the SaaS provider (optimized investment in physical resources and continuous availability, even in the case of failure scenarios requiring disaster recovery). Therefore, it is critical, at least for certain scenarios, to be able to dynamically and transparently reallocate resources across tenants automatically, without human intervention. The elastic tera-architecture capabilities of CEAP are meant to support this requirement at the middleware level, by implementing (in cooperation with the underlying system infrastructure to allocate/de-allocate the appropriate physical/virtual resources) the ability to allocate/deallocate application component instances on-demand, as needed to meet the QoS requirements of each tenant. However, in some cases, tenants must have a certain degree of explicit control over the amount or resources dynamically allocated to/deallocated from them. For example, they may want to inhibit excessive consumption of resources (that would lead to exorbitant costs) stemming from a software bug in an application. Or, applications may want to request more resources or the deallocation of in-place resources to meet certain application requirements without "waiting" for the tera-architecture to perform these tasks automatically on their behalf. Therefore, in many CEAPs, the tera-architecture layer exposes APIs to enable this level of fine-grained, explicit autoscaling control and authorization.

In essence, the tera-architecture capability provides a mechanism by which, per each tenant application instance, it is possible to:

• Define appropriate SLA policies that must be met.
• Track the metrics associated with SLA policies (e.g., response time).
• Dynamically deploy a new application instance (e.g., on behalf of an existing tenant or as part of new tenant provisioning) on available (physical or virtual) computing resources.
• When workload grows for a given tenant, allocate more physical, virtual or logical (for example, more instances of application components) resources to the tenant application instance (this capability is often called autoscaling).
• Deallocate resources when they are not needed or when other application instances with more-demanding SLAs require additional resources.
• Automatically and transparently (and without stopping operations) allocate backup resources to application instances in case of failure (this capability is often referred to as "continuous availability").
• Enable on-the-fly replacement of application components with new versions without stopping operations (another form of continuous availability).
• Provide APIs to enable application to programmatically control and manage autoscaling and failover.
• Enable debugging, management and administration of the whole environment.
• Track resource consumption for billing purposes.

Although not all CEAPs implement all these capabilities, as the market evolves, as users' and SaaS providers' requirements crystallize, and as products mature, leading CEAPs will release a growing number of the above-listed capabilities.

Computing fabric provides messaging and distributed caching.

In advanced CEAP environments, focused on supporting large scale and demanding application scenarios, application components typically communicate with one another on a loosely coupled, event-driven messaging basis so that they can run on different physical or virtualized resources. This way, performance is optimized and load balancing between multiple application component instances can be implemented, typically by the distributed elastic transaction manager of the CEAP (see Section 4.4.4), thus enabling parallelization of transactional and batch workloads, and supporting elastic scalability and continuous availability. Application components can also exploit the messaging infrastructure provided by the computing fabric layer to communicate with one another or with other applications (that is, not running on the same CEAP, whether in the same data center or elsewhere).

To achieve the goal of maximum performance and elastic scalability, advanced CEAP products typically incorporate in the computing fabric layer distributed caching platforms (DCPs), which enable it to maintain a distributed "in memory" object store (usually called a "space" or "cache"). The content of a space can be replicated across clustered spaces through flexible, asynchronous, high-performance and transactional (to preserve data consistency and integrity) replication mechanisms. This way, applications can transparently share a large, distributed virtual space by retrieving and storing objects via proper APIs. The DCP initially loads the space, locks data objects in the space, manages transactions, supports transparent partitioning (the "logical" space is split into multiple physical spaces, but this is transparent for applications) and emits space event notifications. (for more details on DCP see "Distributed Caching Platforms are Enabling Technology for Twenty-First Century Computing") The DCP infrastructure is typically integrated with the messaging/eventing infrastructure. In some cases, the messaging infrastructure is layered on top of the DCP. In other cases, the DCP uses the messaging infrastructure to synchronize data between spaces. Through the DCP, application components can enjoy low latency and highly scalable (through partitioned and replicated spaces) access to shared data, without incurring the performance and scalability penalties associated with manipulating "on disk" data. The DCP infrastructure and the tera-architecture also cooperate to make sure that a given application component and the relevant piece of data are physically co-located to further reduce data access latency. DCP replication also enables data sharing between different CEAP instances, whether local or geographically remote (in the latter case, object replication latency is not negligible and must be properly taken into account by minimizing movement of data through partitioning). This capability provides a mechanism to support disaster recovery, as well as to enable data sharing between on-premises and in-the-cloud applications (which would be impractical through classic DBMSs).

In summary, the computing fabric capabilities of an advanced CEAP support the following functionality:

• Low-latency publish and subscribe event messaging between application components (intraplatform and interplatform)
• Routing of events and service invocations
• A variety of protocols and communication styles to interoperate with external applications
• Consistent and transactional management of a distributed, virtual in-memory object store, enabling data sharing between distributed application components
• Continuous availability of the distributed, virtual object store and the messaging infrastructure
• Ability to persist the content of the virtual object store on a flash memory or magnetic support for reliability/disaster recovery
• Ability to partition, replicate and share data across multiple instances of the CEAP, even if they are geographically remote
• Provide APIs for applications to programmatically send messages and manipulate data in the distributed in-memory object store
• Debugging, management and administration of the whole environment
• Tracking of resource consumption for billing purposes

Generic or specialized low-latency messaging and DCP technology will be at the foundation of most advanced CEAP products, and will be intimately integrated to offer optimized latency and elastic scalability.

Distributed elastic transaction management (DETM) provides workload management and short and long running transaction management

Many cloud applications today don't really have stringent transactional requirements, although certain applications (e.g., SaaS, online gaming, Web commerce and others) do. However, as cloud-style computing becomes more well-understood and proven, the number of transaction-oriented applications deployed in public- and private-cloud-style scenarios (what Gartner calls "cloud TP") will dramatically grow. Advanced CEAP products meant to support these cloud TP applications must provide highly scalable, high-performance and continuously available transaction management. In certain cloud TP scenarios, application components, working in parallel on the same set of (in-memory) data, must be packaged in an "all or nothing" transaction providing atomicity, consistency, isolation and durability (ACID) properties. Other classes of cloud TP applications, instead, must support "eventual consistency" in case of component or node failure, by realigning data when the particular failed resource is operational again. Transaction management is also required to support "log running" transactions and batch workloads managed by the CEAP.

To propagate transaction context and to implement transaction coordination protocols, the DETM layer of the CEAP extensively leverages the underlying computing fabric for low-latency message/event propagation and to provide transactional access to in-memory data. This layer is also in charge of implementing elasticity at the transaction level in cooperation with the tera-architecture layer (to allocate physical, virtual and logical resources to support transaction SLA requirements).

DETM is also in charge of supporting workload management by fanning out incoming workload requests to the appropriate logical application resources as needed to enforce the SLAs agreed-on with each tenant sharing a specific CEAP instance. When more workload is to be supported, more instances of the relevant application components are kicked off through the tera-architecture layer. Typically, this is driven by well-defined SLAs and thresholds, and can be controlled and managed by the applications and the tenants, for example, to avoid that a bug in an application would kick off an enormous number of application components, which would have a terrible impact on costs. The workload management system splits the incoming workload across the multiple instances by sending them activation events or service requests through the messaging infrastructure. When the workload goes down, the unnecessary instances are de-allocated through the tera-architecture layer and the relevant resources are freed for other purposes. The workload management system also takes care of ensuring continuous availability by redirecting incoming workload to back up instances (managed by the tera-architecture layer) in case of application components failure. To manage continuous availability the DETM detects failures in the logical transactions and restarts the failed transactions by making use of all appropriate recovery procedures (e.g., rolling back transactions, triggering compensating processes, reloading or purging data in the virtual distributed space, etc.). This task is performed in cooperation with the tera-architecture, when it comes to requiring additional physical, virtual or logical resources for that particular tenant and transaction, in case this is called for by the recovery process (for example, to replace a failed resource). Similarly, DETM is in charge of managing zero-downtime transactions with minimal perturbation of ongoing operations (conceptually, the upgrade of an application component part of a transaction could be seen as a form of failure management).

Finally, DETM implements the mechanisms required to support parallel execution of tasks in the context of high-performance computing or batch processing applications. The parallel processor capability elastically instantiates multiple copies of the application logic and assigns them different data-sets (whether stored in a persistent storage or in the underlying distributed virtual space), so that processing can operate in parallel.

In summary, the DETM capability of an advanced CEAP implements the following functionality:

• Distributed transaction management (including support for "eventual consistency") for short- and long-running transactions
• Elastic allocation of resources to meet QoS SLAs at the tenant/transaction level
• SLA-driven workload management and distribution
• Zero-downtime automatic failover management
• Continuously available application and application component patching and upgrading
• Support for long-running transactions, batch and parallel processing
• APIs for applications to programmatically access to the DETM functionalities
• Debugging, management and administration of the whole environment
• Tracking of resource consumption for billing purposes

Ability to support both short- and long-running distributed elastic transactions, as well as to enable zero-downtime applications upgrades, will prove to be a key attribute of advanced CEAPs, because in demanding 24/7 SaaS environments, planned downtime for application management and batch windows will increasingly be scarce resources.

The current CEAP/APaaS market is early in its development phase. There are no standards, no assured long-term leaders (although vendors like salesforce.com and Google have a substantial lead in the installed base) and no established best practices for IT organizations. We expect substantial changes in the market in the next three years as Microsoft continues to build up its Windows Azure technology, VMware continues to advance its Spring technology to the cloud, Google delivers and enhances its App Engine for Business offering, salesforce.com continues to build its enterprise presence, Oracle delivers its promised cloud-enabled Fusion applications, SAP releases its multiple SaaS offerings (SAP Business ByDesign and others), and IBM unveils the cloud platform development, which is still in its research labs.

The vendors that offer a CEAP as a product include the following (although not a complete list)

• Appistry
• Apprenda
• Corrent
• Expanz
• Gigaspaces
• LongJump
• Magic Software
• Progress
• RollBase
• Vertical Solutions
• Wavemaker

The vendors that offer an APaaS and use an embedded CEAP to deliver a shared-container or shared-everything model of multitenancy include the following (although not a complete list):

• Appistry
• Apprenda
• Aptana
• Engine Yard
• Express Dynamics
• Foresoft
• Gigaspaces
• Google
• Heroku
• Intuit
• LongJump
• MicroFocus
• OrangeScape
• Qrimp
• Salesforce.com
• SiteMasher
• Tibco Software
• Vertical Solutions

See "Who's Who in Application Platforms for Cloud Computing: The Cloud Specialists" and "Who's Who in Application Platforms for Cloud Computing: The Enterprise Generalists" for further details on these and other cloud application platform providers.

IT organizations should anticipate substantial changes in the next three years, yet they should also seek the opportunities already available in the cloud-computing space. The risk of an early entry into a developing market is clearly there, and IT organizations should proceed cautiously, but so is the risk of being late to adopt the next-generation business and technology model for enterprise IT.

Source: Gartner Core Research, G00201437, Yefim V. Natis, Massimo Pezzini, Eric Knipp, 6 July 2010