Click here to Skip to main content
Click here to Skip to main content

Cloud Computing - SaaS

, 30 Dec 2009
Rate this:
Please Sign up or sign in to vote.
Introduction to Cloud Computing - SaaS.

Introduction

Cloud computing is the current buzz word in the air. This paper begins by asking just what exactly is cloud computing. We will take a high-level look at how cloud computing works and how is that going to make an impact to our current working environment. In the later part of the paper, we will take a deeper look into one of the categories of cloud computing, SaaS (software as a service). But to start off, let's understand the basic concepts of cloud computing.

What is Cloud Computing?

Cloud computing, as the name suggests, is a style of computing where dynamically scalable and often visualized resources are provided as a service over the internet. These services can be consumed by any user over a standard HTTP medium. The user doesn't need to have the knowledge, expertise, or control over the technology infrastructure in the "cloud" that supports them. The name cloud computing was inspired by the cloud symbol that's often used to represent the Internet inflow charts and diagrams. The clouds denote the abstraction of the complex infrastructure it conceals.

The diagram below displays the basic high-level layout of cloud computing, where the provider would create their solution (software, infrastructure, or platform) on the internet and one or more users can consume that service "on demand".

Cloud computing can be categorized into three groups:

  1. Platform as a Service (PaaS)
  2. Infrastructure as a Service (IaaS)
  3. Software as a Service (SaaS)

We will take a deep look into the Software as a Service (SaaS) category of cloud computing in this paper.

A cloud can be private or public. A public cloud sells services to anyone on the Internet. A private cloud is a proprietary network or a data center that supplies hosted services to a limited number of people. When a service provider uses public cloud resources to create their private cloud, the result is called a virtual private cloud. Private or public, the goal of cloud computing is to provide easy, scalable access to computing resources and IT services.

All the major companies have come up with their own code based or non-code based cloud computing frameworks. Some of the most prominent code-based frameworks are:

  1. Java Google Web Toolkit (Google App Engine).
  2. Python Djangno (Google App Engine)
  3. Ruby on Rails
  4. Microsoft .NET (Azure Service Platform)

There are numerous ISVs (e.g., Mosso) that provide a platform to host cloud based solutions.

Where SaaS Fits In

SaaS is one of the methodologies of Cloud Computing, which is based on a "one-to-many" model whereby an application is shared across multiple clients. The exact definition of software as a service (SaaS) is open to debate, and asking different people would probably result in different definitions. Everyone believe that SaaS is going to have a major impact on the software industry, because software as a service will change the way people build, sell, buy, and use software. For this to happen, though, software vendors need resources and information about developing SaaS applications effectively. Still, most experts would probably agree on a few fundamental principles that distinguish SaaS from traditional packaged software on the one hand, and simple websites on the other. Expressed most simply, software as a service can be characterized as "Software deployed as a hosted service and accessed over the Internet".

Software as a service (or SaaS) is a way of delivering applications over the Internet as a service. Instead of installing and maintaining software, you simply access it via the Internet, freeing yourself from complex software and hardware management. SaaS applications are sometimes called Web-based software, on-demand software, or hosted software. Whatever the name, SaaS applications run on a SaaS provider's servers. The provider manages access to the application, including security, availability, and performance. SaaS customers have no hardware or software to buy, install, maintain, or update. Access to applications is easy: you just need an Internet connection. This type of cloud computing delivers a single application through the browser to thousands of customers using a multi-tenant architecture. On the customer side, it means no upfront investment in servers or software licensing; on the provider side, with just one app to maintain, costs are low compared to conventional hosting.

Salesforce.com is by far the best-known example among enterprise applications which provide CRM solutions as SaaS, but SaaS is also common for HR apps, and has even worked its way up the food chain to ERP, with players such as Workday. Beside these, some of the desktop applications like Google Apps and Zogo Office have made their mark in the market.

Looking Down the Well: SaaS

Let's take a deeper look at the basic principles of SaaS, i.e., software deployed as a hosted service and accessed over the Internet. We can come up with two major categories of SaaS:

  1. Line-of-business services, offered to enterprises and organizations of all sizes. Line-of-business services are often large, customizable business solutions aimed at facilitating business processes such as finances, supply-chain management, and customer relations. These services are typically sold to customers on a subscription-basis.
  2. Consumer-oriented services, offered to the general public. Consumer-oriented services are sometimes sold on a subscription-basis, but are often provided to consumers at no cost, and are supported by advertising.

Moving from offering on-premise software to offering software as a service requires software vendors to shift their thinking in three interrelated areas: in the business model, in the application architecture, and in the operational structure.

The Business Model

Most software continues to be sold in the same way it has been sold for decades. The customer buys a license to use the software, and installs it on hardware that belongs to the customer or that is otherwise under the customer's control, with the vendor providing support as directed by the terms of the license or a support agreement. In an honest, above-board software transaction, the notion of a "license" can seem like something of a technicality: legally, the customer is only purchasing the right to use a copy of the software, but for practical purposes, it's as though the customer "owns" the software and may use it as often and for as long as it wishes. SaaS brings a new concept which is defined, i.e., instead of "owning" important software outright, customers are told that they can pay for a subscription to software running on someone else's servers, software that goes away if they stop subscribing.

Let's look at it from a different angle. Basically speaking, there are three types of components to an IT infrastructure in a company:

  1. Software
  2. Hardware
  3. Professional service

Out of these, from an organization perspective, software is the most important aspect of it, as software is the main component which helps them complete the objective of the organization. Whereas, hardware and professional service enable the software to function and produce the result needed for the organization. In other words, an organization would be happy to add new software or functionality to an existing software without any addition to the hardware, if existing hardware would enable the new software/functionality to run effectively, but no organization would add a new hardware if there is no anticipated need of a new software.

But with the current situation, majority of the budget is spent on the hardware and the software professional to run the software. This leaves a minority of the budget for software which will most directly involve in information management, which is the ultimate goal of any IT organization.

In opposed to that, if the organization can consume these software from a remote location, which is being managed by a third-part SaaS vendor, and they would only need to pay the subscription of that software, then a huge chuck of their budget can be saved from hardware and professional services, since the hardware and professional services will be managed by the third party SaaS vendor. This would enable them to spend majority of the budget on software services, which would have direct impact on meeting the objective of their organization. Moreover, applications delivered over the Web or through smart clients place significantly less demand on a desktop computer than traditional, locally-installed applications, which enables the customer to extend the desktop technology life-cycle significantly.

From a SaaS provider perspective, for SaaS applications that are built to scale well, the operating cost for each customer will continue to drop as more customers are added. As this is happening, the provider will develop multi-tenancy as a core competency, leading to higher-quality offerings at a lower cost. Therefore, even accounting for the hardware and professional services costs incurred by SaaS vendors, customers can still obtain significantly greater pure software functionality for the same IT budget.

A small question, is this not a fairy tale, as the subscription for the software service would also include the management of the server and the professional service? The answer is no, and the magic behind is "Economy of Scale". A SaaS vendor with x number of customers subscribing to a single, centrally-hosted software service enables the vendor to serve all of its customers in a consolidated environment. For example, a line-of-business SaaS application installed in a load-balanced farm of five servers may be able to support 50 medium-sized customers, meaning that each customer would only be responsible for a tenth of the cost of a server. A similar application installed locally might require each customer to dedicate an entire server to the application - perhaps more than one, if load balancing and high availability are concerns.

There are clearly quite a lot of benefits for both the consumer (end users) as well as the providers. We can consolidate some of the core points as mentioned below:

Realizing the benefits of SaaS requires shifts in thinking on the part of both the provider and the customer, and it's up to the provider to help the customer make this shift.

Application Architecture

Sounds pretty good? But, how are the applications going to be made so that end users and providers can make the maximum benefit out of it?

Much like any other software, Software as a Service can also take advantage of Service Oriented Architecture to enable software applications to communicate with each other. Each software service can act as a service provider, exposing its functionality to other applications via public brokers, and can also act as a service requester, incorporating data and functionality from other services.

It is important to understand that the SaaS methodology requires system architecture capable of supporting peak usage demands and the ability to process large numbers of transactions in a secure and reliable environment. The software would need to meet certain criteria to work on a model such as this. The application would need to be well designed to sustain and provide scalability and the ease of use of traditional desktop applications. There are three key points which would differentiate a successful SaaS application from an unsuccessful SaaS application:

  • Scalability: Scaling the application means maximizing concurrency and using application resources more efficiently; for example, optimizing locking duration, statelessness, sharing pooled resources such as threads and network connections, caching reference data, and partitioning large databases.
  • Multi-tenant efficient: Multi-tenancy may be the most significant paradigm shift that an architect accustomed to designing isolated, single-tenant applications has to make. For example, when a user at one company accesses customer information by using a CRM application service, the application instance that the user connects to may be accommodating users from dozens, or even hundreds, of other companies - all completely abstracted to any of the users. This requires an architecture that maximizes the sharing of resources across tenants, but that is still able to differentiate data belonging to different customers.
  • Configurable: if a single application instance on a single server has to accommodate users from several different companies at once, you can't simply write custom code to customize the end-user experience - anything you do to customize the application for one customer will change the application for other customers as well. Instead of customizing the application in the traditional sense, then, each customer uses meta data to configure the way the application appears and behaves for its users. The challenge for the SaaS architect is to ensure that the task of configuring applications is simple and easy for the customers, without incurring extra development or operation costs for each configuration.

There can be four ways of hosting an application on the SaaS architecture. These are also called as the maturity models of SaaS:

  • Ad hoc/Custom: It is similar to the traditional application service provider (ASP) model of software delivery, dating back to the 1990s. Each customer has his own customized version of the hosted application, and runs his own instance of the application on the host's servers.
  • Configurable: The vendor hosts a separate instance of the application for each customer (or tenant). Unlike the previous one, each instance is individually customized for the tenant; at this level, all instances use the same code implementation, and the vendor meets customers' needs by providing detailed configuration options that allow the customer to change how the application looks and behaves to its users. Despite being identical to one another at the code level, each instance remains wholly isolated from all the others.
  • Configurable, multi-tenant-efficient: The vendor runs a single instance that serves every customer, with configurable meta data providing a unique user experience and feature set for each one. Authorization and security policies ensure that each customer's data is kept separate from that of other customers; and, from the end user's perspective, there is no indication that the application instance is being shared among multiple tenants. This approach eliminates the need to provide server space for as many instances as the vendor has customers, allowing for a much more efficient use of computing resources than the second level, which translates directly to lower costs. A significant disadvantage of this approach is that the scalability of the application is limited.
  • Scalable, configurable, multi-tenant-efficient: The vendor hosts multiple customers on a load-balanced farm of identical instances, with each customer's data kept separate, and with configurable meta data providing a unique user experience and feature set for each customer.

High Level Architecture

The key behind the economic advantages for SaaS is an architecture that uses "customization through configuration" and intelligent data partitioning. Without these two elements, you probably won't be able to move past the first maturity level (Ad hoc/Custom) and recognize the efficiencies of multi-tenancy.

The basic architecture of SaaS is quite similar to any SOA (Service Oriented Architecture) based application. Probably, a few of the additions are two extra layers:

  1. Meta-data Services: The meta data service provides customers with the primary means of customizing and configuring the application to meet their needs. Typically, this can be categorized in broad areas: user interface and branding, work flow and business rules, extension to data model access control.
  2. Security Services: The SaaS provider typically delegates to each tenant the responsibility for creating and maintaining their own user accounts, a process known as delegated administration. Delegated administration creates a situation in which the customer is responsible for creating individual user accounts, but the vendor has to authenticate them. Typically, access to resources and business functions in a SaaS application is managed by using roles that map to specific job functions within an organization. Each role is given one or more permissions that enable users assigned to the role to perform actions in accordance with any relevant business rules.

Large-scale enterprise software is intended to be used by thousands of people simultaneously. If you have experience building enterprise applications of this sort, you've gotten to know first-hand the challenges of creating a scalable architecture. For a SaaS application, scalability is even more important: you'll have to support the average user base of a single customer, multiplied by the total number of customers that you have. Applications can be scaled up (by moving the application to a larger, more powerful server) and scaled out (by running the application on more servers). A few of the common best practices for designing SaaS applications, that the experts adhere to are:

  • Design the application to run in a stateless fashion, with any necessary user and session data stored either on the client side, or in a distributed store that's accessible to any application instance. Statelessness means that each transaction can be handled by one instance as well as any other; a user may transact with dozens of different instances during a single session, without ever knowing it.
  • Design the application to conduct I/O operations asynchronously, so that the application can perform useful work while waiting for input and output to complete.
  • Pool resources such as threads, network connections, and database connections; this helps maximize your computing resources, and it improves your ability to predict resource usage.
  • Write your database operations in such a way as to maximize concurrency and minimize exclusive locking. For example, don't lock records when performing read-only operations.

Based on the maturity model chosen for the SaaS implementation, the database schema would differ. Keeping tenancy in mind, the database schema can be:

Shared Database, Shared Schema (for Ad-Hoc/Custom and Configuration maturity model) Shared Database, Separate Schema (for Configuration, multi-tenant efficient maturity model) and Separate Database (for scalable, configurable, multi-tenant maturity model).

Conclusion

Cloud Computing and SaaS is definitely going to make a huge impact to our current way of working. Consuming and exposing all software services over the HTTP network would enable the organization IT infrastructure to fully depend on the Internet medium. There have been criticisms and counter-criticisms for such a dependency. If SaaS becomes fully functional, it might probably solve one of the major concerns of the software industry, which is making the application development companies lose billions of dollars each year, and that is illegal piracy of software. Time will only tell.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

No Biography provided

Comments and Discussions

 
GeneralMy vote of 5 [modified] Pinmemberpashad28-Dec-11 20:31 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140709.1 | Last Updated 30 Dec 2009
Article Copyright 2009 by Bhaskardeep Khaund
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid