How to SaaS

This is my first blog entry and I am happy to get this blog meant only for Microsoft Full Time Employees.

Okay coming on to the title for this blog post. Today I am going to write down on Sofware as a Service (SaaS) architecture strategy.

I will un-cover the technical aspects involved in building a SaaS application and very high level overview of the technical aspects of a SaaS solution.

These concepts can be applied to any Application which is a good candidate for a SaaS application.

Contents:

1.     SaaS- Introduction

2.     SaaS -Challenges

3.     SaaS -Solution to challenges

SaaS-Introduction

A SaaS application can be defines as any “Software deployed as a service and accessed using internet technologies”. In order to realize a SaaS solution (in fact any solution) we need to do two things:

1. Build our application which can be used as a service over internet by different clients. This could range from a programmatic service (accessed programmatically by other softwares) to a stand-alone application used by different clients. This step is involves us to follow certain steps that are different than developing a normal “On-Premise” or simply called a non-SaaS application.

Typically when we develop an application (a non-SaaS application) then we do assume two things:

·         Application will be installed at client side (e.g., a desktop application) be it through a CD or downloading via internet. This also implies that the client will have to do the maintenance (like upgrading to new version, apply patches, maintain databases etc.) of application even after he has bought the application (not true for Application Service Provider model). This fact is not true in terms of a web application. So we can say that any web application forms a different category of application since it is not installed at client side. But still we cannot call ANY web application a SaaS application.

·         Application will be served to requirement of a particular client. If another client needs some changes in the application, we will make changes in the application source code and then run another instance of that application for the new client. So in nutshell, we assume that one application is meant for one client only. This assumption is true even for a web application.

Here comes the difference! The core of a SaaS application is based on the opposites of these two (above mentioned) assumptions. The following are assumptions that are true for a SaaS application.

·         Application will be typically deployed and maintained by a hosting provider. So, clients don’t have to invest in terms of buying hardware resources and employing the IT staff to manage the application. This will be done by the hosting provider.

·         Application will be accessed by clients using internet. In special cases where a SaaS application is hosted inside the enterprise itself this is not true but still the clients accessing the hosted application will still use internet technologies to access the application.

·         A single SaaS application (in fact a single database too) serves more than one client having different needs. So the application will be designed in such a way that only a single application instance will be able to provide different functionalities to different clients. This model is more popularly known as Multi-tenant model.

Among these assumptions, the last assumption related to multi-tenancy requires a SaaS application to be architected in a special way keeping in mind about certain aspects of a multi-tenant application. These aspects form the challenges of building a SaaS application and also our next topic of discussion.

2. SaaS world does not end just by building the application that satisfies SaaS characteristics. Deploying a SaaS application forms another set of challenges. Typically a SaaS application is deployed by a SaaS hosting provider and the hosting provider is responsible of maintaining the application. So, not only clients get rid of maintaining the application but also ISVs get rid of that aspect.

Microsoft provides end to end resources in developing and deploying a SaaS application. It provides resources ranging from development frameworks and technical resources used to build and design the application to hosting options that assist in deploying the application.

SaaS-Challenges

As we have seen that one of the important characteristics of a SaaS application is multi-tenancy, this aspect implies further challenges in building a SaaS application. Let’s see those challenges after trying to define the multi tenancy.

Multi Tenant Architecture:

A single SaaS application serves more than one client having different needs. This means that you run only one instance of the application and that single instance will be accessed by all clients. For example, you built a CRM SaaS application and hosted it over a SaaS hosting provider. Now many organizations have different CRM needs depending on the nature of business they do. We will not build any separate application for all the companies but our single application will have the option using which each client will customize the SaaS application according to his need. Not only that a single database can be used (not always) for storing data of different clients. So security is also a major concern. Let’s see all the concerns and challenges that we need to consider while building a SaaS application.

Challenges

Here are some important challenges that we need to consider while building a SaaS application. It is important to note that not all challenges are required in a single SaaS application. These challenges depend on your application’s requirement. Here only the challenges are presented. Next section will deal about ways to address those challenges.

Business Agility:

Different organizations can have (in fact they do have) different business needs. For example process of approving a loan in two banks may be different in a way that Bank-X requires a Loan Manager to approve the loan request document before sanctioning the loan while Bank-Y requires both the Loan Manager and Bank Manager to approve the loan request. Now if we are building a SaaS application to target these different business requirements, then, we must provide a way through which different clients can configure the SaaS application according to their business requirement. This is what we mean by Business Agility (we can call it as ability of an application to configure its business rules).

User Interface Configurability:

Each client of our SaaS application might have the requirement to change the UI of the application according to their need. This could range from configuring color, font, Company Logo etc. to positioning , ordering of UI elements (for example web parts) etc. incorporating this capability of configuring the UI of a SaaS application according to client’s requirements form another requirement and thus challenge to building a SaaS application.

Database configurability:

Since typically a SaaS application uses a single database (not always) for every client, all the data of different clients can be stored in a single database. This approach makes a SaaS application more efficient since only a single database is used but this also poses challenges on how to design the database so that different data model needs can be accommodated in a single database approach. This approach is commonly known as Multi-tenant database.

Security:

Since a single application instance caters to requests of all clients, it is important (in fact a must) that we have some mechanism to make sure that data of each client remains secured and users of a particular client can access data meant for them alone.

Scalability:

A single application can be used by different clients and each client can have a number of users accessing the SaaS application. This puts a constraint that the application must be able to handle increased number of users. Scalability is a challenge that has to be handles at 3 different levels: The SaaS application (your code) must take care of scalability issues, the SaaS application server (generally done by hosting providers) must be scalable and then finally the database server must be scalable. Scalability at all these three different levels is achieved using different techniques that we will see later on.

SaaS-Solution to Challenges

We will take all the challenges, discussed in previous section, one at a time and propose techniques used to address these challenges. To some techniques we will provide the direct links to already existing resources instead of dwelling those techniques in detail out here.

Business Agility:

This aspect involves designing your SaaS application architecture in such a way that clients of the application can modify the business logic written in your application. Now, how do we provide the modification of business logic of application without writing new code or even modifying existing code?

The most commonly used approach is Metadata driven architecture. Let’s see how it work and what ways (maybe tools etc.) do Microsoft helps in designing such applications.

Concept of metadata driven architecture is quite simple and complex aspects are handled by Microsoft technologies and tools. In a metadata driven system there are three major steps involved:

1. Metadata: Whatever features of an application are to be configured during runtime, we define those features of the application in the form of Metadata (it could be an XML file stored on hard drive or a backend database). This metadata can be extended by writing more data to it.
2. Metadata Services: A set of programmatically accessible services are designed that provides an interface to access/modify the metadata. This can be thought of as an interface layer or façade layer. We provide these services so that metadata can be exposed (maybe over internet) to any application/tool while keeping the integrity, validity etc. of the metadata intact. Imagine a situation where an application (by mistake) modified the metadata that violates some core semantics of metadata. Providing an interface layer to any data store is a common principle in building a distributed application and any SaaS application is on first place a distributed application.
3. An Engine: The business layer of our SaaS application will be nothing more than an engine that runs the business processes defined in the metadata store and accessed using metadata services. These steps could be a bit complex depending on the configurability requirement of your SaaS application therefore Microsoft provides a number of options to build such systems.

Most commonly used technology is using BizTalk Server. BizTalk server has two main components:

3. • A process execution engine that manages the steps, applies the business logic, and invokes the supporting applications of a complex process and/or transaction set.
   • A multi-transport messaging hub for transforming and routing information to and from applications and process steps.

Another technology seen by developers in their most loved development environment (Visual Studio) is Windows Workflow Foundation (Part of .NET Framework 3.0) used to model business processes as workflows.

Yet another technology from Microsoft is Microsoft Web Services used to build Service oriented applications which in turn is essential to deliver the business agility and IT .

For more details on these technologies you can refer to following resources:

https://www.dmreview.com/article_sub.cfm?articleId=1075079

https://www.microsoft.com/technet/prodtechnol/biztalk/biztalk2004/planning/business-rules-framework-overview.mspx

https://www.microsoft.com/technet/prodtechnol/biztalk/biztalk2004/planning/bpm-solution-overview.mspx

https://msdn2.microsoft.com/en-us/architecture/aa699456.aspx

https://msdn2.microsoft.com/en-us/architecture/aa948857.aspx

User Interface Configurability:

The process involved in allowing end users to modify the user interface according to their need is similar to achieving Business Agility- Using Metadata Driven Architecture. End-user preferences are stored in form of Metadata and UI is composed using this metadata. User interface metadata defines connections into user interface elements, such as menus, Windows Forms controls, and HTML.

https://msdn2.microsoft.com/en-us/library/ms954610.aspx

https://www.microsoft.com/technet/solutionaccelerators/cits/iwp/ibf/soldev/moibf1_sdg_07.mspx

https://msdn2.microsoft.com/en-us/library/aa480019.aspx#aj1metadat_topic13

https://msdn2.microsoft.com/en-us/library/ms136029.aspx

Database Configurability:

For a SaaS application we can use different databases for each client and also use single database for every client depending on the need of the application. This asks us to design a Multi-Tenant Data Architecture (where tenant is equivalent to client).

This involves choosing an approach to in a given scenario and also how to realize that approach. There is a very good article dedicated to developing a Multi-Tenant database system. I would recommend going through that article while going to develop the data model for your application.

https://msdn2.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4

Arcast:

https://www.skyscrapr.net/blogs/arcasts/archive/2006/07/18/232.aspx

Security: (Most of the content of this heading is from the famous Catching the Long Tail article)

As we discussed earlier, security is an important aspect of a SaaS application (in fact any application). Security requires special attention for a SaaS application because a single application instance is serving different clients. This poses two major challenges:

1. How will the administrative tasks related to security handles? For example, creating new users, security policies, and permissions etc. for every client is obviously different.
2. How to keep client specific request secured? This also involves keeping data for clients secured even if we have data for different clients in same table.

There are different techniques and patterns such as filtering, encryption etc. Let’s see an overview of how are security requirements handles by a SaaS application.

Common approach is to create security services for the application. So security is also applied in the form of services (sole reason is to incorporate the distinct requirement of SaaS application). SaaS application is built on the foundations of SOA (service oriented architecture) and services are building blocks of any SOA application. Typically we divide security services into two components:

• Authentication Services
• Authorization Services

The SaaS provider typically delegates to each tenant the responsibility for creating and maintaining its 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. To accommodate this delegated-administration model, SaaS designers use two general approaches for handling authentication: a centralized authentication system, or a decentralized authentication system. The approach that you choose will have ramifications for the complexity of your architecture and the way end users experience the application, and you should consider what your business model says about the needs of the application, customers, and end users when making a decision.

In a centralized authentication system, the provider manages a central user account database that serves all of the application's tenants. Each tenant's administrator is granted permission to create, manage, and delete user accounts for that tenant in the user account directory. A user signing on to the application provides his or her credentials to the application, which authenticates the credentials against the central directory and grants the user access if the credentials are valid.

This approach requires a relatively simple authentication infrastructure that is comparatively easy to design and implement, and that does not require any changes to the tenant's own user infrastructure. An important disadvantage to this approach is that a centralized authentication system makes it much more difficult to implement single sign-on, in which the application accepts the credentials that the user has already entered to gain access to his or her corporate network. Without single sign-on, users are frequently presented with an inconvenient login prompt when logging in to the application, and they must enter their credentials manually.

In a decentralized authentication system, the tenant deploys a federation service that interfaces with the tenant's own user directory service. When an end user attempts to access the application, the federation service authenticates the user locally and issues a security token, which the SaaS provider's authentication system accepts and allows the user to access the application

This is an ideal approach when single sign-on is important, because authentication is handled behind the scenes, and it doesn't require the user to remember and enter a special set of credentials. The decentralized approach is more complex than the centralized approach, however, and a SaaS application with thousands of customers will require individual trust relationships with each of the thousands of tenant federation services.

In many cases, the SaaS provider may want to consider a hybrid approach—using the centralized approach to authenticate and manage users of smaller tenants, and the federated approach for larger enterprises that demand, and will pay for, the single sign-on experience.

To understand more about security concepts and how to apply them you can refer following resources:

https://download.microsoft.com/download/5/c/4/5c49d9c8-a3e9-4806-8c6d-a621b8d2402b/Windows-basedHosting_CentralizedManagement.doc

https://www.microsoft.com/technet/security/guidance/identitymanagement/idmanage/P1Fund_4.mspx?mfr=true

To configure security at database level use guidelines given in following resource:

https://msdn2.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4

Scalability:

Scalability refers to the capability of an application to handle large concurrent requests. There are two approaches generally used to scale an application:

Scale Up: Scaling-up is process of upgrading the existing computer. For example, you can upgrade your Server computer from a 4 processor machine to an 8 processor.

Scale Out: Scaling-out is the process of adding additional computers. This ways if a server reaches its maximum number of requests, another server takes up further requests. SaaS solutions generally use Scale out. A Common techniques used for scaling out is clustering.

Scaling an application can typically be done at 3 levels:

• Scaling the backend database
• Scaling the Web Server on which the web application is running (scale up and scale out)
• Scaling the application itself

Please refer to following resources to learn about different scaling techniques:

Scaling SQL Server:

https://www.microsoft.com/sql/prodinfo/previousversions/scalability.mspx

 Techniques used for scaling application:

 https://technet2.microsoft.com/WindowsServer/en/library/4842d992-2b2f-41f8-b681-3696c6b23d5c1033.mspx?mfr=true

 Architecture and design review of application for scalability

https://msdn2.microsoft.com/en-us/library/ms998544.aspx

 https://msdn2.microsoft.com/en-us/library/aa479040.aspx

Another good resource on scaling

https://download.microsoft.com/download/a/7/e/a7ea6fd9-2f56-439e-a8de-024c968f26d1/ScaleNet.pdf

Scaling the Web Server:

Good resource on Scaling a Microsoft® Windows® Server 2003 running IIS 6 (also included is a case study of scaling an asp.net website on IIS 6.0)

 https://technet2.microsoft.com/WindowsServer/en/library/12dc2cfc-9b2f-480d-9838-892a135e7ff11033.mspx?mfr=true

I will keep posting new entries on SaaS in future.

Please let me know your comments/questions.

Rahul's

Comments

• Anonymous
  March 27, 2007
  Hey Rahul... thats a great post. I would wait for your further postings on SaaS. Do you have something specific to business layer configurability (you called it agility)?

• Anonymous
  June 14, 2007
  Hey Rahul It was a nice article. DO u have anything specific on SaaS implementation in DW/BI environment. Regards, Neel

• Anonymous
  May 14, 2008
  This is realy fine artical.... i am working on a similar concept, but here i have to create different database and different url for the accessing the application for different customer. is it possible in windows 2003 IIS 6.0 with ASP.NET 2.0 -Raja

• Anonymous
  May 15, 2008
  Raja, Thanks for your comment. I am not absolutely sure about your requirement from the comment but it seems like virtualization can be a solution to your requirement. Specifically, application virtualization is what I would recommend you to have a look. Microsoft's Softgrid can be a good approach to realize this. Softgrid works well with windows server 2003 and IIS 6.0. Rahul's

• Anonymous
  August 18, 2008
  Good information, here all information related to .net only...Is there any related to java that supports SaaS.If there is any can you provide that links.

• Anonymous
  September 16, 2008
  Hey, Rahul, Really great work, keept it up. I am working on similar kind of project and need help on creating and configuring metadata. Can you help me in this.

• Anonymous
  September 17, 2008
  Hi Anwar, Thank you for your comment. I would definitely assist you on this. Can you share me your email? Send me an email using the email link on my blog. Rahul

• Anonymous
  September 17, 2008
  Hi Raam, I am not sure about Java based technologies that in this scenario. Rahul

• Anonymous
  November 03, 2008
  Rahul, Nice article.. Thanks, Satheesh

• Anonymous
  December 09, 2008
  Really gr8 article Will be requiring more inputs from you in implementation of SaaS

• Anonymous
  December 11, 2008
  Sure Satya! Whenever you need any assistance, feel free to contact me here: http://blogs.msdn.com/rahul/contact.aspx Rahul's

• Anonymous
  January 16, 2009
  Very nicely done....really calmed my fears of having to rewrite our software package as a SAAS model.  Keep up the good work.

• Anonymous
  July 31, 2009
  very good article, but I am not able to access these links for example http://msdn2.microsoft.com/en-us/library/ms998544.aspx, its getting redirected to https://aps.mail.microsoft.com/OWA/auth/logon.aspx, page and expecting username / password. Is these meant for internal microsoft employees, can I get access if I am not a Microsoft employee thanks