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

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

procha — Wed, 12 Mar 2008 17:24:58 GMT

Excelente post, principalmente de se tratar de um assunto tão abstrato, embora se torne mais relevante a cada dia.

wcamb, eu me pergunto quais os limites do SaaS. Me refiro aos limites em sua utilização em si, não aos limites técnicos (que, sabemos, não são muitos). O que define um serviço a ser exposto pela web contra um serviço "local" (se podemos chamar assim)? Até onde devemos reter a funcionalidade em aplicações e deixar de expor tais aspectos em um "provedor de funcionalidades". Não sou arquiteto e talvez seja um ponto bobo, sem muito nexo, mas eu comparo isto a deixar código de acesso a um banco de dados NO banco de dados: é melhor ter um cliente "magro", com pouco código para manter. Mas a balança puxa para o lado do consumo de rede e das imposições de segurança utilizando esta abordagem.

Mas eu não sou arquiteto, não dá muita bola não :-)

De qualquer forma, leio aqui seus textos para me educar no assunto. Excelente fonte para mim!

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

wcamb — Thu, 13 Mar 2008 02:34:39 GMT

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.

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

Flavio de Moraes — Thu, 13 Mar 2008 05:36:10 GMT

Olá a todos,

Não sei se esse post será útil.

Mas entendo o SaaS não apenas como um modelo de software mas um modelo de negócio para os produtores de software. E como esse modelo tem fundamentos no modelo da "Cauda Longa" vejo os custos como um dos principais limitadores de sua aplicação. Quando falo em custos não penso apenas nos custos de TI - desenvolver a aplicação e manter mas também os custos de bilhetagem e cobrança (custo de transação) pois como outro fundamento do modelo é o "micro-pagamento" o custo para cobrar corretamente o cliente deverão ser baixos.

Outro item que acredito ser fundamental é a comparação de custos com soluções existentes, por que alguém contrataria um software que deverá pagar pelo uso (além de conexão internet) se pode adquirir um sofware do tipo produto por um custo (e não preço) menor (hardware, conexão, sofware e treinamento para uso). Se tudo isso tiver sentido então nem todos os softwares deverão convertidos para o modelo SaaS limitando seu uso. Outro limite (mais óbvio) é a demanda, se o seu mercado não tiver muitos consumidores provavelmente você não alcançará muito mais clientes baixando os custos de adoção, nessa situação acredito que deve ser avaliado o modelo já que podem existir outros beneficios na adoção do modelo.

Pensando no conceito de custo de adoção me vem a mente não somente os custos de desenvolvimento, implantação e manutenção (TI), mas também o custo de mudança para o cliente, pensando no usuário final, (aprendizado do novo software ou do novo modelo de sofware), assim vejo como ponto crítico para a solução desenhá-la não apenas pensando em baixar os custos de TI, mas baixar esses custos também.

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

wcamb — Thu, 13 Mar 2008 15:45:14 GMT

Olá Flávio, tudo certo?

Obrigado pelo comentário! Veja algumas idéias ainda, a partir do seu post:

- o modelo SaaS é um modelo de negócio, que envolve aspectos importantes de tecnologia e infra-estrutura no provedor de serviços;

- realmente, os conceitos da Cauda Longa são determinantes no modelo: micro-pagamento, billing, mecanismos de customização automática, cobrança por demanda, são elementos importantes;

- concordo com você quando diz que nem todo software é indicado ao mundo SaaS. Realmente, essa conta precisa ser feita pela empresa. Quando temos um uso intenso do software de forma corpoariva, é provável que os custos sejam muito maiores quando pagos por demanda do que o software adquirido on-premise, instalado localmente. Nesse ponto, o cliente deve realizar um estudo dos gastos envolvidos, assim como estimativas de uso das funcionalidades SaaS;

- ainda, conforme comentei com o procha, para a Cauda Longa fazer sentido, realmente é preciso ter público, ou seja, o mercado precisa perceber a necessidade das funcionalidades oferecidas;

- finalmente, mais um ponto importante no processo de adoção do modelo SaaS. Como diria Garrincha, os fornecedores precisam combinar com o cliente que o modelo de adoção de funcionalidades vai mudar no online. Nesse ponto, algumas iniciativas podem minizar esse impacto nas arquiteturas corporativas, como entender os problemas de consumo e governança de um ambiente orientado a serviços, conhecer frameworks que facilitem essa adoção (como o próprio WCF), pensar em camadas de composição ou consumo de serviços, etc. Ainda, novos modelos como aplicações compostas ou de composição começam a aparecer no enterprise. Já comentei aqui sobre o mashup corporatvio. Essas aplicações possuem maior aderência ao modelo de serviços, independente da localização dos mesmos, seja local ou na rede. Mas outros impactos como segurança, SLA, auditoria e monitoração estarão presentes.

Enfim, seu post foi muito útil pois você acabou citando alguns grandes desafios do mundo SaaS.

Grande Abraço!

Waldemir.

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

David — Thu, 13 Mar 2008 19:32:37 GMT

Ola Srs.,

Gostaria de adicionar mais um elemento a discussão.

O modelo do micro-pagamento não é o único modo de pagamento. Lembrando que o custo de processamento ou armazenamento é ridiculamente barato, podemos dar isso de graça aos usuários e ter lucro de outras formas. Podemos oferecer de graça o serviço ao cliente e cobrar de anunciantes o "micro-pagamento". Porém a diferença entre o micro-pagamento e o free é imensa.

Quem discutiu com mais profundidade esse assunto é o mesmo autor da "Calda Longa", o Chirs Anderson. Ele escreveu um artigo recentemente sobre o “Free”.

Free! Why $0.00 Is the Future of Business

http://www.wired.com/techbiz/it/magazine/16-03/ff_free

Recomendo...

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

wcamb — Fri, 14 Mar 2008 04:45:44 GMT

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.

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

Carlos ulot — Fri, 14 Mar 2008 05:45:19 GMT

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....

Do Windows DNA para o mundo orientado a serviços : a visão Software + Serviço e a Cloud Computing.

Arquitetura de Soluções — Fri, 25 Apr 2008 18:37:43 GMT

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

Um mal necessário ou um elemento estratégico? Como você considera sua TI?

Arquitetura de Soluções — Fri, 25 Apr 2008 21:14:16 GMT

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

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

Marcio — Wed, 08 Oct 2008 21:18:01 GMT

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

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

wcamb — Thu, 09 Oct 2008 00:40:28 GMT

Olá Marcio, tudo certo?

Obrigado pelos comentários no blog.

Um exemplo de material que faz uma boa discussão sobre esses aspectos de segurança é esse:

patterns & practices - Improving Web Services Security

Ref.: http://www.codeplex.com/WCFSecurityGuide

patterns & practices - WCF Security Guidelines

Ref.: http://www.codeplex.com/WCFSecurityGuide/Wiki/View.aspx?title=WCF%20Security%20Guidelines&referringTitle=Home

Tenho usado esse material como base de discussão, durante conversas com empresas e arquitetos.

Mais ainda, quando falamos em S+S e composição de serviços locais e remotos, uma série de desafios aparecem para o arquiteto, seja um arquiteto de soluções ou um arquiteto de infra-estrutura.

Muitos desses aspectos são discutidos no App Arch Guide 2.0, veja:

patterns & practices: App Arch Guide project

Ref.: http://www.codeplex.com/AppArch

Da mesma forma, continua valendo o básico sobre o comportamento da solução. São questões tradicionais, como:

- Disponibilidade

- Integridade

- Flexibilidade

- Interoperabilidade

- Manutenabilidade

- Gerenciabilidade

- Desempenho

- Confiabilidade

- Reusabilidade

- Escalabilidade

- Suportabilidade

- Testabilidade

- Usabilidade (User Experience), entre outras.

Assim como questões conhecidas estão presentes em todas essas arquiteturas, novas questões são específicas de cada cenário, como:

- latência, composição de serviços, governança de serviços, interfaces de composição, contratos de serviços, tipos de mensagens, para arquiteturas SOA;

- combinação de SLA's distintos entre serviços locais e serviços remotos, autenticação online, federação, barramento de serviços, monitoração de disponibilidade de serviços remotos, etc, para arquiteturas S+S;

- provisionamento, repositório de metadados, visão multi-inquilino, configuração dinâmica, particionamento de dados em bancos multi-inquilino, micro-pagamento, otimização de recursos de infra-estrutura, etc, para arquiteturas SAAS.

Com certeza, cada caso é um caso, mas algumas perguntas estarão sempre ao nosso redor.

Um abraço!

Waldemir.

Azure Issue Tracker : integração entre o enterprise e a nuvem

Waldemir Cambiucci Solutions Architect Microsoft Brasil — Sat, 09 May 2009 02:29:14 GMT

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