Chapter 26: Designing Hosted and Cloud Services

For more details of the topics covered in this guide, see Contents of the Guide.

Contents

• Overview
• Benefits of Cloud Applications
• Design Issues
• Relevant Design Patterns
• Additional Resources

Overview

This chapter looks at the new and emerging technologies and approaches for building and consuming services and applications that are hosted remotely. These kinds of services and applications are accessed over the Internet and run in what is usually termed the cloud, hence the commonly used description cloud computing. Cloud solution hosters and vendors will generally provide prebuilt service applications with varying levels of configurability and customization. Alternatively, you may prefer to create your own application in-house and host it either internally on your own systems, or externally in the cloud at a hosting provider.

The concept of building or consuming services and applications that are hosted off-premises is becoming more attractive both to independent software vendors (ISVs) and to enterprises as a way to reduce costs, maximize efficiency, and extend capabilities. This chapter will help you to understand the nature and use of cloud-hosted services and applications. It describes the benefits and the typical design issues, and the constraints and technology considerations often encountered when building and consuming these kinds of applications.

Cloud Computing

In many ways, cloud computing represents the converging evolution of computing infrastructure and application models for building and consuming scalable distributed solutions. As techniques for building these kinds of applications have advanced, so too have the capabilities of the infrastructure on which they run. This synergistic evolution allows the infrastructure to be provisioned and maintained largely independently of the applications that it hosts. This in turn allows applications to take advantage of supporting infrastructure services and capabilities while they focus on their specific business functionality.

Many organizations have been able to realize the joint benefits of scalable application models and supporting infrastructure internally on-premises in their own data centers. However, it is the ability to leverage an off-premises outsourced application hosting infrastructure that is behind much of the excitement around cloud computing. The infrastructure provider focuses on hardware, networking, power, cooling, and the operating environment that supports application manageability, reliability, and scalability; leaving the organization free to focus on their application's business functionality. This provides many benefits in terms of reduced capital outlay and operating costs; and increased capacity, scalability and availability.

To leverage these benefits, cloud-hosted applications typically must be architected to follow a specific application model. This allows the cloud-hosting provider to generalize and optimize their operating environment support for application manageability, reliability, or scalability.

Different cloud-hosting providers have different application model requirements. Some adopt a virtual machine approach, where the application is developed and packaged along with its operating system image and the dependent runtime frameworks. Others utilize an application model that provides higher level abstractions for data access and storage (as described later in this chapter), and for computation and communication. Still others provide higher level application models based on highly configurable applications that focus on specific vertical application functionality, such as Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM). Each of these approaches provides distinct advantages and disadvantages.

Furthermore, some off-premises hosted applications are self-contained and designed for users who interact with the application through a dedicated UI. Some of these applications are service-enabled, and provide both a UI and expose their functionality through an API (often exposed through standards such as REST or SOAP) so that they can be integrated into other applications, which themselves can be hosted either on-premises or off-premises. Some off-premises hosted services are specifically designed to provide functionality for integration into other applications, and provide no UI at all.

Cloud-based services generally fall into categories such as storage/compute, business services, and retail/wholesale services. Some common examples of these remote services are:

• Business services such as stocks and shares information, invoicing and payment systems, data interchange facilities, merchant services, and business information portals.
• Retail/wholesale services such as catalogues, stock query and ordering systems, weather and traffic information, mapping services, and shopping portals.
• Storage/compute services such as data storage and processing, data backup, source control systems, and technical or scientific processing services.

These remote services can be consumed by software that runs on-premises, in an organization's data center or on a user's machine, which may be a desktop computer or any other Internet-enabled device. This typically involves a mix of technologies and techniques that are referred to as Software plus Services (S+S). S+S refers to an approach to application development that combines hosted services with locally executed software. The combination of the remote services and the software running locally, with rich seamlessly integrated interfaces and user experience, can provide a more comprehensive and efficient solution than traditional on-premises silo applications. S+S is an evolution of several other technologies including Service Oriented Architecture (SOA), Software as a Service (SaaS), Platform as a Service (PaaS), and Web 2.0 community-oriented architectural approaches.

Common Vocabulary for Hosted and Cloud Services

Some of the terms commonly encountered in this chapter and in cloud and hosted service scenarios are the following:

• Building block service. A service designed to be consumed by or integrated with other applications or services. An example is a storage service or a hosted Security Token Service (STS) such as the Access Control Service in the Azure Services Platform.
• Cloud-hosting environment. An environment that provides a core runtime for hosting applications; and, optionally, building block services, business services, social network services, and hosting services such as metering, billing, and management.
• Home-built application. An application that you create in-house, usually specifically targeted at some task, scenario, or process you require; it will often address a need that cannot be sourced from a third party.
• Hosted application. An application (packaged or home-built) hosted as a service. It may be hosted internally on your own system, or hosted externally by a partner or hoster.
• Packaged application. An application created by a third party or vendor that may provide only limited customization capabilities based on configuration or plug-ins.
• Platform as a Service (PaaS). A core hosting operating system, and optional plug-in building block services, that allow you to run your own applications or third-party applications obtained from vendors, in a remote cloud hosting environment.
• Software as a Service (SaaS). Applications that perform comprehensive business tasks, or accomplish business services, and allow you to consume them as services with no internal application requirements other than composition and UI.

Benefits of Cloud Applications

Cloud-hosted applications and services may be very beneficial to ISVs, and to service delivery or hosting companies that build, host and deliver services. They also offer benefits to large enterprises that generally consume hosted and cloud-based solutions.

Benefits for ISVs and Service Hosts

The key advantages for ISVs and service hosting companies building and offering cloud-based solutions are the following:

• Architectural Flexibility. Vendors can offer their customers a range of deployment options, including hosting for the services they require, and allow users to choose from a range of prebuilt features or choose which features of the application they will implement themselves. This can reduce the architectural liabilities for end users who are developing services
• Rich User Experience. ISVs and service providers can offer richer experiences to their customers by leveraging existing specialized services (such as Virtual Earth). Hosters can combine their offerings with other cloud services obtained elsewhere to offer additional value propositions, and make it easier for end users to integrate services.
• Ubiquitous Access. Services in the cloud persist user data and state, and resynchronize when the user reconnects from any location. This supports both offline and occasionally connected scenarios, which is especially useful for mobile devices where a constant connection or bandwidth cannot be guaranteed.

ISVs and service hosts may also consider entering the market for commercial reasons to take advantage of monetization opportunities. The following are some examples:

• Vendors may wish to take advantage of an untapped market opportunity by offering a product that is not currently or easily available elsewhere, or use the cloud to offer lower end versions of their products to protect a high end franchise.
• Startup companies may use the cloud-hosted approach to minimize initial capital expenditure, and to take advantage of properties of the cloud such as elasticity (the capability to grow as required without high initial cost commitment).
• Vendors and users can create applications that generate income more quickly by taking advantage of ancillary services that are already available. For example, they can take advantage of payment and accounting systems in the cloud. Users can even build virtual stores without requiring large investments in IT equipment and networking capabilities.

Benefits for Enterprise Service Consumers

The key advantages for enterprises that consume cloud-based solutions are the following:

• Architectural Flexibility. In-house developers can create complete solutions that compose services in the cloud with local application code and their own services. IT departments can choose which features of the application they will implement themselves, and buy in other services that they require.
• Cost and Time Savings. IT departments can select the best cloud-based service for each task, and combine them to expose fully functional applications with shorter development times, and at a reduced cost. In addition, the reduction in the requirements for in-house IT infrastructure simplifies management, security, and maintenance costs.
• Economies of Scale. Companies can leverage economies of scale for industry average capabilities, and focus on their core activities. The economies of scale available from hosted applications arise from a range of factors, including reduced in-house infrastructure costs to better utilization of hardware that offers opportunities for reduced running costs. However, the gains in economies of scale must be balanced with the loss of control inherent with moving from on-premises to fully hosted applications.
• Offline Capability. The cloud can act as hub for roaming users. User data and state can be stored in the cloud and resynchronized when the user reconnects. Users can move between desktop and mobile clients seamlessly with fewer network configurations.

Design Issues

Several common issues are of concern to both ISVs and enterprise customers. While they cover a range of different aspects of hosted and cloud-based scenarios, these issues can be categorized into specific areas. Consider the following as your develop your strategy for hosted and cloud-based services:

• Data Isolation and Sharing
• Data Security
• Data Storage and Extensibility
• Identity Management
• Multi-tenancy
• On-premises or Off-premises, Build or Buy
• Performance
• Service Composition
• Service Integration
• Service Management

Data Isolation and Sharing

Hosters can implement isolation and sharing for databases and for database schemas. There are three basic models:

• Separate Databases. Each tenant has a separate database containing their own data schemas. This has the advantage of being easy to implement, but the number of tenants per database server might be relatively low, with subsequent loss of efficiency, and the infrastructure cost of providing services can rise rapidly. It is most useful when tenants have specific data isolation or security requirements for which you can charge a supplement.
• Shared Databases, Separate Schemas. All tenants use the same database, but have separate sets of predefined fields available. This approach is also easy to implement, maximizes the number of tenants per database server, and improves database efficiency. However, it usually results in sparsely populated tables in the database. It is most useful when storing data for different tenants in the same tables (commingling) is acceptable in terms of security and isolation, and when you can anticipate the predefined custom fields that will be required.
• Shared Databases, Shared Schema. All tenants use the same database and special techniques are used to store data extensions. This approach has the advantage that the number of custom fields you can offer is practically unlimited. However, indexing, searching, querying, and updating processes are more complex. It is most useful when storing data for different tenants in the same tables (commingling) is acceptable in terms of security and isolation but it is difficult to predict the range of predefined custom fields that will be required.

The following table illustrates the benefits and liabilities for the three isolation and sharing models described above. Rows nearer the top of the table imply higher cost and lower development and operational effort. Rows nearer the bottom of the table imply lower cost and higher development and operational effort.

Applications optimized for a shared database approach may be more complex and involve higher development cost and effort. However, they will generally support more tenants per server, and may have lower operational costs. Applications optimized for a shared schema approach are simpler, and will generally reduce operational costs in the long term, though this reduction is likely to be less than the shared database approach.

If you must create applications quickly, consider the Separate Databases approach by configuring each tenant with their own database. Using this approach no special design is required. Also, consider this approach if your individual tenants have particularly high data security requirements, or will store very large volumes of data, or have a very large number of concurrent end users. The Separate Databases approach is also appropriate if you require the application to be easy to move from on-premises to hosted, or from hosted to on-premises, and it can allow you to more easily scale out if the need arises.

Higher isolation is also useful if you expect to offer per tenant value-added services, where you should consider the Separate Databases or the Shared Database, Separate Schemas approach. However, if you expect to have a very large number of tenants, each with relatively small amount of data, consider a less isolated approach such as Shared Database, Separate Schemas or Shared Database, Shared Schemas.

Data Security

Cloud-hosted applications must implement strong security, using multiple defense levels that complement one another to provide data protection in different ways, under different circumstances, and against both internal and external threats. When planning a security strategy, consider the following guidelines:

• Filtering. Use an intermediate layer between a tenant and a data source that acts as a sieve so that it appears to the tenant that theirs is the only data in the database. This is especially important if you use a shared database instance for all of your tenants.
• Permissions. Use access control lists (ACLs) to determine who can access data in the application, and what they can do with it.
• Encryption. Obscure every tenant's critical data so that it will remain unreadable to unauthorized parties, even if they manage to access it.

Data Security Patterns

Depending on the multi-tenant model you adopt, consider the following security patterns:

• Trusted Database Connections (applies to all three multi-tenant models). The application always connects to the database using its own application process identity, independent of the identity of the user, and the server grants the application access to the database objects that it can read or manipulate. Additional security must be implemented within the application itself to prevent individual end users from accessing any database objects that should not be exposed to them. Each tenant (organization) that uses the application has multiple sets of credentials associated with their tenant account, and must grant their end users access to the application using these credentials. These end users access the application using their individual credentials associated with the tenant account, but the application accesses the database using the single set of credentials associated with that application. This means that a single database access account is required for each application (one for each tenant). Alternatively, you can use an STS to obtain encrypted login credentials for the tenant irrespective of the individual user, and use security code in the application to control which data individual users can access.
• Secure Database Tables (applies to the Separate Database model and the Shared Database, Separate Schema model). Grant a tenant user account access to a table or other database object. In the Separate Database model, restrict access on a database-wide level to the tenant associated with that database. In the Shared Database, Separate Schema model, restrict access on a per table basis to the tenant associated with specific tables.
• Tenant Data Encryption (applies to all three multi-tenant models). Secure the data using symmetric encryption to protect it, and secure the tenant's private key using asymmetric (public/private key pair) encryption. Use impersonation to access the database using the tenant's security context, and use the tenant's private key to decrypt the data in the database so that it can be used. The disadvantage is that you cannot index encrypted columns, which means that there is a tradeoff between data security and performance. Try to avoid using index fields that contain sensitive data.
• Tenant Data Filter (applies to the Shared Database\Shared Schema model). Use SQL views to select subsets of data from tables based on the tenant or user ID, or the tenant account's security identifier. Grant tenants access to only their views, and not to the underlying tables. This prevents users from seeing or accessing any rows belonging to other tenants or users in the shared tables.

Data Storage and Extensibility

Hosted data may be stored in variety of ways. Two different approaches are emerging for implementing data storage in hosted applications: hosted relational database management systems (RDBMS) and nonrelational cloud-based storage. Relational database systems provide storage for structured data, and are more suited to transactional systems or applications that are I/O intensive; they also typically provide lower latency and advanced query capabilities. In contrast, cloud storage refers to any type of data storage that resides in the cloud; including services that provide database-like functionality, unstructured data services (for example, file storage for digital media), data synchronization services, and network-attached storage (NAS) services. Data services are often consumed in a pay as you go model, or in this case a pay per GB model (including both stored and transferred data).

Cloud storage offers a number of benefits, such as the ability to store and retrieve large amounts of data in any location at any time. Data storage services are fast, inexpensive, and almost infinitely scalable; however, reliability can be an issue as even the best services do sometimes fail. Applications that are sensitive to high latency might also be affected as each interaction with the storage service requires network transversal. Finally, transaction support can be an issue with cloud-based storage systems.These systems generally focus heavily on partitioning and availability, and consistency cannot always be guaranteed.

Microsoft Azure storage (in an early preview release at time of writing) comprises a number of services that span different storage needs, which you can access using a REST API:

• Table Storage Services provide structured storage in the form of tables, but these tables have no defined schema; instead, they contain entities, each of which holds a number of properties. Popular APIs such as LINQ can be used over any combination of properties. Table Storage Services focuses on providing massively scalable tables at a very low cost. However, it is not a relational database and lacks many of the features you would expect to find in an RDBMS such as joins and foreign keys across multiple tables.
• Blob Storage Services offers storage for binary data stored in user-defined containers, which organize sets of blobs within a storage account.
• Queue Services store messages that may be read using queuing semantics by any client that has access to the storage account.

A key challenge to solve when using an RDBMS is schema extensibility. This is the ability to extend a table with custom fields without recompiling or rebuilding the application. There are four approaches to extending the schemas at runtime:

• Fixed Columns. This pattern models the extension fields as a set of fixed named columns for each extensible entity (each table). The number of fixed columns will depend on the nature of the entity and its usage pattern. It requires a data access layer that encapsulates and abstracts the named fixed columns and metadata tables. Consider the following factors for the Fixed Columns approach:
  • Filtering based on extensible columns is a challenge due to the predefined data types. For example, using variable length data types such as varchar for all the extensible columns limits the capability to filter numerically using the <, >, and = operators. Possible solutions are to allocate a fixed number of fields of each common data type, or to allow the user to mark columns as searchable and use a separate table to store data type specific fields.
  • While this is one of the fastest and more scalable approaches to extensibility, it generally requires a solution for indexed columns that are not string-based.
  • The way that the database treats null values may result in sparse data distribution and wasted space. If a tenant extends only one field, while another extends 20 fields, the database and pages in memory will grow. Microsoft SQL Server 2008 provides a modifier for columns named SPARSE that helps to mitigate this issue.
• Custom Schemas. This pattern is used in conjunction with the Separate Schemas multi-tenancy pattern. Each schema belongs to a tenant, and contains a different set of extensible strongly typed columns. Consider the following factors for the Custom Schemas approach:
  • It requires encapsulation and abstraction of the data access layer, and a query processor; though O/RM Frameworks such as Microsoft Entity Framework (EF) or the open source NHibernate framework can assist in implementation. For more information, see Additional Resources at the end of this chapter.
  • Each tenant has their own table, and the table schema will change every time they add or remove a field. The queries will work against the real data type (the columns are not all string types). However, rolling up database schema updates will be non-trivial due to excessive duplication between the tenants' shared fields (as opposed to the Fixed Columns approach, where one or more tables exist for all tenants).
  • This approach is faster than the Fixed Columns pattern when filtering based on extended columns because it uses the primitive data types.
• Name Value Extension Table. This pattern allows customers to extend the data model arbitrarily (with an unlimited number of columns), storing custom data in a separate table and using metadata to define labels and data types for each tenant's custom fields. Consider the following factors for the Name Value Extension Table approach:
  • It adds a level of complexity for database functions, such as indexing, querying, and updating records. For example, retrieving data requires multiple joins, and filtering and grouping is a challenge.
  • There is only a single database to manage. However, if a growing user base causes the database to grow, it could be scaled horizontally with tenant partitioning to use separate databases.
  • This approach will be slower than the other approaches because data retrieval requires multiple joins.

• XML Columns. This pattern allows customers to extend the data model arbitrarily with an unlimited number of extensions by storing the extension data in an XML column. Consider the following factors for the XML Columns approach:
  • While this approach may seem to be a natural choice for extensibility, it has lower scalability (the capability to add more records) and lower performance (query response time) compared to other approaches.
  • While the use of XML columns in the database leads to relatively simple implementations, ISVs and developers will require additional skills to manipulate XML in the database.
  • It is possible to define indexes for XML columns, but this adds additional complexity and requires extra storage space.

Identity Management

All applications and services must manage user identity. This is particularly important in hosted and cloud-based scenarios that can potentially serve a very large number of customers, and each of these customers may have their own identity framework. A common approach is for the hoster to delegate the responsibility for managing its own user accounts to each customer. The ideal is a solution that takes advantage of the customer's existing on-premises or federated directory service to enable single sign on (SSO) across their local and all external hosted services. This reduces the development effort of building individual and separate identity management systems. Customers can configure access to the application using familiar tools, and SSO allows users to access the application or service using their existing credentials.

To enable such a scenario, you must adopt a solution based on industry standards that interoperate across platforms and organizational boundaries. In general, you should consider a claims-based identity model based on a federated identity service, as illustrated in Figure 1. This helps to decouple applications and services from the authentication mechanism.

Figure 1

Claims-based identity model based on a federated identity service

The customer's existing identity system sends a cryptographically signed security token that contains a set of claims about each user with every request they make to an application. Hosting companies that trust the customer's identity system can design applications and services to focus just on authorizing relevant claims. The customer identity system must implement an STS that authenticates users, creates and signs security tokens using a standard format, and exposes a service to issue these tokens based on industry standards such as WS-Trust and WS-Federation. The Microsoft Geneva Framework and Geneva Server provide much of the infrastructure required to implement these requirements. When implementing a claims-based identity model, consider the following issues:

• If there is a suitable identity store available, consider using this to provide a single sign on experience across local applications, hosted Web applications, and other hosted services.
• For small or consumer-focused applications where there is no existing identity store available, consider using a service such as .NET Services Access Control federating against Windows Live, or an online solution from a third party.
• You may need to perform transformations on claims generated from a local STS to match the requirements of the hoster. Alternatively, hosters may need to implement transformation systems for different customer STS mechanisms. Consider using the .NET Access Control Service to provide a transformation layer or use the Geneva Framework for implementing your own. For more information about the Geneva Framework, see https://msdn.microsoft.com/en-us/security/aa570351.aspx.
• There may be minor differences in the way that standards-based products from different vendors are implemented. Compatibility and interoperability issues may arise if these products do not strictly adhere to the complex standards, or they provide a slightly different implementation.
• If you decide to design your own STS, ensure that it is secure against attack. As it contains all of the authentication information, vulnerabilities could leave all applications open to exploit. Also, ensure that your STS implementation is robust and reliable, and can serve all foreseeable volumes of requests. Failure of the STS will prevent users accessing all of the applications that depend it.

Multi-tenancy

Individual tenants share the use of the hoster's hardware and infrastructure, as well as sharing databases and database systems (each tenant is an organization that may each have more than one user). Service suppliers must provide a platform with appropriate capacity and performance for hosted services. They must also consider how to keep the cost structure under control, and how they will provide customization through configuration. There are four common stages in moving towards an efficient multi-tenancy architecture with user-enabled configuration. The following sections describe these stages.

• Custom. Each customer runs a separate copy of the software assigned only to that customer, and the only way to support multiple customers is to serve them with different copies of the software. Furthermore, because little is done to allow customization through configuration, each copy includes specific customer customizations in the form of custom extension code, custom processes, and/or custom data extensions. Although the software is, technically, delivered as a service (it does not run on the customer's premises), economy of scale cannot be achieved because each customer runs a different instance of the software. Although this could be a useful starting point to validate the business model, it must be avoided once the volume of customers increases. It is impractical to manage thousands of customers using this model.
• Configurable. The software can be tailored for each tenant through configuration and by avoiding the use of custom code. All the tenants run the same code; however, the architecture is still not multi-tenant and each customer runs their own copy of the code, even though the copies are identical. The separation can be either virtual (virtual machines on a same server) or physical (running on separate machines). Although this model is a considerable improvement over the custom model described above, the architecture still allows customization through configuration, and the computing power is not shared among the instances. Therefore, the provider cannot achieve economy of scale.
• Multi-tenant. The UI can be customizable per tenant, as can the business rules and the data model. The customization per tenant is entirely through configuration using a self service tool, which removes the requirement for the service provider to perform configuration. This level is almost the SaaS perfect case; the exception is any capacity to scale out. At this level, data partitioning means that growth can only be achieved by scaling up.
• Scalable. The architecture supports multi-tenancy and configuration, plus the capability to scale out the application. New instances of the software can be transparently added to the instance pool to dynamically support the increasing load. Appropriate data partitioning, stateless component design, and shared metadata access are part of the design. At this level, a Tenant Load Balancer (implemented using a round robin or a rule based mechanism) is introduced, maximizing the utilization of hosting resources such as CPU and storage. This means that the total load is distributed across the entire available infrastructure. The data is also reorganized periodically in order to average the data load per instance. The architecture is scalable, multi-tenant, and customizable through configuration.

On-premises or Off-premises, Build or Buy

Cloud-hosted applications allow ISVs and hosters to realize economies of scale; and, in a competitive market, they will tend to pass these saving on to enterprise customers. However, the move to off-premises and hosted scenarios means that enterprises must accept some loss of control of applications, data, and service levels. Enterprises must consider the tradeoffs for moving to such services, in addition to deciding whether to build their own applications or buy them from a third party. The following table illustrates the differences between the build and buy scenarios for hosted applications.

Gains from economies of scale must be balanced with the reduction in control inherent with moving from on-premises to fully hosted applications. Consider the following guidelines when deciding whether to move to a cloud-based solution, what type of application development approach to follow, and where to host your application:

• Consider on-premises hosting if you require full control of your application and data, you have security requirements that prevent you from using hosted services, or laws or national policies prohibit you from using hosted services. When hosting applications internally on your own infrastructure, you may:
  • Choose to develop an in-house application when you cannot source a suitable prebuilt application, or when you want to retain full control of the application feature set.
  • Choose a prebuilt packaged application when one is available that is cost effective and meets all of your requirements.
• Consider at hoster hosting if you are considering optimizing your operations but still want to retain control of the software. For example, you might decide to deploy a heavily customized Enterprise Resource Planning (ERP) package at a hoster and offload to them the management of power, hardware, network, and the operating system. Typically, a hoster will accommodate very specific requirements of your organization; for example, setting up a Virtual Private Network (VPN), adding specialized hardware, and more. When hosting applications at an external hosting company, you may:
  • Choose one of the hoster's prebuilt packaged applications if it can meet your requirements. The availability of prebuilt packaged applications may influence your choice of hoster.
  • Choose a home-built application where you cannot locate a hoster that offers a suitable prebuilt application. In this case, you must factor in the cost and time required to develop your own application.
• Consider the cloud service (vendor-hosted) approach if you are buying an SaaS application from a hoster or an ISV; you can provide a specification of the required application; you do not have the resources, time, or in-house skills to build the application; or you require an existing standard or customized application at short notice. Another reason is to take advantage of the intrinsic properties of cloud based building block services (such as elasticity) if you are building an application yourself. When purchasing cloud application services from a vendor:
  • Choose a prebuilt packaged application created by a vendor if it can meet your short term and long term requirements. This is the SaaS approach.
  • Choose a vendor-supplied hosting platform to run your home-built application where you cannot source a suitable prebuilt application. You must factor in the cost and time required to develop your own application. This is the PaaS approach.

Performance

Cloud-hosted applications must be scalable to support increasing numbers of services, and increasing load for each service and tenant. When designing services, consider the following guidelines for scaling applications:

• Design services and components to be stateless where possible. This minimizes memory usage for the service, and improves the opportunity to scale out and load balance servers.
• Use asynchronous input and output calls, which allow the applications to do useful work while waiting for I/O to complete.
• Investigate the capabilities of the hosting platform that can improve performance. For example, in Microsoft Azure, use queues to manage requests and worker processes to carry out background processing.
• Use resource pooling for threads, network, and database connections.
• Maximize concurrency by using locking only where absolutely necessary.

When scaling data storage and applications, consider the following guidelines:

• When scaling the data partition, divide subscriber data into smaller partitions to meet performance goals. Use schemes such as Hashing (to subdivide content) and Temporal (based on the time or date range in which the data is valid).
• Consider implementing dynamic repartitioning to repartition the data automatically when the database size reaches a specific maximum size.
• When scaling data storage and applications investigate standard patterns, and the specific techniques and implementations provided by the hosting platform—some examples are data partitioning, load balancing, failover, and geographical distribution.

Service Composition

Users in enterprise-level organizations require access to many different document repositories, types of data, sources of information, and applications that perform specific functions. Traditionally, users interacted directly with each store or application, often using specific isolated applications. However, over time, enterprises have attempted to consolidate systems; often using intranet Web portals or façade-style applications that connect to the appropriate downstream applications.

With the advent of services and SOA applications, IT departments can expose applications and data as services, either hosted in-house or bought in as SaaS. The service portfolios can still expose the combination of traditional local applications, internally hosted services, and remote services through portals, which hide the user from the implementations and allow IT departments to adapt the ranges of services quickly and easily. However, S+S and SaaS designs and technologies allow IT departments and enterprise customers to integrate services fully. Service integration can help to achieve the goal of a many to one model where all applications and services are available to the user through a composition architecture that effectively exposes them as a single application, as shown in Figure 2. A service integration mechanism combines the groups of applications in the portfolios and exposes them though a rich client that can interact with any service or application.

Figure 2

A service integration mechanism can compose multiple services into a single interface

Enterprise consumers of cloud-hosted services will usually need to create composition systems that use the raw services exposed by hosters, and expose them through in-house portals and portfolios. Effective consumer composition architecture can integrate information from many sources for end users; which reduces redundant data entry, enhances human collaboration, and heightens awareness of outstanding tasks and their status. It also improves the visibility of interrelated business information and help users to make informed business decisions. Composition of a unified solution that uses cloud-hosted services usually incorporates the following three layers:

• Input source layer. The input sources include cloud-hosted services, internal applications, internal databases, Web services, flat files, and more. Internal resources may be exposed though IT service portfolios.
• Composition layer. This is where the raw data is aggregated and provided to the user in a new, unified form. Its function is to transform data into business information and process intelligence. This layer will usually incorporate the following:
  • Components that manage access, data, workflow, and rules.
  • Service agents that negotiate and exchange messages with applications, databases, Web services, and other resources.
  • Identity management components that authenticate and authorize users, and manage credentials for Web service communication.
  • Data aggregation components that transform data to match the application entity model.
• User-centric layer. This layer presents the composite data to the user in a central, integrated, task-focused user interface.

Consuming cloud-hosted services as part of a composite user interface usually requires workflow or step-by-step processes to achieve integration of external and internal services. A common solution is an integration broker that consists of a modularized pluggable pipeline and associated metadata services to control message movement and routing. Typical operations in an integration broker pipeline include the following:

• Security. A security module authenticates the data source or digital signature, decrypts the data, and examines it for security risks such as viruses. Security operations can be coordinated with existing security policies to control access.
• Validation. A validation module compares the data to relevant schemas and rejects non-conforming data.
• Transformation. A transformation module converts the data to the correct format.
• Synchronization workflow. A synchronization module uses workflows and rules to determine the logical destinations and order for propagating messages to the appropriate destinations. It can also manage workflow process transactions to guarantee data consistency.
• Routing. A routing module uses routing rules that define the physical destinations, and transmits the data messages to the specific target. It may use information in the message to determine destinations based on the content.

Service Integration

Cloud-hosted solutions can help to mitigate some of the challenges encountered with traditional software, but add new and different challenges for the consumer of these services. Consider the following the challenges when moving to hosted cloud services and applications:

• Identity Management. Enterprise procedures for adding, updating, and removing users must be extended to the remote services. If the external service depends on user identity, which is very likely for SaaS and for S+S, the provisioning and deprovisioning processes must be extended. In addition, translation of in-house user identity into specific roles may be required, possibly through a federated service, to minimize the migration or duplication of individual user identities at the remote service host. Enterprise user account policies such as password complexity and account lockouts must also be compatible with those of the remote service supplier. If no SSO facility is available, there can be increased liabilities, maintenance costs, and operational inefficiencies.
• Data. Requirements of data operations, such as Extract, Transform, and Load (ETL) and data integration, must be analyzed for compatibility with service capabilities. Hosted services may not support complex data storage patterns, which may affect the design of data entities and application architecture. In addition, data may need to be protected more securely to counterbalance the lack of physical security available when hosting in-house. However, applications can store sensitive or private data locally, and use the cloud services only for nonsensitive data. You must also plan for how you will migrate data to the service provider, and how you will migrate it away and to a different provider should the need arise.
• Operations. In-house integration services and client applications may not be compatible with services exposed by the service supplier, even when using industry standard protocols. You must also ensure that the service provider can generate appropriate reporting information, and determine how you will integrate this with your own management and reporting systems. In terms of service levels, Service Level Agreements (SLAs) may require revision to ensure that they can still be met when depending on the service provider for escalated support. Enterprises must also be prepared to implement help desk facilities that act as the first contact point for users, and define procedures for escalating issues with the service provider.
• Security. Enterprise privacy policies must be compatible with those of the service provider, and rules for actions that users can execute, such as limits on transaction size and other business rules, must be maintained—even if these are not part of the remote service capabilities. This may make the service integration infrastructure more complex. Procedures and policies for maintaining the security and integrity of data in the event of service or interconnectivity failure will also be required. Authentication, encryption, and the use of digital signatures will require the purchase of certificates from certified providers, and may require implementation of a Public Key Infrastructure (PKI). In addition, integration may require changes to firewall rules, and updates to firewall hardware and software may need to be required to provide filtering for application data and XML Schema validation.
• Connectivity. Some types of cloud-based applications rely on good quality broadband Internet connections to function well. Examples are online transaction processing and real time services such as voice over IP (VoIP) and Microsoft Office Communications Server. In some areas and some countries, this may not be available. In addition, services that require large data transfers such as backup services and file delivery services will generally run more slowly over an Internet connection compared to a local or in-house implementation, which may be an issue. However, messaging and other similar services may not be as dependent on connection bandwidth or severely affected by occasional loss of connectivity.
• Service Level Agreements. Skills and expertise will be required to assess suppliers more comprehensively, and make choices regarding service acquisition and contracts. SLAs may also require revision to ensure that they can still be met when depending on the services hosted by a remote provider.
• Compliance and Legal Obligations. Compliance with legal and corporate directives may be affected by the performance of the service supplier, or these compliance directives and legal obligations may conflict if the service provider is located in another country or region. There may also be costs associated with obtaining compliance reports from the service supplier. Local laws and policies may prevent some types of applications, such as banking applications, from running in hosted scenarios.

Service Management

Cloud service providers face certain challenges when hosting and offering services that run in the cloud, specifically around service delivery and support. Some ISVs may build applications that are hosted elsewhere while others may build and host their applications themselves, and there are several challenges that you must consider when contemplating developing hosted services. Some will apply to ISVs that host their own services, while others apply only to hosting companies. The following sections summarize these challenges:

• Service Level Management. Enterprise users may each demand variations to the hoster's standard SLAs, with can make it difficult to meet all demands for all customers. Customers may choose a cloud-hosted solution as a way of increasing availability and performance, and so expectations may generally be higher than for an in-house application. Managing and satisfying these expectations could be a complex task because it usually demands managing dependencies (such as network and power providers) and different demands from geographically distributed customers. Maintenance and service downtime should also be carefully planned when hosting services for many different enterprises, especially if they are located in different time zones or have usage that peaks at different times during the day or week.
• Capacity and Continuity Management. Service providers will not have the same insight into upcoming changes to customer's capacity requirements as in-house teams will, which may result in unexpected peaks in usage that require extra capacity to be available. Advance planning is difficult as each customer's growth and usage patterns will differ with little or no advance warning. Implementing and adapting services that match customer requirements is more difficult when there are many customers to satisfy. Short term decisions on capacity are likely to prove more expensive in the long run than a staged capacity growth plan, but long term planning without growth estimates from consumers is more difficult.
• Customer Support. Help desk staff may need to be aware of and take into account the requirements and usage scenarios of customers to offer optimum support. With many customers for each service, failures or issues with that service will prompt large volumes of calls that may overload the help desk. Help desk staff may need to be able to quantify incurred costs on a per user basis, especially for models where support is a chargeable extra. Ideally, the hosted cloud solution should offer proactive support where the provider will be made aware of issues by monitoring the health of the solution and proactively initiate resolution of the problem with the customer. Self-service support mechanisms may also be utilized to provide the customer with a streamlined, dedicated issue tracking system.

Relevant Design Patterns

Key patterns are organized into categories such as Data Availability, Data Transfer, Data Transformation, Integration and Composition, Performance and Reliability, and User Experience; as shown in the following table. Consider using these patterns when making design decisions for each category.

Additional Resources

For more information on Microsoft Azure, see "Azure Services Platform" at https://www.microsoft.com/windowsazure/.

For more information on Microsoft "Geneva" identity management, see "Geneva Simplifies User Access to Applications and Services" at https://msdn.microsoft.com/en-us/security/aa570351.aspx.

For more information on Software plus Services, see the following MSDN Developer Center resources:

• "Multi-Tenant Data Architecture" at https://msdn.microsoft.com/en-us/architecture/aa479086.aspx.
• "Software + Services (S+S)" at https://msdn.microsoft.com/en-us/architecture/aa699384.aspx.
• "Software + Services for Architects" WebCast by Gianpaolo Carraro at https://www.microsoft.com/feeds/msdn/en-us/architecture/media/SaaS/ssForArchitects.asx.

For more information on Software plus Services architecture, see the following resources from the MSDN Architecture Journal:

• "A Planet Ruled by Software Architectures" at https://msdn.microsoft.com/en-us/architecture/bb906059.aspx.
• "Head in the Cloud, Feet on the Ground" at https://msdn.microsoft.com/en-us/library/dd129910.aspx
• "Enterprise Mash Ups" at https://msdn.microsoft.com/en-us/architecture/bb906060.aspx.
• "Implications of Software + Services Consumption for Enterprise IT" at https://msdn.microsoft.com/en-us/architecture/bb906061.aspx.
• "Microsoft Office as a Platform for Software + Services" at https://msdn.microsoft.com/en-us/architecture/bb906062.aspx.
• "The Internet Service Bus" at https://msdn.microsoft.com/en-us/architecture/bb906065.aspx.

For more information on the open source NHibernate framework, see "NHibernate Forge" at http://nhforge.org/Default.aspx.