Internet das coisas

Usando o Barramento de Serviço do Windows Azure para... coisas!

Clemens Vasters

Quando você perambula (ou navega) por uma loja de eletrônicos com um bom estoque atualmente, você encontra uma variedade enorme de “coisas” que têm a capacidade de conectá-lo a uma rede. Não pense apenas em telefones, tablets, notebooks ou desktops, ou apenas TVs, players de Blu-ray e decodificadores de sinais. Pense em máquinas de café expresso, refrigeradores e porta-retratos. Pense em abridores de portas de garagens, sistemas de ar-condicionado e alarme. Se olhar em volta e atrás de painéis de cobertura em ambientes industriais ou comerciais como seu próprio edifício de escritórios, encontrará sensores de temperatura e umidade, sensores de movimento, câmeras de vigilância e uma variedade de outras espécies de sensores ou chaves de controle dentro de equipamentos.

Muitos desses dispositivos geram dados úteis: leituras de temperatura, número de xícaras de café feitas e como o moedor foi definido, imagens infravermelho mostrando que ninguém está na sala de conferências e que as luzes podem ser desligadas. 

É fácil imaginar um cenário onde você gostaria de carregar alguns dados em uma “coisa” também, como enviar as mais recentes fotos de seus filhos (ou animalzinho) para um porta-retrato que está no aparador da vovó; ou um onde você deseja acionar uma chave à distância, mesmo se essa distância signifique apenas seu telefone conectado via rede de operadora de celular 3G/4G, para aumentar um pouco a temperatura em sua casa. De uma perspectiva de rede está a três mundos, mas da perspectiva do consumidor não há diferença considerável entre acionar a chave em casa ou enquanto está sentado em um táxi voltando do aeroporto depois de duas semanas de férias.

As oportunidades em torno de dispositivos conectados são enormes. Fornecer serviços para dispositivos com fins especiais pode de fato oferecer mais potencial de monetização para desenvolvedores de nuvem que olham o futuro do que aplicativos em dispositivos de tela com fins gerais desenvolvidos para interação humana, como telefones, tablets ou os muitos fatores forma de PC. Isso parece especialmente verdadeiro quando se combina tais serviços com tecnologias de nuvem que surgem em torno de análise de “grandes dados”

O cenário

Para o objetivo da seguinte discussão sobre arquitetura, vamos imaginar que a oferta é um Software como Serviço (SaaS) para aparelhos de ar-condicionado. Embora o cenário seja fictício, assim como todos os números, os padrões e as magnitudes são bastante próximos de cenários reais que a equipe do Windows Azure está discutindo com parceiros e clientes.

O que é legal sobre os aparelhos de ar-condicionado, de uma perspectiva de negócios, é que há uma demanda saudável e tendências de clima global indicam que não estarão fora de moda tão cedo. Menos legal é que eles devoram muita eletricidade e podem sobrecarregar a rede elétrica em regiões mais quentes, resultando em blecautes parciais.

A solução SaaS, para a qual descreverei a arquitetura, destina-se a companhias de eletricidade que procuram uma visão analítica do uso de ar-condicionado com o objetivo de gerenciamento de capacidade e por um mecanismo que permita que façam amplos ajustes de emergência nos sistemas de ar-condicionado pendurados em sua rede elétrica, quando a rede está à beira de um colapso.

A aposta é de que clientes do serviço preferem suas temperaturas ambientes ajustadas de forma forçada para um confortável 80° F/27° C, do que ter a rede elétrica cortada, deixando-os sem defesa contra as escaldantes temperaturas externas de 100° F/38°.

Vamos supor ainda que o SaaS será comparado a uma variedade de fabricantes de aparelhos de ar-condicionado para integrar o hardware e protocolos necessários. Estando os dispositivos instalados e conectados ao serviço, haverá oportunidades de vender aplicativos complementares da companhia de eletricidade ou com a marca de fabricantes através de lojas de aplicativos para celular que permitem que os clientes monitorem e controlem seus aparelhos de ar-condicionado de seus telefones ou tablets. A Figura 1 mostra uma visão geral do cenário.

Figura 1 Visão geral da solução Software como Serviço

Enquanto arquiteta a solução, você precisa acomodar duas direções gerais do tráfego de mensagens. Entrada (da perspectiva de nuvem), você precisa coletar métricas e eventos dos dispositivos, agregar os dados e direcioná-los para o sistema de análise. Saída, você precisa poder enviar comandos de controle para os dispositivos.

Cada dispositivo de ar-condicionado deve ser capaz de enviar leituras de status de umidade, temperatura e do dispositivo desde uma vez a cada hora até uma a cada 10 minutos, conforme necessário. Alterações no status do dispositivo devem também causar a geração e o envio de eventos. Comandos de controle serão muito mais raros, provavelmente não mais que um ou dois eventos por dia e dispositivo.

Para a evolução inicial, defina uma escala alvo de 250.000 dispositivos no primeiro ano, acelerando para 2,5 milhões de dispositivos depois do terceiro ano. Nessa escala, você pode esperar de 0,25 a 1,5 milhões de eventos por hora no primeiro ano e cerca de 2,5 a 15 milhões de eventos por hora no terceiro ano.

Arquitetando a solução

Você precisa abordar três importantes áreas de preocupação na arquitetura: provisionamento, fan-in de eventos e fan-out de comandos.

Provisionamento Está relacionado à instalação de novos dispositivos, atribuindo a eles uma identidade exclusiva dentro do sistema e dando a cada um uma maneira de provar a identidade. Além disso, os dispositivos devem estar associados a recursos específicos no sistema e devem receber um documento de configuração contendo todas as informações.

Fan-in de eventos Envolve o projeto do sistema de modo que possa manipular o rendimento desejado para a ingestão de eventos. 15 milhões de eventos por hora se traduz em, aproximadamente, 4.200 eventos por segundo, o que justifica pensar arduamente em como particionar o sistema. Esse é especificamente o caso quando esses eventos se originam de 4.200 fontes distintas com cada cliente conectando-se remotamente, estabelecendo uma nova sessão com latência de rede potencialmente significativa.

Como os eventos e as estatísticas resultantes de cada unidade domiciliar específica interessam não apenas no nível macro, mas também aos residentes que compram o aplicativo para celular e desejam ter gráficos de tendências precisos, você não apenas tem de enviar dados acumulados para análise, mas também descobrir como reter 360 milhões de eventos por dia.

Fan-out de comandos Diz respeito ao fluxo de comandos para os dispositivos. Os comandos podem instruir um dispositivo a mudar sua configuração ou podem ser consultas de status que mandam o dispositivo emitir um evento de status. Em casos em que a companhia de eletricidade precisa fazer ajustes gerais para diminuir a pressão na rede, eles podem querer enviar um único comando para todos os dispositivos a um só tempo e o mais rápido possível. No caso do telefone celular, em que um residente quer ajustar uma temperatura confortável, o comando é direcionado a um dispositivo específico ou a todos os dispositivos em uma unidade domiciliar.

Fan-in de eventos

A Figura 2 ilustra o layout geral do modelo de fan-in para o cenário de ar-condicionado.

Figura 2 O modelo de fan-in

O primeiro e mais óbvio aspecto da arquitetura é a presença de partições. Em vez de olhar para uma população de milhões de dispositivos conectados como um todo, você está subdividindo a população de dispositivos em partições muito menores e, portanto, mais gerenciáveis de vários milhares de dispositivos cada. Mas a capacidade de gerenciamento não é a única razão para introduzir as partições.

Primeiro, cada recurso em um sistema distribuído tem um teto de capacidade de rendimento e armazenamento. Portanto, você quer limitar o número de dispositivos associados a qualquer Tópico de Barramento de Serviço único de modo que os eventos enviados pelos dispositivos não excedam a capacidade de rendimento do Tópico, e quaisquer mensagens pendentes acumuladas temporariamente não excedam a capacidade de armazenamento do Tópico. Segundo, você deseja alocar recursos computacionais adequados e também não quer sobrecarregar o back-end de armazenamento com muitas gravações. Como resultado, você deve reunir um conjunto de recursos relativamente pequeno com características de desempenho relativamente bem-conhecidas em uma “unidade de escala” autônoma e principalmente isolada.

Cada unidade de escala dá suporte a um número máximo de dispositivos, e isso é importante para limitar os riscos em um crescimento de escalabilidade. Um bom efeito colateral de introduzir unidades de escala é que elas reduzem de forma significativa o risco de paradas totais do sistema. Se um sistema depende de um repositório de dados único e esse repositório tem problemas de disponibilidade, o sistema inteiro é afetado. Mas se, em vez disso, o sistema consistir em 10 unidades de escala, cada uma delas mantendo um repositório independente, uma falha em um repositório afetará apenas 10% do sistema.

A decisão de arquitetura mostrada na Figura 2 é que os dispositivos soltem todos os eventos nos Tópicos do Barramento de Serviço do Windows Azure, em vez de em uma borda de serviço que a solução fornece diretamente. O Barramento de Serviço do Windows Azure já fornece um gateway de serviço de rede dimensionado e seguro para mensagens, e faz sentido aproveitar essa funcionalidade sempre que possível.

Para esse cenário específico, você irá supor que os dispositivos são capazes de dar suporte a HTTPS e, portanto, podem conversar diretamente com o Barramento de Serviço do Windows Azure com seu suporte de protocolo existente. No entanto, à medida que os dispositivos ficam mais baratos e menores e têm somente alguns quilobytes de memória e um processador lento, o suporte a SSL e, portanto, HTTPS, pode se tornar um desafio significativo, e mesmo HTTP pode começar a ficar tremendamente pesado. Esses são casos em que criar e executar um gateway de rede personalizado (consulte a extrema direita da Figura2) com um protocolo do setor vertical ou personalizado é uma boa ideia.

Cada Tópico de ingestão está configurado com três assinaturas. A primeira assinatura é para um gravador de armazenamento que grava o evento recebido em um repositório de eventos; a segunda assinatura é para um componente de agregação que acumula eventos e os direciona para um sistema global de estatísticas; e a terceira assinatura é para encaminhar mensagens ao sistema de controle do dispositivo.

Como um teto de rendimento para cada um desses Tópicos, suponha uma média de 100 mensagens por segundo no nível da entidade. Considerando que você está criando e encaminhando três cópias de cada evento enviado, você pode ingerir no máximo 33 mensagens por segundo em cada Tópico. Obviamente, esse é um número defensivo (surpreendentemente). O motivo para ser muito cuidadoso é que você está lidando com dispositivos distribuídos que enviam mensagens a cada hora, e seria um pouco ingênuo supor perfeito, distribuição aleatória de envios de eventos em qualquer determinada hora. Se for suposto o cenário de pior caso de um intervalo entre eventos de 10 minutos com uma mensagem de comentário de interação de controle extra por dispositivo e hora, você pode esperar sete mensagens por hora de cada dispositivo e, portanto, arredondando, é possível conectar 50.000 dispositivos em cada Tópico.

Embora essa taxa de fluxo não seja preocupante para o rendimento do armazenamento, a capacidade de armazenamento e a de gerenciamento do repositório de eventos são preocupações. Os dados de eventos por dispositivo a uma resolução de uma hora para 50.000 dispositivos totalizam 438 milhões de registros de eventos por ano. Mesmo que você seja muito ávido sobre como empacotar esses registros e usar, digamos, apenas 50 bytes por registro, ainda assim verá 22 GB de dados de carga por ano para cada uma das unidades de escala. Isso ainda é gerenciável, mas também enfatiza que você deve ficar atento à capacidade de armazenamento e ao crescimento do armazenamento, enquanto pensa no dimensionamento das unidades de escala.

Com base na projeção de crescimento em um ano, você precisará de cinco dessas unidades de escala para o primeiro ano e 50 depois do terceiro.

Armazenando, recuperando e agregando eventos

Vamos olhar agora mais detalhadamente como os eventos de entrada serão manipulados e usados. Para ilustrar isso, estou ampliando uma das unidades de escala na Figura 3. 

Figura 3 Uma unidade de escala

As mensagens originadas dos dispositivos podem ser divididas em duas amplas categorias: respostas de controle e eventos. As respostas de controle são filtradas pela assinatura para o sistema de controle. Os eventos, contendo os status atuais do dispositivo e as leituras dos sensores, são roteadas para o gravador de armazenamento e para o agregador via assinaturas diferentes.

O trabalho do gravador de armazenamento é receber um evento da assinatura e gravá-lo no repositório de eventos.

Para armazenar eventos, o Armazenamento de tabela do Windows Azure é um excelente candidato. Para dar suporte ao modelo de particionamento, uma conta de armazenamento será compartilhada por todas as partições no sistema e terá uma tabela por partição. O armazenamento de tabela precisa de uma chave de partição para alocar linhas de dados em uma seção do armazenamento, e você usará o identificador do dispositivo para essa chave, que produzirá ótimo desempenho de pesquisa quando você precisar fornecer estatísticas históricas para plotar gráficos. Para a chave de linha, simplesmente use um carimbo de data/hora codificado como cadeia de caracteres em um formato AAAAMMDDHHMMSS compacto que produz classificação cronológica e permite consultas de intervalo para plotar gráficos. Ainda, como os dispositivos individuais nunca, nesse caso, enviarão eventos em intervalos menores que um segundo, você não precisa se preocupar com colisões potenciais. O carimbo de data/hora será derivado da propriedade EnqueuedTimeUtc da mensagem que o agente do Barramento de Serviço do Windows Azure automaticamente carimba em cada mensagem recebida; portanto, você não tem de confiar no relógio do dispositivo. Se você estivesse criando uma solução de alto rendimento em que as colisões fossem possíveis, você poderia aproveitar adicionalmente a propriedade SequenceNumber da mensagem, que é um identificador exclusivo, sequencial de 64 bits que o agente carimba em cada mensagem.

A tarefa do agregador é receber eventos de entrada e acumulá-los para que possam ser encaminhados para um dos Tópicos de estatísticas de todo o sistema que alimentam a infraestrutura de análise. Isso é feito com frequência computando médias ou somas por um conjunto de eventos por um período específico, e encaminhando apenas os valores computados. Nesse caso, você pode estar interessado em tendências em energia e leituras de temperatura por vizinhança com uma resolução de 15 minutos. Assim o agregador, em execução por duas funções da Web, cada uma vendo aproximadamente a metade dos dados, manterá um mapa de dispositivos em casas e vizinhanças, agregará dados em compartimentos por vizinhança à medida que os eventos de dispositivos chegarem, e emitirão um evento com os agregados computados a cada 15 minutos. Como cada instância de agregador consegue ver apenas a metade dos eventos, o back-end de análise por trás do Tópico de estatísticas pode ter de fazer uma agregação dos dois eventos para obter um quadro completo de toda a vizinhança.

O primeiro artigo da MSDN Magazine nessa série, “Criando a Internet das coisas” (msdn.microsoft.com/magazine/hh852591), trata do uso do Microsoft StreamInsight no contexto do dispositivo. É uma excelente ilustração do estágio de acúmulo; o exemplo descrito no artigo poderia facilmente tomar o lugar do agregador nessa arquitetura.

Fan-out de comandos, direcionando e coletando respostas

Como a Figura 4 mostra, o Sistema de Controle enviará comandos para Tópicos e os dispositivos receberão mensagens de assinaturas para fan-out de comandos.

Figura 4 O modelo de fan-out

O principal argumento para usar uma assinatura por dispositivo é a confiabilidade. Ao enviar um comando, você quer que, por fim, o comando chegue ao dispositivo, mesmo que ele esteja desligado. Portanto, você precisa do equivalente a uma caixa de correio para o dispositivo.

O custo para essa confiabilidade e flexibilidade extras é uma complexidade um pouco maior. O teto de rendimento de cada entidade que abordei também se manifesta no número de assinaturas que o Barramento de Serviço do Windows Azure permite em cada Tópico; a cota do sistema atualmente limita um Tópico a 2.000 assinaturas. Quantas assinaturas você realmente aloca em cada Tópico para o cenário de fan-out depende da taxa de fluxo desejada. O custo associado à filtragem e seleção de uma mensagem para uma assinatura pode ser visto como uma operação de cópia. Portanto, um Tópico com 1.000 assinaturas resultará em uma taxa de fluxo de uma mensagem por segundo se for suposto um rendimento por entidade de 1.000 mensagens por segundo.

Para os comandos de emergência, é preciso enviar um comando para todos os dispositivos conectados em modo de difusão. Para comandos direcionados em que um consumidor ajusta a temperatura de um dispositivo específico ou de uma casa específica via um aplicativo conectado em 3G, o ajuste deve acontecer dentro de alguns segundos.

Para descobrir se uma mensagem por segundo é também bom o suficiente para comandos direcionados, suponha que um morador ajustará ou pedirá o status atual de seu sistema de ar-condicionado muito raramente. Deve-se esperar que a maioria dos comandos ocorra durante eventos climáticos significativos. Suponha, de forma pessimista, que todo dispositivo seja ajustado uma vez a cada dia e os ajustes ocorram, geralmente, entre 7 e 19 horas. Se estiver supondo um limite de 1.000 assinaturas por Tópico para o caso de difusão, esses comandos resultariam em um requisito de 1,4 mensagens por minuto. Mesmo que todos ligassem seu ar-condicionado durante uma única hora, você estaria bem com 16 mensagens por minuto. Como resultado dessas considerações sobre escala e rendimento, limite cada Tópico de fan-out a 1.000 assinaturas, o que significa que você precisará de 50 Tópicos de fan-out para cada unidade de escala.

Você pode direcionar mensagens para dispositivos ou unidades domiciliares específicos ou emitir uma mensagem de difusão para todos os dispositivos com o uso de filtros de assinatura. A Figura 5 ilustra um filtro simples que permite mensagens que carregam uma propriedade com um DeviceId ou um HousingUnit específicos, ou que tenham a propriedade Broadcast personalizada definida como verdadeira. Se qualquer dessas condições for verdadeira, a mensagem será selecionada para a assinatura. Portanto, o sistema de controle pode usar exatamente o mesmo Tópico para mensagens de difusão e direcionadas e selecionar os destinos definindo as respectivas propriedades de roteamento na mensagem.

Figura 5 Direcionando mensagens

O sistema de controle também pode obter respostas a comandos por meio de sua assinatura no lado do fan-in na qual as respostas de comando carregam propriedades de filtro especiais que são manipuladas de forma similar.

Estrutura de namespace, provisionamento e identidades de dispositivos

O Barramento de Serviço do Windows Azure usa a noção de namespaces para organizar os recursos e para governar o acesso a eles. Os namespaces são criados via o portal do Windows Azure e são associados a uma região de datacenter específica. Se sua solução abrange diversas regiões geográficas grandes, é possível criar diversos namespaces e, então, fixar recursos e clientes a um datacenter do Windows Azure específico com a vantagem óbvia de rotas de rede mais curtas. Para essa solução poderia criar um namespace na região norte/central dos EUA (clemensv-ac-ncus-prod.servicebus.windows.net) e um na região sul/central dos EUA (clemensv-ac-scus-prod); ou poderia criar namespaces para clientes de serviços públicos específicos (clemensv-­ac-myenergy-prod). O sufixo “prod” distingue namespaces de produção de possíveis namespaces de teste em paralelo ou de preparação.

Para facilitar a configuração e o gerenciamento das unidades de escala, aproveite a estrutura hierárquica do namespace. O nome da unidade de escala, que forma o caminho básico de todas as entidades dentro da unidade de escala, poderia ser apenas um número, ou poderia estar associado a um cliente específico (/myenergy-3). Como você tem um único Tópico de ingestão, você pode colocá-lo diretamente abaixo (/myenergy-3/fan-in) e, em seguida, colocar os tópicos de fan-out abaixo de um segmento separado apenas numerando os tópicos (/myenergy-3/fan-out/01). As assinaturas de fan-out dos dispositivos individuais seguem essa estrutura, usando o identificador de dispositivo como o nome da assinatura (/myenergy-3/fan-out/01/subscriptions/0123456).

Criar uma nova unidade de escala é, efetivamente, um script de gerenciamento (utilizando a API do Barramento de Serviço do Windows Azure) que cria uma nova estrutura com essa forma. As assinaturas dos dispositivos e as regras do filtro são criadas durante o provisionamento do dispositivo. Certamente, você também precisa criar, implantar e configurar o armazenamento e os recursos de computação correspondentes. Para o repositório de eventos, como observado anteriormente, você configurará uma nova tabela por unidade de escala.

Provisionar trata da integração de um dispositivo novo de fábrica ao ser instalado em uma unidade domiciliar. Para esse artigo pularei detalhes como desativação de dispositivo e apenas discutirei um modelo de provisionamento no qual os dispositivos são configurados com um identificador de dispositivo exclusivo na fábrica. O modelo alternativo seria ter dispositivos vindos da fábrica completamente não inicializados e implementar um esquema similar ao que você talvez conheça de serviços como Netflix, Hulu ou Twitter, em que o novo dispositivo entra em contato com um serviço Web para obter um código, exibe o código, e o usuário se conecta ao site de ativação digitando o código.

A Figura 6 mostra o fluxo do provisionamento de um dispositivo que tem um identificador anteriormente atribuído. A primeira etapa da configuração do dispositivo não é mostrada e trata da colocação do dispositivo em uma rede, que poderia acontecer via Ethernet com fio, Wi-Fi ou alguma rede de operadora sem fio.

Figura 6 O modelo de provisionamento

Para o provisionamento, o sistema executa um serviço Web especial que trata da definição e gerenciamento da identidade e configuração do dispositivo. O alocador de partição controla quantos dispositivos foram ativados e quais dispositivos são atribuídos a qual unidade de escala. Estando o dispositivo associado a uma unidade de escala, ele obtém o provisionamento na unidade de escala.

Na etapa 1, o dispositivo estabelece uma conexão com o serviço de provisionamento apresentando seu identificador de dispositivo. Nesse modelo, todos os identificadores de dispositivos emitidos estão em uma lista de permissão (etapa 2) que permite ativar o dispositivo uma vez. Tendo sido verificado que o dispositivo é bom para ativação, o serviço de provisionamento chama o ACS (Access Control Service) para criar uma nova identidade e chave de serviço para o dispositivo (etapa 3), e também cria uma regra de permissão “Send” para o Tópico de ingestão e uma regra “Listen” para a assinatura de fan-out criada logo depois na etapa 4. Com isso, a conta do dispositivo tem apenas e exatamente os direitos de que precisa para interagir com o sistema. Depois da etapa 4, você tem uma coleção de todos os URIs de recursos com os quais o dispositivo irá interagir, além de uma conta e chave que o dispositivo pode usar para autenticação no ACS para obter um token. Todas essas informações são colocadas na resposta à chamada de ativação do dispositivo, e o dispositivo grava isso em armazenamento de configuração permanente.

Vale a pena observar que embora uma boa quantidade de particionamento de expansão tenha sido introduzido nesse artigo, as identidades do Access Control não estão sendo particionadas no exemplo dado aqui.

Para diminuir a pressão no ACS, faça apenas com que seu cliente adquira menos tokens. A expiração padrão do token para definição de terceira parte confiável do ACS no Barramento de Serviço do Windows Azure é 1.200 segundos ou 20 minutos. Você pode discar isso até 24 horas, ou 86.400 segundos, e fazer com que o cache do dispositivo adquira tokens por esse período. Nesse caso, os dispositivos terão de adquirir um novo token somente uma vez ao dia. A única desvantagem é que não é possível revogar o acesso para o portador do token se tal token de vida longa fosse interceptado, mas para tokens restritos a enviar ou escutar entidades específicas isso parece ser um risco tolerável.

Na nuvem

Conectar “coisas” com e através da nuvem é uma área que a equipe do Barramento de Serviço do Windows Azure prestará atenção significativa durante os vários próximos anos. A arquitetura descrita neste artigo é considerada um bom início e, por exemplo, no conceito de unidades de escala, inclui preciosas práticas recomendadas da criação do próprio Barramento de Serviço do Windows Azure. Há muito espaço para otimizações em torno dos cenários de fluxo de mensagens, agregação e distribuição, não apenas em termos de capacidade, mas também para modelos de programação e configuração mais simples.

Você começará a ver algumas dessas otimizações, como encaminhamento automático, aparecer no Barramento de Serviço do Windows Azure dentro dos próximos messes, e a equipe aproveitará esses novos recursos para criar melhores abstrações que tornarão os cenários de expansão, como o descrito aqui, até mais simples de gerenciar. Distribuir eventos para milhões de dispositivos de forma oportuna sempre irá necessitar de um número significativo de recursos de sistema distintos, mas há muita mágica de abstração que você pode acrescentar para reduzir o número visível de partes móveis.

Para tornar o cenário mais tangível e mais divertido, o próximo artigo dessa série o ajudará a criar um simples ar-condicionado (sim, hardware!) da plataforma Microsoft .NET Micro Framework. Esse pequeno ar-condicionado tipo faça você mesmo conversará com um serviço back-end via Barramento de Serviço do Windows Azure que seguirá a arquitetura geral explicada aqui. Até mais.

Clemens Vasters é o principal chefe técnico na equipe do Barramento de Serviço do Windows Azure. Ele está na equipe do Barramento de Serviço desde os estágios iniciais e trabalha no roteiro de recursos técnicos do Barramento de Serviço do Windows Azure, que inclui notificações por push e sinalização em alta escala para a Web e dispositivos. Ele é também um assíduo palestrante em conferências e autor de material para cursos sobre arquitetura. Siga-o no Twitter em twitter.com/clemensv.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Elio Damaggio, Abhishek Lal, Colin Miller e Todd Holmquist-Sutherland