#1 Preference – Software as a Service (SaaS)
Problem Statement: How can software be offered dynamically over a network?
Context: A software shall be offered to different users that are isolated from each other on a pay‐per‐use basis.
Challenges: In order to allow multiple users to access software over a network it has to be ensured that each user perceives the software as if he was the only user. Since it is often unfeasible to provide an individual instance of the software for every user, the software itself has to be made multi‐tenant aware. This way, its components, such as the user interface, business logic, and data storage can be shared by multiple isolated users. Further, every user shall be enabled to configure the software to his needs regarding the location or content of menus in the user interface, for example, or the date and currency formats that shall be used.
Solution: A user interface or an API is used to access the Software as a Service. Access is controlled to ensure the isolation of multiple users while the desired customisation is stored in a central database that controls how shared components behave.
Results: The software is offered over a network using either a user interface or an API. In the former case, a user often accesses the software using a browser. In the latter case, the software provides functionality that is integrated with a user’s application that he runs on his own premise. For example, an external provider could offer communication services to send text messages or establish teleconferences. These services could then be integrated in a user developed calendar application.
Access to the hosted software is controlled to avoid that users can access other users’ data or influence the performance that others experience. The customisations specified by users are stored in a database and are accessed from software components to determine their behaviour.
Relation to other patterns: Software as a Service may use underlying Platform or Infrastructure as a Service offerings to enable the desired elasticity. While this elasticity does not directly benefit the user of the Software as a Service offering, it allows the provider to scale the offered software dynamically with changing user demands. This is a very important aspect in the Software as a Service market, since the software offered often targets a large number of customers to leverage economies of scale.
The components out of which the offered software is comprised can be implemented accordingly to multi‐tenancy patterns to ensure the required multi‐tenant awareness.
Software as a Service may be part of the offerings that form a public, private, or hybrid cloud. In this case it is ensured that resources are available at virtually infinite numbers.
#2 Preference – Platform as a Service (PaaS)
Problem Statement: How can Software platforms be offered dynamically over a network?
Context: A middleware platform shall be offered to different users that are isolated from each other on a pay‐Per‐use basis.
Challenges: In order to host the software components created by multiple users in a shared runtime environment, that offers commonly used platform functionality, additional isolation of these components has to be insured. The platform itself therefore has to be made multi-tenant‐aware, so that software components cannot access data or functionality and do not influence the performance of other users’ software components. Also, the platform needs to offer common services that can be used for communication between these components, data storage and the routing of accesses to components. Elasticity of the hosted components shall also be enabled automatically.
Solution: An API allows users to deploy software components to a Platform as a Service offering, register and configure other platform services for communication e.g., message queues, storage e.g., block storage, and routing e.g., realised in an enterprise service bus.
Results: Accesses to deployed software components and registered platform services are controlled to ensure isolation of users. The middleware components, such as applications servers, enterprise service busses, and messaging systems are extended to assure equivalent performance to all users. Software components are often created using specific development environments or libraries to ensure certain component properties, such as statelessness for example, to enable a platform controlled elasticity of deployed applications. Billing services, also offered by the platform, are often based on the amount of storage used, number of messages sent, or accesses to the hosted services.
Relation to other patterns: The offered platform services follow cloud infrastructure patterns. Communication between components can be realised using messaging patterns and storage using cloud storage patterns.
Platform as a Service may be built upon an Infrastructure as a Service to enable elasticity on the underlying hardware on which the offered middleware services are hosted.
To enable multi‐tenancy of the offered middleware components, such as applications services, messaging systems etc., they implement multi‐tenancy patterns. Platform as a Service may be part of the offerings that form a public, private, or hybrid cloud. In this case it is ensured that resources are available at virtually infinite numbers.
#3 Preference – Infrastructure as a Service (IaaS)
Problem Statement: How can IT‐infrastructure be offered dynamically over a network?
Context: The (virtual) servers of an elastic infrastructure shall be offered to different users that are isolated from each other on a pay‐per‐use basis.
Challenges: Resources in an elastic infrastructure share common underlying resources such as networking, storage and optionally servers if virtual servers are provisioned on top of them. In such a setting different users of the infrastructure must be isolated regarding data and performance. It therefore has to be ensured that users cannot access other users’ data and that resource utilisation of one user does not affect the performance of another user. Also, additional support systems are needed to monitor the resource usage and bill them to customers accordingly.
Solution: Access control is added to an elastic infrastructure and the resource management is extended to isolate users from each other. The monitoring component collects additional information to support pay‐per‐use billing
Results: Access controls authenticates users and control their usage of the API during the management of (virtual) server images and the starting and stopping of (virtual) servers. Further, the monitoring component is extended to support billing based on accesses to the API as well as the amount of used resources. The resource management now ensures that one user does not utilise that many resources that it affects other users. Assured service levels are often expressed as a comparison to traditional systems, i.e. compute performance is said to be equivalent to a 1.6 GHz dual core CPU. Statements like this however have no indication how this performance is actually achieved.
Additional requirements regarding the isolation of running (virtual) server relies on technologies used in traditional server hosting environments, such as quotas for communication channel throughput.
Relation to other patterns: Higher functionality that constitutes the application stack, such as middleware, software, or individual composition of applications can also be offered as a service as described by the Platform, Software, and Composition as a Service patterns respectively.
Infrastructure as a Service may be part of the offerings that form a public, private, or hybrid cloud. In this case it is ensured that resources are available at virtually infinite numbers.