SaaS - Software as a Service - Uma visão sobre o software como serviço.

Olá pessoal, tudo certo?

SOA, SaaS, S+S, ESB, WEB 2.0 e VIRTUALIZAÇÃO são de fato temas constantes em muitas mesas de discussão de arquitetos. Estão entre as mais quentes definições de arquitetura de hoje em dia. Assim, vamos atacar um desses temas hoje, o SaaS - Software as a Service (Software como Serviço).

Alguns especialistas afirmam que o mercado ao redor de SaaS envolve cifras em torno de US$ 5 bilhões. Ainda, de acordo com o Gartner Group, SaaS representou cerca de 5% do mercado total de software em 2005 e até 2011, deverá representar 25% das vendas totais para o segmento corporativo. O uso de SaaS para a automação dos processos de negócio fim-a-fim, como ordens de pagamento para grandes empresas por exemplo, deve crescer ainda mais nos próximos anos.

Do wikipedia, tiramos a seguinte definição:

"Software as a service (SaaS) is a software application delivery model where a software vendor develops a web-native software application and hosts and operates (either independently or through a third-party) the application for use by its customers over the Internet. Customers do not pay for owning the software itself but rather for using it. They use it through an API accessible over the Web and often written using Web Services or REST. The term SaaS has become the industry preferred term, generally replacing the earlier terms Application Service Provider (ASP) and On-Deman." [6]

Em poucas palavras teríamos que SaaS é um software distribuído como um serviço, implementado em plataforma web de forma nativa e acessado usando tecnologias e protocolos de internet. Do ponto de vista do usuário, é um software que não é instalado localmente na infra-estrutura do cliente (on-premise), mas é utilizado através da web e pago pelo tempo de uso, por demanda. Desse modo, um software SaaS envolve mecanismos de tarifação e métricas de uso e billing. Ainda, é um software que fornece uma API para acesso pela web, através de Web services, serviços REST e outros. Do ponto de vista da arquitetura, podemos dizer que SaaS envolve uma infra-estrutura escalável, altamente configurável e multi-inquilino.

Conceitos e Princípios

Quando pensamos em SaaS, o conceito de multi-inquilino deve ser colocado. Ele é referente ao uso do mesmo software e instância por vários clientes e empresas de forma simultânea. Em apresentações sobre SaaS, o termo tenant é utilizado para designar o inquilino, ou cliente que acessa o software pela web. O objetivo dessa abordagem é disponibilizar os mesmos recursos de software para um número muito maior de clientes. E essa visão tem suas bases no conceito da "Cauda Longa" .

Se você ainda não leu um livro chamado "The Long Tail", é o primeiro passo que indico para um entendimento completo do tema SaaS.

The Long Tail: Why the Future of Business is Selling Less of More
por Chris Anderson
Ref.: https://www.amazon.com/LONG-TAIL-FUTURE-BUSINESS-SELLING/dp/1401302378

Veja o desenho abaixo sobre a visão da Cauda Longa:

O gráfico demonstra que, conforme baixamos o custo de adoção, um número maior de clientes pode adotar nossa solução. E esse número tende ao infinito, uma vez que a curva não toca o eixo "x". Assim, no modelo SaaS de fornecimento de software, precisamos pensar em soluções e infra-estruturas de baixo custo, com alto aproveitamento de recursos por um número muito grande de clientes, para atingirmos um público não suportado hoje em dia, devido os custos proibitivos de entrada.

Outro conceito importante do modelo é o "micro-pagamento". Na cauda longa, um número muito grande de usuários poderá adotar nossa solução pagando pelo uso, por demanda, o que deve gerar um valor muito baixo de ticket. Porém, estamos realmente buscando o chamado "milhões de mercados de poucos" ao invés dos atuais "poucos mercados de milhões".

Fica claro o impacto na construção de uma arquitetura SaaS. Existem diversas necessidades de tecnologia e infra-estrutura que precisam ser atendidas para que esse novo modelo seja suportado. Um modelo de maturidade SaaS é apresentado a seguir, conforme discussão que encontramos no artigo "Architecture Strategies for Catching the Long Tail" de Frederick Chong and Gianpaolo Carraro [1]:

[1]

Note que no primeiro quadrante, a solução possui uma instância dedicada para cada inquilino (tenant). Isso garante um completo atendimento das demandas do cliente, mas com elevado custo devido ausência de compartilhamento de recursos e customização elevada. Também no quadante 1, cada cliente é atendido por uma instância dedicada da solução. No quadrante 2, a solução ainda apresenta uma instância dedicada para cada inquilino, porém, já é possível observar que a solução é a mesma, com nenhuma customização presente. Isso garante um custo menor de manutenção, já que a mesma solução atende a diversos clientes. No quadrante 3, a solução é multi-inquilino (multi-tenant) e apresenta total compatilhamento de recursos, havendo uma única instância para todos os clientes. Note que questões importantes para o tratamento de metadados, assim como manutenção e modelagem do banco de dados estão presentes aqui. Finalmente, o quadrante 4 permite um atendimento diferenciado para inquilinos que exigem elevada demanda de recursos, havendo uma carga balanceada na infra-estrutura do provedor da solução SaaS (o chamado tenant load balancer).

Falamos rapidamente de um modelo de maturidade SaaS, onde notamos alguns pontos importantes como um serviço de metadados, assim como questões para se garantir um base de dados com facilidades para o tratamento multi-inquilino.

A partir dos elementos descritos acima, uma arquitetura de alto nível para um modelo SaaS é proposta abaixo:

[1]

Note que essa visão exige uma arquitetura diferenciada, assim como uma discussão seguinte sobre os modelos de multi-inquilino para o banco de dados. Algumas opções possíveis são:

• bases de dados separadas por inquilino;
• mesma base de dados, com inquilinos separados por schemas;
• mesma base de dados, com inquilinos com schemas compartilhados, etc.;

Finalmente, vamos falar um pouco sobre os principais atores do mundo SaaS e seus interesses:

Veja que cada ator possui perspectivas diferentes sobre os benefícios da visão SaaS:

• Para os consumidores de solução SaaS: maior controle, permitindo o teste da solução antes da compra, pagamento pelo uso, tarifação por demanda, menor risco de implantação;
• Para agregadores de soluções e ISV's: possibilidade de criação de novos mercados, oferecendo aplicações compostas e plataformas de integração;
• Para ISV's: possibilidade de novos modelos de negócio, fundamentados na Cauda Longa, o que deve exigir uma reengenhaira das soluções atuais;
• Para Hosters e provedores SaaS: oferecer serviços compartilhados, como billing, SLA, monitoração, provisionamento, etc, para ISV's SaaS clientes;
• Para Hosters clássicos: possibilidade de evolução para serviços com maior valor agregador, rumo ao modelo de hoster SaaS.

Nesse ponto, surge a necessidade de vermos algum código. Como exemplo de solução que implementa essa visão SaaS temos o LitwareHR, uma solução multi-inquilino que está disponível no Codeplex para o público:

Litware HR - A Multitenant sample application
Ref.: https://www.codeplex.com/LitwareHR

Finalmente, o arquiteto Otávio Coelho publicou recentemente um post sobre o tema, onde ele toca num dos pontos nevrálgicos da discussão aqui no Brasil, o dilema do ovo e da galinha, veja aqui :)

Hospedagem de aplicações SaaS
Ref.: https://blogs.msdn.com/otavio/archive/2008/03/04/hospedagem-de-aplica-es-saas.aspx

De fato, não temos mais hosters (ou Application Service Providers) capacitados a operar soluções SaaS porque não temos soluções implementadas nesse modelo pelos ISV's ou é o contrário - não temos implementações SaaS de fornecedores porque não temos hosters capacitados a suportar uma infra-estrutura diferenciada como o modelo exige em sua definição?

A discussão é boa...deixe também sua opinião aqui no blog...

Como leitura adicional indico:

[1] Architecture Strategies for Catching the Long Tail
por Frederick Chong and Gianpaolo Carraro
Ref.: https://msdn2.microsoft.com/en-us/library/aa479069.aspx

[2] Multi-Tenant Data Architecture
por Frederick Chong, Gianpaolo Carraro, and Roger Wolter
Ref.: https://msdn2.microsoft.com/en-us/library/aa479086.aspx

[3] O Barramento de Serviços para a Internet
por Donald F. Ferguson, Dennis Pilarinos, e John Shewchuk
Ref.: https://www.microsoft.com/brasil/msdn/arquitetura/journal/Bar_int_Services.mspx

[4] Software + Services (S+S)
Ref.:  https://msdn2.microsoft.com/en-us/architecture/aa699384.aspx 

[5] The Architects in Action Series presents...A SaaS Solution
Ref.: https://msdn2.microsoft.com/en-us/skyscrapr/aa699403.aspx

e ainda...

[6] Software as a service no Wikipedia
Ref.: https://en.wikipedia.org/wiki/Software_as_a_Service

Por enquanto é só! Até o próximo post :)

Waldemir.

Comments

• Anonymous
  March 12, 2008
  The comment has been removed
• Anonymous
  March 12, 2008
  Olá procha, tudo certo? Obrigado pelo comentário... De fato, são questões relevantes e nada triviais. São questionamentos sempre presentes quando falamos de uma visão SaaS. Vou arriscar aqui alguns comentários.

1. O que define um serviço a ser exposto pela web contra um serviço "local"? Pense na visão do micro-pagamento, da cauda longa, do processo de billing automatizado, com customizações automáticas por metadados, etc. Serviços que possam oferecer essas características para um número muito grande de usuários são candidatos para uma visão SaaS. Na verdade, qualquer serviço poderia ser oferecido como um SaaS. A questão está no retorno previsto com sua publicação, uma vez que a força motora é uma visão de negócio. Os provedores e hosters buscam ganhar dinheiro com a economia de escala, menores custos de operação, customizações inexistentes e o micro-pagamento obtido com a contração de um serviços por demanda. Ainda, isso só fará sentido se os serviços tiverem público, isto, clientes interessados nesses serviços, permitindo assim a monetização na cauda longa. Um exemplo clássico de necessidade atendida é o CRM SaaS. Muitas empresas gostaria de consumir e utilizar um serviço ou sistema de CRM mas o custo é proibitivo no modelo on-premise. Uma oferta por demanda, onde o cliente paga pelo uso, tem se mostrado promissor como negócio. Veja que já para uma visão de orientação a serviços no mundo corporativo, no enterprise, as forças motivadoras são outras, como reuso de serviços e funcionalidades, garantia de qualidade, melhor administração, maior flexibilidade e composição de serviços, disponibilidade de funcionalidades por todos os departamentos da empresa, etc. Essas diferenças devem ser pesadas e mapeadas na hora de se definir um serviço como "on-premise" ou "in-the-cloud".
2. Até onde devemos reter a funcionalidade em aplicações e deixar de expor tais aspectos em um "provedor de funcionalidades". Penso que o processo é gradual. Talvez a questão não seja exatamente essa, mas seu efeito será o mesmo. Algumas funcionalidades serão reconhecidas aos poucos como indicadas para uma publicação para o mundo externo. Num segundo momento, outros sistemas ou soluções poderão reconhecer e aproveitar esses serviços publicados. Os modelos de maturidade de serviços falam que, nos níveis avançados, a empresa deve possuir repositórios e mecanismos de publicação de serviços com discovery integrado, o que facilita a descoberta dos serviços disponíveis para consumo. Aplicações compostas podem usufruir desses recursos, consolidando realmente um mashup corporativo de fato. Para o modelo SaaS, novamente temos os aspectos de negócio na seleção de serviços e funcionalidades expostas. Para o modelo SOA, temos os aspectos de flexibilidade de composição, processos de negócio (BPM), assim como reuso, etc.
3. ...No banco de dados: é melhor ter um cliente "magro", com pouco código para manter. Finalmente, essa questão também é um dilema, nada trivial: o quanto de lógica de negócio devo ter implementada no banco de dados? Ou, o quanto de lógica de negócio devo ter implementada na camada de aplicação, em código e componentes fora da base de dados. Alguns aspectos que orientam essa discussão:

• cultura da empresa, que tende mais para o ambiente de banco de dados (com equipes de DBA's fortes e capacitados) ou para componentes e aplicações (com equipes de desenvolvimento mais fortes e capacitados);
• visão para uso de recursos do gerenciador de banco de dados, quando a empresa adota como visão de arquitetura um uso intensivo dos recursos de triggers, consistências, broker de mensagens, etc, integrados ao banco de dados. Nesse caso, a natureza do negócio é um fator importante.
• sistema com grande processamento de tabelas, massas de dados e operações ETL são candidatas para uma visão database intensive, pois garantimos assim um melhor desempenho. Enfim, essa 2 últimas questões podem variar de acordo com o perfil da empresa e da natureza do negócio. Creio mesmo que cada cenário precisa ser avaliado com cuidado. Por enquanto é só! Seus novos comentários serão benvindos... :) Waldemir.

• Anonymous
  March 12, 2008
  The comment has been removed

• Anonymous
  March 13, 2008
  The comment has been removed

• Anonymous
  March 13, 2008
  The comment has been removed

• Anonymous
  March 13, 2008
  Olá David, tudo certo? Sim, realmente o ganho com campanhas e patrocínios em soluções SaaS faltava ser comentado aqui. Veja que nessa visão, a Microsoft criou o AdCenter, que implementa um advertising engine. Ela oferece uma infra-estrutura preparada para a publicação de campanhas e propaganda em soluções e sistemas SaaS de provedores de serviçoes (hosters). Veja Adcenter Microsoft aqui... Ref.: http://www.microsoft.com/serviceproviders/saas/services.mspx ...e aqui... Ref.: https://adcenter.microsoft.com/ []s Waldemir.

• Anonymous
  March 13, 2008
  Um artigo que pode complementar a discussão acima relativa ao processo de hosting (SaaS/Classic), ISV e o modelo de inter/intra relaçao entre ambos, bem como o processo de medição e tarifação, modelo de negócio, etc, pode ser encontrado num outro artigo do Gianpaolo muito interessante "ISVs are from Mars and Hosters are from Venus" http://msdn2.microsoft.com/en-us/library/bb891759.aspx Vale a pena le-lo. my 2 cents....

• Anonymous
  April 25, 2008
  Olá pessoal, tudo certo? Continuando nosso assunto de evolução de uma plataforma WinDNA para uma arquitetura

• Anonymous
  April 25, 2008
  Olá pessoal, tudo certo? Bom, se você tem acompanhado os posts e webcasts frequentes do Otávio , do Gebara

• Anonymous
  October 08, 2008
  Olá pessoal, Li uns artigos e fiquei confuso, pelo que alguém consegue ajudar-me a interpretar esta situação: Quais os  desafios que um arquitecto de Sistemas de Informação tem de enfrentar em SaaS / S+S numa prepspectiva de Segurança de IT/SI. OBG

• Anonymous
  October 08, 2008
  The comment has been removed

• Anonymous
  May 08, 2009
  Olá pessoal, tudo certo? Já falamos aqui sobre o Azure Issue Tracker , uma solução SaaS (Software as