Estratégias de Arquitetura para Cauda Longa (Long Tail)

Por Frederick Chong e Gianpaolo Carraro - Microsoft Corporation

Introdução

Software como serviço, SaaS (Software as a service). As palavras estão na boca de todos. As páginas de publicações da indústria de software estão cheias de artigos sobre software como serviço, artigos que usam palavras como "revolução" e "horizonte". Todo mundo sabe (ou pensa que sabe) o que isso é, em termos gerais, e todos sabem que vai se tornar grande. Mesmo assim, poucos podem dizer que realmente sabem definir e menos ainda sabem como construir.

Então, se o SaaS contém tanta promessa para o futuro da entrega de aplicativos, porque não existem mais orientações disponíveis para ajudar as pessoas a realmente desenvolvê-lo?

Acreditamos que SaaS terá um grande impacto na indústria de software, pois Software como serviço irá transformar a maneira como as pessoas constroem, vendem, compram e utilizam software. Mas para isso acontecer, os fornecedores de software precisam de recursos e informações sobre como desenvolver aplicativos de SaaS de forma efetiva.

Este é o primeiro de uma série de documentos da Microsoft dedicados a desmistificar o SaaS e fornecer orientação prática do mundo real para a arquitetura de aplicativos de SaaS. Este documento serve como uma visão geral do SaaS, seus desafios e benefícios para os interessados em oferecer SaaS. Os futuros documentos irão explorar muitos desses tópicos com mais detalhes.

Este documento começa perguntando o que é exatamente software como serviço e explica a perspectiva de mudanças conceituais que os fornecedores de SaaS precisarão realizar para entender como ele se diferencia do software por premissa tradicional. Em seguida, analisaremos o modelo de negócios do SaaS para ver como o software como serviço pode ser monetizado no mundo real.

Como este é um estudo arquitetônico, a seção maior trata da arquitetura de um aplicativo de SaaS. Apresentamos um modelo de maturidade de quatro níveis que explica e coloca em perspectiva alguns dos atributos principais do SaaS: configurabilidade, eficiência com vários inquilinos e escalabilidade. Examinaremos os componentes de uma arquitetura de SaaS de alto nível e olharemos mais de perto um desafio típico que o arquiteto de SaaS enfrenta: o de fornecer um mecanismo para estender o modelo de dados de um aplicativo de vários inquilinos.

Por último, daremos uma breve olhada em alguns dos problemas operacionais envolvidos no suporte a um aplicativo de SaaS após a implementação.

O que é Software como serviço?

Até hoje, a definição exata de "software como serviço" (SaaS) está aberta para debates e se perguntarmos a cinco pessoas, provavelmente teremos cinco definições diferentes. No entanto, os especialistas provavelmente concordariam em alguns princípios fundamentais que distinguem o SaaS, por um lado, do software em pacote tradicional e, por outro, dos sites da Web simples. Expresso da forma mais simples, o software como serviço pode ser caracterizado da seguinte maneira:

"Software implementado como um serviço hospedado e acessado pela Internet."

Pare um momento para considerar as implicações dessa definição. Ela não descreve nenhuma arquitetura de aplicativo específica; não diz nada sobre tecnologias ou protocolos específicos; não traça uma distinção entre serviços orientados a negócios e serviços orientados a consumidor e não exige modelos de negócios específicos. De acordo com essa definição, os detalhes principais de distinção do software como serviço são o local em que o código do aplicativo reside e como ele é implementado e acessado.

De acordo com essa definição, o SaaS inclui uma série de serviços e aplicativos que você pode não esperar encontrar nessa categoria. Por exemplo, considere um serviço de email baseado na Web como o Microsoft® Hotmail®. Embora o Hotmail possa não ser o primeiro exemplo que vem à mente ao pensar sobre SaaS, ele atende todos os critérios básicos: um fornecedor hospeda todos os dados e a lógica do programa e fornece acesso a esses dados ao usuário final através da Internet pública por meio de uma interface do usuário baseada na Web.

Indo do geral para o específico, podemos identificar duas categorias principais de software como serviço:

• Serviços de linha de negócios, oferecidos a empresas e organizações de todos os tamanhos. Os serviços de linha de negócios geralmente são soluções de negócios grandes e personalizáveis direcionadas para facilitar processos de negócios como finanças, gerenciamento da cadeia de suprimentos e relações com o cliente. Normalmente esses serviços são vendidos aos clientes como assinatura.

• Serviços orientados a cliente, oferecidos ao público em geral. Os serviços orientados a cliente às vezes são vendidos como assinatura, mas geralmente são fornecidos sem custo e financiados por anúncios.

Pensando em Software como serviço

Passar a oferecer software como serviço em vez de software por premissa exige que os fornecedores de software mudem a maneira de pensar em três áreas inter-relacionadas: no modelo de negócios, na arquitetura do aplicativo e na estrutura operacional.

Nas três seções a seguir daremos uma olhada com mais detalhes em cada uma dessas mudanças, enfocando principalmente o aspecto da arquitetura de aplicativo do SaaS.

Alterando o modelo de negócios

A alteração do modelo de negócios poderá envolver um ou mais dos seguintes aspectos:

• Mudar a "propriedade" do software, do cliente para um provedor externo.

• Realocar a responsabilidade pela infra-estrutura de tecnologia e pelo gerenciamento, ou seja, hardware e serviços profissionais, do cliente para o provedor.

• Reduzir o custo do fornecimento de serviços de software por meio de especialização e economia de escala.

• Objetivar a longa cauda das empresas menores reduzindo ao mínimo o custo em que o software pode ser vendido.

Para perceber os benefícios do SaaS é necessário que haja mudanças na maneira de pensar por parte do provedor e do cliente e é responsabilidade do provedor ajudar o cliente a fazer essa mudança.

Quem é o "proprietário" do software?

A maior parte do software continuará a ser vendido da mesma maneira que tem sido vendido há décadas. O cliente compra uma licença para usar o software e instala-o no hardware que pertence ao cliente ou está sob o controle do cliente, com o fornecedor dando suporte conforme estabelecido pelos termos da licença ou de um contrato de suporte. Em uma transação de software honesta e legal, a noção de uma "licença" pode parecer algo como um detalhe técnico: legalmente, o cliente está adquirindo somente o direito de utilizar uma cópia do software, mas para fins práticos é como se o cliente fosse "proprietário" do software, podendo utilizá-lo com a freqüência e durante o tempo que desejar.

Com o modelo de software como produto fornecendo o contexto para o mercado de software, a idéia de software como serviço poderá parecer como algo estranho: em vez de "possuir" software importante diretamente, dizem aos clientes, eles podem pagar pela assinatura de software que é executado em servidores de outras pessoas, software que vai embora se eles param de assinar. Portanto, é particularmente importante que o cliente em perspectiva entenda como o SaaS fornece um benefício econômico direto e quantificável em relação ao modelo tradicional.

Transferindo as responsabilidades de TI

Em uma organização típica, o orçamento da tecnologia da informação (TI) é gasto em três áreas amplas:

• Software - os dados e programas reais que a organização utiliza para computação e processamento de informações.

• Hardware - os computadores de mesa, servidores, componentes de rede e dispositivos móveis que fornecem aos usuários o acesso ao software.

• Serviços profissionais - as pessoas e instituições que garantem a disponibilidade e operação contínua do sistema, incluindo a equipe de suporte técnico, consultores e representantes do fornecedor.

Desses três, é o software que está envolvido mais diretamente no gerenciamento das informações, que é o objetivo final de qualquer organização de TI. Hardware e serviços profissionais, embora componentes fundamentais e importantes do ambiente de TI, são corretamente considerados meios para um fim, no sentido em que tornam possível ao software produzir o resultado final desejado de gerenciamento efetivo das informações. (Dizendo de outra maneira, qualquer organização adicionaria alegremente funcionalidade de software sem hardware extra se fosse possível, mas nenhuma organização simplesmente adicionaria hardware sem uma necessidade antecipada de adicionar software também.)

Em um ambiente de TI baseado em software por premissa, a maior parte do orçamento normalmente é gasto em hardware e serviços profissionais, deixando uma parte secundária do orçamento disponível para software.

Nesse modelo, o orçamento de software é gasto principalmente em cópias licenciadas de software comercial pronto e software de linha de negócios personalizado. O orçamento de hardware vai para computadores de mesa e computadores móveis para usuários finais, servidores para hospedar dados e aplicativos, e componentes para ligá-los em rede. O orçamento de serviços profissionais paga uma equipe de suporte para implementar e dar suporte a software e hardware, além de consultores e recursos de desenvolvimento para ajudar a projetar e criar sistemas personalizados.

Em uma organização que se apóia principalmente em SaaS, a alocação do orçamento de TI tem uma aparência bem diferente.

Nesse modelo, o fornecedor de SaaS hospeda aplicativos críticos e dados associados em servidores centrais no local do fornecedor e dá suporte ao hardware e software com uma equipe de suporte dedicada. Isso tira da organização do cliente a responsabilidade de dar suporte ao software hospedado e de comprar e manter hardware de servidor para ele. Além disso, os aplicativos entregues pela Web ou por meio de clientes inteligentes imprimem uma demanda significativamente menor em um computador de mesa do que os aplicativos tradicionais instalados localmente, o que permite ao cliente estender de forma significante o ciclo de vida da tecnologia de desktop. O resultado final é que há uma porcentagem muito maior do orçamento de TI disponível para gastar em software, normalmente na forma de taxas de assinatura de provedores de SaaS.

Aproveitando a economia de escala

Mas esse resultado não é apenas uma ilusão? Afinal, uma porcentagem das taxas de assinatura pagas aos fornecedores de SaaS pelo "software" deve pagar pelo hardware e pelos serviços profissionais do fornecedor. A resposta está na economia de escala. Um fornecedor de SaaS com um número x de clientes assinando um serviço de software único hospedado centralmente permite ao fornecedor servir todos os seus clientes em um ambiente consolidado. Por exemplo, um aplicativo de SaaS de linha de negócios em uma farm de cinco servidores com carga balanceada poderá dar suporte a 50 clientes de tamanho médio, o que significa que cada cliente seria responsável por somente um décimo do custo de um servidor. Um aplicativo semelhante instalado localmente poderia exigir que cada cliente dedicasse um servidor inteiro ao aplicativo, às vezes mais de um se as preocupações forem balanceamento de carga e alta disponibilidade. Isso representa uma economia em potencial substancial em relação ao modelo tradicional e, para os aplicativos de SaaS que forem construídos para escalarem bem, o custo operacional por cliente continuará a cair à medida que mais clientes forem adicionados. Enquanto isso estiver acontecendo, o provedor desenvolverá a capacidade de ter vários inquilinos como uma competência central, o que irá resultar em ofertas de qualidade mais elevadas a um custo mais baixo. Portanto, mesmo responsabilizando-se pelos custos do hardware e dos serviços profissionais em que os fornecedores de SaaS incorrem, os clientes ainda podem obter uma funcionalidade pura de software significantemente maior pelo mesmo orçamento de TI.

Vendendo para a Longa cauda

Com o seu artigo "The Long Tail" (A longa cauda) na edição de outubro de 2004 de Wired, o escritor Chris Anderson popularizou a idéia da "longa cauda" ao explicar por que os varejistas on-line como Amazon.com estão posicionados de uma forma singular para atender uma imensa demanda que os varejistas tradicionais não podem atender de uma maneira econômica.

A demanda por categorias de produtos como livros ou CDs tende a seguir o que é conhecido como "distribuição da lei da potência". Nesse tipo de cenário, milhares de livros, CDs e DVDs são publicados todo ano, mas somente algumas dezenas de títulos alcançam o nível de bestseller. O restante se perde na chamada longa cauda: a quantidade imensa de lançamentos menores com atrativos especializados que nunca poderão esperar vender mais do que alguns milhares de cópias, talvez nem isso.

O traditional varejo convencional em lojas concentra-se em vender os itens mais populares, pois não é possível ter em estoque cada um dos milhões de livros, CDs e DVDs que é produzido. Os varejistas on-line, no entanto, não precisam preocupar-se com espaço de prateleira limitado; despachando os produtos para os clientes diretamente dos grandes armazéns espalhados pelo mundo, podem anunciar e vender o milionésimo título mais popular tão facilmente quanto o número um dos mais vendidos. O acesso a essa longa cauda de vendas de baixo volume se converte em uma quantidade imensa de renda.

Uma grande livraria convencional pode conter cerca de 130.000 títulos diferentes em suas prateleiras. No entanto, de acordo com Anderson, a maior parte das vendas de livros da Amazon.com vem de fora dos seus 130.000 títulos principais; em outras palavras, a maior parte dos livros que a Amazon.com vende nem mesmo faria parte dos estoques de uma livraria convencional.

Os fornecedores de soluções complexas de software de linha de negócios se defrontam com uma curva de mercado semelhante.

Em contraste com os pacotes mais simples de software pronto, o software de linha de negócios tende a ser personalizado para atender as necessidades de clientes individuais, potencialmente incluindo instalação no local e visitas de serviço por parte das equipes de manutenção do fornecedor, muitas vezes exigindo hardware de servidor dedicado e uma equipe de suporte para gerenciá-lo. O custo de fornecer esse tipo de atenção dedicada contribui para o preço mínimo com que o fornecedor pode vender o software. Esse software, portanto, tende a ser comercializado com empresas maiores que podem pagar por esse nível de atenção. Mas, para cada grande empresa que compra uma solução de linha de negócios existem dezenas de empresas menores e de tamanho médio que poderiam beneficiar-se dessa solução, mas não possuem os recursos para adquiri-la.

Ao eliminar grande parte da manutenção e utilizando a economia de escala para combinar e centralizar as necessidades de hardware e de serviços dos clientes, os fornecedores de SaaS podem oferecer soluções a um custo muito menor do que os fornecedores tradicionais, não somente em termos monetários mas também ao reduzir a necessidade de os clientes aumentarem a complexidade da sua infra-estrutura de TI. Isso permite ao SaaS acesso exclusivo a uma faixa inteiramente nova de clientes em potencial que sempre esteve inacessível aos fornecedores de soluções tradicionais porque nunca foi economicamente viável servi-los.

Para atingir de forma efetiva esses clientes menores é necessário uma outra mudança de pensamento por parte dos fornecedores que estão acostumados a um processo de vendas que depende de contatos pessoais e de relacionamentos entre fornecedor e cliente; a maioria dos fornecedores não será capaz de fornecer serviços pessoais a uma base de clientes muito maior em um nível de preços que essa base irá suportar. Vender SaaS é como vender opções de toque de telefone celular ou música transferível por download: O cliente deve ter condições de visitar o site da empresa na Web, assinar os seus serviços, pagar com cartão de crédito, personalizar o serviço e começar a usá-lo, tudo sem intervenção humana por parte do fornecedor. Isso não significa que você deve eliminar a abordagem mais pessoal para os clientes maiores com necessidades mais extensas. Mas, ao criar os processos de vendas, marketing, fornecimento e personalização para funcionarem de forma totalmente automática, torna-se possível oferecer uma abordagem automatizada como opção, com o efeito secundário altamente favorável de simplificar o trabalho que o seu pessoal de suporte deve realizar para executar as mesmas tarefas em favor de um cliente.

Arquitetura de aplicativos

A nossa definição de trabalho de software como serviço é: "Software implementado como um serviço hospedado e acessado pela Internet." Dependendo de como definimos palavras como software e acesso, essa definição pode abranger muitas coisas... talvez coisas demais. Para um arquiteto de aplicativos, certamente, não lança nenhuma luz sobre o que exatamente faz um aplicativo de SaaS funcionar, aquilo que faz a diferença entre um aplicativo de SaaS bem-sucedido e um fracassado. Um aplicativo de linha de negócios com uma base de código com uma década de idade combinado com um front-end em HTML precário poderá se encaixar na definição ampla de software como serviço, mas a maioria desses aplicativos enfrenta problemas quando não consegue escalar bem ou de maneira econômica. Portanto, para definir o que poderia ser denominado aplicativo de SaaS maduro, precisamos introduzir alguns critérios adicionais.

Os três atributos de arquitetura para vários inquilinos de única instância

Do ponto de vista de um arquiteto de aplicativos, existem três diferenciadores principais que separam um aplicativo de SaaS bem projetado de outro mal projetado. Um aplicativo de SaaS bem projetado é escalonável, eficiente para vários inquilinos e configurável.

Escalar o aplicativo significa maximizar a simultaneidade e utilizar os recursos do aplicativo de forma mais eficiente, por exemplo, otimizando a duração do bloqueio, ausência de estado, compartilhamento de recursos agrupados como threads e conexões de rede, armazenamento em cache de dados de referência e particionamento de bancos de dados grandes.

Vários inquilinos pode ser a mudança de paradigma mais significativa que deve ser feita por um arquiteto acostumado a projetar aplicativos isolados para inquilino único. Por exemplo, quando um usuário de uma empresa acessa informações de cliente utilizando um serviço de aplicativo CRM, a instância de aplicativo à qual o usuário se conecta pode estar acomodando usuários de dezenas ou mesmo centenas de outras empresas, cada um ignorando completamente os demais. Porém isso exige uma arquitetura que maximize o compartilhamento de recursos pelos inquilinos, mas mesmo assim seja capaz de diferenciar os dados que pertencem aos diferentes clientes.

Naturalmente, se uma única instância de aplicativo em um único servidor tiver de acomodar usuários de várias empresas diferentes ao mesmo tempo, você não pode simplesmente escrever código personalizado para personalizar a experiência do usuário final: qualquer coisa que você fizer para personalizar o aplicativo para um cliente irá alterar o aplicativo para os outros clientes também. Por isso, em vez de personalizar o aplicativo no sentido tradicional, cada cliente utiliza metadados para configurar a maneira como o aplicativo se apresenta e se comporta para os seus usuários. O desafio para o arquiteto do SaaS é garantir que a tarefa de configurar os aplicativos seja simples e fácil para os clientes, sem exigir desenvolvimento extra ou custos operacionais para cada configuração.

O modelo de maturidade do Software como serviço

Aprimoramos a nossa definição de serviço do SaaS identificando os atributos importantes de um aplicativo de SaaS maduro. Mas maturidade não é uma proposição de tudo ou nada. Um aplicativo pode possuir apenas um ou dois desses atributos e mesmo assim atender todos os requisitos de negócios necessários, caso em que os arquitetos do aplicativo podem ativamente optar por não atender os demais atributos se isso não for economicamente conveniente.

De maneira ampla, a maturidade do aplicativo de SaaS pode se expressa utilizando um modelo com quatro níveis distintos. Cada nível se distingue do anterior pela adição de um dos três atributos citados acima.

Nível I: Ad-Hoc/Personalizado

O primeiro nível de maturidade é semelhante ao modelo de entrega de software do provedor de serviços de aplicativos (ASP) tradicional, que data da década de 1990. Nesse nível, cada cliente tem a sua própria versão personalizada do aplicativo hospedado e executa a sua própria instância do aplicativo nos servidores do host. Pensando em arquitetura, software nesse nível de maturidade é muito semelhante ao software de linha de negócios vendido tradicionalmente, em que diferentes clientes em uma organização conectam a uma instância única em execução no servidor, mas essa instância é totalmente independente de quaisquer outras instâncias ou processos que o host esteja executando para os seus outros clientes.

Normalmente, os aplicativos cliente-servidor tradicionais podem ser levados para o primeiro nível de maturidade do modelo SaaS com um esforço de desenvolvimento relativamente pequeno e sem rearquitetar o sistema inteiro desde a base. Embora esse nível ofereça poucos dos benefícios de uma solução SaaS inteiramente madura, permite aos fornecedores reduzir os custos consolidando administração e hardware de servidor.

Nível II: Configurável

No segundo nível de maturidade, o fornecedor hospeda uma instância separada do aplicativo para cada inquilino enquanto que no primeiro nível cada instância é personalizada individualmente para o inquilino, neste nível todas as instâncias utilizam a mesma implementação de código e o fornecedor atende as necessidades dos clientes fornecendo opções de configuração detalhadas que permitem ao cliente alterar a aparência e o comportamento do aplicativo para os seus usuários. Apesar de serem idênticas umas às outras no nível do código, cada instância permanece totalmente isolada de todas as demais.

Mudar para uma base de código única para todos os clientes de um fornecedor reduz grandemente os requisitos de serviço de um aplicativo de SaaS, pois qualquer alteração feita na base do código pode ser fornecida facilmente para todos os clientes do vendedor ao mesmo tempo, eliminando assim a necessidade de atualizar ou acelerar as instâncias personalizadas individuais. No entanto, a reposição de um aplicativo tradicional como SaaS no segundo nível de maturidade pode exigir uma rearquitetura mais profunda do que o primeiro nível se o aplicativo foi projetado para personalização individual em vez de metadados de configuração.

Semelhante ao primeiro nível de maturidade, o segundo nível exige que o fornecedor forneça hardware e armazenamento suficientes para dar suporte a um número potencialmente grande de instâncias de aplicativo em execução simultaneamente.

Nível III: Configurável e eficiente para vários inquilinos

No terceiro nível de maturidade, o fornecedor executa uma única instância que serve a todos os clientes, com metadados configuráveis fornecendo uma experiência de usuário e conjunto de recursos exclusivos para cada um. Políticas de autorização e de segurança garantem que os dados de cada cliente sejam mantidos separados dos de outros clientes e que, da perspectiva do usuário final, não exista qualquer indicação de que a instância do aplicativo esteja sendo compartilhada entre vários inquilinos.

Essa abordagem elimina a necessidade de fornecer espaço de servidor para tantas instâncias quanto o número de clientes do fornecedor, permitindo o uso muito mais eficiente dos recursos de computação do que o segundo nível, o que se traduz diretamente em custos mais baixos. Uma desvantagem considerável dessa abordagem é que a escalabilidade do aplicativo é limitada. A menos que seja usado particionamento para gerenciar o desempenho do banco de dados, o aplicativo somente pode ser escalonado mudando-o para um servidor mais poderoso (escalabilidade vertical) até a diminuição do retorno tornar impossível adicionar mais potência de forma econômica.

Nível IV: Escalonável, configurável e eficiente para vários inquilinos

No quarto e último nível de maturidade, o fornecedor hospeda vários clientes em uma farm com carga balanceada de instâncias idênticas, com os dados de cada cliente mantidos separados e com metadados configuráveis fornecendo uma experiência do usuário e um conjunto de recursos exclusivos para cada cliente. Um sistema de SaaS é escalonável para um número de clientes arbitrariamente grande, uma vez que a quantidade de servidores e instâncias no lado do fornecedor pode ser aumentada ou diminuída conforme necessário para corresponder à demanda sem a necessidade de rearquitetura adicional do aplicativo, além do que as alterações ou correções podem ser transmitidas para milhares de inquilinos tão facilmente quanto para um único inquilino.

Escolhendo um nível de maturidade

Que nível de maturidade você deve visar para o seu aplicativo? Normalmente se esperaria que o quarto nível fosse a meta definitiva para qualquer aplicativo de SaaS, mas não é sempre assim. Pode ser mais útil pensar em maturidade do SaaS como uma seqüência contínua entre código e dados isolados em uma extremidade e código e dados compartilhados na outra.

O ponto em que o seu aplicativo se situa nessa seqüência contínua depende das suas necessidades operacionais, arquitetônicas e de negócios e das considerações dos clientes. Como você poderá ver mesmo nesta explicação simples, todas essas considerações estão inter-relacionadas em algum grau.

• Modelo de negócios. Uma abordagem isolada faz sentido financeiramente? Abrir mão dos benefícios econômicos e de gerenciamento de uma abordagem compartilhada significa oferecer o seu aplicativo ao consumidor a um custo mais elevado, mas em algumas circunstâncias pode valer a pena atender outras necessidades. Além disso, os clientes podem ter uma forte resistência legal ou cultural a um modelo de arquitetura no qual vários inquilinos compartilham o acesso a um aplicativo, mesmo se você puder demonstrar que isso não coloca dados confidenciais em risco. No final, naturalmente, você precisará de um modelo de negócios que mostre como o seu aplicativo pode produzir dinheiro qualquer que seja o nível de maturidade objetivado.

• Modelo de arquitetura. O seu aplicativo pode ser feito para executar em uma única instância lógica? Se você estiver procurando mudar um aplicativo cliente-servidor tradicional ou baseado em computador de mesa para um sistema de entrega baseado na Internet, isso pode ser fundamentalmente incompatível com uma abordagem de instância única centrada em metadados e você pode determinar que nunca fará sentido financeiramente investir no esforço de desenvolvimento necessário para transformá-lo em um aplicativo de SaaS totalmente maduro. Se você estiver projetando e criando do zero um aplicativo nativo da rede, provavelmente terá muito mais liberdade para utilizar a abordagem de instância única.

• Modelo operacional. Você pode garantir os seus contratos de nível de serviço (SLAs) sem isolamento? Examine com cuidado as obrigações impostas pelos SLAs existentes mantidos com os clientes em relação a considerações como tempo de interrupção, opções de suporte e recuperação de desastres e determine se essas obrigações podem ser atendidas em uma arquitetura de aplicativos no qual vários clientes não relacionados compartilham o acesso a uma única instância de aplicativos.

Arquitetura de alto nível

Arquitetonicamente, os aplicativos de SaaS são muito semelhantes a outros aplicativos criados com a utilização de princípios de projeto orientados a serviços.

A maior parte dos componentes representados no diagrama deve ser familiar à maioria dos arquitetos de aplicativos. Os serviços de processo mostram interfaces que clientes inteligentes e/ou a camada de apresentação da Web podem chamar e dão início a um fluxo de trabalho síncrono ou uma transação de longa duração que chamará outros serviços de negócios, o que interage com os armazenamentos de dados respectivos para ler e gravar dados de negócios. Os serviços de segurança são responsáveis pelo controle do acesso aos serviços de software do usuário e do fornecedor.

A diferença mais significativa é a adição de serviços de metadados, que são responsáveis pelo gerenciamento da configuração do aplicativo para inquilinos individuais. Os serviços e os clientes inteligentes (smartclients) interagem com os serviços de metadados para recuperar informações que descrevem configurações e extensões que são específicas de cada inquilino.

Serviços de metadados

Em um aplicativo de SaaS maduro, o serviço de metadados fornece aos clientes os meios básicos para personalizar e configurar o aplicativo para atender as suas necessidades. Normalmente, os clientes podem fazer alterações na configuração de três áreas amplas:

• Interface do usuário e identificação de marca. Os clientes geralmente apreciam a capacidade de modificar a interface do usuário para refletir a sua identificação de marca corporativa, de modo que os aplicativos de SaaS normalmente oferecem recursos que permitem aos usuários alterar detalhes como gráficos, cores, fontes etc.

• Fluxo de trabalho e regras de negócios. Para ser útil para uma ampla variedade de clientes em potencial, um aplicativo SaaS crítico para negócios deve ter a capacidade de acomodar diferenças no fluxo de trabalho. Por exemplo, um cliente de um aplicativo de rastreamento de faturas pode exigir que cada fatura seja aprovada por um gerente; um segundo cliente pode exigir que cada fatura seja aprovada por dois gerentes em seqüência; um terceiro pode exigir que dois gerentes aprovem cada fatura, mas permite que trabalhem em paralelo. Quando apropriado, os clientes devem poder configurar a maneira como o fluxo de trabalho do aplicativo alinha com os seus processos de negócios.

• Extensões para o modelo de dados. Para muitos aplicativos de SaaS dirigidos a dados, um tamanho definitivamente não serve para todos. Mesmo com aplicativos relativamente simples específicos de tarefas, os clientes podem se irritar com as restrições impostas por um conjunto de campos de dados e tabelas estáticos e inalteráveis. Um modelo de dados extensível dá aos clientes a liberdade de fazer com que um aplicativo funcione da sua maneira em vez de serem forçados a trabalhar da maneira do aplicativo. Mais adiante neste documento você aprenderá um pouco mais sobre como é feita a arquitetura de um modelo de dados extensível ao cliente.

• Controle do acesso. Normalmente, cada cliente é responsável por criar contas individuais para usuários finais e determinar a quais recursos e funções cada usuário deve ter direito de acesso. Os direitos e as restrições de acesso de cada usuário são rastreados com a utilização de políticas de segurança, que devem ser configuráveis por cada inquilino.

Para fornecer aos clientes flexibilidade para configurar o software como necessário, essas opções são organizadas em unidades de configuração hierárquicas conhecidas como escopos, cada uma das quais contém opções para fazer alterações em cada uma das quatro áreas citadas acima. Cada cliente tem um escopo de nível superior que pode configurar conforme necessário e pode estabelecer um ou mais escopos abaixo do nível superior em uma hierarquia arbitrária. Uma estratégia de relacionamento determina como e se os nós filhos herdam e substituem as definições de configuração dos nós pais.

Por exemplo, um cliente comum que compra acesso ao seu aplicativo para a empresa toda pode ter várias unidades de negócios com necessidades distintas, sendo que todas devem seguir determinados padrões da empresa, mas também ser capaz de configurar alguns aspectos do aplicativo individualmente. Dentro de cada unidade de negócios também, pode haver grupo organizacionais com suas próprias necessidades de configuração particulares. Para cada uma dessas unidades organizacionais identificadas, o cliente pode estabelecer um escopo que dá ao grupo acesso às opções de configuração que ele pode definir ou alterar.

Ao contrário dos aplicativos de linha de negócios tradicionais personalizados pelo fornecedor, os aplicativos de SaaS são muito mais provavelmente configurados pelos próprios clientes. Projetar a interface de configuração, portanto, é quase tão importante quanto projetar a interface dos usuários finais. Idealmente, os clientes deverão poder configurar o aplicativo por meio de um assistente ou de telas simples e intuitivas que apresentam todas as opções disponíveis sem causar sobrecarga de informações e que distinguem claramente entre opções que podem e não podem ser alteradas dentro de um escopo determinado.

Serviços de segurança

Importante como é em qualquer contexto de software, a segurança torna-se uma preocupação principal para os clientes e uma alta prioridade para os arquitetos de aplicativos devido à natureza do SaaS. A seguir estão algumas diretrizes básicas que podem ajudar a garantir que os inquilinos mantenham o controle dos seus dados privados.

Autenticação

O provedor de SaaS normalmente transfere a cada inquilino a responsabilidade de criar e manter as suas próprias contas do usuário, um processo conhecido como administração delegada. A administração delegada cria uma situação em que o cliente é responsável pela criação das contas de usuários individuais, mas o fornecedor precisa autenticá-las. Para acomodar esse modelo de administração delegada, os projetistas de SaaS utilizam duas abordagens gerais para tratar da autenticação: um sistema de autenticação centralizado ou um sistema de autenticação descentralizado. A abordagem que você escolher terá ramificações para a complexidade da sua arquitetura e a maneira como os usuários finais utilizam o aplicativo e você deve considerar o que o seu modelo de negócios indica sobre as necessidades do aplicativo, dos clientes e dos usuários finais ao tomar uma decisão.

Em um sistema de autenticação centralizado, o fornecedor gerencia um banco de dados central de contas do usuário que serve todos os inquilinos do aplicativo. O administrador de cada inquilino tem a permissão de criar, gerenciar e excluir contas do usuário desse inquilino no diretório de contas do usuário. Um usuário que assina o aplicativo fornece as suas credenciais para o aplicativo, o qual autentica as credenciais no diretório central e concede acesso ao usuário se as credenciais forem válidas.

Essa abordagem exige uma infra-estrutura de autenticação relativamente simples, que é comparativamente fácil de projetar e implementar e não necessita de nenhuma alteração na infra-estrutura do usuário. Uma desvantagem importante dessa abordagem é que um sistema de autenticação centralizado torna muito mais difícil implementar logon único, em que o aplicativo aceita as credenciais que o usuário já inseriu para acessar a sua rede corporativa. Sem logon único, os usuários recebem com freqüência um inconveniente aviso de logon ao acessar o aplicativo e precisam inserir as suas credenciais manualmente.

Em um sistema de autenticação descentralizado, o inquilino implementa um serviço de federação que faz interface com o próprio serviço de diretório de usuário do inquilino. Quando um usuário final tentar acessar o aplicativo, o serviço de federação autentica o usuário localmente e emite um token que o sistema de autenticação do provedor de SaaS aceita e permite ao usuário o acesso ao aplicativo.

Essa é uma abordagem ideal quando logon único é importante, pois a autenticação é manipulada em segundo plano e não exige que o usuário recorde e insira um conjunto especial de credenciais. No entanto, a abordagem descentralizada é mais complexa do que a abordagem centralizada e um aplicativo de SaaS com milhares de clientes exigirá relacionamentos de confiança individuais com cada um dos milhares de serviços de federação de inquilino.

Em muitos casos, o provedor de SaaS poderá considerar uma abordagem híbrida: utilizar a abordagem centralizada para autenticar e gerenciar usuários de inquilinos menores e a abordagem federada para empresas maiores que exigem e pagarão pela experiência de logon único.

Autorização

Normalmente o acesso aos recursos e às funções de negócios em um aplicativo de SaaS é gerenciado com a utilização de funções que mapeiam para funções de trabalho específicas dentro de uma organização. A cada função são concedidas uma ou mais permissões que permitem aos usuários atribuídos à função executar ações de acordo com quaisquer regras de negócios relevantes.

As funções são gerenciadas dentro do próprio aplicativo de SaaS; elas podem conter contas de usuários individuais além de grupos de usuários. As contas de usuários individuais e os grupos podem receber a atribuição de várias funções diferentes conforme necessário.

Dependendo das funções atribuídas a um usuário, ele recebe uma ou mais permissões para executar operações ou ações específicas. Essas ações normalmente mapeiam diretamente para funções de negócios importantes ou para o gerenciamento do próprio aplicativo. Por exemplo, um aplicativo de compras poderá incluir permissões para criar, submeter, aprovar e rejeitar pedidos de compra; um aplicativo para agentes de financiamento imobiliário poderá incluir permissões para verificar o crédito de um tomador de empréstimo e conceder um empréstimo etc. Uma permissão única pode ser atribuída a uma ou várias funções conforme necessário; cada usuário receberá o conjunto das permissões atribuídas a todas as funções às quais o usuário pertence.

Os aplicativos podem utilizar regras de negócios para controlar o acesso a ações e recursos em um nível mais refinado do que as permissões. As regras de negócios introduzem condições que devem ser atendidas antes de o acesso ser concedido. Por exemplo, você pode utilizar uma regra de negócios que permite a um usuário transferir fundos entre contas diferentes somente durante o horário comercial ou se o montante a ser transferido não ultrapassar um valor determinado.

O controle do acesso é gerenciado no nível do escopo. Cada escopo herda as funções, permissões e regras de negócios de quaisquer escopos pai de acordo com a estratégia de relacionamento e pode modificar, adicionar e excluí-las conforme apropriado. Por exemplo, suponha um cliente estabelecido nos Estados Unidos com uma filial em Toronto, Canadá. O escopo raiz possui uma função denominada "Administrador de benefícios" que contém uma série de permissões relacionadas ao gerenciamento de benefícios dos funcionários, incluindo a administração do plano de aposentadoria 401(k) da empresa. Como os planos 401(k) são uma criação da lei fiscal dos Estados Unidos, não são utilizados no Canadá. Portanto, um escopo filho é criado para o escritório canadense que herda a função "Administrador de benefícios" e suas permissões, com exceção da permissão que permite à função modificar as ofertas do 401(k). No lugar dessa permissão, o cliente adiciona uma permissão que permite à função modificar as ofertas do RRSP (Registered Retirement Savings Plan), o equivalente canadense ao 401(k) dos EUA.

Como prática recomendada, o seu aplicativo deverá incluir um conjunto de funções, permissões e regras de negócios padrão disponíveis a todos os inquilinos e que permitam aos inquilinos individuais personalizar essas regras e criar mais regras por meio de uma interface do usuário útil e intuitiva.

Uma olhada mais de perto: Modelo de dados para vários inquilinos

Até agora estivermos analisando a arquitetura de aplicativos em um nível razoavelmente alto, por isso vamos agora examinar um desafio específico com mais detalhes: o de criar um modelo de dados que os clientes possam estender em um ambiente de vários inquilinos. Isto de modo algum é uma exploração abrangente do processo de extensão do modelo de dados, mas deverá ajudar a dar-lhe uma idéia dos tipos de problemas de arquitetura que devem ser considerados ao se projetar aplicativos de SaaS.

Como projetado, o seu aplicativo incluirá naturalmente uma configuração de banco de dados padrão com tabelas, campos, consultas e relacionamentos padrão que são apropriados à natureza da sua solução. Porém, organizações diferentes possuem suas próprias necessidades exclusivas que um modelo de dados padrão rígido e não extensível não conseguirá abranger. Por exemplo, um cliente de um sistema de acompanhamento de trabalho de SaaS precisa armazenar com cada registro uma seqüência de código de classificação gerado externamente para integrar totalmente o sistema com seus outros processos. Um cliente diferente poderá não ter necessidade de um campo de seqüência de classificação, mas poderá precisar de suporte para rastrear um número de ID de categoria, um número inteiro. Portanto, em todos os casos, exceto alguns especializados, você precisará desenvolver e implementar um método por meio do qual os clientes possam estender o modelo de dados padrão para que atenda às suas necessidades sem afetar o modelo de dados utilizado pelos demais clientes. Iremos analisar três abordagens gerais para resolver esse problema: um banco de dados de inquilinos dedicado, um banco de dados compartilhado com um conjunto de extensões fixas e um banco de dados compartilhado com extensões personalizadas.

Banco de dados de inquilinos dedicado

A primeira abordagem envolve simplesmente dar a cada inquilino o seu próprio banco de dados, que eles podem estender conforme a necessidade.

Com essa abordagem, um novo banco de dados padrão é criado para um novo inquilino como parte do processo de fornecimento e o serviço de metadados mantém o rastreamento de qual banco de dados é atribuído a qual inquilino. Quando o novo banco de dados é criado, o inquilino fica livre para modificá-lo na extensão que a interface do usuário e a lógica de programa do aplicativo permitirem, criando potencialmente novos campos, novas consultas e até mesmo novas tabelas e relacionamentos.

Se o custo do fornecimento de serviços não for um fator, esta seria a única abordagem a considerar porque é o arranjo mais simples de criar e oferece aos clientes o máximo de liberdade para estender o modelo de dados padrão. Além do que, os clientes de áreas como bancos ou gerenciamento de registros médicos poderão ter requisitos de isolamento de dados muito rígidos e nem mesmo irão considerar um aplicativo que não forneça a cada usuário o seu próprio banco de dados individual. A desvantagem dessa abordagem é que será possível dar suporte a um número limitado de bancos de dados por servidor, de forma que o custo da infra-estrutura será mais elevado e aumentará mais rapidamente do que o faria de outro modo.

Banco de dados compartilhado, conjunto de extensões fixas

A segunda abordagem envolve criar um banco de dados único que é compartilhado por todos os inquilinos e inclui um número predefinido de campos personalizados que os inquilinos podem atribuir e utilizar conforme desejado.

Na ilustração acima, os registros de diferentes clientes são misturados em uma única tabela; um campo de ID do inquilino cliente associa cada registro a um inquilino individual. Além do conjunto de campos padrão, diversos campos personalizados são fornecidos e cada cliente pode escolher a maneira de usar esses campos e como os dados serão coletados por eles.

Os campos personalizados podem ser digitados, de modo que o cliente pode utilizar qualquer função de verificação incorporada disponível que o aplicativo e o banco de dados forneçam para validar os dados. Como alternativa, os campos podem ser não digitados, de modo que o cliente pode usá-los para armazenar qualquer tipo de dados. (O cliente pode opcionalmente fornecer a sua própria lógica de validação para impedir que usuários insiram acidentalmente dados inválidos.)

Um banco de dados compartilhado tem um custo de fornecimento de serviços muito menor do que a abordagem isolada, pois permite que um único mecanismo de banco de dados dê suporte a um número de clientes maior antes de um particionamento tornar-se necessário. A maior desvantagem dessa abordagem é que a capacidade de extensão do modelo de dados é limitada ao número de campos personalizados que você fornece. A escolha desse número com sabedoria exige uma avaliação cuidadosa das necessidades potenciais do seu cliente. Se houver campos personalizados insuficientes, os clientes não conseguirão utilizar o aplicativo de forma efetiva; se houver demais, o resultado será um banco de dados escasso e com muito desperdício, com muitos campos não utilizados.

Banco de dados compartilhado, extensões personalizadas

A terceira abordagem envolve criar um banco de dados único e compartilhado e permitir aos clientes estender o modelo de dados arbitrariamente, armazenando dados personalizados como pares de nome-valor em uma tabela separada.

Aqui, cada registro do cliente que inclui dados personalizados recebe a atribuição de uma ID de registro exclusiva que corresponde a uma ou mais linhas em uma tabela de extensões separada. Para cada linha dessa tabela é armazenado um par de nome-valor. Cada cliente pode criar o número de pares nome-valor que for necessário para atender as suas necessidades de negócios. Quando o aplicativo recupera um registro do cliente, realiza uma pesquisa na tabela de dados personalizada, seleciona todas as linhas correspondentes à ID do registro e retorna-os para serem tratados como dados de campos comuns. Obviamente, os dados da tabela de dados personalizada não podem ser digitados, pois é provável que contenham dados em muitas formas diferentes para os diferentes clientes. Para contornar essa limitação, uma terceira coluna pode conter opcionalmente um identificador do tipo de dados, de modo que os dados possam ser lançados no tipo de dados apropriado quando recuperados.

Essa abordagem torna o modelo de dados arbitrariamente extensível enquanto conserva o custo-benefício de utilizar um banco de dados compartilhado. A principal desvantagem é um nível adicional de complexidade para as funções do banco de dados, como pesquisar, indexar, consultar e atualizar registros. Normalmente é a melhor abordagem se você tiver a previsão de que os seus clientes irão exigir um grau de flexibilidade considerável para estender o modelo de dados padrão, mas não exigirão o isolamento dos dados.

Ao desenvolver uma abordagem extensível do seu modelo de dados, lembre-se de que qualquer extensão implementada por um cliente irá exigir uma extensão correspondente na lógica de negócios, de forma que o aplicativo possa utilizar os dados personalizados assim como uma extensão da lógica de apresentação para que os usuários tenham uma maneira de inserir os dados personalizados como entrada e recebê-los como saída. A interface de configuração que você apresenta ao cliente, portanto, deve fornecer mecanismos para atualizar todos os três, de preferência de uma forma integrada. (O fornecimento de mecanismos por meio dos quais os clientes podem estender a lógica de negócios e a interface do usuário será analisado em um documento futuro.)

Escalabilidade

O software corporativo de grande escala é criado para ser utilizado por milhares de pessoas simultaneamente. Se você tiver experiência em criar aplicativos corporativos desse tipo, deve saber de primeira mão os desafios envolvidos na criação de uma arquitetura escalonável. Para um aplicativo de SaaS, a escalabilidade é até mais importante: você terá de dar suporte à base de usuários média de um único cliente multiplicado pelo número total de clientes existentes. Para ISVs acostumados a criar software corporativo por premissa, dar suporte a esse tipo de base de usuários é como mudar da liga amadora para a liga profissional: as regras podem ser familiares, mas o jogo se desenvolve em um nível inteiramente diferente. Em vez de um aplicativo corporativo crítico de negócios amplamente implantado, você estará criando realmente um sistema em escala de Internet que precisa dar suporte ativamente a uma base de usuários que potencialmente pode chegar a milhões.

Escalonando o aplicativo

Naturalmente, é muito improvável que você termine dando suporte a tantos usuários quanto o Hotmail, (se isso acontecer, parabéns!). Mas os desafios de escalabilidade são na verdade bastante semelhantes.

Os aplicativos podem ser escalonados verticalmente (mudando o aplicativo para um servidor maior e mais poderoso) e horizontalmente (executando o aplicativo em mais servidores). O escalonamento vertical, uma solução familiar para quem já substituiu um computador antigo por outro novinho em folha, geralmente é a melhor escolha para aplicativos menores que não precisam servir tantos usuários simultâneos. No entanto, no nível do SaaS, o escalonamento horizontal é quase sempre a melhor maneira de adicionar capacidade, como descrito no modelo de maturidade do SaaS. Um aplicativo de SaaS bem projetado pode ser escalonado horizontalmente para um número de servidores arbitrariamente grande, cada qual executando uma ou mais instâncias idênticas do aplicativo. Algumas diretrizes para projetar um aplicativo para escalonamento horizontal são as seguintes:

• Projete o aplicativo para executar de uma maneira sem estado, com quaisquer dados do usuário e da sessão necessários armazenados no lado do cliente ou em um armazenamento distribuído acessível a qualquer instância do aplicativo. Sem estado significa que cada transação pode ser manipulada por uma instância diferente assim como qualquer outra; um usuário pode realizar transações com dezenas de instâncias diferentes durante uma única sessão sem ao menos perceber.

• Projete o aplicativo para realizar operações de E/S de forma assíncrona, de modo que o aplicativo possa realizar trabalho útil enquanto aguarda a conclusão da entrada e saída.

• O agrupamento de recursos como threads, conexões de rede e conexões de banco de dados ajuda a maximizar os recursos de computação e aprimora a capacidade de prever a utilização de recursos.

• Grave as suas operações de banco de dados de forma a maximizar a simultaneidade e minimizar o bloqueio exclusivo. Por exemplo, não bloqueie os registros ao realizar operações somente leitura.

Naturalmente, esta é somente a análise mais ligeira do tópico; volumes inteiros poderiam ser (e têm sido) escritos sobre a implementação de uma arquitetura escalonável. Para obter orientação adicional, consulte os recursos de Desempenho e escalabilidade publicados pelos Padrões e práticas Microsoft em http://msdn.microsoft.com/practices/Topics/perfscale/default.aspx.

Escalonando os dados

À medida que os bancos de dados servem mais usuários simultaneamente e crescem em tamanho, o intervalo de tempo necessário para realizar operações como consultas e pesquisas aumenta de forma significativa. Os aplicativos de SaaS, que geralmente utilizam os mesmos bancos de dados para servir milhares de clientes, são particularmente suscetíveis a esses tipos de degradação de desempenho, de modo que é importante planejar adequadamente o crescimento.

Uma maneira bastante simples de escalar um banco de dados é por meio de particionamento, dividindo os dados em blocos menores para melhorar a eficiência das consultas e atualizações. Considere o desenvolvimento de uma estratégia de particionamento para determinar a melhor maneira de particionar os seus dados. Por exemplo, se um aplicativo tiver clientes de todo o mundo, uma estratégia de particionamento geográfica poderá ser apropriada, com os dados pertencentes aos clientes europeus em uma partição, os dados pertencentes aos clientes asiáticos em outra, etc

Na maior parte das situações, é provável que o tamanho dos bancos de dados continuará crescendo. Portanto, também é importante ter estratégias de particionamento dinâmicas estabelecidas para garantir que dados já particionados possam ser reparticionados para acompanhar o desempenho e escalar a métrica.

Estrutura operacional

A terceira mudança de pensamento importante refere-se à estrutura operacional do aplicativo: o que é necessário para entregar o aplicativo aos clientes e mantê-lo disponível e executando corretamente em um nível econômico. Para muitos ISVs, que nunca precisaram executar um centro de dados para seus clientes, esse pode ser o aspecto mais incomum do SaaS. Os provedores de SaaS precisam não apenas ser especialistas em criar software e levá-lo até o mercado, precisam também tornar-se especialistas na sua operação e gerenciamento.

Recursos como o Microsoft Operations Framework (MOF) fornecem muitas orientações relevantes para a manutenção da confiabilidade, disponibilidade, suportabilidade e gerenciabilidade do sistema. Além dos problemas operacionais comuns que o MOF foi projetado para tratar, o SaaS apresenta alguns desafios específicos próprios.

Serviços compartilhados

Se você já teve experiência com uma presença na web no nível corporativo, já está familiarizado com os conceitos básicos de serviços de middleware e hospedagem na Web, em que uma organização hospeda um site internamente ou contrata um provedor externo para co-locação de equipamento ou hospedagem completa de serviços, incluindo hardware, armazenamento e largura de banda de rede. O serviço de hospedagem é responsável pela disponibilidade do site, mas normalmente não é responsável pela operação e manutenção do site.

Fornecer software como serviço adiciona uma nova camada a ser considerada ao se fazer os arranjos de hospedagem. Dependendo do seu plano de negócios, você pode precisar de um sistema de medição e cobrança para:

• Acompanhar com precisão o uso por parte dos clientes e cobrá-los pelo tempo ou recursos utilizados.

• Restringir ou acelerar o acesso em determinadas horas do dia ou atender outros critérios.

• Monitorar o acesso ao site e o desempenho para garantir que os SLA (acordos de nível de serviço) estão sendo cumpridos.

• Executar outras funções para garantir uma experiência uniforme para os seus clientes que atenda ou exceda as expectativas.

Coletivamente, os sistemas utilizados para realizar essas funções são conhecidos como serviços compartilhados.

Os serviços compartilhados podem ser classificados em duas subcategorias.

• Os Serviços de suporte operacional (OSS) tratam das questões operacionais como ativação de contas, provisionamento, garantia de serviço, utilização e medição.

  

• Os Serviços de suporte de negócios (BBS) dão suporte à cobrança (incluindo faturamento, classificação, taxação e cobranças) e gerenciamento do cliente, que incluiu entrada de pedido, auto-serviço do cliente, atendimento ao cliente, trouble ticketing e gerenciamento de relacionamento com o cliente.

Da mesma maneira que na hospedagem da Web tradicional, você precisa decidir se você mesmo irá construir a camada de serviços compartilhados e você mesmo irá hospedar o aplicativo ou se irá contratar uma empresa de hospedagem externa (conhecida como provedor de SaaS) para isso. Os provedores de SaaS oferecem um conjunto de serviços compartilhados para tratar dos problemas operacionais e de negócios identificados acima.

Monitoramento

Os SLAs que você estabelecer com os seus clientes irão quantificar os padrões operacionais que você terá a obrigação de atender. Os SLAs são contratos de obrigação legais e falhar em cumpri-los pode significar perda de receita significativa e danos à sua reputação. O monitoramento da arquitetura do seu aplicativo para detectar qualquer sinal de problemas, portanto, é uma ferramenta vital para detectar problemas e corrigi-los antes que resultem em interrupções significativas ou degradação do desempenho.

Monitoramento da disponibilidade

Assegurar alta disponibilidade deve ser uma das prioridades mais importantes de qualquer fornecedor de SaaS. Uma interrupção que afeta um único servidor ou centro de dados pode resultar em perdas de produtividade e de dados significativos para uma grande porcentagem dos clientes e talvez para a base de clientes inteira! Para os ISVs que estão mudando para SaaS a partir de uma experiência em desenvolvimento de software cliente-servidor ou de computador de mesa tradicional, os requisitos de alta disponibilidade de um modelo de aplicativo centrado na Web pode envolver desafios novos e incomuns. É recomendável criar suporte para técnicas básicas como monitoramento de pulsação e mecanismos de alerta no seu aplicativo, e colocar uma atenção especial em links potencialmente fracos, como uma conexão com um banco de dados em um local remoto que não está sob o seu controle.

Naturalmente, mecanismos técnicos como alertas são somente uma parte do processo de garantir alta disponibilidade, pois se um alerta for acionado e ninguém responder, não se pode realmente dizer que ele seja parte do processo de forma alguma. Tenha certeza de haver processos estabelecidos no seu centro de operações que indiquem cursos de ação específicos e padrões a alcançar no caso de uma falha de sistema.

Para ter uma visão geral dos problemas que cercam a alta disponibilidade, consulte "Service Management Functions: Availability," um artigo na Microsoft TechNet (http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfavamg.mspx).

Monitoramento do desempenho

Os seus clientes esperam que você lhes forneça acesso ao aplicativo a um nível de desempenho aceitável. Em certa medida essa expectativa será tornada explícita pelos SLAs que você concorda em honrar como parte do seu contrato com o cliente. Além dos SLAs, no entanto, se os clientes perceberem que o seu aplicativo é lento ou não responde, muito provavelmente encerrarão a assinatura ou não farão a sua renovação; usuários insatisfeitos poderão expressar seu desagrado em sites da Web e nas páginas de publicações da indústria, dando uma reputação negativa ao seu aplicativo. No caso contrário, um aplicativo rápido e enxuto que atende às necessidades dos usuários irá agradar aos clientes e, se eles mudaram para o seu software vindo de um pacote de software tradicional menos responsivo, irá até mesmo torná-los mais receptivos ao SaaS como categoria.

Para garantir um alto nível de desempenho, crie suporte para contadores de desempenho no seu aplicativo diretamente, se possível. Defina limites de desempenho para métricas como utilização da CPU e tempos de resposta do aplicativo e utilize alertas para notificar o pessoal apropriado quando ocorrerem eventos de gerenciamento.

Estabelecer uma linha de base para o desempenho geralmente é a atividade mais crítica. Com uma linha de base estabelecida é muito mais fácil saber quando algo anormal está acontecendo e onde o problema se localiza.

Conclusão

Existe muito para ser dito sobre cada um dos tópicos abordados neste documento, mas esperamos que neste ponto você já tenha lido o suficiente para começar a desenvolver uma estrutura conceitual para entender o SaaS e perceber como você e os seus clientes poderão beneficiar-se dele. O SaaS representa um novo paradigma no fornecimento de software, um modelo arquitetônico criado sobre os princípios de eficiência para vários inquilinos, escalabilidade massiva e configurabilidade dirigida a metadados para fornecer software de qualidade a baixo custo para clientes existentes e em potencial. Adotar esses princípios agora pode ajudá-lo a encontrar o caminho para transformar a maneira de você capturar os negócios da longa cauda.

Comentários

Os autores agradeceriam os seus comentários (em inglês) sobre este documento. Envie seus comentários por e-mail para fredch@microsoft.com ou gianpc@microsoft.com. Obrigado.