Migrar ambientes do IoT Core

Last reviewed 2023-02-01 UTC

O Google anunciou a descontinuação do IoT Core. Este documento tem como objetivo ajudar você a traçar e implementar um plano de migração de um ambiente baseado no IoT Core para um novo ambiente que não depende do IoT Core para nenhum dos seguintes casos:

  • Autenticação de dispositivos de borda
  • Gerenciamento de dispositivos de borda
  • Comunicação entre seus dispositivos de borda e o Google Cloud

O documento também fornece orientações para avaliar a oportunidade de migrar após a descontinuação do IoT Core e se você quiser conhecer a migração.

Este documento faz parte de uma série de documentos que fornecem informações sobre arquiteturas de IoT no Google Cloud e como migrar do IoT Core. Os outros documentos desta série incluem:

A carga de trabalho a ser migrada

Neste documento, pressupomos que as cargas de trabalho que você quer migrar do IoT Core tenham as seguintes partes:

  • Uma parte executada em dispositivos de borda (implantada nas bordas do ambiente e ao lado dos dados que você quer processar)
  • Um back-end executado no Google Cloud

Confira no diagrama a seguir a arquitetura de uma carga de trabalho típica que usa o IoT Core. Nesta arquitetura, o Cloud IoT integra dispositivos de borda que têm um back-end executado no Google Cloud.

Fluxo de eventos de dispositivos de borda para o Cloud IoT (resumidos no texto a seguir).

O diagrama anterior pode ser resumido da seguinte forma:

Para planejar sua migração com eficiência, recomendamos que você faça uma avaliação para entender completamente a arquitetura do ambiente de origem. Nesse caso, o ambiente de origem é o ambiente atual baseado no IoT Core.

Neste documento, pressupomos que você possa atualizar a configuração e os componentes de software em execução nos dispositivos de borda para sua migração. Em alguns casos, essa abordagem pode ser inviável. Por exemplo, seus dispositivos de borda ou seus processos de implantação podem não ser compatíveis com esse caso de uso. Nesse caso, recomendamos que você planeje a desativação dos dispositivos de borda que não são compatíveis com atualizações. Para mais informações sobre como projetar e implementar processos automatizados de provisionamento e configuração para dispositivos de borda, consulte Práticas recomendadas para provisionar e configurar automaticamente sistemas e servidores de borda e bare metal.

Projetar a migração

Para migrar o ambiente baseado em IoT Core, recomendamos que você siga o framework de migração descrito em Migração para o Google Cloud.

No diagrama a seguir, descrevemos o caminho da sua jornada de migração:

Caminho de migração com quatro fases.

Como mostrado no diagrama anterior, a jornada tem quatro fases:

  1. Avaliar: nesta fase, você avalia o ambiente de origem e as cargas de trabalho e os dispositivos de borda que quer migrar do Cloud IoT Core.
  2. Planejar: nesta fase, você cria a infraestrutura básica no Google Cloud, como o provisionamento da hierarquia de recursos e a configuração do acesso à rede.
  3. Implantar: nesta fase, você implanta a nova solução em vez do IoT Core e migra os dispositivos de borda para a nova solução.
  4. Otimização: nesta fase, você otimiza o ambiente de destino. Nesse caso, o ambiente de destino se refere ao ambiente para o qual você está migrando que não é baseado no IoT Core.

Avaliar o ambiente de origem e as cargas de trabalho

Na fase de avaliação, você coleta informações sobre o ambiente de origem, os dispositivos de borda e o uso do IoT Core na sua organização. Essas informações ajudam a projetar um plano de migração e garantir que você tenha os recursos necessários para a migração e seu ambiente de destino.

Na fase de avaliação, faça o seguinte:

  1. Crie um inventário dos dispositivos de borda registrados para o Cloud IoT Core.
  2. Crie um inventário das cargas de trabalho de back-end que se integram ao Cloud IoT Core.
  3. Categorize seus dispositivos de borda e cargas de trabalho de back-end.
  4. Testar e projetar provas de conceito
  5. Calcular o custo total de propriedade
  6. Projete a arquitetura do ambiente de destino.
  7. Escolha os dispositivos de borda e as cargas de trabalho de back-end para migrar primeiro.

No final da fase de avaliação, você tem dois inventários: um para os dispositivos de borda e outro para as cargas de trabalho de back-end.

Para evitar inconsistências, recomendamos pausar a implantação de novos dispositivos de borda e cargas de trabalho de back-end antes de criar esses inventários. Também recomendamos que você não implante novos dispositivos de borda e cargas de trabalho em segundo plano depois de criar os inventários.

Criar um inventário dos seus dispositivos de borda

Para definir o escopo da migração e projetar o plano de migração, é preciso saber quantos dispositivos de borda existem no ambiente de origem. Você também precisa entender como os dispositivos interagem com o IoT Core e se é possível categorizá-los por características comuns, por comportamento, por finalidade ou por dependências.

Cada dispositivo de borda que você registra no IoT Core pertence a um registro do IoT Core. A primeira etapa para criar o inventário dos dispositivos de borda é listar os registros do IoT Core criados. Em seguida, colete informações sobre os dispositivos de borda registrados em cada registro.

Para criar o inventário dos dispositivos de borda, considere as seguintes informações para cada dispositivo de borda e como o dispositivo se integra ao IoT Core:

  • Identificadores: colete as seguintes informações sobre os identificadores do IoT Core do dispositivo de borda:

    • O identificador definido pelo usuário
    • O ID não editável definido pelo servidor que o IoT Core gera automaticamente quando você registra um dispositivo de borda no IoT Core
    • O nome do recurso que identifica exclusivamente o dispositivo de borda usando o identificador do registro do IoT Core em que você registrou o dispositivo de borda.

  • Estado de implantação: avalia o estado atual da implantação do dispositivo de borda. Por exemplo, o dispositivo de borda pode estar em um dos seguintes estados:

    • Ainda não foi fabricado ou está em andamento
    • Pronto para ser implantado, mas ainda não está registrado no IoT Core
    • Já implantado no site de destino e registrado no IoT Core

  • Tipo de dispositivo do IoT Core: avalie o tipo de dispositivo do IoT Core. Cada dispositivo de borda que você registra no IoT Core pode funcionar de duas maneiras. Pode ser um cliente que se conecta diretamente ao IoT Core. Ou pode ser um gateway para os clientes que você não consegue ou não quer conectar diretamente ao IoT Core.

  • Protocolo de comunicação: o IoT Core é compatível com dois protocolos para comunicação com dispositivos de borda: HTTP e MQTT. Avalie qual protocolo seus dispositivos de borda usam para se comunicar com o IoT Core. Para o protocolo MQTT, também é preciso determinar a Qualidade do Serviço em que os dispositivos de borda e as cargas de trabalho de back-end dependem.

  • Credenciais: o IoT Core autentica os dispositivos de borda usando um par de chaves e tokens de curta duração gerados com esse par de chaves. Se quiser, verifique a assinatura da parte pública do par de chaves usando um método de verificação baseado em certificado. Avalie como a autenticação do dispositivo de borda está configurada. Verifique se você está usando o mecanismo de verificação baseado em certificado do registro do IoT Core a que o dispositivo pertence.

  • Metadados do dispositivo: no IoT Core, é possível definir metadados para cada dispositivo de borda, na forma de pares de chave-valor. Por exemplo, é possível definir uma impressão digital de hardware, um número de série, informações do fabricante ou qualquer outro atributo relevante para um dispositivo de borda. É possível definir metadados ao adicionar um dispositivo de borda a um registro do IoT Core ou editar um dispositivo de borda que já esteja em um registro. Os metadados nunca são enviados de/para um dispositivo de borda pelo IoT Core. Reúna informações sobre os metadados que você definiu para o dispositivo de borda.

  • Estado do dispositivo: no IoT Core, cada dispositivo de borda pode relatar informações sobre o estado como dados estruturados ou não estruturados arbitrários. Por exemplo, um dispositivo de borda pode informar a versão do firmware em execução. Ou ele pode relatar informações sobre a integridade dele, de acordo com métricas específicas. O IoT Core publica as informações recebidas sobre o estado do dispositivo como mensagens em um tópico do Pub/Sub configurado. Avalie como seu dispositivo de borda reporta informações sobre o estado dele e em quais tópicos do Pub/Sub o IoT Core publica essas mensagens. Determine quais componentes da arquitetura dependem de informações sobre o estado do dispositivo de borda.

  • Eventos de telemetria: cada dispositivo de borda adicionado a um registro do IoT Core pode enviar eventos de telemetria como dados estruturados ou não estruturados arbitrários para o IoT Core. O IoT Core publica os eventos de telemetria recebidos como mensagens em um tópico do Pub/Sub que você configurou. Avalie como seu dispositivo de borda informa eventos de telemetria e em quais tópicos do Pub/Sub o IoT Core publica essas mensagens. Determine quais componentes da sua arquitetura dependem de eventos de telemetria informados pelo dispositivo de borda.

  • Configuração do dispositivo: no IoT Core, é possível definir a configuração de um dispositivo de borda como dados estruturados ou não estruturados arbitrários. O IoT Core também permite definir atualizações na configuração de um dispositivo como novas versões dela, que serão enviadas para o dispositivo de borda. Avalie se o dispositivo de borda recebe configurações do Cloud IoT Core e colete informações sobre todas as versões de configuração definidas.

  • Comandos: no IoT Core, os dispositivos de borda podem receber comandos do IoT Core e reagir de acordo com esses comandos. Avalie se os dispositivos de borda são compatíveis com a reação a comandos provenientes do IoT Core.

  • Atualizações de software e configuração: durante a migração, talvez seja necessário atualizar os componentes de software em execução no dispositivo de borda ou a configuração desses componentes. Avalie os mecanismos de atualização compatíveis com seu dispositivo de borda. Determina se o dispositivo também é compatível com um mecanismo de reversão para voltar a um estado conhecido se houver problemas durante essas atualizações.

  • Inatividade: durante a migração, as cargas de trabalho de back-end ou outras partes do ambiente de origem podem ficar indisponíveis. Avalie se o dispositivo de borda é compatível com a inatividade, os mecanismos substitutos e como ele se recupera após a inatividade.

Crie um inventário das cargas de trabalho de back-end que se integram ao IoT Core

Depois de criar o inventário dos dispositivos de borda, você coleta informações sobre as cargas de trabalho de back-end no ambiente de origem que se integram ao Cloud IoT Core. Uma carga de trabalho de back-end pode ser integrada ao IoT Core das seguintes maneiras:

  • Enviando comandos para dispositivos de borda e atualizando a configuração dos dispositivos de borda usando o IoT Core.
  • Se inscrevendo nos tópicos do Pub/Sub em que o IoT Core publica mensagens sobre eventos de telemetria e estado do dispositivo de borda.
  • Integrando com as APIs do IoT Core diretamente ou usando uma ferramenta de provisionamento de infraestrutura. Por exemplo, é possível usar o Terraform para provisionar registros e dispositivos do IoT Core.

Para criar o inventário das cargas de trabalho de back-end que se integram ao Cloud IoT Core, considere o seguinte para cada carga de trabalho de back-end:

  • Comandos e configuração do dispositivo: avalie se a carga de trabalho de back-end envia comandos a dispositivos de borda e se ela atualiza a configuração do dispositivo. As duas ações exigem uma integração com as APIs IoT Core.
  • Eventos de telemetria e estado do dispositivo: avalie se a carga de trabalho de back-end se inscreve nos tópicos do Pub/Sub em que o IoT Core publica mensagens sobre eventos de telemetria e estado do dispositivo.

  • Integração com outras APIs do IoT Core: avalie se a carga de trabalho de back-end interage com outras APIs IoT Core, além daquelas para enviar comandos e atualizar as configurações do dispositivo. Por exemplo, a carga de trabalho de back-end pode depender das APIs IoT Core para fazer o seguinte:

    • Criar registros do IoT Core e atualizar a configuração deles.
    • Criar dispositivos IoT Core e atualizar a configuração deles.
    • Coletar informações sobre registros e dispositivos IoT Core.
    • Usar as métricas de registro do IoT Core e os registros de atividade do dispositivo.

Categorize seus dispositivos de borda e cargas de trabalho de back-end

Depois de criar os inventários dos dispositivos de borda e da carga de trabalho de back-end, classifique os itens em cada inventário com base nas características deles. Essa categorização ajuda a criar um rascunho do plano de migração e escolher quais dispositivos de borda e cargas de trabalho de back-end migrar primeiro.

Para categorizar seus dispositivos de borda, recomendamos uma categorização com base nos tipos de interações que podem acontecer entre dispositivos de borda e cargas de trabalho de back-end. Considere os seguintes tipos de interação:

  • Quando um dispositivo de borda envia dados para cargas de trabalho de back-end usando eventos de telemetria ou informações sobre o estado do dispositivo.
  • Quando as cargas de trabalho de back-end enviam diretivas para dispositivos de borda usando comandos ou atualizações de configuração do dispositivo.

Para cada um dos tipos de interação anteriores, os tipos de mensagens trocados durante as interações desse tipo são diferentes. No entanto, as mensagens têm finalidades semelhantes. Alguns dispositivos enviam dados de um dispositivo de borda para cargas de trabalho de back-end, como eventos de telemetria e informações sobre o estado do dispositivo. Alguns dispositivos enviam diretivas de cargas de trabalho de back-end para dispositivos de borda, como comandos e atualizações de configuração do dispositivo.

Com base nos tipos propostos de interações, recomendamos as seguintes categorias para seus dispositivos de borda:

  • Somente transmissão: dispositivos de borda que enviam eventos de telemetria ou informações sobre o estado do dispositivo, mas não recebem comandos ou atualizações de configuração de dispositivos de cargas de trabalho de back-end.
  • Somente recebimento: dispositivos de borda que não enviam eventos de telemetria ou informações sobre o estado do dispositivo, mas recebem comandos ou atualizações de configuração de dispositivos de cargas de trabalho de back-end.
  • Recebimento e transmissão: dispositivos de borda que enviam eventos de telemetria e informações sobre o estado do dispositivo e recebem comandos ou atualizações de configuração do dispositivo de cargas de trabalho de back-end.

Para categorizar as cargas de trabalho de back-end, siga uma abordagem semelhante à usada para categorizar dispositivos de borda. Com base nos tipos de interações propostos, recomendamos as seguintes categorias para suas cargas de trabalho de back-end:

  • Somente recebimento: cargas de trabalho de back-end que recebem eventos de telemetria ou informações sobre o estado do dispositivo dos dispositivos de borda, mas não enviam comandos ou atualizações de configuração.
  • Somente envio: cargas de trabalho de back-end que não recebem eventos de telemetria ou informações sobre o estado do dispositivo, mas enviam comandos ou atualizações de configuração do dispositivo.
  • Envio e recebimento: cargas de trabalho de back-end que recebem eventos de telemetria ou informações sobre o estado do dispositivo de dispositivos de borda e enviam comandos ou atualizações de configuração do dispositivo.

Concluir a avaliação

Depois de criar os inventários, será necessário concluir as seguintes partes da fase de avaliação:

Após concluir essas atividades, continue lendo este documento.

Projete a arquitetura do ambiente de destino

Depois de concluir as atividades de avaliação anteriores, você vai criar a arquitetura para o ambiente de destino.

O foco deste documento é a migração do ambiente de origem para o de destino. No entanto, a migração do ambiente do IoT Core também é uma oportunidade para você planejar novos recursos e atualizações. Ao projetar a arquitetura do ambiente de destino, pense em quaisquer limitações que você possa ter tido no ambiente de origem. Considere como você quer configurar o ambiente de destino para evitar essas limitações. Considere também os novos recursos que podem ser necessários no ambiente de destino.

Com base em como você categorizou os dispositivos de borda e as cargas de trabalho de back-end, é possível que sejam exibidos os seguintes casos de uso complementares do IoT Core na avaliação do ambiente de origem:

  • Ingestão de dados provenientes de dispositivos de borda em um back-end em execução no Google Cloud.
  • Executar cargas de trabalho de back-end de gerenciamento de dispositivos de borda no Google Cloud.

Para reduzir a complexidade da migração, recomendamos que você se concentre nos casos de uso que surgiram da avaliação do ambiente de origem. Por exemplo, se você está ingerindo dados de dispositivos de borda, mas não usa nenhum dos recursos de gerenciamento de dispositivos do IoT Core, recomendamos que você se concentre no planejamento do ambiente de destino. Essa abordagem permite compatibilidade somente com o caso de uso de ingestão de dados, sem precisar considerar o caso de uso de gerenciamento de dispositivos.

O design do ambiente de destino pode variar dependendo de quais desses casos de uso do Cloud IoT Core você implementou no ambiente de origem e como quer implementá-los no ambiente de destino. Considere os seguintes fatores:

  • Se você tiver implementado os dois casos de uso no ambiente de origem, poderá projetar o ambiente de destino para implementar os dois casos de uso com uma única solução. Também é possível implementar os dois casos de uso separadamente usando soluções distintas.
  • Se você implementar apenas um dos dois casos de uso no ambiente de origem, poderá projetar o ambiente de destino para implementar esse caso de uso com uma única solução.

No diagrama a seguir, mostramos uma série de exemplos de perguntas a serem consideradas ao decidir como projetar a arquitetura do ambiente de destino.

Exemplos de perguntas, mencionados no texto a seguir.

O diagrama anterior pode ser resumido da seguinte forma:

  • Você precisa ingerir dados de dispositivos de borda e gerenciar dispositivos de borda?

    • Se sim, vá para a próxima pergunta.
    • Caso contrário, prossiga para as perguntas sobre o caso de uso de gerenciamento de dispositivos de borda.

  • Você precisa de uma única solução para implementar a ingestão de dados e os casos de uso de gerenciamento de dispositivos de borda?

    • Em caso afirmativo, implante uma solução para ingestão de dados e gerenciamento de dispositivos de borda no Google Cloud.
    • Caso contrário, implante uma solução de gerenciamento de dispositivos de borda no Google Cloud e, em seguida, prossiga para as perguntas de avaliação do caso de uso de ingestão de dados.

  • Você precisa gerenciar dispositivos de borda?

    • Em caso afirmativo, implante uma solução de gerenciamento de dispositivos de borda no Google Cloud e siga para as perguntas de avaliação do caso de uso de ingestão de dados.
    • Caso contrário, prossiga para as perguntas de avaliação do caso de uso de ingestão de dados.

  • Você precisa ingerir dados de dispositivos de borda?

    • Se sim, vá para a próxima pergunta.
    • Caso contrário, você concluiu a migração ou não precisa migrar o ambiente de origem. Em ambos os casos, é possível desativar o ambiente de origem.

  • Qual é o protocolo de comunicação preferido?

    • Se for MQTT, implante um agente do MQTT no Google Cloud.
    • Se for HTTP ou gRPC, faça a ingestão de dados provenientes de dispositivos de borda usando o Pub/Sub.
    • Caso contrário, avalie soluções de ingestão de dados compatíveis com seus protocolos de comunicação preferidos.

Ao projetar a arquitetura do ambiente de destino, considere o seguinte:

  • Gerenciar qualquer componente da arquitetura requer conhecimento e esforço. Recomendamos que você avalie quantos recursos adicionais precisa considerar para o ambiente de destino.
  • O provisionamento de muitos dispositivos de borda representa desafios de segurança, escalonabilidade e operação. Para mais informações sobre o provisionamento de dispositivos de borda, consulte Práticas recomendadas para provisionar e configurar automaticamente sistemas e servidores de borda e bare metal.
  • O uso do Pub/Sub para ingerir dados dos dispositivos de borda libera você de gerenciar e escalonar uma plataforma de mensagens distribuída. Se você usar o Pub/Sub para ingerir dados de dispositivos de borda, considere as cotas e limites do Pub/Sub, especialmente se precisar ingerir dados de muitos dispositivos.

  • Para autenticar seus dispositivos de borda no ambiente de destino e gerenciar as identidades deles, recomendamos que você avalie quais métodos de autenticação e armazenamentos de credenciais são compatíveis com o ambiente de destino. Compare-os com os que você usa com o IoT Core no ambiente de origem.

    Depois de coletar essas informações, recomendamos que você siga as orientações do guia de segurança de back-end da IoT para projetar e implementar um mecanismo de autenticação e gerenciamento de identidade para os dispositivos de borda.

Escolha os dispositivos de borda e as cargas de trabalho de back-end para migrar primeiro

Depois de projetar a arquitetura do ambiente de destino, defina o seguinte:

  1. As categorias de dispositivos de borda e cargas de trabalho de back-end a serem migradas primeiro.
  2. Os lotes de migração (os grupos de itens a serem migrados do ambiente de origem para o ambiente de destino).

Defina as categorias de dispositivos de borda que serão migradas primeiro

As categorias de dispositivos de borda e cargas de trabalho de back-end podem oferecer desafios e dificuldades diferentes para a migração. Um exemplo seria a migração de dispositivos de borda somente de transmissão, que podem ser mais fáceis do que a migração de dispositivos de borda de recebimento e transmissão.

Para entender melhor como escolher quais categorias de dispositivos de borda e cargas de trabalho de back-end migrar primeiro, consulte Como escolher os apps para migrar primeiro.

Esta seção resume as considerações que você precisa fazer para cada categoria de dispositivo de borda ao decidir qual migrar primeiro.

Dispositivos de borda somente para transmissão

Esses dispositivos de borda enviam eventos e informações de telemetria sobre o estado do dispositivo usando MQTT ou HTTP.

Se os dispositivos usarem o MQTT, talvez seja necessário atualizar a configuração deles para se conectar e autenticar no agente do MQTT no seu ambiente de destino. É possível continuar publicando eventos de telemetria e informações sobre o estado do dispositivo por meio do agente MQTT no ambiente de destino. Em alguns casos, talvez você não tenha um agente MQTT no ambiente de destino e precise migrar para um tipo diferente de ambiente de destino, como uma solução de terceiros. Nesse caso, é necessário avaliar os recursos e as interfaces de integração fornecidos pela solução. Em seguida, é possível projetar e implementar um plano de migração adequado.

Se os dispositivos usarem HTTP, talvez seja necessário atualizar a configuração para se conectar e autenticar no ambiente de destino. Talvez também seja necessário refatorar a semântica de como os dispositivos se comunicam para considerar as diferenças no ambiente de destino em comparação com o uso das APIs IoT Core. Por exemplo, se você estiver usando o Pub/Sub no ambiente de destino, poderá migrar das APIs IoT Core para publicar mensagens em tópicos do Pub/Sub e usar APIs Pub/Sub para a mesma finalidade. Em alguns casos, talvez você não use o Pub/Sub no ambiente de destino e, portanto, precise migrar para um tipo diferente, como uma solução de terceiros. Nesse caso, avalie os recursos e as interfaces de integração que a solução de terceiros oferece para projetar e implementar um plano de migração adequado.

Dispositivos de borda somente para recebimento

Esses dispositivos de borda recebem comandos usando MQTT e atualizações de configuração usando MQTT ou HTTP. O IoT Core não é compatível com o uso de HTTP para enviar comandos.

Se os dispositivos receberem comandos e atualizações de configuração usando o MQTT, considerações semelhantes à categoria de dispositivos de borda anterior são aplicadas. Para migrar essa categoria de dispositivos de borda, atualize a configuração dos dispositivos de borda para se conectar e autenticar no agente MQTT no seu ambiente de destino. Você continua assinando tópicos do MQTT em que o IoT Core publica comandos e atualizações de configuração do dispositivo. Em alguns casos, talvez você não tenha um agente MQTT no ambiente de destino e precise migrar para outro tipo de ambiente, como uma solução de terceiros. Nesse caso, é necessário avaliar os recursos e as interfaces de integração que a solução fornece para projetar e implementar um plano de migração adequado.

Se os dispositivos receberem atualizações de configuração usando HTTP, são aplicadas considerações semelhantes à categoria de dispositivos de borda anterior. Para migrar essa categoria de dispositivos de borda, pode ser necessário atualizar a configuração para se conectar e autenticar no ambiente de destino. Para receber atualizações de configuração, também pode ser necessário refatorar a semântica da comunicação para considerar as diferenças no ambiente de destino, em comparação com o uso das APIs IoT Core. Por exemplo, se você estiver migrando para um tipo diferente de ambiente de destino, como uma solução de terceiros, precisará avaliar os recursos e as interfaces de integração que a solução oferece para projetar e implementar um plano de migração adequado.

Dispositivos de borda de recebimento e transmissão

Esses dispositivos de borda podem ser mais difíceis de migrar porque são consumidores de dados vindos das cargas de trabalho de back-end e produtores de dados que os dispositivos de borda recebem. Nesse caso, as considerações para migrar as categorias de dispositivos de borda discutidas acima se aplicam, portanto, você precisa ter cuidado especial com a migração dessa categoria de carga de trabalho de back-end.

Depois de escolher quais categorias de dispositivos de borda migrar primeiro, você escolhe quais categorias de cargas de trabalho de back-end migrar primeiro.

Cargas de trabalho de back-end somente de recebimento

Essas cargas de trabalho de back-end são separadas dos dispositivos de borda que produzem eventos de telemetria ou informações sobre o estado do dispositivo. Portanto, pelos seguintes motivos, a migração pode ser relativamente simples:

  • As cargas de trabalho de back-end assinam tópicos do Pub/Sub. Por isso, os dispositivos não precisam saber sobre os produtores dessas informações. Talvez não seja necessário atualizar a configuração ou o software em execução nos dispositivos de borda.
  • As cargas de trabalho de back-end não enviam comandos ou atualizações de configuração do dispositivo a dispositivos de borda. Portanto, não é necessário considerar esse caso de uso durante a migração dessas cargas de trabalho de back-end.
  • É possível manter os tópicos do Pub/Sub atuais para publicar ou consumir mensagens. Nesse caso, as cargas de trabalho de back-end poderão continuar assinando tópicos do Pub/Sub atuais se o ambiente de destino continuar encaminhando eventos de telemetria e informações sobre o estado do dispositivo para esses tópicos do Pub/Sub.

Cargas de trabalho de back-end somente para envio

Essas cargas de trabalho de back-end exigem uma avaliação abrangente para entender como elas interagem com dispositivos de borda ao enviar comandos e atualizações de configuração de dispositivo e como migrá-las para o ambiente de destino. Por exemplo, se você estiver migrando para um ambiente de destino com um agente do MQTT, essas cargas de trabalho de back-end poderão migrar do uso das APIs IoT Core para enviar comandos ou atualizações de configuração do dispositivo para publicar mensagens pelo MQTT. Em alguns casos, não é necessário realizar uma atualização de software ou configuração nos dispositivos de borda. Por exemplo, se as cargas de trabalho de back-end publicarem comandos e atualizações de configuração no mesmo formato e para os mesmos tópicos do MQTT em que o IoT Core publica mensagens sobre comandos e atualizações de configuração do dispositivo no seu ambiente de origem. Se você estiver migrando para um tipo diferente de ambiente de destino, como uma solução de terceiros, precisará avaliar os recursos e as interfaces de integração que a solução fornece para projetar e implementar um plano de migração adequado.

Cargas de trabalho de back-end de envio e recebimento

Essas cargas de trabalho de back-end podem ser as mais difíceis de migrar porque são consumidores de dados provenientes de dispositivos de borda e produtores de dados que os dispositivos de borda recebem. Nesse caso, as considerações para migrar as categorias de cargas de trabalho de back-end discutidas acima se aplicam. Portanto, é necessário cuidado especial para lidar com a migração dessa categoria de carga de trabalho de back-end.

Defina lotes de migração

Para reduzir os riscos e a complexidade de migrar um grande número de itens em um único lote, divida os itens para migrar em cada categoria em lotes de migração. Para planejar lotes de migração, faça o seguinte:

  1. Crie lotes de migração agrupando itens homogêneos: para agrupar os itens a serem migrados em lotes, recomendamos que você escolha um conjunto de critérios para que os itens em um lote de migração compartilhem características comuns. Por exemplo, é possível agrupar dispositivos de borda em lotes de acordo com o seguinte:

    • A região de implantação
    • O registro do IoT Core em que os dispositivos estão registrados
    • Se houver um conjunto significativo de metadados do dispositivo IoT Core
    • O estado de implantação dos dispositivos

  2. Decida o tamanho de cada lote de migração: para cada categoria de itens a serem migrados, recomendamos planejar os primeiros lotes de migração nessa categoria para que sejam relativamente pequenos. Você aumenta o tamanho dos lotes à medida que ganha experiência e momentum durante a migração.

  3. Avaliar se os lotes de migração precisam de estratégias ad-hoc: dependendo de como você agrupou os itens para migrar em lotes, a estratégia de migração a ser aplicada a um determinado lote de migração pode depender as características dos itens desse lote. Por exemplo, para migrar dispositivos de borda agrupados por estado de implantação, é necessário fazer as seguintes considerações:

    • Se os dispositivos ainda não foram fabricados ou estiverem em fabricação, será possível instruir o fabricante a atualizar a configuração e o software para migrá-los para o ambiente de destino.
    • Se os dispositivos estiverem prontos para serem implantados, mas ainda não estiverem registrados no IoT Core, será possível instruir o implantador a recuperar esses dispositivos de borda. Em seguida, é possível atualizar a configuração e o software para migrá-los para o ambiente de destino.
    • Se os dispositivos já estiverem implantados no local de destino e registrados no IoT Core, será possível atualizar a configuração e o software deles para migrá-los para o ambiente de destino, seja remotamente ou no local.

Planeje e crie sua base

Na fase de planejamento e criação, você provisiona e configura a infraestrutura e os serviços em nuvem compatíveis com suas cargas de trabalho no Google Cloud, da seguinte forma:

  1. Crie uma hierarquia de recursos.
  2. Configure o gerenciamento de identidade e acesso.
  3. Configure o faturamento.
  4. Configurar a conectividade de rede.
  5. Aumente sua segurança.
  6. Configure o monitoramento e os alertas.

Para orientações sobre como criar a infraestrutura e os serviços de nuvem que suportam suas cargas de trabalho e as respectivas dependências, consulte Migração para o Google Cloud: como criar sua base. Siga essas diretrizes para criar uma base para os ambientes. Em seguida, você continuará com as atividades descritas nas próximas seções deste documento.

Migre os dispositivos de borda e as cargas de trabalho de back-end

Depois de criar a base para o ambiente de destino, faça o seguinte para migrar os dispositivos de borda e as cargas de trabalho de back-end para o ambiente de destino.

  1. Provisionar e configurar recursos para implementar a arquitetura do ambiente de destino: como a primeira etapa do processo de migração, você cria e configura a infraestrutura da nova plataforma.
  2. Migrar dispositivos de borda e cargas de trabalho de back-end para o ambiente de destino: depois de verificar se o ambiente de destino está pronto, migre as cargas de trabalho de back-end e os dispositivos de borda para o ambiente de destino. Dependendo da arquitetura do seu ambiente de destino e dos casos de uso, pode haver diferentes abordagens de migração. Neste documento, discutimos uma estratégia de migração em duas etapas que permite que os ambientes de origem e de destino coexistam por um período. Essa abordagem significa que, se houver falhas durante a migração, será possível reverter para o ambiente de origem.
  3. Desativação do ambiente de origem: depois de verificar se o ambiente de destino está totalmente operacional, desative o ambiente de origem.

Provisione e configure os recursos para a arquitetura do ambiente de destino

Nesta fase, você provisiona e configura o ambiente de destino. Conforme descrito em Projetar a arquitetura do ambiente de destino, a arquitetura do ambiente de destino pode ser resumida da seguinte maneira:

  • Um agente do MQTT em execução no Google Cloud: você executa um agente do MQTT no Google Cloud e encaminha eventos de telemetria e informações sobre o estado do dispositivo do agente do MQTT para cargas de trabalho de back-end. Suas cargas de trabalho de back-end publicam comandos e controles no tópico MQTT.
  • Pub/Sub: seus dispositivos de borda publicam eventos de telemetria e informações sobre o estado do dispositivo no Pub/Sub e recebem comandos do Pub/Sub.
  • Uma plataforma terceirizada de ingestão de dados e gerenciamento de dispositivos: você configura uma solução terceirizada para eventos de telemetria e informações sobre a ingestão de estados do dispositivo e o gerenciamento de dispositivos.

Para conferir mais informações sobre cada arquitetura, consulte arquiteturas de dispositivos conectados no Google Cloud.

Migre dispositivos de borda e cargas de trabalho de back-end para o ambiente de destino

Depois de provisionar e configurar os recursos no ambiente de destino, você migrará os dispositivos de borda e as cargas de trabalho de back-end para o ambiente de destino. Nesta seção, você vai migrar dispositivos de borda e cargas de trabalho de back-end do ambiente de origem para o de destino. Os ambientes de origem e de destino coexistem até que você desative o ambiente de origem.

Para reduzir a inatividade, o processo de migração tem as seguintes fases:

  1. Como monitorar os ambientes de origem e destino.
  2. Migração das informações dos metadados do dispositivo de borda para o ambiente de destino. Isso inclui credenciais, configuração e estado do dispositivo.
  3. Como atualizar dispositivos de borda para se conectar à origem e ao ambiente de destino.
  4. Como migrar cargas de trabalho de back-end do ambiente de origem para o de destino.
  5. Como atualizar dispositivos de borda para se conectar apenas ao ambiente de origem.

Recomendamos que você monitore os ambientes de origem e de destino durante cada fase de migração e verifique os resultados de cada fase antes de passar para a próxima.

Além de monitorar o ambiente, você pode introduzir testes de caixa preta para verificar se o ambiente funciona conforme o esperado. Um exemplo desse teste seria um caso de uso em que a carga de trabalho de back-end envia uma notificação por e-mail aos operadores quando detecta um evento específico, como uma temperatura maior que 50 graus Celsius. É possível criar um caso de teste que tenha dados de telemetria para uma temperatura superior a 50 graus Celsius e testar se a carga de trabalho de back-end envia um e-mail para os operadores.

Monitore os ambientes de origem e destino

Para monitorar os ambientes de origem e de destino, recomendamos considerar as seguintes métricas:

  • Contagem de dispositivos ativos: o número de dispositivos que recentemente enviaram dados ao IoT Core.
  • Contagem de erros de comunicação do dispositivo: o número de erros que as cargas de trabalho de back-end encontraram ao se comunicar com dispositivos de borda, agrupados por tipo de erro em um determinado período. Essa métrica é útil para entender se as cargas de trabalho de back-end estão tendo problemas para se comunicar com dispositivos de borda.
  • Contagem de operações do dispositivo: o número de operações realizadas por dispositivos de borda, como solicitações de conexão ou desconexão, publicação de mensagens, agrupadas por tipo de operação em um determinado período. Essa métrica ajuda a entender se os dispositivos de borda estão sendo executados como esperado. Por exemplo, se a contagem de erros do dispositivo e os valores da contagem de operações do dispositivo estiverem aumentando, o ambiente pode ter problemas para enviar mensagens para os dispositivos de borda.
  • Contagem de bytes recebidos: o número de bytes recebidos de dispositivos de borda em um determinado período. Essa métrica ajuda a explicar as estatísticas de tráfego de entrada da rede.
  • Contagem de bytes enviados: contagem de delta do número de bytes enviados para dispositivos de borda. Essa métrica ajuda a entender as estatísticas de tráfego de saída da rede.
  • Capacidade de processamento de mensagens: o número de mensagens que as cargas de trabalho de back-end processaram em um determinado período. Essa métrica ajuda a entender se o ambiente é escalonado de acordo com o volume de tráfego entre dispositivos de borda e cargas de trabalho de back-end. Por exemplo, se a contagem de dispositivos ativos e a operação de dispositivos aumentarem, mas a capacidade de processamento de mensagens não mudar muito, convém verificar se as cargas de trabalho de back-end têm recursos suficientes para lidar com o aumento de mensagens.
  • Latência na entrega de mensagens: o tempo decorrido após um dispositivo de borda publicar uma mensagem e antes que uma carga de trabalho de back-end a receba para processamento. Por exemplo, se o valor de latência aumentar, talvez você queira verificar se há problemas que atrasam a entrega da mensagem.
  • Mensagens que não são entregues: o número de mensagens que não podem ser entregues a dispositivos de borda e cargas de trabalho de back-end. A falha em entregar mensagens aos consumidores pode significar que os dispositivos de borda ou as cargas de trabalho de back-end podem não estar respondendo.
  • Uso da cota de recursos de nuvem: monitore o uso da cota de recursos de nuvem para garantir que o ambiente tenha recursos suficientes para escalonar.
Monitore o ambiente de origem

O Cloud Monitoring coleta automaticamente métricas do IoT Core e do Pub/Sub. Por exemplo, o IoT Core expõe as métricas device/active_devices, device/error_count e device/operation_count. Esses dados ajudam você a entender quantos dispositivos de borda conectados ao ambiente de origem e quantos dispositivos de borda estão enfrentando erros de comunicação com o IoT Core. As métricas device/received_bytes_count e device/sent_bytes_count ajudam a monitorar o consumo de largura de banda da rede.

Para monitorar a integridade e o status da entrega de mensagens, use a Linguagem de consulta do Monitoring para medir a pontuação de integridade da latência de entrega de uma assinatura, capacidade de processamento de mensagens e mensagens não entregues.

Monitore o ambiente de destino

Monitore o ambiente de destino para entender se a migração foi bem-sucedida. Dependendo da arquitetura do ambiente de destino, o agente do MQTT ou a plataforma de IoT de terceiros pode fornecer as seguintes métricas:

  • Agente do MQTT: se o ambiente de destino for baseado em um agente do MQTT, o agente poderá fornecer métricas sobre dispositivos de borda e a entrega de mensagens. Para monitorar os bytes enviados e recebidos, consulte as métricas fornecidas pelo Cloud Load Balancing. Se o agente MQTT estiver em execução em um cluster do GKE, será possível configurar o Cloud Monitoring para definir quais métricas serão enviadas para o Monitoring. Se o agente MQTT estiver em execução em uma instância do Compute Engine, será possível usar o painel padrão ou instalar o Agente de operações para coletar telemetria detalhada da instância do Cloud Monitoring.

  • Pub/Sub: se o ambiente de destino for baseado no Pub/Sub, use tópicos e assinaturas do Pub/Sub. Por exemplo, é possível usar a Linguagem de consulta do Monitoring para realizar uma consulta e buscar a pontuação de integridade da latência de entrega em uma assinatura, capacidade de processamento de mensagens e mensagens não entregues.

  • Plataforma de IoT: se o ambiente de destino for baseado em uma plataforma de IoT, a plataforma poderá fornecer informações sobre dispositivos de borda e a entrega de mensagens. Se a plataforma de IoT de terceiros estiver em execução em um cluster do GKE, será possível configurar o Logging e o Monitoring para configurar quais métricas serão enviadas para o Cloud Monitoring. Se a plataforma de IoT de terceiros estiver em execução em uma instância do Cloud Monitoring, use o painel padrão ou instale o Agente de operações para coletar telemetria detalhada da instância do Cloud Monitoring.

Migre as informações de metadados do dispositivo de borda do ambiente de origem para o de destino

Para migrar para a nova plataforma de IoT, migre informações de metadados de dispositivos de borda para o ambiente de destino. Para migrar os metadados do dispositivo de borda, considere estas categorias:

  • Credenciais do dispositivo: o IoT Core autentica os dispositivos de borda usando um par de chaves e tokens de curta duração. Siga as etapas necessárias do ambiente de destino para registrar dispositivos nele e criar credenciais de dispositivo de acordo com o mecanismo de autenticação.

  • Configuração do dispositivo: seu ambiente de destino pode ser uma plataforma de IoT de terceiros que fornece um serviço de configuração de dispositivo, e o caso de uso exige que os dispositivos de borda sejam configurados com o estado desejado mais recente. Nesse caso, é necessário migrar a configuração do dispositivo para o ambiente de destino. Durante a migração, verifique se a configuração do dispositivo está sincronizada entre o ambiente de origem e o de destino. Se o ambiente de destino for baseado em um agente do MQTT ou no Pub/Sub, e não for possível gerenciar a configuração do dispositivo, convém armazenar as configurações do dispositivo nos buckets do Cloud Storage como um arquivo de longo prazo.

  • Informações sobre o estado do dispositivo: verifique se os dispositivos de borda atualizam o estado quando se conectam ao ambiente de destino pela primeira vez, para que esse ambiente tenha as informações mais atualizadas sobre estado do dispositivo.

Depois de concluir essa etapa, verifique se as informações e as credenciais necessárias estão configuradas corretamente e se os dispositivos de borda podem se conectar e autenticar no ambiente de destino.

Atualize os dispositivos de borda para se conectar aos ambientes de origem e destino

Quando você chegar a esse estágio, o ambiente de destino estará pronto para aceitar conexões de dispositivos de borda. É possível atualizar os dispositivos de borda para conectá-los ao ambiente de destino e de origem para enviar eventos de telemetria e informações sobre o estado do dispositivo. Ao atualizar dispositivos de borda, a abordagem que você precisa seguir depende da categoria de dispositivo de borda.

Para dispositivos de borda que enviam eventos de telemetria ou informações sobre o estado do dispositivo, mas não recebem comandos nem atualizações de configuração de dispositivos de cargas de trabalho de back-end, faça o seguinte:

  1. Atualize os dispositivos de borda para que eles enviem eventos de telemetria e informações sobre o estado do dispositivo para o ambiente de origem e de destino.
  2. Verifique se o ambiente de destino recebe corretamente os eventos de telemetria e as informações sobre o estado do dispositivo.

Por outro lado, para dispositivos de borda que não enviam eventos de telemetria ou informações sobre o estado do dispositivo, mas recebem comandos ou atualizações de configuração de cargas de trabalho de back-end, faça o seguinte:

  1. Atualize os dispositivos de borda para receber comandos e atualizações de configuração do ambiente de destino.
  2. Verifique se os dispositivos de borda informam o resultado da execução do comando ou das atualizações de configuração para o ambiente de destino.
  3. Enviar um comando e uma atualização de configuração do ambiente de destino para os dispositivos de borda.
  4. Verifique se a execução do comando e da atualização de configuração foram bem-sucedidas.

Para dispositivos de borda que enviam eventos de telemetria e informações sobre o estado do dispositivo e que também recebem comandos ou atualizações de configuração de cargas de trabalho de back-end, faça o seguinte:

  1. Atualize os dispositivos de borda para que eles enviem eventos de telemetria e informações sobre o estado do dispositivo para o ambiente de origem e de destino.
  2. Verifique se o ambiente de destino recebe corretamente os eventos de telemetria e as informações sobre o estado do dispositivo.
  3. Atualize os códigos dos dispositivos de borda para receber comandos e atualizações de configuração do ambiente de destino.
  4. Verifique se os dispositivos de borda informam o resultado da execução do comando ou das atualizações de configuração para o ambiente de destino.
  5. Enviar um comando e uma atualização de configuração do ambiente de destino para os dispositivos de borda.
  6. Verifique se a execução do comando e da atualização de configuração foram bem-sucedidas.

Depois de executar essas etapas para seu caso de uso, todas as categorias de dispositivo de borda vão fazer o seguinte:

  • Conectar ao ambiente de origem e destino.
  • Enviar eventos de telemetria e informações sobre o estado do dispositivo para o ambiente de origem e de destino.
  • Receber comandos e atualizações de configuração do ambiente de origem apenas porque você ainda não migrou cargas de trabalho de back-end.

É melhor evitar um cenário em que as cargas de trabalho de back-end processam a mesma mensagem que os dispositivos de borda enviam aos ambientes de origem e de destino. Recomendamos que você configure o período de armazenamento de mensagens no ambiente de destino com o valor mínimo possível. Essa abordagem permite verificar se o ambiente de destino está funcionando conforme o esperado. Ela também permite que você verifique se as mensagens no ambiente de destino expiram antes de migrar as cargas de trabalho de back-end. É possível ajustar a configuração de armazenamento de mensagens no ambiente de destino após a próxima etapa de migração.

Se os dispositivos de borda não puderem se conectar ao ambiente de origem e de destino ao mesmo tempo por motivos técnicos ou regulamentares, configure o dispositivo de borda para se desconectar do ambiente de origem primeiro. Depois disso, é possível se conectar ao ambiente de destino. Nesse caso, as cargas de trabalho de back-end que ainda estão conectadas ao ambiente de origem param de receber eventos de telemetria e informações sobre o estado do dispositivo dos dispositivos de borda. Os dispositivos não podem mais enviar comandos e atualizações de configuração para dispositivos de borda.

Também recomendamos provisionar e configurar um mecanismo de armazenamento em buffer. Essa abordagem ajuda a evitar a perda de dados quando o dispositivo envia eventos de telemetria e informações sobre o estado do dispositivo para o ambiente de destino quando as cargas de trabalho de back-end ainda estão conectadas ao ambiente de origem. As cargas de trabalho de back-end podem consumir essas informações ao se conectarem ao ambiente de destino. Por exemplo, é possível configurar a retenção de mensagens do ambiente de destino com base em um agente do MQTT, Pub/Sub ou uma plataforma de IoT. Essa abordagem permite que você mantenha as mensagens não confirmadas disponíveis pelo tempo necessário para concluir a próxima fase da migração, conforme descrito na seção a seguir.

Migre cargas de trabalho de back-end do ambiente de origem para o de destino

As cargas de trabalho de back-end são migradas para o ambiente de destino. Dependendo da arquitetura do ambiente de destino, será necessário adotar diferentes abordagens para migrar a carga de trabalho.

Agente MQTT no Google Cloud: se o ambiente de destino for baseado em um agente do MQTT, os fatores a seguir orientarão sua abordagem de migração:

  • Para cargas de trabalho de back-end que recebem eventos de telemetria ou informações sobre o estado do dispositivo de dispositivos de borda, mas não enviam comandos ou atualizações de configuração de dispositivo: configure o cargas de trabalho de back-end para assinar tópicos MQTT e receber eventos de telemetria e informações sobre o estado do dispositivo provenientes dos dispositivos de borda.
  • Por outro lado, para cargas de trabalho de back-end que não recebem eventos de telemetria ou informações sobre o estado do dispositivo, mas enviam comandos ou atualizações de configuração do dispositivo: configure as cargas de trabalho de back-end para publicar mensagens para enviar comandos e atualizações de configuração a tópicos do MQTT para comandos e atualizações de configuração no ambiente de destino.
  • Para cargas de trabalho de back-end que recebem eventos de telemetria ou informações sobre o estado do dispositivo de dispositivos de borda e que enviam comandos ou atualizações de configuração de dispositivo: configure as cargas de trabalho de back-end para assinar tópicos do MQTT para receber telemetria, e então configure suas cargas de trabalho de back-end para publicar mensagens para enviar comandos e atualizações de configuração aos tópicos do MQTT.

Pub/Sub: se o ambiente de destino for baseado no Pub/Sub, os fatores a seguir guiarão sua abordagem de migração:

  • Para cargas de trabalho de back-end que recebem eventos de telemetria ou informações sobre o estado do dispositivo de dispositivos de borda, mas não enviam comandos ou atualizações de configuração de dispositivo: crie uma nova assinaturas do Pub/Sub no ambiente de destino e atualize suas cargas de trabalho de back-end para consumir as assinaturas recém-criadas.
  • Por outro lado, para cargas de trabalho de back-end que não recebem eventos de telemetria ou informações sobre o estado do dispositivo, mas enviam comandos ou atualizações de configuração do dispositivo: crie tópicos do Pub/Sub e configure suas cargas de trabalho de back-end para publicar mensagens para enviar comandos e atualizações de configuração aos tópicos do Pub/Sub.
  • Para cargas de trabalho de back-end que recebem eventos de telemetria ou informações sobre o estado do dispositivo de dispositivos de borda e que enviam comandos ou atualizações de configuração de dispositivo: configure as cargas de trabalho de back-end para assinar tópicos do Pub/Sub para receber eventos de telemetria e informações sobre o estado do dispositivo. Em seguida, configure as cargas de trabalho de back-end para publicar mensagens e enviar comandos e atualizações de configuração aos tópicos do Pub/Sub.

Plataforma de IoT de terceiros: se o ambiente de destino for baseado em uma plataforma de IoT de terceiros, siga as instruções da plataforma de IoT de terceiros para configurar integrações entre cargas de trabalho de back-end e a plataforma de IoT. Em seguida, você verifica se as cargas de trabalho de back-end podem receber eventos de telemetria e informações sobre o estado do dispositivo proveniente de dispositivos de borda. Você também verifica se as cargas de trabalho de back-end podem publicar mensagens para enviar comandos ou atualizações de configuração de dispositivo ao dispositivo de borda.

Para verificar se os dispositivos de borda e as cargas de trabalho de back-end estão funcionando conforme o esperado, recomendamos que você faça o seguinte:

  • Verifique se as cargas de trabalho de back-end recebem eventos de telemetria e informações sobre o estado do dispositivo e reagem corretamente. Por exemplo, se as cargas de trabalho de back-end gerarem um painel quase em tempo real para monitorar dados de telemetria específicos, verifique se o painel está atualizado com o período de dados mais recente.
  • Verifique se as cargas de trabalho de back-end enviam comandos e atualizações de configuração para dispositivos de borda conforme o esperado. Verifique se os dispositivos de borda também reagem conforme o esperado.
  • Verifique se o dispositivo de borda informa eventos de telemetria e informações sobre o estado do dispositivo para o ambiente de destino.

Neste ponto, as cargas de trabalho de back-end fazem o seguinte:

  • Conectar ao ambiente de destino.
  • Receber eventos de telemetria e informações sobre o estado do dispositivo de dispositivos de borda do ambiente de destino.
  • Enviar comandos e atualizações de configuração a dispositivos de borda do ambiente de destino.

Agora é possível atualizar a configuração do armazenamento de mensagens do ambiente de destino definida como um valor mínimo ao conectar dispositivos de borda aos ambientes de origem e destino e defini-la de acordo com seus requisitos.

Quando você atualiza a configuração de cargas de trabalho de back-end para receber eventos de telemetria e informações sobre o estado do dispositivo do ambiente de destino, as cargas de trabalho de back-end podem precisar de tempo para aplicar essa configuração atualizada. Durante a fase temporária, as cargas de trabalho de back-end não podem consumir eventos de telemetria e informações sobre o estado do dispositivo que os dispositivos de borda enviam. Se os casos de uso exigirem integridade de dados completa, talvez seja necessário configurar o período de armazenamento de mensagens do ambiente de destino antes de atualizar a configuração de cargas de trabalho de back-end. Essa abordagem garante que as mensagens não expirem antes que as cargas de trabalho de back-end possam aplicar a nova configuração e consumir as mensagens.

Atualize os dispositivos de borda para se conectar apenas ao ambiente de destino

Neste ponto, você migrou seus dispositivos de borda para o ambiente de destino, mas eles ainda estão usando o ambiente de origem. Para concluir a etapa de migração, atualize os dispositivos de borda para se conectarem ao ambiente de destino apenas removendo as conexões e a integração com o IoT Core. Após a conclusão da atualização, os dispositivos de borda só se conectam ao ambiente de destino.

Desative o ambiente de origem

Depois de migrar os dispositivos de borda e as cargas de trabalho de back-end para o ambiente de destino e validar o ambiente de destino, desative o ambiente de origem.

Para desativar o ambiente de origem, faça o seguinte:

  1. Exclua as assinaturas do Pub/Sub que assinam tópicos do IoT Core.
  2. Exclua tópicos do Pub/Sub não utilizados. Se você reutilizar tópicos do Pub/Sub, não exclua os tópicos criados pelo IoT Core. É possível encontrar os tópicos do Pub/Sub usados pelo IoT Core usando o console do IoT Core.
  3. Exclua os dispositivos e registros do IoT Core.

Otimizar o ambiente após a migração

A otimização é a última fase da migração. Nesta fase, você torna seu ambiente mais eficiente do que antes. Nesta fase, você executa várias iterações de um loop repetível até que o ambiente atenda aos requisitos de otimização. As etapas desse loop repetível são as seguintes:

  1. Avaliação do ambiente, das equipes e do ciclo de otimização atuais.
  2. Estabelecimento dos seus requisitos e metas de otimização.
  3. Otimização do seu ambiente e das suas equipes.
  4. Ajuste do loop de otimização.

As seções a seguir baseiam-se na Migração para o Google Cloud: como otimizar seu ambiente.

Avalie o ambiente de destino, as equipes e o loop de otimização

Embora a primeira avaliação que você faz se concentre no ambiente de origem, essa fase de avaliação é destinada à fase de otimização. Para mais informações sobre como avaliar o ambiente de destino, as equipes e o loop de otimização, consulte Medir o ambiente, as equipes e o loop de otimização.

Estabelecer seus requisitos de otimização

Confira os seguintes requisitos de otimização que podem ser necessários no ambiente de destino:

  • Configure o escalonamento automático: use serviços do Google Cloud, como grupo gerenciado de instâncias ou Google Kubernetes Engine para fazer o escalonamento automático horizontal ou vertical da sua solução de IoT e das cargas de trabalho de back-end quando os carregamentos aumentarem. Essa abordagem ajuda a garantir que o armazenamento de dados de telemetria e registro do seu dispositivo possa lidar com um volume maior de dados quando você implantar uma grande frota de dispositivos. Como o Spanner é um banco de dados transacional distribuído, altamente disponível e escalonável, ele é um bom candidato para armazenar dados de telemetria e informações de registro de dispositivo.
  • Aprimore o mecanismo de geração de registros e monitoramento: otimize e integre seu mecanismo de geração de registros e monitoramento para formar uma solução centralizada. Talvez você também queira melhorar algumas métricas de monitoramento para entender como os dispositivos de borda interagem com a solução de IoT. Também é preciso registrar e correlacionar atividades, como eventos de conexão, desconexão e telemetria. Também recomendamos monitorar erros do sistema e de aplicativos. Se possível, configure um alerta quando determinadas falhas críticas ocorrerem no nível do sistema.
  • Proteja suas cargas de trabalho usando os serviços de segurança do Google Cloud: o Security Command Center é um serviço centralizado de vulnerabilidade e geração de relatórios de ameaças que pode ser usado para ajudar a reforçar a postura de segurança avaliando a segurança e a superfície de ataque de dados. Ele fornece inventário e descoberta de recursos, além de ajudar a identificar configurações incorretas, vulnerabilidades e ameaças. O Security Command Center também ajuda a mitigar e corrigir riscos. Para saber como proteger as cargas de trabalho executadas no Google Kubernetes Engine (GKE), consulte a Visão geral de segurança do Google Kubernetes Engine e entenda como proteger as cargas de trabalho do GKE.

Concluir a otimização

Depois de preencher a lista de requisitos de otimização, você conclui a fase de otimização. Para saber como fazer isso, consulte Migração para o Google Cloud: como otimizar seu ambiente.

A seguir