(Reprinted courtesy of O'Reilly from the Book "Web 2.0 Architectures". Purchase book here)
The Software as a Service (SaaS) acronym has confused many people as vendors have abused the term to hawk anything with a network capability. In order to understand it, it is useful to tease out the core aspects of it agnostic to any specific implementation or product. James Governor, Dion Hinchcliffe and I wrote about it in the book "Web 2.0 Architectures" along with other patterns. In this context, a pattern is the idea of capturing architectural design ideas as archetypal and reusable description. SaaS is in effect, a pattern specifically for the delivery of software functionality to the end consumer.
To describe it within the book, we used the MacKenzie-Nickull Architectural Patterns meta-model.
Pattern
Software as a Service (SaaS)
Also Known As
Terms often associated with the Software as a Service pattern include:
Utility Computing and Cloud Computing
Cloud Computing is not the same as SaaS; rather, it is a specialized pattern of virtualization. Utility and Cloud Computing refer to treating computing resources as virtualized, metered services, similar from a consumer’s perspective to how we consume other utilities (such as water, gas, electricity, and pay-per-view cable).
On-demand applications
On-demand applications provide access to computing resources on an ad hoc basis when the functionality is required. Using the http://createpdf.adobe.com service to create a single PDF document online rather than having to download and install a version of Acrobat is a good example.
Software Above the Level of a Single Device
This pattern relates to software that spans Internet-connected devices and builds on the growing pervasiveness of the online experience. It touches on various aspects of the SaaS pattern; in particular, the concepts of distributed computing of tasks via network connections.
Model-View-Controller (MVC)
Some people consider SaaS a specialization of the MVC pattern that distributes the Model, View, and Controller (or parts thereof) over multiple resources located on the Internet. It is strongly related to SaaS, and most SaaS providers follow the MVC pattern when implementing SaaS.
Business Problem (Story)
Consider a software vendor that wishes to develop spam removal software to keep spam from reaching its clients’ inboxes. This can be achieved by writing algorithms that analyze incoming local email messages, detect possible spam messages, and flag them in such a way that the mailbox owners can filter them out automatically without having to manually sort through all the messages.
The business problem arises from the fact that spam is constantly changing, which makes it difficult to detect and flag. Spam is typically sent from a variety of spoofed email addresses, and the specific text patterns are changed frequently. For example, if you wanted to detect any spam that had the word “Viagra” in it, you could simply use Perl’s regular expression matching syntax:
if ($emailString =~ m/viagra/;)
{
$SpamScore =+ 1;
}
However, all the spammer would have to do is alter the case of some of the letters to thwart this detection, as in the following:
"ViAGRA"
You could counter this in Perl by adding an i flag to ignore case, as follows:
if ($emailString =~ m/viagra/i;)
{
$SpamScore =+ 1;
}
However, the spammer could then substitute an exclamation point, the number 1, or the letter l for the letter I, capitalizing on the face that the human mind will perceive “Viagra” if it sees “V!AGRA,” “V1AGRA,” or “VlAGRA.” To a human these terms might semantically be the same, but changing the one byte from an I to another character will render useless the efforts of a computer trying to filter spam based on a string of characters. Each possible mutation would require the software vendor to write and distribute new patches to detect the latest variations to each client, possibly on a daily or even hourly basis. In this case, the Perl syntax could be changed to:
if ($emailString =~ m/v.*gra/i;) {
{
$SpamScore =+ 1;
}
The ballet between those who create and send spam and those who try to detect and delete it is a constantly morphing work in progress, with new steps being introduced every day. Each individual the company serves could attempt to create these rules by himself for his own mailbox, but this would be both ineffective and inefficient. Users would each sample only a small subset of all spam, would not be able to easily create heuristic filters to detect spam, and would likely spend an inordinately large amount of time on this activity.
Context
The SaaS pattern is useful any time a customer base has needs that could be addressed more efficiently or reliably by creating a service all of them can share across organizational boundaries.
This pattern occurs whenever a person or organization is building an application whose model, control, or view aspects must be refreshed based on dynamic circumstances or instances in which specialized functionality of the application must be delivered. The pattern could apply anywhere a static application does not easily lend itself to frequent specialization of the model, view, or control aspects required to make it function properly.
The pattern is useful in situations in which users need more computer resources than they can easily support on their local systems and in those situations where users need particular computing resources only occasionally.
Derived Requirements
Computing resources should be architected to be reachable (as discussed in the section on SOA) over whatever network or fabric the architect designs the application to work with. For example, most web-enabled SaaS applications use a common transport protocol, and most ham radio operators use a common frequency to broadcast information or pass it along in a chain.
Functional components of the core computing resources must be usable via a well-defined interface. Such an interface should not be bound to a single client or single model for delivery (such as installation of an application) and should support multiple options for building the user interface (e.g., web-based or client application interface).
Generalized Solution
SaaS is a model of software delivery in which the manufacturer is responsible for the daily technical operation of the software provided to the clients (including maintenance and support), while the clients enjoy the full benefits of the software from remote locations. SaaS is a model of “functionality delivery” rather than “software distribution.” Most of the functionality can be delivered over the Internet or made available in such a way that the end user can interact with the application to get that functionality without having to install the software on her machine. This approach can deliver functionality to any market segment, from home consumers to corporations, and hybrid solutions can deliver small pieces of client-side software that make certain tasks easier.
Static Structure
The basic deployment pattern for SaaS involves deploying different aspects of the model, view, and control components of an application to multiple physical locations. The deployment approach may vary greatly depending on the software and its complexity and dependence on other aspects. Figure 7.9, “Deployment patterns contrasted (SaaS versus conventional approach)” shows how the basic deployment pattern for SaaS differs from traditional software distribution.
The service should also be able to learn from its users when appropriate. This concept of “software that gets better as more people use it,” a hallmark of Web 2.0, has many advantages. For example, in the business story shown in Figure 7.10, “Spam filter software as a service”, if enough email flows through a pattern detector, spam recognition becomes much more accurate based on the collective interactions of thousands of users. As more and more users flag the same messages as spam, the server will begin to recognize those messages as spam, and the global filter will then prevent them from being delivered to other end users. Many readers probably use this type of functionality already without really knowing it.
Google’s Gmail is a prime example of this pattern in action. Google Search is another dynamic example of Software as a Service that gets better the more that people use it. Google actually tracks the links users click on to determine how many people seek the same resource for the same search term. This system is much more sophisticated than a simple adaptive algorithm, yet the principle benefit of large-scale use is that the system learns and adapts based on users’ behaviors.
This functionality is a side benefit of SaaS rather than a core aspect of the pattern.
Dynamic Behavior
The dynamic behavior of the SaaS pattern can vary greatly depending on which protocols, standards, and architectural approaches are chosen. Figure 7.11, “A dynamic view of one way to visualize SaaS” shows a common depiction of the pattern.
First, a user identifies his requirements for consuming computing resources. This pattern can be implemented at many levels of complexity, from a secure web service to a simple user interface such as an HTML web page in a browser. The user will interact with the service (the service in this case is a proxy), which will then invoke the core functionality. The responses are appropriately directed back to the user, as required.
Note that this pattern becomes very interesting when multiple users employ the resources and implementers have capabilities that do not exist for their non-SaaS counterparts. First, the functionality provider can detect and act on patterns in runtime interactions. An example of this might be the detection of some error state that is occurring for multiple users of the system (e.g., the email clients are crashing because of a nefarious script contained within some emails). Rather than waiting for enough users to contact the software provider with enough information to enable it to fix the error, the provider can detect the condition itself at an early stage and has access to sufficient information to enable it to trace the source of the error. Ultimately, all users of the software will have a much better user experience if problems are mitigated sooner rather than later and before they feel compelled to complain about them.
Second, a provider may want to consider scaling the system in the backend to handle large numbers of requests. Sudden traffic spikes can adversely impact the user experience, making the system seem unresponsive. Service providers may want to investigate other services, notably those of Cloud Computing providers, if they need to support widely varying usage levels. Most Cloud Computing providers offer automatic scaling to support the amount of processing power and storage needed by an application.
Implementation
As shown in Figure 7.12, “Distinctions of the SaaS pattern”,[75] designers of software provided as a service rather than as a static, installed entity must consider several new nuances of the industry, as these changes in how users interact with software vendors are affecting the way we should design and architect SaaS.
When implementing SaaS, you may need to ensure that no one can take advantage of your license model. For example, if you license only one user, what keeps that user from simply sharing her username and password and reselling your service? There are various types of license models for SaaS. Some are single-enterprise licenses, with the cost based on the size of the enterprise. Spam software and Microsoft Exchange Server are reported to use this model. By contrast, Adobe Systems uses a “per use” model for http://createpdf.acrobat.com, where users can either create PDFs one at a time or protect them with a persistent policy. Other software business models (e.g., for Google Search and other widgets) are built around advertising revenue models.
A software vendor implementing SaaS also can react swiftly to bugs in the system. The vendor can monitor all users concurrently to detect software glitches that may require immediate attention and may be able to fix them before most users even notice.
Business Problem (Story) Resolved
The spam detection software is housed in a federated server environment, and users’ incoming email can be automatically pre-passed through the filters to detect spam. Any spam that sneaks through can be recognized and trapped by secondary mechanisms (including human users) and reported back to the spam detection infrastructure, enabling the system to adapt to the latest spammer tactics. There is no discernable delay or lag in incoming email, and most spam email gets eliminated.
Sampling a very large cross section of all mail makes it easier to detect patterns indicating spam emails. This results in the entire system performing better, to the benefit of all users.
Specializations
SaaS may be specialized by using advanced computer algorithms to perform reasoning tasks such as inference. These ultra-advanced systems may one day be able to use cognitive skills to recognize and act on certain patterns of events. For example, these hybrid systems could use a combination of the Bayesian Theorem (conditional probability) and lexical heuristic filtering (finding evidence to support a hypothesis) to dynamically change their functionality. Such specializations will also benefit from adoption of the Collaborative Tagging (a.k.a. folksonomy) pattern, discussed later in this chapter, as it will help foster computational intelligence applications that can reason and infer hypotheses.
Known Uses
Postini, Inc. (which Google acquired in 2007[76]) figured out quite a while ago that centralization and offering its security, compliance, and productivity solutions as a service would result in better spam detection for end users. Recently, many other email companies have begun to use similar SaaS models. Apple’s iTunes music application is perhaps one of the most prominent examples of a hybrid approach to the Software as a Service pattern. The iTunes application has some predetermined functionality and user interfaces (the “V” and “C” components of “Model-View-Controller”); however, much of the information presented to the user is based on information (the “M” in “MVC”) the application receives from the iTunes servers during runtime. This hybrid approach can link user profiles to service calls to offer users better experiences.
Adobe Systems recently launched a service that allows people to manually create small numbers of PDF documents online and optionally link to them other functionality for things such as enabling rights management. Google continues to expand its SaaS offerings. Initially, its search service used algorithms to vary search result rankings based on user interaction patterns. Recently, Google has added multiple other SaaS offerings, including creation and manipulation of online documents, spreadsheets, and more. Note that most of Gmail has always been provided as a service rather than as an application.
Consequences
The negative consequences of using the SaaS pattern are minimal, but they need to be addressed from the outset. Offering software as a service may create additional complexity in supporting computing resources for large numbers of users. The ability to dynamically scale an offering based on surges in the number of users requesting the functionality is also an issue.
In addition, authentication—especially when used to force compliance with software licensing—can be difficult to implement and to police.
The most noteworthy consequence of implementing this pattern is that the software may have a dependency on an Internet connection. In many cases, if the connection does not work, neither will the software. When such a mechanism is possible and makes sense, the best way to avoid such issues is to employ client-side caching. The appropriateness of this strategy varies by application. Caching Google Search is difficult, and would be mostly useless in an environment where readers couldn’t go to the linked articles anyway. On the other hand, technologies like the Adobe Integrated Runtime (AIR) and Google Gears are steps in the right direction.
Denial-of-service attacks can also be a threat. A malicious user may be able to overpower the bandwidth or computational capabilities of software implemented as a service and effectively deny or greatly slow down other users’ experiences.
End users often prefer to keep their software in a controlled and secure environment. Because SaaS applications are not hosted or controlled by the user, the user might be subjected to occasional outages when service upgrades or other events take place on the provider side.
Also, personal security risks are inherent in passing information back and forth on the open Internet. Users should carefully assess what risks are acceptable for their purposes.
(c) Copyright - O'Reilly Media. See this and other patterns via the book at http://oreilly.com/web2/excerpts/9780596514433/specific-patterns-web20.html
Also Known As
Terms often associated with the Software as a Service pattern include:
Utility Computing and Cloud Computing
Cloud Computing is not the same as SaaS; rather, it is a specialized pattern of virtualization. Utility and Cloud Computing refer to treating computing resources as virtualized, metered services, similar from a consumer’s perspective to how we consume other utilities (such as water, gas, electricity, and pay-per-view cable).
On-demand applications
On-demand applications provide access to computing resources on an ad hoc basis when the functionality is required. Using the http://createpdf.adobe.com service to create a single PDF document online rather than having to download and install a version of Acrobat is a good example.
Software Above the Level of a Single Device
This pattern relates to software that spans Internet-connected devices and builds on the growing pervasiveness of the online experience. It touches on various aspects of the SaaS pattern; in particular, the concepts of distributed computing of tasks via network connections.
Model-View-Controller (MVC)
Some people consider SaaS a specialization of the MVC pattern that distributes the Model, View, and Controller (or parts thereof) over multiple resources located on the Internet. It is strongly related to SaaS, and most SaaS providers follow the MVC pattern when implementing SaaS.
Business Problem (Story)
Consider a software vendor that wishes to develop spam removal software to keep spam from reaching its clients’ inboxes. This can be achieved by writing algorithms that analyze incoming local email messages, detect possible spam messages, and flag them in such a way that the mailbox owners can filter them out automatically without having to manually sort through all the messages.
The business problem arises from the fact that spam is constantly changing, which makes it difficult to detect and flag. Spam is typically sent from a variety of spoofed email addresses, and the specific text patterns are changed frequently. For example, if you wanted to detect any spam that had the word “Viagra” in it, you could simply use Perl’s regular expression matching syntax:
if ($emailString =~ m/viagra/;)
{
$SpamScore =+ 1;
}
However, all the spammer would have to do is alter the case of some of the letters to thwart this detection, as in the following:
"ViAGRA"
You could counter this in Perl by adding an i flag to ignore case, as follows:
if ($emailString =~ m/viagra/i;)
{
$SpamScore =+ 1;
}
However, the spammer could then substitute an exclamation point, the number 1, or the letter l for the letter I, capitalizing on the face that the human mind will perceive “Viagra” if it sees “V!AGRA,” “V1AGRA,” or “VlAGRA.” To a human these terms might semantically be the same, but changing the one byte from an I to another character will render useless the efforts of a computer trying to filter spam based on a string of characters. Each possible mutation would require the software vendor to write and distribute new patches to detect the latest variations to each client, possibly on a daily or even hourly basis. In this case, the Perl syntax could be changed to:
if ($emailString =~ m/v.*gra/i;) {
{
$SpamScore =+ 1;
}
The ballet between those who create and send spam and those who try to detect and delete it is a constantly morphing work in progress, with new steps being introduced every day. Each individual the company serves could attempt to create these rules by himself for his own mailbox, but this would be both ineffective and inefficient. Users would each sample only a small subset of all spam, would not be able to easily create heuristic filters to detect spam, and would likely spend an inordinately large amount of time on this activity.
Context
The SaaS pattern is useful any time a customer base has needs that could be addressed more efficiently or reliably by creating a service all of them can share across organizational boundaries.
This pattern occurs whenever a person or organization is building an application whose model, control, or view aspects must be refreshed based on dynamic circumstances or instances in which specialized functionality of the application must be delivered. The pattern could apply anywhere a static application does not easily lend itself to frequent specialization of the model, view, or control aspects required to make it function properly.
The pattern is useful in situations in which users need more computer resources than they can easily support on their local systems and in those situations where users need particular computing resources only occasionally.
Derived Requirements
Computing resources should be architected to be reachable (as discussed in the section on SOA) over whatever network or fabric the architect designs the application to work with. For example, most web-enabled SaaS applications use a common transport protocol, and most ham radio operators use a common frequency to broadcast information or pass it along in a chain.
Functional components of the core computing resources must be usable via a well-defined interface. Such an interface should not be bound to a single client or single model for delivery (such as installation of an application) and should support multiple options for building the user interface (e.g., web-based or client application interface).
Generalized Solution
SaaS is a model of software delivery in which the manufacturer is responsible for the daily technical operation of the software provided to the clients (including maintenance and support), while the clients enjoy the full benefits of the software from remote locations. SaaS is a model of “functionality delivery” rather than “software distribution.” Most of the functionality can be delivered over the Internet or made available in such a way that the end user can interact with the application to get that functionality without having to install the software on her machine. This approach can deliver functionality to any market segment, from home consumers to corporations, and hybrid solutions can deliver small pieces of client-side software that make certain tasks easier.
Static Structure
The basic deployment pattern for SaaS involves deploying different aspects of the model, view, and control components of an application to multiple physical locations. The deployment approach may vary greatly depending on the software and its complexity and dependence on other aspects. Figure 7.9, “Deployment patterns contrasted (SaaS versus conventional approach)” shows how the basic deployment pattern for SaaS differs from traditional software distribution.
Figure 7.9. Deployment patterns contrasted (SaaS versus conventional approach)
The service should also be able to learn from its users when appropriate. This concept of “software that gets better as more people use it,” a hallmark of Web 2.0, has many advantages. For example, in the business story shown in Figure 7.10, “Spam filter software as a service”, if enough email flows through a pattern detector, spam recognition becomes much more accurate based on the collective interactions of thousands of users. As more and more users flag the same messages as spam, the server will begin to recognize those messages as spam, and the global filter will then prevent them from being delivered to other end users. Many readers probably use this type of functionality already without really knowing it.
Google’s Gmail is a prime example of this pattern in action. Google Search is another dynamic example of Software as a Service that gets better the more that people use it. Google actually tracks the links users click on to determine how many people seek the same resource for the same search term. This system is much more sophisticated than a simple adaptive algorithm, yet the principle benefit of large-scale use is that the system learns and adapts based on users’ behaviors.
This functionality is a side benefit of SaaS rather than a core aspect of the pattern.
Figure 7.10. Spam filter software as a service
Dynamic Behavior
The dynamic behavior of the SaaS pattern can vary greatly depending on which protocols, standards, and architectural approaches are chosen. Figure 7.11, “A dynamic view of one way to visualize SaaS” shows a common depiction of the pattern.
Figure 7.11. A dynamic view of one way to visualize SaaS
First, a user identifies his requirements for consuming computing resources. This pattern can be implemented at many levels of complexity, from a secure web service to a simple user interface such as an HTML web page in a browser. The user will interact with the service (the service in this case is a proxy), which will then invoke the core functionality. The responses are appropriately directed back to the user, as required.
Note that this pattern becomes very interesting when multiple users employ the resources and implementers have capabilities that do not exist for their non-SaaS counterparts. First, the functionality provider can detect and act on patterns in runtime interactions. An example of this might be the detection of some error state that is occurring for multiple users of the system (e.g., the email clients are crashing because of a nefarious script contained within some emails). Rather than waiting for enough users to contact the software provider with enough information to enable it to fix the error, the provider can detect the condition itself at an early stage and has access to sufficient information to enable it to trace the source of the error. Ultimately, all users of the software will have a much better user experience if problems are mitigated sooner rather than later and before they feel compelled to complain about them.
Second, a provider may want to consider scaling the system in the backend to handle large numbers of requests. Sudden traffic spikes can adversely impact the user experience, making the system seem unresponsive. Service providers may want to investigate other services, notably those of Cloud Computing providers, if they need to support widely varying usage levels. Most Cloud Computing providers offer automatic scaling to support the amount of processing power and storage needed by an application.
Implementation
As shown in Figure 7.12, “Distinctions of the SaaS pattern”,[75] designers of software provided as a service rather than as a static, installed entity must consider several new nuances of the industry, as these changes in how users interact with software vendors are affecting the way we should design and architect SaaS.
Figure 7.12. Distinctions of the SaaS pattern
When implementing SaaS, you may need to ensure that no one can take advantage of your license model. For example, if you license only one user, what keeps that user from simply sharing her username and password and reselling your service? There are various types of license models for SaaS. Some are single-enterprise licenses, with the cost based on the size of the enterprise. Spam software and Microsoft Exchange Server are reported to use this model. By contrast, Adobe Systems uses a “per use” model for http://createpdf.acrobat.com, where users can either create PDFs one at a time or protect them with a persistent policy. Other software business models (e.g., for Google Search and other widgets) are built around advertising revenue models.
A software vendor implementing SaaS also can react swiftly to bugs in the system. The vendor can monitor all users concurrently to detect software glitches that may require immediate attention and may be able to fix them before most users even notice.
Business Problem (Story) Resolved
The spam detection software is housed in a federated server environment, and users’ incoming email can be automatically pre-passed through the filters to detect spam. Any spam that sneaks through can be recognized and trapped by secondary mechanisms (including human users) and reported back to the spam detection infrastructure, enabling the system to adapt to the latest spammer tactics. There is no discernable delay or lag in incoming email, and most spam email gets eliminated.
Sampling a very large cross section of all mail makes it easier to detect patterns indicating spam emails. This results in the entire system performing better, to the benefit of all users.
Specializations
SaaS may be specialized by using advanced computer algorithms to perform reasoning tasks such as inference. These ultra-advanced systems may one day be able to use cognitive skills to recognize and act on certain patterns of events. For example, these hybrid systems could use a combination of the Bayesian Theorem (conditional probability) and lexical heuristic filtering (finding evidence to support a hypothesis) to dynamically change their functionality. Such specializations will also benefit from adoption of the Collaborative Tagging (a.k.a. folksonomy) pattern, discussed later in this chapter, as it will help foster computational intelligence applications that can reason and infer hypotheses.
Known Uses
Postini, Inc. (which Google acquired in 2007[76]) figured out quite a while ago that centralization and offering its security, compliance, and productivity solutions as a service would result in better spam detection for end users. Recently, many other email companies have begun to use similar SaaS models. Apple’s iTunes music application is perhaps one of the most prominent examples of a hybrid approach to the Software as a Service pattern. The iTunes application has some predetermined functionality and user interfaces (the “V” and “C” components of “Model-View-Controller”); however, much of the information presented to the user is based on information (the “M” in “MVC”) the application receives from the iTunes servers during runtime. This hybrid approach can link user profiles to service calls to offer users better experiences.
Adobe Systems recently launched a service that allows people to manually create small numbers of PDF documents online and optionally link to them other functionality for things such as enabling rights management. Google continues to expand its SaaS offerings. Initially, its search service used algorithms to vary search result rankings based on user interaction patterns. Recently, Google has added multiple other SaaS offerings, including creation and manipulation of online documents, spreadsheets, and more. Note that most of Gmail has always been provided as a service rather than as an application.
Consequences
The negative consequences of using the SaaS pattern are minimal, but they need to be addressed from the outset. Offering software as a service may create additional complexity in supporting computing resources for large numbers of users. The ability to dynamically scale an offering based on surges in the number of users requesting the functionality is also an issue.
In addition, authentication—especially when used to force compliance with software licensing—can be difficult to implement and to police.
The most noteworthy consequence of implementing this pattern is that the software may have a dependency on an Internet connection. In many cases, if the connection does not work, neither will the software. When such a mechanism is possible and makes sense, the best way to avoid such issues is to employ client-side caching. The appropriateness of this strategy varies by application. Caching Google Search is difficult, and would be mostly useless in an environment where readers couldn’t go to the linked articles anyway. On the other hand, technologies like the Adobe Integrated Runtime (AIR) and Google Gears are steps in the right direction.
Denial-of-service attacks can also be a threat. A malicious user may be able to overpower the bandwidth or computational capabilities of software implemented as a service and effectively deny or greatly slow down other users’ experiences.
End users often prefer to keep their software in a controlled and secure environment. Because SaaS applications are not hosted or controlled by the user, the user might be subjected to occasional outages when service upgrades or other events take place on the provider side.
Also, personal security risks are inherent in passing information back and forth on the open Internet. Users should carefully assess what risks are acceptable for their purposes.
(c) Copyright - O'Reilly Media. See this and other patterns via the book at http://oreilly.com/web2/excerpts/9780596514433/specific-patterns-web20.html
