Este artigo inclui uma lista de itens que você deve considerar ao mover uma solução de IoT para um ambiente de produção.
Usar carimbos de implantação
Os carimbos são unidades discretas de componentes principais da solução que suportam um número definido de dispositivos. Cada cópia é chamada de carimbo. ou unidade de escala. Por exemplo, um carimbo pode consistir em uma população de dispositivo definida, um Hub IoT, um Hub de Eventos ou outro ponto de extremidade de roteamento e um componente de processamento. Cada carimbo suporta uma população de dispositivos definida. Você escolhe o número máximo de dispositivos que o selo pode conter. À medida que a população de dispositivos cresce, você adiciona instâncias de carimbo em vez de dimensionar diferentes partes da solução de forma independente.
Se, em vez de adicionar carimbos, você mover uma única instância de sua solução de IoT para a produção, poderá encontrar as seguintes limitações:
Limites de escala: sua única instância pode encontrar limites de escala. Por exemplo, sua solução pode estar usando serviços que têm limites no número de conexões de entrada, nomes de host, soquetes TCP ou outros recursos.
Dimensionamento ou custo não linear: os componentes da solução podem não ser dimensionados linearmente de acordo com o número de solicitações feitas ou a quantidade de dados ingeridos. Em vez disso, para alguns componentes, pode haver uma diminuição no desempenho ou aumento no custo uma vez que um limite tenha sido atingido. Escalar com mais capacidade pode não ser uma estratégia tão boa quanto expandir adicionando carimbos.
Separação de clientes: pode ser necessário manter os dados de determinados clientes isolados dos dados de outros clientes. Da mesma forma, você pode ter alguns clientes que exigem mais recursos do sistema para atender do que outros, e considerar agrupá-los em carimbos diferentes.
Instâncias de inquilino único e multilocatário: você pode ter alguns clientes grandes que precisam de suas próprias instâncias independentes da sua solução. Você também pode ter um pool de clientes menores que podem compartilhar uma implantação multilocatário.
Requisitos de implantação complexos: talvez seja necessário implantar atualizações em seu serviço de maneira controlada e implantar em carimbos diferentes em momentos diferentes.
Frequência de atualização: você pode ter alguns clientes que são tolerantes a ter atualizações frequentes no seu sistema, enquanto outros podem ser avessos ao risco e querer atualizações pouco frequentes para o seu serviço.
Restrições geográficas ou geopolíticas: para reduzir a latência ou cumprir os requisitos de soberania de dados, você pode implantar alguns de seus clientes em regiões específicas.
Para evitar os problemas anteriores, considere agrupar seu serviço em vários selos. Os selos operam independentemente uns dos outros e podem ser implantados e atualizados de forma independente. Uma única região geográfica pode conter um único carimbo ou vários carimbos para permitir a expansão horizontal dentro da região. Cada selo contém um subconjunto dos seus clientes.
Use back-off quando ocorrer uma falha transitória
Todas as aplicações que comunicam com serviços e recursos remotos devem ser sensíveis a falhas transitórias. Este é especialmente o caso de aplicativos que são executados na nuvem, onde a natureza do ambiente e a conectividade pela internet significam que esses tipos de falhas provavelmente serão encontrados com mais frequência. As falhas transitórias incluem:
- Perda momentânea de conectividade de rede para componentes e serviços
- Indisponibilidade temporária de um serviço
- Tempos limite que surgem quando um serviço está ocupado
- Colisões causadas quando os dispositivos transmitem simultaneamente
Estas falhas são muitas vezes auto-corretivas, e se a ação for repetida após um atraso adequado, é provável que tenha sucesso. Determinar os intervalos apropriados entre as novas tentativas é, no entanto, difícil. As estratégias típicas usam os seguintes tipos de intervalos de repetição:
- Término exponencial. A aplicação aguarda pouco tempo antes da primeira repetição e, em seguida, aumenta exponencialmente os tempos entre cada repetição posterior. Por exemplo, poderá repetir a operação após 3 segundos, 12 segundo, 30 segundos e assim por diante.
- Intervalos regulares. A aplicação aguarda o mesmo tempo entre cada tentativa. Por exemplo pode repetir a operação a cada 3 segundos.
- Repetição imediata. Às vezes, uma falha transitória é breve, talvez devido a um evento como uma colisão de pacotes de rede ou um pico em um componente de hardware. Neste caso, repetir a operação imediatamente é adequado, porque poderá ser bem-sucedida se a falha tiver sido eliminada no tempo que a aplicação demora a preparar-se e enviar o próximo pedido. No entanto, nunca deve haver mais de uma tentativa de repetição imediata, e você deve mudar para estratégias alternativas, como ações exponenciais de back-off ou fallback, se a repetição imediata falhar.
- Aleatoriedade. Qualquer uma das estratégias de repetição anteriores pode incluir um elemento de aleatorização para evitar que várias instâncias do cliente enviem tentativas de repetição subsequentes ao mesmo tempo.
Evite também os seguintes anti-padrões:
- As implementações não devem incluir camadas duplicadas de código de nova tentativa.
- Nunca implemente um mecanismo de repetição permanente.
- Nunca efetue uma repetição imediata mais do que uma vez.
- Evite usar um intervalo de repetição regular.
- Impeça múltiplas instâncias do mesmo cliente ou múltiplas instâncias de clientes diferentes de enviar repetições ao mesmo tempo.
Usar provisionamento zero-touch
O provisionamento é o ato de registrar um dispositivo no Hub IoT do Azure. O provisionamento torna o Hub IoT ciente do dispositivo e do mecanismo de atestado que o dispositivo usa. Você pode usar o DPS (Serviço de Provisionamento de Dispositivos) do Hub IoT do Azure ou provisionar diretamente por meio das APIs do Gerenciador do Registro do Hub IoT. O uso do DPS confere o benefício da vinculação tardia, que permite remover e reprovisionar dispositivos de campo para o Hub IoT sem alterar o software do dispositivo.
O exemplo a seguir mostra como implementar um fluxo de trabalho de transição de ambiente de teste para produção usando o DPS.
- O desenvolvedor da solução vincula as nuvens IoT de teste e produção ao serviço de provisionamento.
- O dispositivo implementa o protocolo DPS para localizar o Hub IoT, se ele não estiver mais provisionado. O dispositivo é inicialmente provisionado para o ambiente de teste.
- Como o dispositivo é registrado no ambiente de teste, ele se conecta lá e o teste ocorre.
- O desenvolvedor reprovisiona o dispositivo para o ambiente de produção e o remove do hub de teste. O hub de teste rejeita o dispositivo na próxima vez que ele se reconectar.
- O dispositivo se conecta e renegocia o fluxo de provisionamento. O DPS agora direciona o dispositivo para o ambiente de produção, e o dispositivo se conecta e autentica lá.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Principais autores:
- Matthew Cosner - Brasil | Gerente Principal de Engenharia de Software
- Ansley Yeo - Brasil | Gerente de Programa Principal
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.