Nesta sessão, pela voz do cliente e do parceiro, você irá conhecer um pouco da arquitetura do Advanced-Beer-as-a-Service, desenvolvido pela ChoppUp.com.br em parceria com br.Capgemini.com. A solução conta com AWS IoT, Step Functions, S3, Lambda e mais.
https://aws.amazon.com/pt/blogs/startups/internet-of-beer-introducing-simple-beer-service/
30 segundos para apresentar a empresa, rapidamente
Os 4 (máximo) maiores desafios do projeto, que foram resolvidos pela utilização da nuvem da AWS
Diagrama de solução, e explicar a solução, vantagens, etc
Titans Group precisava garantir que a solução de storage do produto atendesse os requisitos mais exigentes do ponto de vista de durabilidade, disponibilidade e confidencialidade das informações dos usuários.
Também era preciso garantir a escalabilidade tanto do ponto de vista técnico quanto do ponto de vista de custo.
Até então, a ChoppUP utilizava servidores em serviços de hospedagem tradicionais para realizar a integração com serviços web.
A AWS forneceu três grandes benefícios à ChoppUP:
Acesso a uma plataforma de IoT robusta, de alta-disponibilidade, e de fácil uso: a AWS IoT.
A oportunidade de utilização de serviços sem servidor, permitindo à ChoppUP pagar somente pelo que de fato é utilizado.
Acesso à rede de parceiros e arquitetos de soluções AWS, para que a ChoppUP possa manter o foco no desenvolvimento das tecnologias diretamente relacionadas à chopeira.
Aqui apenas explicar que na chopeira há um código em execução que é dividido em duas partes relevantes:
Há um código em Python que submete comandos à chopeira, solicitando os dados do sensor e também enviando comandos de estado à chopeira. Foi escolhido python porque os testes iniciais com a biblioteca NodeJs não deram bons resultados, mas ainda estamos avaliando a possibilidade de uniformizar o código em torno de nodeJs.
Há um código em nodejs que realiza a integração com a AWS IoT, que é por onde são enviados para a nuvem os dados do sensor, as mudanças de estado da chopeira, e há a integração com os serviços de validação de códigos e liberação de chopp. Essa parte basicamente contém uma máquina de estados para cada bico, que controla o seu estado de acordo com o estado informado pela chopeira e as requisições vindas do IoT.
Tanto uma Amazon Echo quanto um dispositivo não integrado (não faz parte da chopeira) de QRCode estarão previamente vinculados a um par {chopeira,bico}.
Alexa ou Leitor de QRCode entram em contato com API-Gateway para pedir a validação do código (a interação, para Alexa, começa quando o código é fornecido).
API Gateway chama lambda de consumo de código.
Lambda verifica o status do par {chopeira,bico} por meio da Shadow, para agilizar resposta caso não esteja disponível.
Solicita ao par {chopeira,bico} que entre em estado de validação de código, para não sofrer interferência de outras requisições.
Chopeira muda de estado do bico, alterando a shadow.
Lambda (ainda rodando) após 500ms consulta novamente o estado do par {chopeira,bico} para verificar se a mudança foi aceita.
Se a mudança foi aceita, faz o consumo do código no DynamoDB. Se o código for válido, retorna Valid=True para o lambda, junto com outros dados.
Lambda (ainda rodando) submete a validação à chopeira por meio de um tópico, o que a informa o resultado da validação. A lambda também responde ao API-Gateway.
Conjunto de ações que ocorrem após a leitura do valor do tópico:
A chopeira libera o chopp (caso seja válido, senão volta para o status inicial).
O resultado do consumo é publicado num tópico.10. AWS IoT Rules capturam os dados do tópico e fazem o que for mandado (enviar para Kinesis, publicar no DynamoDB etc)
Precisamos fazer um cálculo realista aqui.
Precisamos fazer um cálculo realista aqui.
Desenvolvimento do portal de gerenciamento de eventos e chopeiras.
Desenvolvimento do ChoppUP Alexa Skill.
Evolução na parte de BI/BigData e Real-time analytics.
Otimização dos custos de hardware.
… (João, o que você achar que faz sentido.)..
Outro diagrama se for necessário, detalhando ou com foco em outra parte da aplicação