AWS e IBM: uma comparação de serviços IoT: 4 etapas

2025 Autor: John Day | [email protected]. Última modificação: 2025-01-13 06:58

Hoje estamos comparando duas pilhas que permitem desenvolver aplicativos IoT sob o ponto de vista de diferentes ofertas de serviços.

Etapa 1: funções como um serviço

FaaS é uma categoria de serviços em nuvem usada para construir uma arquitetura “sem servidor”. O FaaS permite que os clientes desenvolvam, executem e gerenciem funcionalidades de aplicativos sem construir e manter a infraestrutura.

A Amazon oferece AWS Lambda, a IBM oferece IBM Cloud Functions. Esses serviços são bastante semelhantes, porém Lambda foi o primeiro desse tipo. Usando FaaS, você pode executar pedaços de código na nuvem e cada serviço oferece suporte a diferentes linguagens de programação.

IBM Cloud Functions: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C # F # etc.), Any via Docker AWS Lambda: JavaScript, Java, C #, F #, Go, Python, Ruby, PowerShell, Any via API Runtime

A IBM oferece suporte a mais idiomas e com docker é fácil de usar scripts escritos em outros idiomas. Isso também pode ser feito com Lambda, mas não é imediato. Você pode ler um exemplo aqui:

Ambos os serviços têm limites de uso, nós os reportamos em uma tabela e destacamos os melhores.

O preço é baseado em GigaBytes por segundos (RAM) com a adição do número de solicitações para AWS Lambda. Cada serviço tem um plano gratuito e eles são quase equivalentes. Como você pode ver, Lambda é um pouco mais barato para GB / s, mas tem um custo relacionado a solicitações que o Cloud Functions não tem, então o custo é quase o mesmo em geral. Claro, se você precisa executar tarefas que consomem memória e usam poucas solicitações, você deve usar o Lambda. A principal vantagem do IBM Cloud Function, em nossa opinião, é que sua pilha é de código aberto. É totalmente baseado no Apache OpenWhisk e também pode ser implantado em uma infraestrutura privada.

Etapa 2: aprendizado de máquina

Um campo em que as pilhas IBM e AWS oferecem serviços semelhantes é o de aprendizado de máquina: Amazon com seu SageMaker e IBM com Watson Machine Learning. Os dois serviços são em muitos aspectos muito semelhantes: ambos se apresentam como ferramentas para ajudar cientistas de dados e desenvolvedores a construir, treinar e então implantar em ambientes prontos para produção seus modelos de aprendizado de máquina, mas as filosofias que as duas empresas adotam variam um pouco. Ambos os serviços permitem que você escolha entre diferentes graus de controle nos modelos que você usa. No Watson ML, você tem alguns modelos integrados que já são treinados para fazer algumas tarefas muito específicas: por exemplo, se você quiser reconhecer quais objetos estão presentes em uma imagem, basta importar o modelo VisualRecognitionV3 e passar para ele a imagem que você deseja analisar. Você também pode construir um “modelo customizado”, mas no Watson ML isso significa principalmente pegar um modelo já construído e fazer nosso treinamento nele, portanto, a customização é bastante limitada. É importante notar, porém, que nem SageMaker nem Watson ML são as únicas maneiras de fazer aprendizado de máquina nas pilhas de seus desenvolvedores, eles são apenas serviços que visam tornar a vida dos desenvolvedores mais fácil. A plataforma Watson ML também suporta muitas das bibliotecas de aprendizado de máquina mais populares, portanto, você pode até construir um modelo do zero com PyTorch, Tensorflow ou bibliotecas semelhantes. Você pode usar essas bibliotecas diretamente ou usar os modelos pré-fabricados, não há meio-termo. Além disso, o Watson ML não oferece suporte à biblioteca de escolha da Amazon, Apache MXNet, que, em vez disso, possui suporte de primeira classe no SageMaker.

A abordagem do Amazon SageMaker, mesmo ao usar opções integradas, é um pouco mais de baixo nível: em vez de fazer você escolher a partir de modelos pré-fabricados, permite que você escolha entre uma infinidade de algoritmos de treinamento já implementados, que você pode usar ao construir seu modelo de uma forma mais tradicional. Se isso não for suficiente, você também pode usar seu próprio algoritmo. Essa maneira de fazer as coisas certamente requer mais conhecimento sobre como o aprendizado de máquina é feito em comparação com apenas usar um modelo treinado no Watson ML.

À primeira vista, pode parecer que o Watson ML é a maneira “fácil e rápida”, sendo o Amazon SageMaker a mais complexa de configurar. Isso pode não ser totalmente verdadeiro de alguns pontos de vista, já que o SageMaker é estruturado para fazer tudo rodar em um Notebook Jupyter, enquanto para os mesmos recursos no Watson ML você precisa configurar muitos sub-serviços diferentes da IU da web. O pré-processamento dos dados também possui espaços dedicados no serviço IBM, enquanto o SageMaker depende de você fazer tudo a partir do código em seu notebook. Isso mais o fato de que os notebooks Jupyter não são exatamente a melhor escolha do ponto de vista da engenharia de software, pode impedir o SageMaker de escalar muito bem na produção. Ambos os serviços têm mecanismos muito bons e simples para implantar seu modelo e disponibilizar APIs para ele no mundo externo.

Concluindo, o Watson ML tem um desempenho melhor em grandes projetos onde os notebooks Jupyter começam a mostrar seus limites e onde você não precisa de muita customização no que o próprio modelo faz. O SageMaker é muito melhor quando você precisa de mais flexibilidade na definição dos algoritmos, mas ao usá-lo, você precisa levar em consideração o fato de que precisa contar com os Notebooks Jupyter, que podem não escalar bem na produção. Uma solução poderia ser desacoplar o resto do código do modelo o máximo possível, de modo que o código nos notebooks reais não fique muito grande e possamos organizar melhor nosso software nos outros módulos que usam apenas a API do nosso modelo.

Etapa 3: Streaming e análise de dados

Os serviços de streaming de dados são cruciais para lidar e analisar grandes fluxos de dados em tempo real. Esse fluxo pode ser da nuvem para o dispositivo dos usuários, como um streaming de vídeo, ou dos usuários para a nuvem, como telemetria IoT e leituras de sensores. Especialmente no segundo caso, poderíamos ter uma situação em que fontes únicas carregam pequenas quantidades de dados, mas quando consideramos a taxa de transferência geral, proveniente de todos os dispositivos, consome uma largura de banda considerável, portanto, faz sentido usar um serviço especializado para lidar com tal fluxos de dados. Sem manipular esse fluxo contínuo diretamente, teríamos que colocar em buffer as informações recebidas em um armazenamento temporário e, em uma segunda vez, processá-las com algum mecanismo computacional. O problema desta última abordagem é que teríamos que coordenar mais serviços diferentes para alcançar o que um único serviço de fluxo de dados já faz sozinho, aumentando a complexidade da manutenção e configuração do aplicativo. Além disso, o buffering pode, em princípio, fazer com que nossa aplicação não seja mais em tempo real, uma vez que para um item ser processado é necessário que todos os outros itens anteriores a ele também sejam processados, e adicionar políticas de precedência ao buffer pode, novamente, aumente a complexidade drasticamente. Resumindo, os serviços de streaming de dados oferecem manuseio do fluxo de dados em tempo real, com uma configuração fácil, e podem fornecer análises sobre os dados recebidos. Aqui, comparamos os dois principais serviços de streaming da pilha IBM e AWS, ou seja, IBM Streams e AWS Kinesis.

Começamos observando que todos os recursos básicos que podemos desejar de um serviço de streaming são oferecidos pela IBM e pela AWS. Esses recursos incluem taxa de processamento virtualmente infinita, baixa latência e análise de dados em tempo real. Como estamos falando de serviços profissionais, ambos oferecem ferramentas de nível de produção para implantação e automação.

Por falar em análise de dados, os dois serviços oferecem como opcional, fazendo com que você pague apenas se precisar ou não. No caso do Kinesis, quando você não precisa de análises, mas apenas de manuseio do fluxo de dados, os preços são cobrados por GB processado ao invés do tempo de processamento, como no caso da IBM. O preço por GB será geralmente mais barato do que o preço por hora, uma vez que você está pagando apenas pelo tráfego de entrada. No restante desta postagem, consideraremos o IBM Streams e o AWS Kinesis com o recurso de analítica de dados habilitado.

Streams e Kinesis fornecem integração com diferentes serviços para pré-processamento e filtragem dos dados recebidos antes de transmiti-los para análise de dados, respectivamente com Apache Edgent e AWS Lambda. Embora esses serviços sejam radicalmente diferentes um do outro, iremos discuti-los apenas do ponto de vista dos dois serviços de streaming. A diferença fundamental entre os dois é que o Apache Edgent é executado no dispositivo, enquanto o AWS Lambda é executado na nuvem. Isso traz muitos prós e contras: do lado da Lambda, temos um serviço flexível e fácil de usar com uma integração perfeita com o Kinesis, mas exige que os dados já estejam carregados para a nuvem, perdendo assim em eficiência e pagando Kinesis também para os dados que eventualmente serão descartados. Em vez disso, do lado do Edgent, temos que a maior parte da computação é feita, bem, na borda da rede (portanto, nos dispositivos) antes de enviar dados inúteis na nuvem. A principal desvantagem é que o Edgent é uma estrutura grande, que pode exigir tempo para ser configurada e pode ser complexa de manter. Outra diferença que pode ser relevante na escolha de uma plataforma é que o Edgent é totalmente open source, o Lambda não. Isso pode ser visto como um profissional, já que ter acesso ao código que você ou seu cliente irá executar é sempre uma coisa positiva, tanto como um contra, porque pode haver situações em que você precisa de suporte urgente que não pode ser fornecido em todos os ambientes de código aberto.

Outros recursos que podemos mencionar é a autoescalabilidade do Kinesis dos recursos alocados. Na verdade, o hardware que oferece é composto por várias chamadas Kinesis Processing Units (KPUs) rodando em paralelo, onde uma KPU oferece 1 vCore e 4 GB de RAM. Seu número depende das necessidades do aplicativo e são alocados de forma dinâmica e automática (o que você paga é de fato o tempo de CPU vezes o número de KPUs), apenas lembre-se de que é uma política do Kinesis cobrar um KPU a mais se você usar um Java aplicativo. O IBM Streams, ao contrário, não oferece esse tipo de flexibilidade, oferecendo a você um container com hardware fixo, mais detalhes quando falamos de preços. Por outro lado, o IBM Streams é mais aberto do que o Kinesis, uma vez que faz interface com a WAN por meio de protocolos comuns usados, como HTTP, MQTT e assim por diante, enquanto o Kinesis é fechado para o ecossistema AWS.

Como comparação final, vamos falar sobre preços e deixe-me dizer que a IBM não funciona muito bem neste ponto. Configuramos soluções diferentes para três categorias diferentes (básico, high-end, ultra-high-end) para IBM e AWS e vamos comparar seus preços. Na configuração básica, temos um AWS KPU, mencionado anteriormente, em uma solução IBM com o mesmo hardware. Para o high-end temos 8 KPUs rodando paralelamente para Kinesis e 2 containers sempre em paralelo para IBM, cada um com 4 vCores e 12GB de RAM. Sempre a IBM oferece no ultra-high-end um único contêiner com 16 vCores e 128 GB de RAM, enquanto omitimos uma solução equivalente para AWS, já que se algum aplicativo exigir essa grande quantidade de RAM não será possível executá-lo em KPUs diferentes. Os preços que informamos são expressos em $ / mês, considerando um uso 24 horas por dia, 7 dias por semana. Para a configuração básica temos para IBM e AWS respectivamente 164 $ e 490 $, para o high-end 1320 $ e 3500 $, para o ultra-high-end AWS não é considerado e há apenas IBM com 6300 $. A partir desses resultados, podemos ver que o Kinesis funciona melhor para o usuário cotidiano até o nível empresarial, enquanto carece de opções para lidar diretamente com a análise de dados que exige uma enorme quantidade de poder de computação. Kinesis oferece melhor relação desempenho / $ do que IBM Streams, ajudado também pela alocação dinâmica de pequenos blocos de recursos apenas quando necessário, enquanto a IBM oferece um contêiner fixo. Desta forma, se sua carga de trabalho é caracterizada por picos, com a IBM você é forçado a superestimar as necessidades de seu aplicativo e configurar uma solução no pior cenário possível. A IBM oferece taxas de horas em vez de pagar o mês inteiro, mas não é automatizado como o Kinesis.

Etapa 4: Arquitetura IoT

A configuração de dispositivos para aws iot é bastante fácil quando comparada ao ibm watson iot. Porque no ibm watson iot, a autenticação é feita por dispositivo com token e, depois de exibir o token, ele nunca mais será exibido. Voltar para a precificação de peças ibm watson iot é bastante caro em comparação com o aws iot. Portanto, o preço em encargos do ibm watson iot é baseado em por dispositivo, armazenamento de dados, tráfego de dados. Mas, no final das contas, podemos pagar o valor uma vez e podemos adicionar mais dispositivos e dados publicados a partir de dispositivos e entregues a dispositivos.

Comece com seu dispositivo - seja um sensor, gateway ou outra coisa - e deixe-nos ajudá-lo a se conectar com a nuvem.

Os dados do seu dispositivo estão sempre protegidos quando você se conecta à nuvem usando o protocolo de mensagens MGTT leve e aberto ou HTTP. Com a ajuda de protocolos e nó-vermelho podemos conectar nosso dispositivo com a plataforma iot e podemos acessar dados ao vivo e históricos.

Use nossas APIs seguras para conectar seus aplicativos com dados de seus dispositivos.

Crie aplicativos dentro de nosso serviço de nuvem para interpretar dados.