Este artigo foi traduzido por máquina.

Windows Azure Insider

Arquitetura de aplicativos para vários inquilinos no Windows Azure

Bruno Terkaly
Ricardo Villalobos

Baixar o código de exemplo

Há um grande e vibrante ecossistema de provedores de serviços que o pacote de soluções e hospedá-los em plataformas de nuvem. Em geral, estes Software como um serviço (SaaS) usar arquiteturas de diversos clientes. Você pode encontrar muitos exemplos do mundo real no bit.ly/vIPcyc. Se você pensar nisso, a maioria das aplicações populares na Web, como Facebook ou Hotmail, é aplicações para múltiplos inquilinos. Esta abordagem faz sentido numa perspectiva de negócio porque os recursos de computação e armazenamento podem ser maximizados por compartilhá-los entre vários assinantes. Depois de tudo, um dos principais pontos de computação em nuvem é maximizar eficiências através da partilha de um grande pool de recursos de computação e armazenamento.

Recebemos perguntas frequentes relacionadas com as práticas recomendadas e padrões para a implementação de arquiteturas de diversos clientes utilizando o Windows Azure. Esta é a primeira de duas colunas que irá apresentar-lhe alguns princípios e conceitos-chave, bem como fornecer alguma orientação sobre onde você pode obter as habilidades práticas para começar até a velocidade em alguns blocos de construção do núcleo.

O conceito de software para múltiplos inquilinos é simples. É um sistema único e completo que oferece suporte a várias organizações de cliente (inquilinos), onde cada inquilino é executado com segurança em paralelo no mesmo hardware e software, completamente inconsciente que existem outros. Feito corretamente, permite que os provedores de serviços oferecer muita funcionalidade aos inquilinos, percebendo uma utilização extremamente eficiente do Windows Azure. Os inquilinos estão focados em segurança, baixo custo e bom desempenho.

Arquitetos de nuvem devem considerar cuidadosamente alguns pilares fundamentais na construção de sistemas para múltiplos inquilinos:

• Identidade e segurança
• Segregação e isolamento de dados
• Análise de medição e desempenho
• Dimensionamento acima e para baixo, mantendo os SLAs

Discutiremos aqui os dois primeiros e os dois últimos na nossa próxima coluna.

Identidade

Identidade desempenha um papel central em arquiteturas de diversos clientes. Para começar, inquilinos devem garantir que seus dados particulares não não acessíveis por outros usuários, exceto em casos onde o objetivo é compartilhar entre os assinantes. Microsoft SharePoint fornece um exemplo. Você pode ter documentos que são visíveis apenas para um determinado inquilino, mas você também pode ter alguns que são compartilhados por um grupo de trabalho (dois ou mais, inquilinos que podem abranger as organizações). A linha inferior — identidade desempenha um papel central no que diz respeito a visibilidade de dados.

No mundo de hoje, sistemas de gerenciamento de identidade devem ser interoperáveis, aderindo para abrir padrões (como mantida pela organização para o avanço de Structured Information Standards, ou OASIS), como o WS-Trust e WS-Security. Juntos, esses padrões permitem sistemas de diversos clientes avaliar a presença de e corretor de confiança, relações entre, inquilino e provedor em uma troca de mensagens seguras de serviços. Além disso, arquiteturas de diversos clientes normalmente oferecem suporte a vários provedores de identidade, tais como Google, Facebook, Yahoo! e Microsoft Live. Em cenários mais sofisticados, prestadores de serviços vão apoiar a identidade corporativa, como o Active Directory. Suporte para Web single sign-on (SSO) é também importante.

Gerenciamento de identidade baseada em declarações

É geralmente aceite que abordagens baseadas em reivindicações para o gerenciamento de identidades fornecem o maior valor. Para começar, abordagens baseadas em reivindicações centralizam as diferentes partes da identidade em um único token abstrato composto de créditos e um emissor ou autoridade. O valor de tais abordagens é que eles são baseados em padrões abertos e são altamente interoperáveis. Gerenciamento de identidade baseada em declarações permite que os provedores de serviços desassociar aplicativos a partir do código de encanamento vasto, baixo nível de gerenciamento de identidades. Suporte a padrões de serviços Web (WS-Trust, WS-Federation, WS-Security), formatos de token (Security Assertion Markup Language [SAML], JSON Web chave [JWK], simples Web Token [SWT]) e criptografia (x. 509) não é trivial. Afinal de contas, estas normas estão evoluindo constantemente, para que encapsular e abstrair o gerenciamento de identidade são crucial.

A resposta a todos estes desafios é o Windows Azure ativo diretório acesso controle de serviço (ACS), que simplifica radicalmente a implementação de um sistema de gerenciamento de identidade baseada em declarações. O ACS remove este encanamento de baixo nível e fatores-lo fora do código do provedor de serviços, tornando-se relativamente fácil de implementar um sistema de gerenciamento de identidade baseada em declarações. O que faz com que o ACS tão poderoso é que muito do trabalho pode ser feito através do portal na Web. O ACS simplifica enormemente o provisionamento de novos inquilinos.

Isso significa que você, desenvolvedor, não precisa lidar com as muitas complexidades do gerenciamento de identidades dentro de seu aplicativo. O ACS resolve problemas de difícil, demorada, tais como:

• Como redirecionar solicitações não autenticadas para o provedor de identidade escolhida
• Como validar o token de entrada emitido pelo provedor de identidade
• Como analisar o token de entrada (leia as declarações)
• Como implementar verificações de autorização
• Como transformar símbolos adicionando, removendo ou alterando os tipos de créditos e valores

Recomendamos que você execute através de um par de tutoriais na Web para começar. Você encontrará um bom na autenticação de usuários em bit.ly/uyDLkt. Se você estiver executando o Visual Studio 2012, cargo quatro partes de Vittorio Bertocci bit.ly/12ZOwN9 fornecerá a orientação necessária. O ferramental Visual Studio continua a melhorar, liberando os desenvolvedores de edição manual de arquivos de configuração. Você pode baixar o ferramental e SDKs de bit.ly/NN9NVE.

Figura 1 retrata a experiência de um inquilino com suporte para vários provedores de identidade.

Figura 1 apoio de vários provedores de identidade

Figura 2 representa o que realmente acontece quando você faz uso do ACS. Os inquilinos estão completamente inconscientes que o ACS está fazendo todo o trabalho nos bastidores. O fluxo de trabalho que você vê em Figura 2 termina com o seu aplicativo para múltiplos inquilinos recebendo uma segurança token, normalmente em formato de SAML 2.0. A verdadeira beleza é que o token que recebe de seu aplicativo para múltiplos inquilinos foram padronizado, independentemente do provedor de identidade escolhido pelo inquilino. O ACS corretores de forma transparente a transformação do formato de token específico do provedor uma identidade para um formato de token que você especificar no portal ACS.

Figura 2 Visão geral do Portal do serviço de controle de acesso

Há em JavaScript que consulta o ACS para a lista de provedores de identidade você deseja que seu aplicativo para oferecer suporte, e, em seguida, gera os links de login para cada provedor de identidade. Todos os redirecionamentos necessários para obter um token de segurança padrão para seu aplicativo são manipulados pelo sistema. A "terceira parte" é simplesmente seu aplicativo de diversos clientes, como a aplicação de diversos clientes depende de um emitente para fornecer informações sobre a identidade.

Se você percorrer os tutoriais mencionados anteriormente, você verá a tela mostrada na Figura 3. A parte de introdução do portal ACS é dividida em quatro seções, simplificando o processo de integração do gerenciamento de identidades em um aplicativo baseado em nuvem, para múltiplos inquilinos. Secção 1 permite que você selecione uma lista os provedores de identidade que você deseja oferecer suporte. Para este passo a passo, nós escolheremos o Google, Microsoft Live ID e Yahoo! como os provedores de identidade. Com um pouco de trabalho extra, você também poderia incluir identidades do Facebook e do Active Directory. Secção 2 é onde ocorre a ligação. É onde você vai especificar a URL para que o ACS retorna o token de segurança, normalmente a página inicial do aplicativo. Afinal, o ACS precisa passar um token para o formato que é necessário um ponto de extremidade. Seção 2 você também especificar o formato desejado do token.

Figura 3 o Portal do Windows Azure ACS

Seção 3 é onde você seleciona as reivindicações você deseja que o provedor de identidade para incluir no token de segurança. A terceira parte confiável (aplicação de diversos clientes do prestador de serviços) vai usar esses créditos para ambos identificam um inquilino e autorização de fazer decisões, definir privilégios do inquilino dentro do serviço. As declarações disponíveis variam de acordo com o provedor de identidade; Google é diferente do Windows Live, por exemplo. Com o Google e Yahoo!, as declarações no token podem incluir o endereço de email, nome de usuário, nome de nameidentifier e provedor. Para Microsoft Live ID, no entanto, você recebe apenas o nameidentifier e o provedor de nome, não o e-mail ou nome de usuário. Você vai precisar lidar com as sutilezas dentro do aplicativo.

Secção 4 permite integrar alguns metadados e o código ao serviço. Isso é feito dentro do Visual Studio de ferramentas. Você precisa de metadados dentro dos arquivos de configuração do aplicativo para ligar o aplicativo para o ACS. O trabalho feito com ferramentas Visual Studio 2012 isso torna passo a experiência uma ponto-e-clique, Considerando que com Visual Studio 2010 você precisará editar manualmente a sytem.web seção do Web. config.

Recentemente, a Microsoft lançou Windows Azure Active Directory, que permite que você tire proveito de SSO da Web com suas linha de negócios (aplicativos LOB), no local e na nuvem. Se seu objetivo é implementar o gerenciamento de identidades em um aplicativo de LOB, onde o aplicativo é executado no local e na nuvem, você vai querer ler a informação no bit.ly/157yVPR. A documentação ilustra como o Active Directory do Windows Azure pode tomar um aplicativo LOB existente e torná-lo disponível para outros administradores de locatários de Active Directory do Windows Azure usar em suas organizações.

Bertocci blog post (mencionados anteriormente) leva você para a tela em Figura 4, que mostra que a identidade e acesso podem ser usado para adicionar código de configuração do aplicativo para múltiplos inquilinos. Visual Studio 2012 elimina completamente a necessidade de editar manualmente os arquivos de configuração. Como você pode ver, selecionamos três provedores de identidade e definido o Reino e retornar a URL para a aplicação de diversos clientes. O Reino é simplesmente um URI que identifica o aplicativo, o usuário é acessar a. Este URI também permite que você associe as reivindicações para a aplicação e os endereços para resposta. Você vai mudar o Reino e URL de retorno, uma vez que você implanta o aplicativo em um datacenter da Microsoft. Finalmente, você vai adicionar uma chave de gerenciamento que você obter o portal ACS-tokens de sinal digital para fins de segurança.

Figura 4 a identidade de Visual Studio 2012 e a caixa de diálogo acesso

Adicionar código para o aplicativo

Aplicativos para vários inquilinos precisam manter o usuário conectado para armazenamento permanente. Isto é inicialmente necessário para o processo de provisionamento, mas também pode ser necessário se o inquilino atividade está sendo controlada. O armazenamento de dados usado neste artigo é Windows Azure SQL banco de dados, mas você pode facilmente alterá-lo para Windows Azure tabelas e poderia incluir também os armazenamentos de dados locais. No método Page_Load do arquivo Default.aspx.cs, podemos facilmente ler o token de segurança e analisar as reivindicações, como visto aqui:

protected void Page_Load(object sender, EventArgs e)
{
  // Grab the ClaimsIdentity object. Think of it as a token
  // and set of claims for the currently logged in user.
  ClaimsIdentity ci =
    Thread.CurrentPrincipal.Identity as ClaimsIdentity;
  // Create a TenantTokenManager object that parses the claims.
  TenantTokenManager tenantTokenManager = new TenantTokenManager(ci);
  // Save logged in user to persistent storage.
  tenantTokenManager.SaveTenantToDatabase();
}

Para encapsular essa lógica, vamos adicionar uma classe TenantTokenManager para nosso projeto de nuvem, mostrado em Figura 5.

Figura 5 da classe de TenantTokenManager

public class TenantTokenManager
{
  // Claims that uniquely identify tenants.
  public System.Security.Claims.ClaimsIdentity SecurityToken { get; set; }
  public string IdentityProviderName                         { get; set; }
  public string IdentityProviderNameIdentifier               { get; set; }
  public string IdentityProviderEmail                        { get; set; }
  public string TenantId                                     { get; set; }
  public string TenantName                                   { get; set; }
  public TenantTokenManager(System.Security.Claims.ClaimsIdentity ci)
  {
    try
    {
      // Save a copy of the ClaimsIdentity security token.
      this.SecurityToken = ci;
      // Extract the provider name (Yahoo, Google, Microsoft Live).
      IdentityProviderName = (from c in ci.Claims
        where c.Type ==
        "https://schemas.microsoft.com/accesscontrolservice/
        2010/07/claims/identityprovider"
        select c.Value).SingleOrDefault();
      // Extract the nameidentifier (a unique identifier of
      // a tenant from the identity provider).
      IdentityProviderNameIdentifier = (from c in ci.Claims
        where c.Type ==
          "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
        select c.Value).SingleOrDefault();
      // Extract the emailaddress (not available in Microsoft Live ID).
      IdentityProviderEmail = (from c in ci.Claims
        where c.Type ==
          "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
        select c.Value).SingleOrDefault();
      // Create a unique TenantId based on nameidentifier
      // and provider name.
      TenantId =
        IdentityProviderName + "-" + IdentityProviderNameIdentifier;
      // Extract name from security token (not available
      // from Microsoft Live ID).
      TenantName = SecurityToken.Name == 
        null ? "Not Avail." : SecurityToken.Name;
    } catch (Exception ex) { throw ex; }
  }
  public void SaveTenantToDatabase() {
   IdentityDataStore.SaveTenantToDatabase(this); 
  }
}

O TenantTokenManager classe encapsula duas funções importantes.Primeiro, ele analisa as declarações do token de segurança.No nosso caso, o formato do token é SAML, mas poderia facilmente ser JWT ou SWT.Note que a simples consultas LINQ podem ser usadas para extrair declarações individuais do token.E observe no código que para Microsoft Live ID, você não pode obter quaisquer dados nome ou e-mail.Neste caso, os valores nulos irão retornar da consulta LINQ .Comentários no código explicam o que significam que as reivindicações.Nós também Adicionamos suporte para salvar para o TenantTokenManager usando o método de SaveToDatabase, para que os inquilinos podem ser configurados e controlados.

O próximo passo lógico na aplicação é tomar decisões de autorização com base na identidade ou a associação de função de identidades.Por exemplo, como mostrado na Figura 6, o procedimento armazenado retornará apenas os registros baseados em TenantId.Isso ilustra como você pode começar a pensar sobre o isolamento de dados e de segregação.

Figura 6 procedimento armazenado que retorna registros com base na TenantId

    CREATE PROCEDURE [dbo].[GetTenantData]
      @TenantId nvarchar(max)
    AS
    BEGIN
      SELECT
        [id],
        [TenantId],
        [TenantName],
        [ProviderName],
        [NameIdentifier],
        [Email],
        [SomeTenantData1],
        [SomeTenantData2]
      FROM TenantRecords
      WHERE TenantId = @TenantId
      return;
    END

Segregação e isolamento de dados

Quando se trata de combinar identidade com dados em um sistema com vários locatários, há uma série de problemas para resolver. Em primeiro lugar, o arquiteto deve descobrir como manter os dados confidenciais, completamente isolados de outros inquilinos. Obviamente, você não pode permitir que coisas como números de cartão de crédito, números de CPF, e-mail e assim por diante para ser comprometida de alguma forma. Cada inquilino deve absolutamente garantir que seus dados são mantidos longe de olhares indiscretos. Ao mesmo tempo, dados podem também precisam ser compartilhados entre os inquilinos, como o compartilhamento de calendários, fotos ou mensagens de texto simples. Outro problema a resolver é o provisionamento de trilhas de auditoria, através do qual os prestadores de serviços podem controlar os padrões de uso e login de inquilinos. Isso permite que as organizações controlar as alterações feitas por usuários de nível de administrador para ajudar a resolver o comportamento inesperado do aplicativo.

Em qualquer sistema multi-inquilino, há o desafio técnico para permitir que o provedor de serviços maximizar a eficiência de custo, proporcionando inquilinos com bom desempenho e flexível de serviços de dados e modelos de dados. Esse desafio é especialmente difícil devido a enorme variedade de tipos de dados. Considere que Windows Azure só oferece suporte a uma infinidade de opções de armazenamento, tais como tabelas, blobs, filas, banco de dados SQL, Hadoop e muito mais. O desafio técnico para o provedor de serviços é significativo, porque cada tipo de armazenamento é muito diferente. Necessidade de arquitetos de equilíbrio entre custo, desempenho, escalabilidade e, em última análise, as necessidades de dados dos inquilinos.

Vamos dar uma rápida olhada nas quatro tipos comuns de armazenamento do Windows Azure. BLOBs são usados para armazenar dados não estruturados, texto e binário. Normalmente, blobs são imagens, áudio ou outros objetos multimídia, embora às vezes binário código executável é armazenado como um blob. Filas são usadas para armazenar mensagens que podem ser acessadas por um inquilino. Eles fornecem o sistema de mensagens confiável com as instâncias de escaladas do aplicativo para múltiplos inquilinos. Tabelas oferecem recursos NoSQL para aplicativos que exigem armazenamento de grandes quantidades de dados não-estruturados. Finalmente, banco de dados SQL fornece um banco de dados relacional, completo como um serviço (DBaaS) para aplicativos que precisam isto.

BLOBs estes são comparativamente fáceis de entender em relação ao Windows Azure tabelas ou banco de dados SQL. Você pode ler mais sobre blobs no bit.ly/VGHszH. Uma conta de Windows Azure pode ter muitos recipientes de blob. Um recipiente de blob pode ter muitas bolhas. A maioria dos provedores de serviços terá mais de uma conta. A abordagem típica é para designar um nome de contêiner para cada inquilino. Isso lhe dá a capacidade de definir direitos de acesso, medir o desempenho e quantificar o consumo do serviço de blob. Recentemente, a Microsoft tem revisto sua topologia de rede para melhorar drasticamente a largura de banda entre recursos de computação e armazenamento para suportar velocidades de rede de nó de armazenamento até 10Gbps. Leia mais sobre isso em bit.ly/PrxhAW.

Convenções de nomenclatura para blobs podem forçá-lo a manter um mapa de nomes de recipiente para TenantIds. Você pode usar endereços de email, pois eles são únicos, mas o Windows Live ID não fornece essa reivindicação dentro do token de segurança. Google e Yahoo!, você precisa remover o "@" sinal e "." como recipientes de blob só podem conter letras, números e traços.

O código em Figura 7 demonstra uma abordagem de provisionamento em contentores de blob. Este código pode ser parte do processo de inscrição e configuração de um inquilino. Observe que o TenantId é usado como o nome do contêiner. Em um cenário do mundo real, é claro, provavelmente haveria algum tipo de tabela de pesquisa para fornecer nomes de contêiner com base no TenantIds. O código em Figura 7, o provedor de serviços optou-se por ter uma conta separada do Windows Azure (AccountTenantImages) para armazenar as imagens dos inquilinos. Observe o código "blobClient.GetContainerReference(tm.TenantId),"que é onde um recipiente de blob é provisionado para um novo inquilino.

Figura 7 o provisionamento de um recipiente de Blob para um inquilino

// Grab the ClaimsIdentity object. Think of it as a token
// and set of claims for the currently logged in user.
ClaimsIdentity ci =
  Thread.CurrentPrincipal.Identity as ClaimsIdentity;
// Parse the claim.
TokenManager tm = new TokenManager(ci);
// Retrieve storage account from connection string.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
  Microsoft.WindowsAzure.CloudConfigurationManager.GetSetting(
  "AccountTenantImages"));
// Create the blob client.
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
// Retrieve a reference to a container.
CloudBlobContainer container = blobClient.GetContainerReference(tm.TenantId);
// Create the container if it doesn't already exist.
container.CreateIfNotExists();

Outro ponto importante é que os blobs suportam metadados definidos pelo usuário, o que significa que cada blob pode suportar um ou mais pares de nome-valor. No entanto, armazenamento de blob não permite consultar os blobs em seus metadados globalmente. Para localizar informações em metadados, você tem duas opções. O primeiro é buscar todos os blobs de um recipiente de blob e, em seguida, enumerar sobre eles, procurando os pares nome-valor. A abordagem mais escalonável é para armazenar metadados no armazenamento de tabela, juntamente com a URL do blob. Essa abordagem permite que você consulta o armazenamento de tabela para encontrar o blob desejado e, em seguida, recuperar o blob de armazenamento e consulta de metadados diretamente a partir de um único blob.

Filas de porque as filas são normalmente usadas como mecanismos para fornecer confiança, assíncrona de mensagens dentro de aplicações para múltiplos inquilinos, inquilinos estão geralmente isolados deles. Com isso dito, uma conta tem muitas filas e filas têm muitas mensagens. É concebível, o arquiteto da nuvem pode provisionar uma fila separada para cada inquilino. Mas esta decisão seria baseado nas necessidades específicas do app para múltiplos inquilinos. E lembre-se que esta abordagem não pode escalar bem e poderia se tornar difíceis de gerenciar como o número de inquilinos sobe além dos 100.

Tabelas há muitas opções de isolamento e segregação de dados disponível no Windows Azure tabelas. Por exemplo, o provedor de serviços pode configurar uma conta de armazenamento por inquilino. Porque cada conta de armazenamento aparece como um item de linha em sua conta do Windows Azure, esta abordagem pode ser útil se você deseja identificar os custos precisos por inquilino. Outra opção é combinar vários inquilinos em uma conta de armazenamento único. Esta abordagem permite aos inquilinos do grupo por região geográfica, por requisitos regulamentares e, potencialmente, por requisitos de replicação. No entanto, você ainda precisará de camada em um esquema de particionamento para os inquilinos dentro de uma conta não tem acesso a dados de outros inquilinos — a menos, claro, estratégias de compartilhamento de dados são desejadas. Uma abordagem para hospedagem de múltiplos inquilinos em uma única conta é incluir o TenantId no nome da tabela e dar sua própria cópia das tabelas de cada inquilino.

No entanto, outra abordagem é colocar vários inquilinos em uma única tabela, caso em que você provavelmente usaria chaves de partição interna de uma tabela e chaves de linha para manter dados dos locatários separam uma da outra. É comum usar o TenantId como a chave de partição porque que ele cresce bem, proporcionando o desempenho de consulta excelente.

O código em Figura 8 demonstra como vários inquilinos podem compartilhar uma única tabela. O código ilustra como um inquilino pode recuperar um email endereço e número de telefone usando o Windows Azure tabelas. Observe que o PartionKey é essencialmente a TenantId, que pode ser derivado as credenciais de logon, diretamente ou através de outra tabela de pesquisa.

Figura 8 segregar dados no Windows Azure tabelas usando um PartionKey e uma RowKey

// Grab the ClaimsIdentity object. Think of it as a token
// and set of claims for the currently logged in user.
ClaimsIdentity ci =
  Thread.CurrentPrincipal.Identity as ClaimsIdentity;
// Parse the claim.
TokenManager tm = new TokenManager(ci);
// Retrieve storage account from connection string.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
  Microsoft.WindowsAzure.CloudConfigurationManager.GetSetting(
  "AccountTenantTables"));
// Create a cloud table client object.
CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
// Create an email address table object.
CloudTable emailAddressTable =
  tableClient.GetTableReference("EmailAddressTable");
// Set up the filter for the partition key.
string pkFilter = TableQuery.GenerateFilterCondition("PartitionKey",
  QueryComparisons.Equal, tm.TenantId);
// Set up the filter for the row key.
string rkFilter = TableQuery.GenerateFilterCondition("RowKey", 
  QueryComparisons.Equal, tm.IdentityProviderName);
// Combine the partition key filter and the Row Key filter.
string combinedFilter = TableQuery.CombineFilters(rkFilter,
  TableOperators.And, pkFilter);
// Construct a query.
TableQuery<EmailAddressEntity> query =
  new TableQuery<EmailAddressEntity>().Where(combinedFilter);
// Execute the query.
EmailAddressEntity emailAddressEntity =
  emailAddressTable.ExecuteQuery(query).First();
// Pull the data out that you searched for;
// do something with emailAddress and phoneNumber.
string emailAddress = emailAddressEntity.EMailAddress;
string phoneNumber = emailAddressEntity.PhoneNumber;

Conclusão

Arquitetura de aplicativos diversos clientes requer uma boa compreensão das questões de identidade e dados de isolamento e segregação.Prestadores de serviços podem isolar-se de ter que escrever um monte do código de baixo nível encanamento relativas ao gerenciamento de identidade, tirando partido do ACS.Uma aplicação para vários inquilinos pode suportar uma variedade de provedores de identidade e evitar o obscurecimento de sua base de código com algumas das técnicas fornecidas aqui.Além disso, gerenciamento de identidade robusta simplifica o trabalho leva a isolar ou compartilhar dados do inquilino.

Na coluna do próximo mês, nós vou abordar os outros pilares fundamentais de arquiteturas de diversos clientes, análise de medição e desempenho e dimensionamento.Entretanto, recomendamos que os leitores interessados em obter mais informações leia "Aplicações Multi-Tenant em desenvolvimento para a nuvem, 3ª edição," disponível em bit.ly/asHI9I.

Bruno Terkaly é desenvolvedor e divulgador da Microsoft. Seu profundo conhecimento é fruto de anos de experiência no campo, escrevendo código com uma grande quantidade de plataformas, linguagens, estruturas, SDKs, bibliotecas e APIs. Ele passa seu tempo escrevendo código, escrevendo blogs e fazendo apresentações ao vivo sobre como criar aplicativos baseados na nuvem, especificamente usando a plataforma Windows Azure. Publicou dois aplicativos na Windows Store: Teach Kids Music e Kids Car Colors. Você pode ler seu blog em blogs.msdn.com/b/brunoterkaly.

Ricardo Villalobos is a seasoned software architect with more than 15 years of experience designing and creating applications for companies in the supply chain management industry. Segurando diferentes certificações técnicas, bem como um mestrado em Administração pela Universidade de Dallas, ele trabalha como arquiteto de nuvem do grupo de incubação de Windows Azure CSV para Microsoft. Você pode ler seu blog em blog.ricardovillalobos.com.

Terkaly e Villalobos conjuntamente apresentar conferências da indústria em geral; para disponibilidade, envie um e-mail no bterkaly@microsoft.com ou Ricardo.Villalobos@microsoft.com.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Patrick Butler Monterde (Microsoft) e Bhushan Nenê (Microsoft)
Patrick é um arquiteto de nuvem da Microsoft.Em sua função atual, ele é responsável pelo desenvolvimento de estratégia de nuvem e nuvem IP para o Microsoft Services.Antes deste papel, Patrick trabalhou como o Windows Azure técnico vendas mundiais onde era responsável pelo suporte a clientes de empresas globais para adotar com sucesso a plataforma Windows Azure.Patrick também trabalhou como consultor sênior em MCS, especializada em desenvolvimento de aplicativos corporativos.
Antes de ingressar na Microsoft, Patrick realizou um número de posições de desenvolvimento, gestão e arquitetura de software.Ele traz doze anos da empresa de consultoria de experiência, abrangendo vários setores, inclusive; militar, saúde, óleo e gás, governo e judiciário.Especializou-se no Windows Azure plataforma Azure SQL, .NET desenvolvimento, Microsoft SQL Servere gerenciamento de projetos.Patrick detém um B.S.em ciência da computação do Evergreen State College e um M.S.em sistemas de informação do computador da Universidade de Phoenix .Patrick Leia os último em: https://Blogs.msdn.com/b/patrick_butler_monterde/  

Bhushan Nenê lidera uma equipe de arquitetos de nuvem da Microsoft que ajuda os parceiros ISV estratégicos a desenvolver aplicativos no Windows Azure.  Bhushan publicou o número de artigos técnicos, aplicativos de referência e co-autor de um livro.  Ele apresentou também no número de eventos de nuvem.