- Melhores práticas de gestão de custo na AWS com SPOT
- Melhores práticas de CI/CD na criação de aplicações modernas na AWS
- Construa aplicações utilizando Inteligência Artificial na AWS
- Construindo data lakes na AWS
- A importância da estratégia de redes: acelere e proteja suas aplicações na AWS
- Quer desenvoler aplicações Serverless seguindo as melhores práticas da AWS? Te ensinamos em 12 passos!
- Saiba mais sobre o AWS Fargate para aplicações em Containers
- Dicas importantes sobre Amazon Redshift: escalando armazenamento e computação
- Bases de Dados na AWS: conheça a ferramenta certa para o seu tipo de dado
- Visão geral dos serviços de identidade da AWS: habilitação e proteção da sua jornada na nuvem
- Migrando suas aplicações com segurança e governança: AWS Landing Zone
- Análise detalhada do Amazon Elastic Container Service for Kubernetes (Amazon EKS)
Cleber Moraes, diretor da AWS no Brasil. Fernando Sapata, Principal Solutions Architect.
- Case Embraer: Manutenção preventiva com AWS
- Coletar dados do avião e voo, processar para prever falhas e salvar vidas
- Criptografia na AWS: Serviços (RDS, EBS, etc) já vem com criptografia disponível, basta clicar em um botão.
- Não impacta na performance
- Ferramentas para migração de dados on premise
- Direct Connect (DX), permite uma conexão de rede direta com a AWS
- Snowmobile, um caminhão da AWS vai à sua empresa para transferir os dados
- Serviço de Migração de Banco de Dados (DMS)
- Levar e tirar os dados da nuvem
- Migrar de banco relacional para não relacional
- Cloud Híbrida
- Direct Connect
- Snowball Edge, dispositivo que permite rodar serviços da AWS localmente. Otimizado também para transferência de dados em larga escala.
- VMware on AWS, migração de ambientes VMware
- Case Banco RCI:
- Arquitetura:
- Arquitetura:
- Microserviços
- Cada microserviço faz uma coisa
- Ligado a uma única base de dados
- Os microserviços não acessam as bases dos outros microserviços, conversam entre si
- Requer um time orientado a microserviços
- É necessário manter consistência no contrato de API
- Usar versionamento para não quebrar o contrato (
/v1/,/v2/) - [COLOCAR LINK AQUI](App mesh): Camada única de comunicação entre os microserviços
- "Sabores" de computação na AWS
- EC2
- Até 24TB de RAM
- Famílias otimizadas para cada caso de uso
- Família "m" é de propósito geral
- Containers
- ECS: Serviço de orquestramento de containers
- Fargate: Serverless containers
- AWS cuida de toda a infra
- Gerenciamento através de tasks
- EKS: Serviço de orquestramento de Kubernetes
- Gerenciado
- Deploy do master em 3 zonas de disponibilidade diferentes
- McDonalds: 20 mil pedidos/segundo via Kubernetes
- Registro de imagens Docker: AWS ECR
- EC2
- Serviços serverless AWS
- Banco de dados
- Bancos closed-source (ex. Oracle)
- Lock-in, auditoria, preço muito alto nas licenças
- Bancos Open Source
- Lento, não tinha um suporte enterprise
- Amazon Aurora
- Serviço de banco
- Compatível com MySQL e Postgres
- Até 3x mais rápido que o Postgres e 5x mais rápido que o MySQL
- Durável, altamente disponível e feito para escalar
- DynamoDB
- Banco chave-valor
- Provisionado
- Leitura e Escrita on demand
- Aguentou 2 milhões de transações por segundo no Amazon Prime Day (loja da Amazon.com)
- Bancos closed-source (ex. Oracle)
- Blockchain
- QLDB
- Serviço de Blockchain gerenciado
- Hyperledger
- Ethereum suportado em breve
- Machine Learning
- AWS tem herança da Amazon.com, onde criaram e utilizavam diversos serviços que hoje são disponibilizados
- Amazon Alexa
- Recomendações de produtos
- Objetivo da AWS: Tornar ML simples
- Usar o tempo do desenvolvedor fazendo o que realmente gera valor, deixar a parte técnica com a AWS
- Infraestrutura
- Frameworks Machine Learning
- Tensorflow - Problema de escala
- Pytorch
- MXNet
- AWS AMI para TensorFlow (90% de eficiência)
- Inferência (validar informaçao no modelo) representa 90% dos custos
- Elastic Inference
- Aceleração de GPU para qualquer instância
- AWS Inferentia
- Chip p/ mais performance, menos custo
- Instâncias G4
- Família para treinar modelos de imagem e vídeo
- Serviços Machine Learning
- SageMaker
- Jupyter Notebook gerenciado
- Ground Truth
- Treina com 80% das informações, valida com os outros 20%
- Gerar massas sintéticas
- Treinar e fazer deploy do modelo
- SageMaker
- Serviços Inteligência Artificial
- Computer Vision
- Rekognition: Modelo já treinado
- Textract: Extração textual
- Polly: Voz - Text to Speech
- Comprehend: Interpretação textual
- Lex: Interface para chatbots
- Forecast: Previsões em séries lineares
- Personalize: Personalização e recomendações
- Machine Learning University
- Deep Lens
- Câmera imbutida com Machine Learning
- Não precisa de conectividade
- DeepRacer
- Liga de corrida de carros autônomos
- https://ai.aws
- Computer Vision
- AWS tem herança da Amazon.com, onde criaram e utilizavam diversos serviços que hoje são disponibilizados
Thiago Morais, Solutions Architect Manager
- Abordagens modernas
- Acelerar entrega de novos serviços com alta qualidade = CI/CD
- Simplificar manuseio de ambientes = Serverless
- Diminuir impacto de alterações de código = Microserviços
- Automatizar operações = Infraestrutura como código
- Obter insights, métricas = Observabilidade
- Números caindo podem indicar problemas de infra
- Proteger o cliente e o negócio = Segurança fim-a-fim e conformidade
- Efeitos do CI/CD
- Deploys passam de semanas/meses a horas/dias
- Tempo de entrega passa de meses a dias
- Redução de até 45% na taxa de erro
- Pipeline de testes
- Processo cíclico, objetivo é iterar rápido
- Integração contínua
- Compreende do código ao build da aplicação
- Testar código em um ambiente consistente e replicável
- Lint, análise estática
- Gera um artefato pronto para deploy
- Feedback quando build falha
- AWS CodePipeline
- Serviço de CI
- EC2, Container, serverless
- AWS CodeBuild
- Serviço de build gerenciado, compila o código, roda testes e gera artefato
- Escala automaticamente se a fila de builds estiver muito grande
- Compilações são executadas em um container Docker, consistente e imutável
- Sintaxe Yaml
- Define quais comandos rodar (ex.
npm ci,npm test, etc) - Define os artefatos gerados
- Define quais comandos rodar (ex.
- Deploy Contínuo (CD)
- Envolve todo o processo, do código à produção
- Entregas mais frequentes
- Possível ter um "Gatekeeper", que aprova ou não os builds
- Implantar versões em ambientes de teste
- Canary Releases, Blue/Green Deployments, Rollouts, etc
- AWS CodeDeploy
- Disponível também on-premises
- Deploy em EC2, Lambda ou servidores locais
- Rollback automático em caso de falhas
- Sintaxe Yaml
- Escolha a velocidade de implantação e os grupos
- Um por vez
- Metade por vez
- Todos de uma vez só
- Grupos de desenvolvimento
- Grupos de produção
- Integrado c/ AWS Lambda
- Blue/Green Deployments
- AWS Fargate e ECS
- Integra-se com Load Balancer
- Cria um target group com a nova versão
- Rollback em caso de alarme no CloudWatch
- Infraestrutura como código
- Automatizar as operações
- Consistência entre ambientes
- Documentar os processos não funciona sempre, humanos erram e pulam etapas
- Permite testar mudanças na própria infraestrutura
- Rodar teste de carga, coletar métricas
- Qual o melhor tipo de instância para esse microserviço?
- Pode-se descobrir trocando o tipo da instância para rodar testes, mas com uma infra como código isso fica bem mais fácil
- AWS Serverless Application Model
- Framework open source para aplicações Serverless
- Igual ao CloudFormation, porém para Serverless
- AWS Cloud Development Kit (CDK)
- Escrever infra c/ TypeScript
- Separar em módulos replicáveis
- Leitura recomendada:
Hugo Rozestraten, Big Data and Analytics Specialist Solutions Architect
Baseado em uma conversa que tive com Thiago Morais no final do evento
- Separar cada microserviço em um repositório git diferente (facilita o deploy)
- Começar apenas com alguns, e depois ir "quebrando" o sistema porém mantendo a mesma interface de API
- Compatibilidade pode ser feita através de versionamento das rotas de APIs. Ex: /v1/ dá acesso a um microserviço grande, porém na /v2/ os microserviços já estão mais bem divididos
- Você nunca vai conseguir "quebrar" a aplicação em microserviços de uma forma boa na primeira tentativa
- Pensar em "quebrar a aplicação em pontos de falha"
- Ex: Separar um e-commerce em Catálogo, Login e Checkout
- Em uma Black Friday, o sistema de Login pode falhar mas os usuários ainda vão continuar vendo os produtos e finalizando pedidos se já estiverem logados
- Dica de leitura: https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html