Click here to Skip to main content
15,881,882 members
Articles / Webservice

Cloud Computing - SaaS

Rate me:
Please Sign up or sign in to vote.
4.70/5 (18 votes)
30 Dec 2009CPOL15 min read 88.5K   47   7
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".

Image 1

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:

Image 2

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.

Image 3

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:

Image 4

Image 5

Image 6

Shared Database, Shared Schema (for Ad-Hoc/Custom and Configuration maturity model)Shared Database, Separate Schema (for Configuration, multi-tenant efficient maturity model) andSeparate 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)


Written By
India India
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
QuestionTranslation Pin
Gerson Freire15-Apr-15 16:19
Gerson Freire15-Apr-15 16:19 
Wonderful article! I would like to offer freely a Brazilian portuguese translation. I need the authorization? Whoi would like this? Please send me a message here or an email.
Well, I have a MS-Word document copy, although, I decided to publish here. Following is the translation:

Cloud Computing - SaaS
Bhaskardeep Khaund, 30 de dezembro de 2009 CPOL
Introdução à computação em nuvem - SaaS.
Introdução
A computação em nuvem é o assunto atual da moda. Este artigo começa por perguntar o que exatamente é a computação em nuvem. Vamos dar uma olhada de alto nível na forma como a computação em nuvem funciona e como é que isso vai causar um impacto para o nosso ambiente de trabalho atual. Na parte final do artigo, vamos dar uma olhada mais profunda em uma das categorias de computação em nuvem, SaaS (software como serviço). Mas, para começar, vamos entender os conceitos básicos de computação em nuvem.
O que é Cloud Computing?
A computação em nuvem, como o nome sugere, é um estilo de computação onde os recursos dinamicamente escaláveis e muitas vezes visualizados são fornecidos como um serviço através da internet. Esses serviços podem ser consumidos por qualquer utilizador através de uma conexão HTTP padrão. O usuário não precisa ter conhecimento, perícia, ou controle sobre a infraestrutura de tecnologia na "nuvem" que os suporta. O nome computação em nuvem foi inspirado no símbolo da nuvem que é muitas vezes usado para representar a Internet em diagramas de rede e fluxogramas. As nuvens denotam a abstração da infraestrutura complexa que se esconde na Internet.
O diagrama abaixo mostra o layout básico de alto nível da computação em nuvem, em que o prestador de serviços cria a sua solução (software, infraestrutura, ou plataforma) na internet, onde um ou mais usuários podem consumir esse serviço "on demand".

A computação em nuvem pode ser categorizada em três grupos:
1. Platform As A Service - Plataforma como Serviço (PaaS)
2. Infrastructure As A Service - Infraestrutura como Serviço (IaaS)
3. Software as a Service – Software como Serviço (SaaS)
Neste trabalho, vamos dar uma olhada em profundidade no Software como uma categoria de Serviço (SaaS) da computação em nuvem.
A nuvem pode ser pública ou privada. Uma nuvem pública vende serviços para qualquer pessoa na Internet. Uma nuvem privada é uma rede de propriedade particular de uma empresa ou um centro de dados que fornece serviços de hospedagem a um número limitado de pessoas. Quando um provedor de serviços usa recursos de nuvem pública para criar a sua nuvem privada, o resultado é chamado de nuvem privada virtual. Privado ou público, o objetivo da computação em nuvem é fornecer acesso fácil, escalável para recursos de computação e serviços de TI.
Todas as grandes empresas cresceram através da criação dos seus próprios frameworks (conjunto de bibliotecas de software) para computação em nuvem, baseados em código fonte ou não. Alguns dos frameworks baseados em código fonte mais importantes são:
1. Java Google Web Toolkit (Google App Engine).
2. Python Django (Google App Engine)
3. Ruby on Rails
4. Microsoft .NET (Plataforma de Serviços Azure)
Existem inúmeros ISVs (Independent Software Vendors), como por exemplo, Mosso, que fornecem uma plataforma para hospedar soluções baseadas em nuvem.
Onde o SaaS se encaixa
SaaS é uma das metodologias de Cloud Computing que se baseia em um modelo "one-to-many" (um-para-muitos), pela qual um aplicativo é compartilhado entre vários clientes. A definição exata de software como serviço (SaaS) ainda está aberta ao debate, e perguntando-se a pessoas diferentes, provavelmente resultará em diferentes definições. Todo mundo acredita que SaaS vai ter um grande impacto na indústria de software, porque o software como um serviço vai mudar a maneira de construir, vender, comprar e usar software. Para que isso aconteça, no entanto, os fornecedores de software precisam de recursos e informações sobre como desenvolver aplicativos SaaS eficazmente. Ainda assim, a maioria dos especialistas provavelmente concordaria em alguns princípios fundamentais que distinguem SaaS de software empacotado tradicional, por um lado, e sites simples, por outro. Falando mais simplesmente, software como um serviço pode ser caracterizado como "Software implantado como um serviço hospedado e acessado através da Internet".
Software como um serviço (SaaS) também é uma maneira de entregar aplicativos através da Internet como um serviço. Em vez de instalar e contratar manutenção no software, basta acessá-lo através da Internet, libertando-se de software complexo e do gerenciamento de hardware. Aplicações SaaS são às vezes chamadas de software baseado na Web, software on-demand, ou software hospedado. Seja qual for o nome, aplicativos SaaS são executados em servidores de um provedor de SaaS. O provedor gerencia o acesso ao aplicativo, incluindo a segurança, disponibilidade e desempenho. Clientes de SaaS não precisam de nenhum hardware ou software para comprar, instalar, manter ou atualizar. O acesso a aplicativos é fácil: você só precisa de uma conexão com a Internet. Este tipo de computação em nuvem oferece um único aplicativo através do navegador para milhares de clientes, e usa uma arquitetura multi-tenant (multi-inquilino ou multi-empresa). No lado do cliente, isso significa nenhum investimento inicial em servidores ou licenças de software; no lado do fornecedor, com apenas um aplicativo para manter, os custos são baixos em comparação com hospedagem convencional.
Salesforce.com é de longe o exemplo mais conhecido entre os aplicativos corporativos que fornecem soluções de CRM como SaaS, mas SaaS também é comum para aplicativos de RH, e já abriu seu caminho até a cadeia alimentar dos ERPs, através de fabricantes de software como a Workday. Além destes, alguns dos aplicativos de produtividade pessoal como o Google Apps e Zoho Office deixaram a sua marca no mercado.
Olhando no fundo do poço: SaaS
Vamos dar uma olhada mais profunda dos princípios básicos do SaaS, ou seja, o software implementado como um serviço hospedado e acessado através da Internet. Nós podemos chegar a duas categorias principais de SaaS:
1. Serviços de linha de negócios, ou seja, corporativos, oferecidos a empresas e organizações de todos os tamanhos. Serviços de linha de negócios são muitas vezes soluções de negócios grandes, customizáveis, destinadas a facilitar os processos de negócios, tais como finanças, gestão da cadeia de suprimentos, e relações com clientes. Estes serviços são normalmente vendidos aos clientes com base em assinaturas.
2. Serviços orientados para o consumidor, oferecidos ao público em geral. Serviços orientados para o consumidor, às vezes, são vendidos com base em uma assinatura, mas são muitas vezes fornecidos aos consumidores, sem nenhum custo, e são sustentados por publicidade.
Passar de oferecer software on-premise (instalado na empresa), para oferecer software como um serviço requer que os fornecedores de software mudem o seu pensamento em três áreas inter-relacionadas: modelo de negócio, arquitetura de aplicações, e estrutura operacional.
O Modelo de Negócio
A maioria dos softwares continua a ser vendido da mesma forma como foi vendido por décadas. O cliente compra uma licença para usar o software e instalá-lo em hardware que possua, ou esteja sob o seu controle, com o fornecedor prestando apoio, como ditado pelos termos da licença, ou de um contrato de suporte. Em um sentido franco e honesto, a noção de uma "licença" pode parecer algo muito técnico: legalmente, o cliente está comprando apenas o direito de usar uma cópia do software, mas para efeitos práticos, é como se o cliente fosse o "dono" do software e pudesse usá-lo muitas vezes e durante o tempo que desejar. Já o modelo SaaS traz um novo conceito que é bem definido, ou seja, em vez de "possuir" software a título definitivo, os clientes são informados de que eles podem pagar por uma assinatura de software rodando em servidores de outra pessoa, ou seja, o software “vai embora”, se parar de subscrever.
Vamos olhar para ele a partir de um ângulo diferente. Basicamente falando, existem três tipos de componentes na infraestrutura de TI em uma empresa:
1. Software;
2. Hardware;
3. O serviço profissional.
Destes, a partir de uma perspectiva de organização, o software é o aspecto mais importante, uma vez que o software é o principal componente, que ajuda a completar o objetivo da organização. Considerando que hardware e serviço profissional permitem que o software funcione e produza o resultado necessário para a organização. Em outras palavras, uma organização estaria feliz em adicionar um novo software ou a funcionalidade de um software já existente, sem qualquer adição ao hardware, se o hardware existente permitisse que o novo software / funcionalidade funcionasse de forma eficaz, mas nenhuma organização gostaria de acrescentar um novo hardware, se não houver necessidade prevista de um novo software.
Mas com a situação atual, maior parte do orçamento é gasto com o hardware e o profissional para executar o software. Isso deixa uma minoria do orçamento para o software, que irá se envolver mais diretamente na gestão da informação, que é o objetivo final de qualquer organização de TI.
Em oposição a isso, se a organização pode consumir este software a partir de um local remoto, que está a sendo gerido por um terceiro, fornecedor de SaaS, ela só tem de pagar a assinatura desse software; assim, um enorme pedaço do seu orçamento pode ser salvo de hardware e serviços profissionais, uma vez que o hardware e os serviços profissionais serão geridos pelo terceiro, fornecedor de SaaS. Isso lhes permitiria passar a maior parte do orçamento para serviços de software, o que teria impacto direto sobre o cumprimento do objetivo de sua organização. Além disso, aplicativos entregues através da Web ou através de clientes inteligentes colocam significativamente menor demanda em um computador desktop de aplicativos tradicionais, instalados localmente, o que permite ao cliente para estender o ciclo de vida da tecnologia de desktop de forma significativa.
De uma perspectiva do fornecedor de SaaS, nas aplicações SaaS que são construídas bem-dimensionadas, o custo operacional para cada cliente continuará a cair à medida que mais clientes são adicionados. Como isso está acontecendo, o provedor irá desenvolver multi-tenancy como uma competência essencial, levando a oferta de alta qualidade a um custo menor. Portanto, mesmo incorrendo em custos de hardware e de serviços profissionais embutidos pelos fornecedores de SaaS, os clientes podem ainda obter significativamente maior funcionalidade do software, para o mesmo orçamento de TI.
Uma pequena pergunta, isso não é um conto de fadas, como a subscrição do serviço de software incluiria também a gestão do servidor e o serviço profissional?
A resposta é não, e a mágica por trás é "Economia de Escala". Um fornecedor de SaaS com “x” número de clientes que subscrevem a um único, de serviço de software hospedado centralmente, permite que ao fornecedor atender a todos os seus clientes em um ambiente consolidado. Por exemplo, um aplicativo SaaS “line-of-business” (corporativo), instalado em um grupo de cinco servidores com balanceamento de carga, pode ser capaz de suportar 50 clientes de médio porte, o que significa que cada cliente só seria responsável por um décimo do custo de um servidor. Uma estrutura semelhante instalada localmente pode exigir de cada cliente dedicar um servidor inteiro para o aplicativo - talvez mais do que um, se o balanceamento de carga e alta disponibilidade forem preocupações.
É evidente que há um monte de benefícios para o consumidor (usuários finais), bem como para os prestadores de serviços. Podemos consolidar alguns dos pontos centrais como tais como os mencionados abaixo:


Perceber os benefícios do SaaS requer mudanças no pensamento por parte tanto do prestador como do cliente, e cabe ao provedor ajudar o cliente a fazer essa mudança.
Arquitetura de Aplicações
Soa muito bem? Mas, como é que as aplicações vão ser feitas para que os usuários finais e os prestadores possam tirar o máximo benefício disso?
Muito parecido com qualquer outro software, SaaS também pode tirar proveito de Arquitetura Orientada a Serviços para permitir que aplicativos de software se comuniquem uns com os outros. Cada serviço de software pode agir como um prestador de serviços, expondo a sua funcionalidade para outras aplicações via “corretores” (brokers) públicos, e também pode atuar como um solicitante do serviço, incorporando dados e funcionalidades de outros serviços.
É importante entender que a metodologia SaaS requer que a arquitetura do sistema seja capaz de suportar as demandas de pico de uso, e a capacidade de processar um grande número de transações em um ambiente seguro e confiável. O software terá de cumprir certos critérios para trabalhar em um modelo como este. O aplicativo precisa ser bem projetado, para manter e prover escalabilidade e facilidade de uso semelhante a aplicativos desktop tradicionais.
Existem três pontos fundamentais que diferenciam um aplicativo Web SaaS (software vendido como serviço) bem sucedido, de um malsucedido:
Escalabilidade: Escala da aplicação significa maximizar a simultaneidade e usar recursos de aplicativos de forma mais eficiente; por exemplo, otimizando a duração de bloqueios a dados, independência de estado de sessão web, compartilhamento de recursos críticos, tais como threads e conexões de rede, dados de armazenamento em cache e particionamento de grandes bases de dados.
Eficiência em Multi-tenant (multi-inquilino ou multi-organizações): Multi-tenancy pode ser a mudança de paradigma mais significativa que um arquiteto acostumado a projetar aplicações isoladas, single-tenant tenha que fazer. Por exemplo, quando um usuário em uma empresa acessa as informações do cliente, usando um serviço de aplicação de CRM, a instância do aplicativo que o usuário se conecta pode acomodar dezenas, ou mesmo centenas, de usuários de outras empresas - tudo completamente abstraído a qualquer um dos usuários. Isso exige uma arquitetura que maximize a partilha de recursos entre os inquilinos, mas que ainda é capaz de diferenciar os dados pertencentes a diferentes clientes.

Configurável: se uma única instância da aplicação roda em um único servidor para acomodar os usuários de várias empresas diferentes ao mesmo tempo, você não pode simplesmente escrever código fonte para personalizar a experiência do usuário final - qualquer coisa que você faz para personalizar o aplicativo para um cliente vai muda-lo para outros clientes também. Em vez de personalizar o aplicativo no sentido tradicional, cada cliente usa metadados (dados que definem dados, páginas e relatórios em tempo de execução), para configurar a forma como a aplicação parece e se comporta para seus usuários. O desafio para o arquiteto SaaS é garantir que a tarefa de configuração de aplicativos seja simples e fácil para os clientes, sem incorrer em custos de desenvolvimento ou operação extra para cada configuração
Podem haver quatro maneiras de hospedagem uma aplicação na arquitetura SaaS. Estes são também chamados como os modelos de maturidade SaaS:
• Ad hoc / Custom: É semelhante ao modelo de provedor de serviços de aplicação tradicional (ASP) de entrega de software, que remonta à década de 1990. Cada cliente tem sua própria versão personalizada do aplicativo hospedado, e gerencia sua própria instância do aplicativo em servidores do provedor de hospedagem.
• Configurável: o fornecedor hospeda uma instância separada do aplicativo Web de cada cliente (ou inquilino). Ao contrário do anterior, cada instância é personalizada individualmente para o inquilino; a este nível, todas as instâncias usam o mesmo código fonte de implementação, e o fornecedor atende às necessidades dos clientes, fornecendo opções de configuração detalhadas, que permitem que o cliente mude a forma como a aplicação parece e se comporta, para os seus usuários. Apesar de serem idênticas umas às outras no nível do código, cada instância continua totalmente isolada de todos os outras.

• Configurável, multi-tenant-eficiente: o fornecedor executa uma única instância, que serve a cada cliente, com metadados configuráveis, proporcionando ao usuário uma experiência única e conjunto de recursos individualizados para cada um. Políticas de autorização e segurança garantem que os dados de cada cliente são mantidos separados do de outros clientes; e, do ponto de vista do usuário final, não há nenhuma indicação de que a instância do aplicativo está sendo compartilhada entre vários inquilinos. Esta abordagem elimina a necessidade de proporcionar tanto espaço de servidor quanto maior for o número de clientes, permitindo um uso mais eficiente dos recursos de computação do que o segundo modelo, o que se traduz diretamente em custos mais baixos. Uma desvantagem significativa desta abordagem é que a escalabilidade da aplicação é limitada.

• Escalável, configurável, multi-tenant-eficiente: o fornecedor hospeda vários clientes em uma “fazenda” ou farm, em inglês, (grupo redundante de servidores), com balanceamento de carga, de instâncias idênticas da aplicação web, com os dados de cada cliente mantidos separados, e com metadados configuráveis, proporcionando ao usuário uma experiência única e conjunto de recursos personalizados para cada cliente.

Arquitetura De Alto Nível
O segredo por trás das vantagens econômicas para SaaS é uma arquitetura que utiliza "personalização através de configuração" e particionamento de dados inteligente. Sem esses dois elementos, você provavelmente não será capaz de mover-se após o primeiro nível de maturidade (Ad hoc / Custom) e reconhecer os ganhos de eficiência de multi-tenancy.
A arquitetura básica de SaaS é bastante semelhante a qualquer aplicação baseada em SOA (Service Oriented Architecture). Provavelmente, algumas dos acréscimos necessários serão apenas duas camadas extras:
1. Serviços de metadados: O serviço de metadados oferece aos clientes o principal meio de personalizar e configurar o aplicativo para atender suas necessidades. Normalmente, isso pode ser categorizado em grandes áreas: interface com o usuário e identidade visual (branding), fluxo de trabalho e regras de negócios, além de extensões para controle de acesso ao modelo de dados.
2. Serviços de Segurança: O provedor de SaaS normalmente delega a cada inquilino a responsabilidade de criar e manter as suas próprias contas de usuário, um processo conhecido como a administração delegada. A administração delegada cria uma situação em que o cliente é responsável por criar contas de usuários individuais, mas o provedor tem de autenticá-los. Normalmente, o acesso a recursos e funções de negócio em um aplicativo SaaS é gerenciado por meio das funções que mapeiam funções (papéis) de trabalho específicas dentro de uma organização. A cada função é dada uma ou mais permissões, que permitem aos usuários atribuídos à função executarem ações de acordo com as regras de negócio relevantes.
Software empresarial de grande escala destina-se a ser utilizado por milhares de pessoas simultaneamente. Se você tem experiência em construção de aplicações corporativas deste tipo, você chegou a conhecer em primeira mão os desafios de criar uma arquitetura escalável. Para uma aplicação SaaS, a escalabilidade é ainda mais importante: você vai ter que suportar a base média de usuários de um único cliente, multiplicado pelo número total de clientes que você tem. Os aplicativos podem ser ampliados (movendo o aplicativo para um servidor maior, mais potente) ou escalado para fora (executando o aplicativo em mais servidores). Algumas das melhores práticas comuns para a concepção de aplicações SaaS, às quais os peritos costumam aderir são:
• Projete o aplicativo para ser executado de uma forma “sem estado” (stateless), com todos os dados de usuário e de sessão necessários armazenados, ou no lado do cliente, ou em um armazenamento distribuído, que é acessível a qualquer instância do aplicativo. Stateless significa que cada transação pode ser tratada por uma determinada instância tanto como por qualquer outra; um usuário pode transacionar com dezenas de instâncias diferentes durante uma única sessão, sem nunca saber.
• Projete o aplicativo para realizar operações I / O de forma assíncrona, para que o aplicativo possa realizar um trabalho útil enquanto espera pela finalização da entrada e saída.
• Reúna e compartilhe recursos, tais como threads, conexões de rede e conexões de banco de dados; isso ajuda a maximizar seus recursos de computação, e melhora a sua capacidade de prever o uso de recursos.
• Escreva suas operações de banco de dados de modo a maximizar a concorrência e minimizar o bloqueio exclusivo. Por exemplo, não bloqueie registros ao executar operações somente leitura.

Com base no modelo de maturidade escolhido para a aplicação SaaS, o esquema de banco de dados seria diferente. Mantendo tenancy em mente, o esquema de banco de dados pode ser:


Banco de dados compartilhado (Shared Schema) (para Ad Hoc/customizável e modelo de maturidade de Configuração)

Banco de Dados Particionado, esquema separado (para modelo de maturidade de Configuração e multi-tenant eficiente)

Bancos de dados separados para cada inquilino/cliente (para modelo de maturidade escalável e configurável, multi-tenant).
Conclusão
Cloud Computing e SaaS definitivamente vão ter um impacto enorme para a nossa atual forma de trabalhar. Consumir e expor todos os serviços de software através da rede HTTP permitiria à infraestrutura da organização de TI a depender inteiramente do meio Internet. Houve críticas e contra críticas para tal dependência. Se SaaS tornar-se totalmente funcional, ela provavelmente poderia resolver uma das principais preocupações da indústria de software, que está fazendo as empresas de desenvolvimento de aplicativos perder bilhões de dólares a cada ano, e que é a pirataria ilegal de software. Só o tempo vai dizer.
Licença
Este artigo, juntamente com qualquer código-fonte associado e arquivos, está licenciado sob a licença de código Projeto Open (CPOL)
Ação
Sobre o autor

Bhaskardeep Khaund

Índia

Nenhuma biografia fornecida

Artigo Copyright 2009 by Bhaskardeep Khaund
Tudo o resto Copyright © CodeProject, 1999-2015
AnswerRe: Translation Pin
Bhaskardeep Khaund13-May-15 12:57
Bhaskardeep Khaund13-May-15 12:57 
GeneralMy vote of 5 Pin
Mahsa Hassankashi23-Oct-14 8:43
Mahsa Hassankashi23-Oct-14 8:43 
GeneralMy vote of 5 Pin
Sandeepkumar Ramani29-Mar-12 1:49
Sandeepkumar Ramani29-Mar-12 1:49 
GeneralMy vote of 5 Pin
Prasad_Kulkarni28-Dec-11 20:31
Prasad_Kulkarni28-Dec-11 20:31 
QuestionSecurity Pin
sweep11123-Aug-11 23:24
sweep11123-Aug-11 23:24 
QuestionMy +5 Pin
LaxmikantYadav23-Jun-11 23:56
LaxmikantYadav23-Jun-11 23:56 

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

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