Imagine que você tem um aplicativo que está vendendo no mercado. Você vê o aviso e percebe que Software as a Service (SaaS) em uma infraestrutura em nuvem é a maneira como o setor está orientado. Você sabe que precisa dele e seus próprios clientes podem já estar pressionando para oferecer uma versão SaaS do seu produto.

O desafio é fazer a conversão para SaaS rapidamente, de maneira eficiente e mantendo ou melhorando a lucratividade.

Há muitas diferenças que precisam ser consideradas para um aplicativo SaaS versus um aplicativo da Web regular. Algumas delas são técnicas e outras estão relacionadas à mudança no modelo de negócios ao qual uma empresa precisa se adaptar ao entregar SaaS.

Aplicativo da Web típico vs. SaaS

O SaaS tem suas características de definição centrais na habilidade de os clientes usarem um aplicativo de software em uma base de assinatura de pagamento por uso. Não precisam adquirir as licenças para o software e providenciar sua instalação, hospedagem e gerenciamento. Esses aspectos operacionais são de responsabilidade da organização que fornece o aplicativo SaaS.

Múltiplos arrendatários é a chave para SaaS de sucesso

Embora a habilidade de assinar um aplicativo seja minimamente suficiente para satisfazer os critérios básicos de SaaS, em termos práticos, não é o bastante. Na prática, um aplicativo SaaS precisa também ser um aplicativo de múltiplos arrendatários. .

Isso está muito relacionado com fatores que se resumem a ser simplesmente econômico. Os CEOs de importantes empresas de SaaS concordam, não é possível ampliar um negócio SaaS sem múltiplos arrendatários. (Veja barra lateral.)

Múltiplos arrendatários é o nível de eficiência para SaaS

A principal alavanca para eficiência vem de múltiplos clientes, a habilidade de acomodar diferentes usuários do aplicativo enquanto se faz com que pareça para cada um que possuem o aplicativo todo para si próprio. Estamos acostumados com esse conceito, uma vez que se aplica a usuários individuais em um sistema, mas é ligeiramente diferente para um ambiente SaaS. Em um aplicativo SaaS de uma empresa típico, os usuários são grupos de funcionários de uma organização em particular e essa organização é conhecida como arrendatário. Isso é similar ao que se encontraria em um aplicativo da Web simples se a organização comprasse o aplicativo; haveria um grupo de funcionários que seriam os usuários do aplicativo e a organização seria o proprietário. Em um modelo SaaS, a organização é um arrendatário, não um proprietário, mas os grupos de funcionários ainda são usuários. Cada usuário tem uma associação com um arrendatário em particular (organização) e o SaaS fornece a cada arrendatário a experiência de possuir sua própria cópia do aplicativo, que seus usuários podem utilizar.

Virtualização na nuvem aproveita SaaS

A diferença entre um aplicativo da Web simples e um aplicativo SaaS ativado para nuvem envolve dois dos maiores recursos de utilização de capacidade em TI hoje:

• Múltiplos arrendatários (que foi apresentado anteriormente).
• Virtualização de hardware.

Embora a maior fonte de eficiência de aplicativo venha de múltiplos arrendatários da arquitetura do aplicativo, a alavanca secundária para eficiência vem da virtualização de hardware. Uma nuvem faz um trabalho melhor de aproveitar o valor aumentando as percentagens de utilização de uma dada quantidade de hardware empregando tecnologia de virtualização para reduzir a capacidade não utilizada que resulta quando uma abordagem de máquina física de datacenter comum é usada.

Além disso, a nuvem oferece o potencial para realocar o hardware dinamicamente para o aplicativo com base em sua necessidade de recursos. Essa elasticidade, que pode ser no curto prazo (minutos) ou longo prazo (meses), ajuda a desvincular as decisões sobre hardware de um único aplicativo e distribuí-las sobre um grande número de aplicativos,suavizando as variações e tornando o investimento e hardware mais previsível e gerenciável.

Agora vamos ver as etapas gerais para converter um aplicativo da Web mais tradicional em um aplicativo ativado para SaaS.

Voltar para parte superior

Convertendo aplicativos da Web para SaaS

Para converter seu aplicativo para um aplicativo SaaS, é preciso fazer sete ações:

1. O aplicativo deve dar suporte a múltiplos arrendatários.
2. O aplicativo deve ter algum nível de inscrição por autoatendimento.
3. Deve haver um mecanismo de assinatura/faturamento estabelecido.
4. O aplicativo deve pode ser escalado com eficiência.
5. Deve haver funções estabelecidas para monitorar, configurar e gerenciar o aplicativo e os arrendatários.
6. Deve haver um mecanismo estabelecido para dar suporte a identificação e autenticação exclusivas de usuário.
7. Deve haver um mecanismo estabelecido para dar suporte a algum nível de customização para cada arrendatário.

Vamos observar cada um com mais detalhes.

Suporte a múltiplos arrendatários

Múltiplos arrendatários é a chave para determinar a eficiência de SaaS. Normalmente, um aplicativo dá suporte a múltiplos usuários, mas com a suposição de que todos os usuários são de uma organização. Este modelo é bom para o mundo pré-SaaS, em que uma organização comprava um aplicativo de software para uso por seus membros. Mas no mundo do SaaS e da nuvem, muitas organizações usarão o aplicativo: elas devem poder todas permitir que todos os seus usuários o acessem, mas o aplicativo deve permitir que somente os membros da própria organização acessem os dados para a organização.

Esse recurso de ter múltiplas organizações (chamado de múltiplos arrendatários na nomenclatura do SaaS), coexiste no mesmo aplicativo sem comprometer a segurança de dados para essas organizações define o aplicativo como sendo de múltiplos arrendatários.

Há diversos níveis de múltiplos arrendatários (como visto na figura após a lista):

1. Virtualização simples na nuvem em que apenas o hardware é compartilhado.
2. Aplicativo único com bancos de dados separados por arrendatário.
3. Aplicativo único e banco de dados compartilhado (maior eficiência, verdadeiramente com múltiplos arrendatários).

Pode-se argumentar que o primeiro modelo não é realmente de múltiplos de arrendatários, mas é frequentemente usado em uma nuvem com servidores de virtualização e promovido como uma forma de múltiplos arrendatários. Na realidade, ele é insuficiente e possui apenas vantagens marginais sobre o antigo modelo ASP com hardware dedicado.

O nível mais eficiente é aquele no qual os aplicativos de fato compartilham um banco de dados e a lógica de negócios do aplicativo. Alcançar isso pode ser um processo oneroso que requer alterações ao esquema de banco de dados para adicionar um identificador de arrendatário para toda tabela e visualização, bem como reescrever todo acesso SQL para adicionar os critérios de arrendatários aos filtros. Faltando um local no código onde precisa ocorrer que compromete a segurança de dados do aplicativo.

Além das instâncias de acesso de dados que ocorrem no aplicativo, pode haver outros aplicativos, como gravadores de relatório ou aplicativos de utilitário que também devem ser modificados para incluir a filtragem de arrendatário necessária para manter os dados de arrendatários individuais acessíveis apenas àqueles arrendatários em particular. O tipo de acesso que não é diretamente do aplicativo em si apresenta problemas que devem ser controlados. Se qualquer usuário autorizado puder gravar um relatório, ele deve ser impedido de acessar os dados que não pertençam ao arrendatário do qual eles fazem parte.

Inscrição de autoatendimento

Seu aplicativo deve estar disponível com algum nível de inscrição de autoatendimento, mesmo se for simplesmente um mecanismo de solicitação que resulte em um processo de negócios para adicionar um arrendatário ao aplicativo.

Assinatura e faturamento

Você deve fornecer um mecanismo de assinatura e faturamento. Uma vez que os aplicativos SaaS por design envolvem uma série de pagamentos com base em fatores como número de usuários por arrendatário, opções de aplicativo e talvez duração de uso, deve haver uma maneira de rastrear e gerenciar informações de faturamento que estejam acessíveis aos administradores do arrendatário.

Escalando e gerenciando o aplicativo

Você deve poder escalar conforme as assinaturas aumentam. A infraestrutura de nuvem é uma maneira lógica de fazer isso, uma vez que incorpora muitos recursos que serão precisos para uma escalada eficaz e eficiente.

Ainda, você deve fornecer funcionalidade de administração e gerenciamento de aplicativo para monitorar, configurar e gerenciar o aplicativo e todos os arrendatários.

ID do usuário e autenticação

Você precisa fornecer um mecanismo de suporte à identificação do usuário e autenticação que permita a identificação exclusiva dos usuários. Porque múltiplos arrendatários permite que todos os usuários que se conectam ao sistema sejam identificados para determinar a qual arrendatário pertencem, deve haver um relacionamento definitivo que permita que os usuários sejam identificados como pertencendo a um arrendatário em particular. Esse relacionamento usuário-arrendatário são as informações chave usadas para restringir os dados que podem ser acessados pelo usuário.

Os endereços de e-mail são uma maneira típica de fazer isso de modo que a singularidade seja garantida e os indivíduos possam ser reconhecidos e identificados como pertencendo a um arrendatário em particular.

Há muitos mecanismos de identificação e métodos de integração com eles, então um mecanismo flexível para permitir que um usuário seja identificado é essencial. Frequentemente é necessário que um arrendatário em particular possa utilizar seu LDAP existente ou outro serviço de diretório ou mecanismo de autenticação para dar suporte a conexão única ao aplicativo SaaS. Embora esse tipo de autenticação externa do usuário seja importante, é responsabilidade do aplicativo SaaS estabelecer que o usuário identificado seja um membro do arrendatário alegado.

Personalização por arrendatário

É preciso fornecer um mecanismo para dar suporte a um nível de personalização básica para cada arrendatário, de modo que tenha um URL único, uma página inicial, logotipos, esquemas de cores, fontes e talvez inclusive um idioma.

Esse nível básico de configuração por arrendatário é esperado, mas para verdadeiramente satisfazer as necessidades de múltiplos arrendatários, inevitavelmente haverá uma necessidade de customização por arrendatário que vai além do básico.

Customizações típicas requeridas são similares ao tipo de customizações que seriam feitas por um arrendatário com uma versão interna do aplicativo. Eles podem envolver a adição de campos ou mesmo tabelas, configurando uma lógica de negócios especial ou integração com outro aplicativo. Poder fazer esses tipos de customizações por arrendatário sem precisar estabelecer uma instância separada que comprometa a eficiência de um design de múltiplos arrendatários é o marco da arquitetura SaaS de alta capacidade.

Voltar para parte superior

Questões de desempenho a considerar

Questões de desempenho para aplicativos de múltiplos arrendatários SaaS são tipicamente os mesmos que seriam encontrados para qualquer aplicativo da Web acomodando o mesmo número de usuários com o mesmo nível de atividade. Pode haver melhores práticas para lidar com demandas de capacidade crescentes em aplicativos da Web; em geral, são todas aplicáveis a aplicativos SaaS de múltiplos arrendatários também. Essas técnicas tipicamente envolvem escala horizontal e vertical e balanceamento de carga através de um conjunto de servidores.

Escala horizontal/vertical

Recursos de infraestrutura em nuvem oferecem muitas oportunidades para fazer esse tipo de escalabilidade acontecer dinamicamente e de maneira automatizada, para fornecer os recursos quando necessário e escalar de volta os recursos quando os acordos de nível de serviço (SLAs) de desempenho puderem ser cumpridos com menos recursos. Esse recurso elástico é algo que deve ser ajustado para responder precisamente da maneira necessária para fornecer o serviço sem fornecer recursos que serão subutilizados:

• A escala horizontal normalmente é empregada para a camada do serviço de aplicativos.
• A escala vertical normalmente é empregada para a camada do banco de dados.

Armazenamento em cluster do banco de dados

Com aplicativos SaaS, o número total de usuários pode ser muito alto para um produto bem-sucedido; em algum ponto a escala vertical do banco de dados pode não ser a solução ideal. Muitas tecnologias de banco de dados têm a habilidade de fornecer um modelo de banco de dados em cluster que permite que mais capacidade seja fornecida com relação ao mesmo banco de dados. O DB2® tem diversas opções que funcionam bem com esse modelo e podem ser usadas para criar um cluster de banco de dados.

Geografia, particionamento e sincronização

Entretanto, há outras técnicas que podem ser mais adequadas, dependendo do aplicativo SaaS e da sua população de usuários. Uma vez que o SaaS é inerentemente acessível de qualquer lugar no mundo, a população de usuários pode estar distante; essa distância pode causar prejuízo de desempenho devido às longas topologias de rede.

Nesses casos, pode ser vantajoso usar nuvens que estejam em regiões diferentes e particionem os dados ou usem sincronização para manter a consistência. Qual dessas opções é adequada dependerá da natureza do aplicativo em particular. Algumas não serão receptivas a sincronizações de longa distância.

Bancos de dados separados

É claro que o método mais radical (para aplicativo SaaS, pelo menos) para usar quando a capacidade do banco de dados não puder atingir as demandas é estabelecer um banco de dados separado. Qualquer um que deseje um aplicativo SaaS de múltiplos arrendatários precisa considerar que essa opção pode levar à situação insustentável de dar suporte a um banco de dados por arrendatário, o que leva diretamente ao tipo de ineficiências que os múltiplos arrendatários busca evitar.

E se os servidores do aplicativo precisarem ser divididos para atender apenas um banco de dados, então as ineficiências de múltiplos arrendatários serão ainda mais pioradas. Em um mercado competitivo, essas eficiências de múltiplos arrendatários são fatores de sucesso cruciais para empresas SaaS.

Design resgata o poder do balanceamento de carga

Uma maneira de reter tanta eficiência quanto possível mesmo quando, por qualquer motivo, bancos de dados separados precisam ser usados, é ter um design de múltiplos arrendatários que possa permitir que qualquer um dos servidores de aplicativo no cluster de carga balanceada acesse o apropriado quando houver múltiplos bancos de dados. Desta maneira, a eficiência do cluster de carga balanceada pode ser mantida com todos os servidores de aplicativo podendo conectar-se a qualquer banco de dados para as sessões de usuário a que estão dando suporte. Isso mantém o maior nível de eficiência dentro da restrição de múltiplos bancos de dados.

Capacidade não é a única exigência

Pode haver motivos legítimos para ter múltiplos bancos de dados além de simplesmente a capacidade, como a demanda por uma versão criptografada do banco de dados para certos arrendatários de alta segurança. A capacidade pode não ser o problema, então é importante ter um design que maximize as eficiências quando possível, mesmo quando um modelo inerentemente menos eficiente for necessário.

Voltar para parte superior

Questões de segurança a considerar

Em uma pesquisa de opinião após a outra, a segurança costuma ser listada como a principal preocupação para os assinantes de aplicativos SaaS ou pelo menos uma das principais. Nenhum provedor de SaaS pode ignorar a segurança. Mas frequentemente o conceito de segurança de dados é considerado apenas dentro do contexto do aplicativo SaaS em si.

A maioria das arquiteturas de aplicativo SaaS assume medidas de segurança de dados que evitam que um arrendatário veja os dados de outro arrendatário como um requisito da linha de base.Mas:

• Um recurso crucial que os aplicativos SaaS devem considerar é integrar e interagir com outros aplicativos.
• Alguns desses outros aplicativos podem estar fora dos aplicativos (não controlado pelo provedor do SaaS).
• Nem todas as arquiteturas SaaS são projetadas com acessibilidade com aplicativos externos em mente.

Esses outros aplicativos poderiam ser aplicativos desenvolvidos pela própria empresa que precisem acessar ou compartilhar dados; poderiam ser ferramentas analíticas e de gravação de relatório que minam os dados para tendências. Mesmo ferramentas utilitárias usadas pelos administradores de bancos de dados podem ser preocupações de segurança se os arrendatários puderem usá-las para acessar, ou, pior ainda, manipular dados que não pertencem a eles.

Uma arquitetura de melhor prática para SaaS deve considerar que nem todo o acesso a dados pode estar sob controle do aplicativo; deve haver mecanismos estabelecidos para permitir que os dados sejam protegidos para cada arrendatário, não importa se o acesso é através do aplicativo SaaS ou de algum aplicativo externo.

Voltar para parte superior

Selecione sua pilha de tecnologia

Sempre há trocas quando se tomam decisões sobre pilhas de tecnologia: em um aplicativo SaaS, isso é especialmente verdadeiro porque as decisões são tomadas para todos os arrendatários. Vamos examinar algumas dessas considerações.

Considerações sobre o sistema operacional

O sistema operacional em um aplicativo da Web é provavelmente o menos relevante para os usuários porque sua interação é através do navegador. Entretanto, há considerações financeiras e técnicas que podem entrar em jogo.

• Se houver dependência de um código em particular que seja dependente do sistema operacional, então as escolhas são restringidas.
• Também pode haver uma restrição se houver uma necessidade comum de integração com aplicativos externos que seja mais bem realizada em um sistema operacional que em outro.

A economia implacável da nuvem sempre empurra a escolha em direção ao sistema operacional com as menores tarifas de licenciamento e bom desempenho. Os principais meios de escalar aplicativos da Web envolvem escala horizontal; isso significa que conforme o aplicativo SaaS cresce, o número total de instâncias de servidor de aplicativo da Web aumentará, e isso é um custo direto de operações.

Considerações do banco de dados

O banco de dados em aplicativos da Web provavelmente não é uma preocupação crucial dos usuários finais, porque suas interações sejam através do navegador e desde que o aplicativo possa armazenar e recuperar seus dados, isso é amplamente irrelevante para eles.

Novamente, considerações financeiras e técnicas entram em jogo para o desenvolvedor de aplicativos. Se houver dependência de aplicativo para recursos em particular do banco de dados, as escolhas são restringidas.

A escolha de um banco de dados pode ser importante por diversos motivos de design de aplicativo, e também pode ser afetada pelas demandas em particular do ambiente SaaS.

As demandas sobre um banco de dados são maiores em um aplicativo SaaS simplesmente devido ao número de usuários que por fim estará integrado. Então escalabilidade de banco de dados é muito importante. A escalabilidade do banco de dados normalmente é feita em uma única instância com servidores de banco de dados cada vez mais potentes usados para um aplicativo cada vez mais exigente. Mas a escalabilidade necessária de aplicativos SaaS tem o potencial de superar as habilidades da escala vertical, então a próxima etapa em escalabilidade de banco de dados envolve ter um recurso de armazenamento em cluster.

A habilidade de fazer esse tipo de armazenamento em cluster no ambiente em nuvem pode influenciar na escolha do banco de dados. Por exemplo, o DB2 pode ser selecionado por sua habilidade de executar em uma variedade de sistemas operacionais que fornecem escala vertical e por sua flexibilidade de escolhas para escalabilidade através de múltiplas instâncias de armazenamento em cluster e redundância. Por exemplo, um cluster DB2 HADR (High Availability Disaster Recovery) pode ser configurado na nuvem.

Considerações do servidor de aplicativos

A escolha do servidor de aplicativos, como as outras decisões sobre a pilha de tecnologia, também é principalmente uma decisão do desenvolvedor de aplicativo SaaS, uma vez que as interações do usuário final são apenas através do navegador. Mas pode haver diferenças importantes por diversos motivos de design de aplicativo, e também podem afetadas em função de demandas em particular do ambiente SaaS.

Aplicativos que tiram vantagem de recursos especiais ou componentes complementares de servidores de aplicativos, como o WebSphere® , precisarão usar o servidor do aplicativo na nuvem.

Os raciocínios para escolher um servidor de aplicativos normalmente são feitos em um ponto precoce no ciclo de vida do aplicativo porque o aplicativo pode se beneficiar de alguns recursos em particular ou há complementos de terceiros ou recursos de integração que são importantes ao aplicativo. Às vezes é simplesmente porque os padrões internos e o conhecimento da organização determinam o uso de componentes em particular da pilha de tecnologia.

Os pontos de decisão na seleção e configuração da pilha de tecnologia para usar em um ambiente em nuvem/SaaS envolvem equilibrar as forças técnica e econômica para obter um bom resultado.

Voltar para parte superior

Flexibilidade é a chave para a evolução da tecnologia

Ter a capacidade de tomar decisões e fazer trocas com relação à pilha de tecnologia a usar e capacidade de rever essas decisões mais tarde é um recurso valioso na arquitetura SaaS. Conforme a tecnologia muda, os principais provedores em nuvem incorporarão novos aplicativos e recursos de middleware e é uma vantagem poder adotá-los para seu aplicativo SaaS.

As arquiteturas de aplicativo SaaS que o forçam a tomar decisões que o trancam em uma pilha de tecnologia em particular comprometerão a habilidade de um aplicativo SaaS evoluir e se adaptar. Os conceitos chave de uma arquitetura orientada a serviços são idealmente adequados para fornecer a agilidade e a flexibilidade necessárias para aplicativos SaaS. Loose coupling fornece flexibilidade, e a flexibilidade possibilita evolução estratégica e tática.

No restante deste artigo, usarei o Servidor Multi-Tenant da Corent ™ para fornecer um exemplo de como converter um ™ aplicativo da Web de faturamento de software livre Java em uma versão SaaS de múltiplos arrendatários com mínimo esforço.

Voltar para parte superior

Automaticamente transformar em SaaS aplicativos com o Servidor Multi-Tenant da Corent

Os provedores de nuvem oferecem uma ampla variedade de recursos e podem acomodar quase qualquer aplicativo da Web. Transformar um aplicativo em um aplicativo totalmente SaaS de múltiplos usuários exige amplas mudanças ao código do aplicativo e reprojeto e reconfiguração do banco de dados.

O Servidor Multi-Tenant da Corent possibilita que ISVs assumam uma abordagem diferente, usando uma camada de middleware para fornecer os múltiplos arrendatários críticos (preservando, portanto, o investimento no código existente). Descreverei as quatro etapas necessárias para converter jBilling, um aplicativo da Web Java popular de software livre representativo de um aplicativo de múltiplos arrendatários típico, em uma versão SaaS de múltiplos arrendatários.

Etapa 1. Transformar o esquema de banco de da dos em um modelo abstrato

A pilha típica para um aplicativo da Web é semelhante à Figura 1; um aplicativo comunica-se com um banco de dados, frequentemente através de uma camada de persistência de dados como Hibernate.

Para transformar um aplicativo em um aplicativo de múltiplos arrendatários , o banco de dados precisa ser reprojetado para ter campos adicionais para gerenciar os dados de identificação do arrendatário que serão precisos para permitir que os dados sejam filtrados pelo arrendatário.

O aplicativo SaaS-Factory™ é usado para ler o esquema do banco de dados de aplicativo existente Ele então cria um modelo desse banco de dados, que subsequentemente é usado para gerar um novo banco de dado no MySQL que tem o campo adicional TenantID nas tabelas. Neste momento, diversas tabelas adicionais, incluindo uma para informações do arrendatário , que são usadas pelo Servidor Multi-Tenant, são criadas.

Porque o Banco de dados MetaModel tem uma aparência exatamente igual à do aplicativo original cm as mesmas tabelas e campos, o aplicativo original pode continuar a interagir com o Banco de dados MetaModel exatamente da mesma maneira que fazia com o banco de dados MySQL, O banco de dados real subjacente ao modelo pode ser gerado com o campo adicional TenantID necessário para um aplicativo de múltiplos arrendatários.

O Banco de dados MetaModel é uma abstração apenas e não detém de fato nenhum dado: é um simples modelo. Consequentemente, quando o banco de dados real é gerado, não há motivo para que não possa ser gerado em qualquer Relational Database Management System (RDBMS) suportado. Isso pode ser útil para casos em que o ISV deseja alterar a pilha de tecnologia escolhendo um RDBMS diferente, talvez DB2 para tirar vantagem de alguns recursos ou melhorar o desempenho para o aplicativo.

Etapa 2. Estender o processo de autenticação do usuário

Qualquer aplicativo SaaS de múltiplos arrendatários deve ter a habilidade de gerenciar as informações de sessão necessárias para usuários autenticados, de modo que o arrendatário ao qual pertencem possa ser estabelecido. Há muitos métodos de autenticação para aplicativos; consequentemente, qualquer aplicativo sendo convertido deve ser analisado e seus métodos e autenticação, entendidos.

A Etapa 1 mostrou como estabelecer uma tabela de arrendatário e adicionar uma tabela de usuário de modo que esse relacionamento possa ser mantido nos dados do aplicativo. A meta é implementar um método que estenda o processo de autenticação de usuário do aplicativo, de modo que, depois de um usuário ter efetuado logon, ele também é combinado com seu arrendatário correspondente e esse TenantID torna-se parte das informações da sessão.

Há muitas maneiras de fazer isso. Depende da implementação do aplicativo. Se for usado Tomcat como o contêiner do servlet do aplicativo, a autenticação gerenciada por contêiner pode ser aproveitada para iniciar uma regra de negócios que execute o Servidor Multi-Tenant para realizar uma busca do TenantID. do usuário associado. Alternativamente, um filtro do servlet pode ser empregado par detectar e então definir a variável local do encadeamento TenantID. Para este exemplo com jBilling, o aplicativo trata da autenticação diretamente validando com relação às suas tabelas de usuário. Portanto, o método usado para fornecer a autenticação aprimorada envolveu algumas mudanças simples ao código de autenticação para adicionar os processos para consultar as informações de arrendatário do usuário armazenadas nas novas tabelas.

Tendo um usuário autenticado e conhecendo o TenantID ao qual ele pertence, há informações suficientes para pode filtrar os dados de modo que apenas dados que pertencem àquele arrendatário possam ser acessados.

Etapa 3. Configurar a conexão do banco de dados

O Servidor Multi-Tenant da Corent é construído em uma arquitetura orientada a serviços que usa um Banco de dados MetaModel (descrito na Etapa 1). Esse MetaModel é usado como uma camada de abstração para modelar o banco de dados original do aplicativo e as comunicações do banco de dados do aplicativo são redirecionadas para a abstração do MetaModel, em vez de para a implementação do banco de dados real. Isso é feito simplesmente reconfigurando a conexão JDBC do jBilling para um Banco de Dados MetaModel, em vez do banco de dados MySQL real. Para aplicativos que usam Hibernate, o dialeto Corent de Hibernate é configurado.

Como um resultado dessas alterações, as chamadas do banco de dados do aplicativo agora são direcionadas para o Banco de Dados MetaModel. Esses eventos SQL são interceptados pelo Corent Agile Controller™ e então passados para o ADBC™ (Agile DataBase Connector) da Corent. O ADBC pega a instrução SQL como foi enviada pelo aplicativo para o Banco de dados MetaModel e analisa-a, então adiciona os critérios de filtro para o TenantID do usuário cuja sessão enviou o SQL (por exemplo, onde TenantID = <myTenantID>). Isso garante que a segurança dos dados no banco de dados compartilhado seja sempre estritamente mantida. Mesmo quando um aplicativo externo, como o ReportWriter conecta-se, os dados que ele pode ver ainda são restringidos àqueles adequados para o arrendatário em questão. Porque sabemos quem efetuou o login, não importa de qual aplicativo, sabemos qual arrendatário ele pertence e os filtros adequados são aplicados.

Porque a manipulação das instruções SQL é feita após terem sido enviadas para o Banco de dados MetaModel e o arrendatário do usuário é conhecido, o Corent Agile Controller pode interceptar e realizar operações mais sofisticadas, incluindo procurar processos e configurações específicos do arrendatário. É, portanto, possível realizar ações específicas por arrendatário, mesmo substituindo uma conexão de banco de dados diferente, de modo que um arrendatário poderia usar um banco de dados DB2 embora todos os outros estejam usando um banco de dados MySQL. Ou um arrendatário poderia ter manipulação de SQL adicional para restringir os dados que poderia recuperar aos registros inseridos não mais que 90 dias antes. Todas essas personalizações por arrendatário podem ser feitas através do Agile Rules Engine™ integrado no Servidor Multi-Tenant sem quaisquer alterações ao código do aplicativo original.

Toda a conversão do aplicativo jBilling foi realizada com apenas algumas pequenas alterações ao aplicativo, principalmente relacionadas a aprimorar a autenticação para incluir informações do arrendatário nas informações da sessão e para alterar a conexão do banco de dados para apontar para o servidor de Múltiplos Arrendatários. É possível ver o resumo de alterações do jBilling em um dos seguintes:

• Aplicativo original
  • Número de arquivos de origem: 897 (Java e jsp)
  • Total de linhas de código: 76.621
• Aplicativo convertido
  • Número de arquivos de origem adicionados: 2 (modelo padrão)
  • Linhas de código modificadas: menos de 100
  • Alterações da lógica de negócios do aplicativo: zero

A conversão do jBilling levou menos de uma semana, incluindo toda a análise e preparação para determinar onde o código precisava ser modificado. Muitas das alterações foram simples alterações de uma linha repetitivas em uma série de código Java para acesso do JDBC, o que é desnecessário se uma camada de persistência de banco de dados como Hibernate for usada.

Etapa 4. Implementar o novo aplicativo SaaS de múltiplos arrendatários para a nuvem

O SaaS-Factory agora pode ser usado para implementar um aplicativo SaaS para um servidor designado, incluindo servidores na nuvem.

Depois de selecionar um servidor para o aplicativo e o banco de dados, o banco de dados de destino é gerado (como um banco de dados MySQL em um servidor Windows® para nosso aplicativo jBilling) e o aplicativo do Servidor Multi-Tenant totalmente configurado é implementado como um conjunto de arquivos .WAR para o servidor de aplicativos selecionado. O Servidor Multi-Tenant funciona com qualquer contêiner J2EE moderno e foi certificado para o WebSphere Application Server.

O aplicativo implementado agora é capaz de lidar com múltiplos arrendatários. Entretanto, o aplicativo original não terá uma interface de administração e gerenciamento para gerenciar arrendatários ou monitorar um aplicativo de múltiplos arrendatários.

O SaaS-Factory também pode gerar e instalar um aplicativo parceiro chamado SaaS-Cockpit™ que fornece esses serviços de múltiplos arrendatários básicos. Tem acesso ao mesmo MetaModel Database que um aplicativo principal e tem telas de administração para fornecer arrendatários, atribuindo contas de Administradores de Arrendatários e configurando os parâmetros básicos das diversas configurações de aplicativo por arrendatário que estão disponíveis. Há também instalações de administração para monitorar e relatar arrendatários e seus usuários. Uma vez que uma das características comuns de aplicativos SaaS é a necessidade de rastrear assinaturas e faturamento de arrendatários, estão disponíveis instalações para fazer faturamento ou integração com sistemas de faturamento externos.

Esse nível de implementação é bastante básico no que concerne implementações SaaS. As características dos aplicativos permanecem intactas após tipos padrão de cenários de implementação e conversão, incluindo o uso de ferramentas de gerenciamento na nuvem para criar modelos e propagar instâncias do aplicativo, podem ser usadas para implementar uma arquitetura operacional que atenda as necessidades do aplicativo para escalabilidade, elasticidade, resiliência e redundância.

Um aplicativo SaaS típico pode ter um conjunto de servidores de aplicativos acessados através de um balanceador de carga e conectados a um servidor de banco de dados. O servidor do banco de dados em si pode ser implementado como um cluster com os servidores de banco de dados múltiplos fornecendo redundância e escalabilidade.

O IBM DB2 oferece diversas tecnologias e configurações que podem ser usadas para obter resiliência e tempos de recuperação garantidos, bem como permitindo que a carga no banco de dados seja distribuída.

• As configurações do DB2 HADR (High Availability Disaster Recovery) podem fornecer tanto resiliência de disponibilidade quanto algum balanceamento de carga através do uso do modo secundário como um banco de dados somente leitura.
• A tecnologia IBM pureScale e o Tivoli System Automation (TSA) permite um ambiente de banco de dados em cluster com múltiplos nós que compartilham a carga de processamento, mas esses têm mais restrições sobre as configurações do sistema operacional e hardware.

A tendência na disponibilidade de banco de dados e failover está se tornando mais sofisticada para aplicativos SaaS porque o número de clientes/arrendatários afetados por quaisquer indisponibilidade é maior que aquele no software no local do cliente tradicional (Figura 5).

A tendência é para recursos que possibilitem que o aplicativo execute continuamente mesmo através de reorganizações offline de dados, evoluções de esquema, atualizações de versão e variações de carga pesada. A tecnologia pureScale da IBM está migrando do mundo do z System para AIX® e Linux® e possibilitando o tipo de manipulação de capacidade e tempo de atividade anteriormente reservados para ambientes de mainframe dedicados.

Voltar para parte superior

Conclusão

A evolução do segmento de mercado da tecnologia informação para SaaS está a caminho e como você pode ter suposto, já está começando a causar algumas mudanças importantes na paisagem. A computação em nuvem está crescendo a taxas acima de qualquer outra onda de TI e SaaS é o condutor para esse crescimento. Essa transição está forçando as empresas a repensar a organização de negócios e desenvolver novas maneiras de pensar sobre a entrega de serviços em um mundo de TI centrado em nuvem. Para fornecedores de software, há uma urgência crescente de entender, preparar-se para e realizar a transição para que não sejam deixados para trás no rastro de poeira digital da história.

O modelo SaaS-on-a-cloud diferencia-se do modelo tradicional de fornecedores de software tanto em considerações técnicas quanto de negócios. Essas diferenças fazem a transição para SaaS um empreendimento de maior risco para ISVs. Para reduzir o risco e acelerar o tempo para comercializar, os ISVs podem tirar vantagem de tecnologias, produtos e parceiros comprovados para auxiliar na transição.

Agradecimentos

Contribuições, ideias e sugestões e revisões para este artigo foram generosamente fornecidas por Mike Oliver, Rob Brown, Mark Joncich, Kaiser Saeed e Feyzi Fatehi; e assistência de edição de Aimee Dean. Muito obrigado.

Recursos

Aprender

• O Criar aplicativos de múltiplos arrendatários com script usando a série WebSphere sMash ajuda a desenvolver um padrão de implementação de aplicativo de múltiplos arrendatários.
  
  
• A série Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware descreve padrões diferentes para abordar a ativação de múltiplos arrendatários em seus aplicativos.
  
  
• O clássico Securing a multitenant SaaS application fornece uma abordagem prática e viável à proteção de um aplicativo Java de múltiplos arrendatários
  
  
• Saiba mais sobre o Servidor Multi-Tenant da Tecnologia da Corent .
  
  
• Para mais sobre outras tecnologias mencionadas neste artigo:
  • Visite Java em developerWorks para mais informações sobre o uso dos contêineres J2EE Servlet e JDBC.
  • É possível fazer o download e usar o software livre jBilling do ZK.
  • Saiba como compartilhar bancos de dados com o Hibernate.
  • Descubra DB2 pureScale.
  • Aprenda mais sobre a HADR.
  
  
• Nos recursos para desenvolvedores de nuvem do developerWorks, descubra e compartilhe o conhecimento e a experiência dos desenvolvedores de aplicativos e serviços que estão desenvolvendo os seus projetos de implementação de nuvem.
  
  

Obter produtos e tecnologias

• O site IBM Smart Business Development and Test on the IBM Cloud é seu lugar para ver como começar a desenvolver seus aplicativos para a nuvem.
  
  
• Consulte olista crescente de imagens de software disponíveis no IBM Cloud.
  
  

Discutir

• Participe de um grupo de computação em nuvem na comunidade do developerWorks.
  
  
• Leia todos os ótimos blogs em nuvem na comunidade do developerWorks.
  
  
• Participe dos comunidade do developerWorksuma rede profissional e conjunto de ferramentas comunitárias para conectar, compartilhar e colaborar.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Aplicativo da Web típico vs. SaaS
• Convertendo aplicativos da Web para SaaS
• Questões de desempenho a considerar
• Questões de segurança a considerar
• Selecione sua pilha de tecnologia
• Flexibilidade é a chave para a evolução da tecnologia
• Automaticamente transformar em SaaS aplicativos com o Servidor Multi-Tenant da Corent
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais