Cloud Computing - SaaS

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, 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 of an IT infrastructure in a company.

Out of these, from an organizational perspective, the software is the most important aspect of it, as the software is the main component that 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 another word, an organization would be happy to add new software or functionalities 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 new hardware if there is no anticipated need of new software. But with the current situation, the 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 that 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 this software's 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 chunk of their budget can be saved from hardware and professional services since the hardware and the professional services will be managed by the third-party SaaS vendor. This would enable them to spend the majority of the budget on software services, which would have a 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 lifecycle 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 consumers (end users) as well as 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.

The Application Architecture Sounds pretty good? But, how are the applications going to be made so that the end-users and the 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 architected to sustain and provide the scalability, ease of use of the traditional desktop applications. There are three key points that would differentiate a successful SaaS application from an un-successful SaaS application:

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

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 a SaaS is quite similar to any SOA (Service Oriented Architecture) based application. Probably a few of the additions are two extra layers:

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:

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

Operation Structure What it takes to deliver the application to customers, and to keep it available and running well at a cost-effective level.