AWS re:Invent 2018

Eis que mais um ano se passou! E mais um AWS re:Invent cheio de novidades e novas estratégicas do AWS.

Para os anos anteriores, confira: 2013, 2014, 2015, 2016 e 2017.

A idéia deste newsletter é se dedicar a análise e estratégia. Para a lista de lançamentos completa e os detalhes técnicos estas informações podem ser encontradas no AWS – https://aws.amazon.com/new/reinvent/ e canal no Youtube – https://www.youtube.com/user/AmazonWebServices/videos

Disclaimer: os comentários abaixo foram criados pelo Cloud8 e não representam qualquer posição do AWS.

Resumo estratégico

A expectativa em torno dos keynotes, especialmente do Andy Jassy (CIO do AWS), é sempre enorme. Fila se forma 1:30h antes do início da sessão e a especulação corre solta sobre o que virá de novo. Algumas novidades vem naturalmente da evolução do portifolio do produto e outras são muitas vezes surpreendentes. Este ano, dada a quantidade enorme de anúncios, as features e produtos foram também lançadas ao longo de sessões técnicas e fora de horário – mais sobre as novidades técnicas no próximo tópico.

O primeiro keynote ocorreu no evento “Midnight madness” e marcou o lançamento do AWS RoboMaker – resumidamente, um kit de desenvolvimento de aplicações de robótica usando o ferramental AWS completo na nuvem. Este novo produto reafirma a tendência do AWS de sair dos “bytes” e ter maior presença no mundo físico – lembrando que já existe o Alexa e ano passado foram lançados o DeepLens e o GreenGrass. A estratégia de suportar robôs reserva um território em um mercado que deve explodir nos próximos anos com assistentes robóticos em todos os cantos. Junto com o produto técnico, foi apresentando um kit de carro autônomo – DeepCar – para exercitar a plataforma de robôs e aproveitar para divulgar métodos de AI. É claramente para hobbystas, mas como tudo no AWS, eles devem estudar os casos de uso, coletar feedback e assim profissionalizar cada vez mais o produto. Acredito que em breve veremos cases de manufatura 4.0, robôs caseiros, tudo integrada ao RoboMaker. Também é interessante notar como o produto foi construído. Há elementos de VR (realidade virtual) para simulação (Sumerian e certamente GameLift), IOT, Cloud9, SageMaker (o DeepCar usa um algoritmo de ML com aprendizado reforçado) entre outros. Para quem, imaginou por que o AWS lançou uma plataforma de jogos e VR/AR, está aí um surpreendente uso! Quem sabe veremos um Alexa Robo em um futuro keynote?

O keynote do Andy trouxe os elementos estratégicos diretos e subliminares. As piadas e provocações com a Oracle continuam em dose maior, mas este ano ele assumiu uma postura mais defensiva em relação à concorrência. É raro ver o AWS falar dos concorrentes – como é sempre colocado, a preocupação deve ser com o cliente e não com o concorrente. Na apresentação ele enfatizou 2 aspectos: taxa de crescimento e comparativo de features entre clouds públicos. Claramente ele está incomodado com as análises de mercado que querem comparar taxas de crescimento de 45% (AWS) vs 70% (concorrência) – a base de crescimento é bem diferente e o montante absoluto que o AWS cresceu é o dobro – mas isto a imprensa não consegue comunicar. O outro ponto são as comparações ponto a ponto de produto somente pelos seus nomes que emparelhados entre os clouds e os tornam virtualmente “iguais”. A questão é que ao descer nas características detalhadas, o AWS entrega mais features. Certamente estes dois pontos – crescimento e comparativo de features – são evidentes, mas nunca se mostrou tanta preocupação em esclarecer.

Aproveitando a menção da mudança de tom em relação a concorrência, outra mudança de discurso histórico foi na ampliação da parceria com a VMWare (já iniciada desde o ano passado) que agora se torna 100% híbrida. O AWS poderá ser instalado fisicamente dentro de um datacenter de terceiros: AWS Outposts. As palavras “híbridas” e “on premise” que antes eram tabus, agora são parte do vocabulário AWS. Este é um movimento de humildade que reconhece a necessidade de que algumas empresas ‘enterprise’ possuem em integrar um ambiente híbrido e ter uma parcela da infraestrutura dentro de casa. Este é um recado poderoso que o AWS passa para o mercado e marca território contra concorrentes como o Azure Stack. Agora, quem sabe quando o termo “MultiCloud” entrará para a lista?

A palestra toda do Andy foi toda direcionada aos ‘builders’. As músicas temáticas que introduziam os tópicos alinhavam-se com os desejos dos ‘builders’. O que aconteceu com os ‘developers’? Bem, o fato é que o AWS possuindo centenas de ‘blocos’ básicos de infraestrutura, está construindo suas próprias aplicações ou facilitando a criação como se fosse um ‘Lego’. O desenvolvedor/operador/devops ‘baixo nível’ é cada vez menos protagonista da cena Cloud. Afinal, se as fronteiras técnicas das caixas-pretas dos componentes estão definidas, fica muito mais fácil construir um ‘plug and play’. Logicamente ainda não se está neste patamar, mas com APIs, templates, funções/códigos pré-definidos, marketplace, etc está mais viável a montagem. Lançamentos como AWS Control Power, Security Hub e Lake Formation são exemplos de aplicações construidas com componentes pré-existentes. Esperamos mais aplicações e mais facilidades no ‘plug and play’ ao longo dos próximos anos.

Nota: tem que filtrar a evangelização dos builders. Boa parte dos blocos técnicos foram concebidos de forma flexível e permitem customização e diferenciação específico para o negócio. Partir para a configuração ‘default’ com estes produtos novos (o equivalente ao ‘next’, ‘next’….), o ‘óbvio’ e ‘imediato’ pode ser um bom negócio no começo, mas temos certeza que em um momento iremos esbarrar em um requerimento que o ‘wizard’ não contempla – o conhecimento mais específico e o tailor made, serão então necessários. E também sempre haverá espaço para criação de regras de negócios. Entendemos que o objetivo é  diminuir o tempo gasto em concepção de arquiteturas (well architected framework), tarefas repetitivas e fora do padrão que geram superfície de ataque desnecessária, setup de servidores, bancos de dados, etc, bem como, deixar o cliente dentro do AWS a ponto de não sair mais. Neste ponto, um parceiro que conheça a fundo o AWS tem uma participação cada vez mais importante.

Um destaque técnico para a palestra do Andy foi a apresentação dos chips Graviton (ARM 64 bits) criados pelo próprio AWS (umas semanas antes o AWS já havia divulgado o suporte a chips AMD). O AWS também já havia divulgado há uns meses que estava criando os seus próprios equipamentos de rede (roteadores, switchs, cabos, etc) e desenvolvido o próprio hypervisor, cujo nome é Nitro. A criação de um chip próprio é um movimento gigante rumo à total independência de vendors, neste caso: Intel. Nenhuma empresa é grande o suficiente para ter um lugar como fornecedor garantido com o AWS. Este novo desenvolvimento, a nosso ver, foi uma jogada arrojada e com consequências virtuosas em cascata: chips mais baratos, menos consumo de energia, maior adensamento, integração com o Nitro e rede – mais performance, menos latência, mais flexibilidade – mais workloads, mais margem, mais lucratividade e mais investimento em inovação. Possivelmente workloads dos produtos AWS rodarão no Graviton. Os clientes enterprise devem querer rodar Intel, mas startups, SMBs e outros ficarão bem atendidas em usar o ARM. Alguns twits de benchmark já indicam que o custo/performance de um tipo A1 (novo tipo com ARM) é melhor que um M5. Ou seja, o AWS não falou de redução de custos explicitamente, mas contaria este lançamento como mais uma redução. Também foi lançado um chip especifico para Machine Learning – o Inferentia. Acredito que este siga a linha de não deixar espaço para concorrência – no caso, os chips TPU do Google. Este movimento também é similar ao do Graviton, trazendo elementos caros para o controle do ciclo de desenvolvimento de produtos e aumentando a margem operacional.

Seguindo a linha de manter todas as dependências dentro de casa, o AWS apresentou a rede mundial que possui: cabos submarinos, conectividade mundial, entre outros. Aparentemente está tudo interligado por infraestrutura própria. Por conta disto, foi lançado o Global Accelerator onde se usa esta rede ‘privada’ no lugar da internet pública. Ainda houve a expansão da infraestrutura para se conectar com satélites com a introdução do ‘Ground Station‘, uma estação com antenas para gerenciar envio e recebimento de dados já integrado ao AWS. Já que o próprio Jeff Bezos possui uma empresa de lançamento de foguetes, a BlueOrigin, espere outras novidades neste campo em um futuro próximo.

Sobre lançamentos, o Andy apresentou ainda mais dois tipos de bancos de dados: TimeStream e o Ledger (QLDB). O Dynamo também virou sob demanda (sem mais necessidade de pré-provisionar transações de read e write) e ganhou transações. Em termos de AI (Artificial Inteligence) também houve diversos lançamentos. Mais sobre estes 2 tópicos na próxima sessão de lançamentos.

Vamos ao keynote do Werner Vogels (CTO). Ele dedicou boa parte do início para falar sobre banco de dados. Começou aproveitando para bater na Oracle e se lembrar de um bug que tirou o banco de dados principal do Amazon.com em 2004 por 12 horas. Este episódio desencadeou uma busca/criação interna de um banco/arquitetura que fosse mais resiliente a falhas e tivesse um ‘blast radius’ menor possível. Discorreu sobre como é ruim depender de um fornecedor, o impacto causado pelo bug, mas de certa forma foi injusto. O AWS também já teve um problema grave com o DynamoDB em 2015 que praticamente tirou do ar uma região inteira por algumas horas. O importante é que Oracle e AWS aprendem com episódios como este e consertam. Na linguagem do próprio Werner: “everything fails all the time” – no cloud a falha pode ser mitigada pelo desenho de uma arquitetura resiliente multi região e multi produto. Enfim, hoje os bancos DynamoDB e Aurora são entendidos pelo AWS como nativos para Cloud e os lançamentos do TimeStream e QLDB se juntam a eles. O discurso é que o AWS é o único que possui bancos de todos os tipos preparados para a escala, segurança e resiliência a falhas em um ambiente cloud. É natural ver o AWS investindo tanto em banco de dados – afinal dados são o insumo mais importante da era digital e banco de dados devem possuir a melhor margem e rentabilidade entre os maiores produtos do AWS.

Voltando aos developers, o Werner não os esqueceu completamente. A série de lançamentos de Lambda tem o seu público cativo e certamente o ampliou. Suporta agora Ruby, C++ e runtimes próprios. A ideia é que se a linguagem não estiver no lambda, você pode trazer um runtime. Já existem runtimes para Cobol, Erlang, PHP e outros. Se quiser rodar LUA no Lambda não há impeditivo agora 🙂

Nota: filtrando a evangelização do Lambda. Como já mencionado em anos anteriores, o AWS apresenta o Lambda como uma solução para quase todos os problemas e que mesmo enterprises já o estão adotando. Os lançamentos do Lambda Layers e Step Functions Service integrations somam-se à curva de maturidade da plataforma e ajudam a resolver algumas gambiarras e limitações. Ou seja, é evidente que ainda há espaço para melhorias e maturação. O esperado era ver mais evolução nas aplicações de desenvolvimento (IDE) no suporte a Lambda que deve ficar para o futuro e problemas como warm up time em VPCs. Foi bom ver que o AWS Toolkit foi estendido a mais IDEs. Do outro lado, o AWS não divulga tão incissivamente, mas houve lançamentos em todas as frentes de developers e diversos casos de uso das instâncias EC2 tradicionais – enfim, uma comprovação de que ainda há muito investimento e casos de uso em cima de EC2 básico.

Destaques e lançamentos

Muitos produtos novos e evoluções. Veja a lista oficial completa. Abaixo, nosso resumo e comentários.

• RoboMaker. Kit para desenvolvimento de aplicações de robôs. Foi criada uma liga de corrida com o DeepCar: preliminares nos Summits mundiais e final no re:Invent. Recomendamos assistir ao vídeo da sessão ROB303 que explica como utilizar o exemplo de um robô que segue uma imagem/outro robo por meio de um algoritmo de aprendizado reforçado;
• EC2 Compute. Lançamento de novos tipos – a1: como mencionado é o suporte ao novo chip Graviton baseado em arquitetura ARM 64 bits. Se utilizar sistemas com linguages compiladas, a migração e compatibilidade deve ser praticamente instantânea. p3dn é uma instância com mais GPUs dedicada a processamento de Machine Learning. Um conceito interessante de ‘Elastic Inference’ foi lançado que permite ‘attachar’ GPU para tipos comuns de instância (um m5 por exemplo), usar GPU e depois desconectar (sem necessidade de upgrade/downgrade ou compatibilidade de AMI). c5n são instâncias com rede de notáveis 100 Gbps;
• HPC: novo tipo de rede que diminui a latência entre nós de instância em uma malha HPC – Elastic Fabric Adapter. O AWS usará um protocolo de rede proprietário (SRD) que chega a 100 Gpbs. Já adaptaram bibliotecas como MPI para suportá-lo;
• Rede: rede global do AWS à disposição para todos com o Global Accelerator e uma aplicação para consolidar a gestão de rede e gerenciar melhor a complexidade dos vários blocos básicos de rede em multiconta (VPC, Gateway, ACLs, NAT, Peering, etc) – Transit Gateway. Vale destacar que é necessário conhecimento de rede para melhor utilizá-lo e logicamente deve se valer de montar um ambiente de testes antes de aplicar em produção. E como mencionado nos comentários, houve o lançamento do Ground Station;
• IoT: evolução na gestão com IoT SiteWise e IoT Things Graph – seguindo a linha de construir aplicações no topo dos blocos de infraestrutura. Mais eventos na plataforma com o IoT Events – muito poder em monitorar determinados tipos de eventos e disparar ações para SQS, SNS e/ou Lambda;
• Container: lançamento do FireCracker – criação de um container mínimo (menos código, menos drivers) e seguro que tenha tempo de inicialização (warm up) o mais rápido possível e com o menor overhead. Foi disponibilizado em open source (escrito em Rust) e já é usado no Lambda para que fique mais rápido e consuma menos memória. Para o AWS significa redução de custos e para o usuário mais velocidade sem abrir mão de segurança;
• AI: Comprehend medical – suporte a detecção de vocabulário médico na conversa e estruturação do conhecimento. Alinhado com o lançamento do Translate que define vocabulários específicos para ser mais preciso. SageMaker Neo – faz deploy do inference (isto é, do modelo treinado) em diversos endpoints como instâncias EC2, IoT, GreenGrass e outros. AWS suportará mais destinos ao longo do tempo. Imaginamos que os modelos treinados do RoboMaker devam se valer desta funcionalidade no momento do deploy de forma transparente, uma vez identificado o hardware do robo destino;
• Sagemaker Ground Trust: label automático de imagens – por algoritmos ou por terceirização humana (Mechanical Turk por exemplo) – ajuda na categorização de dados para poder servir de fonte de treinamento de modelos de AI;
• Sagemaker RL: suporte a algoritmos ‘Reinforcement Learning’;
• Mercado de algoritmos de ML: modelos prontos e plugáveis que são fornecidos por terceiros e que podem ser utilizados prontamente;
• Novas aplicações de gestão: Control Power, Security Hub e Lake Formation – aplicações no topo de blocos básicos;
• Marketplace: produtos do marketplace podem fazer deploy em container e não somente mais AMIs. Lançamento de marketplace de algoritmos de AI e funções Lambda:
• Transferência de dados: Data Sync e SFTP. O SFTP é um ‘proxy’ SSH na frente do S3. Segundo o AWS, muitos clientes usam esta topologia para transferir arquivos de sistemas legados (ou simplesmente desconhecem ou não querem usar as APIs) e resolveram facilitar. O Data Sync permite a transferência de dados de um lado para outro: cloud <=> on premise. Pode parecer ‘trivial’ transferir dados, mas quando se fala em sincronizar GB/TB, fontes de dados e frequências diferentes, este produto pode ser bastante útil;
• S3: mais tiers de armazenamento, além de um tier inteligente que distribui o uso dependendo do uso e acesso de arquivos – Glacier Deep archive. Também foi lançado um mecanismo de fazer operações no S3 de forma assincrona, já que todas as aplicações tinham que implementar formas de correções de erro, retentativas, etc.
• EFS: lançamento de filesystem nativo (SMB) para Windows e distribuido (Lustre) – ambos atendem a casos de uso onde é necessário um filesystem centralizado e escalável por até milhares de instâncias EC2. Funciona multi VPC e multi conta. Um exemplo de um caso de uso seria escrever logs de todos os servidores em diretório separados em um único ponto (logicamente poderia ser usado CloudWatch Logs, mas o AWS sempre deixa ao gosto do freguês);
• Banco de dados: TimeStream – armazenamento de séries temporais. Ex: um dispositivo IoT que tenha propriedades modificadas ao longo do tempo encontra o modelo perfeito e performático para armazenar este schema de dados;
• Banco de dados: QLDB (Ledger) – banco de dados com histórico de mudanças registrado com assinaturas digitais para que os itens não sejam modificáveis. A base do novo produto lançado de Blockchain;
• DynamoDB: sob demanda e transações. Muito comemorado o fato de não precisar mais provisionar a capacidade de unidades de leitura e escrita em cada tabela Dynamo. Este processo quase sempre levava a super dimensionamento de capacidade ou a gargalos que causavam gasto demasiado ou problemas na aplicação por conta de picos ou falta de monitoração adequada. O uso sob demanda tira esta preocupação em praticamente todos os casos de uso. Os modelos de preço para sob demanda e capacidade provisionada são bem diferentes então não é possível saber o custo/benefício, mas certamente o sob demanda deve ficar bem mais em conta em um cenário variável (e não precisa ser com picos – um cenário onde por exemplo, a noite o acesso cai a próximo de zero já é suficiente para justificar a mudança de modelo). As transações são necessárias para manter consistência de dados e evitar retrabalho na camada de negócios em reescrever lógica de tratamento de rollback e cenários onde dados não podem ser escritos atomicamente;
• OCR: Textract – produto para extrair informação de documentos digitalizados. Segundo a apresentação, há uma inteligência extra ao se levar em conta o formato da informação e não somente o reconhecimento dos caracteres. Formulários, campos de texto são transformados automagicamente em dados e podem ser inseridos diretamente em um banco de dados. Imagine milhões de formulários digitalizados de saúde poderiam ser inputados em um banco de dados ao ter suas imagens processadas por esta API;
• Recomendações: Personalize – segundo o AWS é o mesmo serviço de recomendações da Amazon. Utiliza modelos de AI, lê os dados do cliente e fornece recomendações. Não somente para loja virtual, mas quaisquer casos de uso que envolva relações em rede;
• Forecast: serviço de estimativa de uma série temporal. Lançam-se os dados e deles se extrai uma previsão para o futuro. Integra com SAP, Oracle e outros sistemas com RDBMS;
• Blockchain: tecnologia HyperLedger Fabric ou Ethereum para gerenciar uma rede blockchain. Utiliza o QLDB por trás;
• Aurora Global: replicação de dados multi região (global). O banco fica acessível em várias regiões, mas a escrita de dados ainda é feita em um único endpoint;
• Lambda: Ruby e engine de linguagens customizadas – ver comentários na análise;
• License Manager: assim como os outros serviços centralizados de gerenciamento, o AWS agora possui um que controla licenças. Não somente um catálogo, mas com regras integradas ao Service Catalog que reforça complaince e pode impeder, por exemplo, um servidor de ser criado se não houver licenças disponíveis;
• LightSail to EC2: movimento natural para quem testou o AWS via LightSail e agora precisa de recursos mais sofisticados;
• Cloud Map: produto de ‘service discovery’ que agrupa recursos e os monitora (Health checks). Boa iniciativa para o mundo de microservices. Funciona com instâncias EC2, ECS/Fairgate e EKS;
• App Mesh: dedicado a microserviços. Não tivemos chance de participar de uma apresentação, mas pela descrição do post é a implementação de um proxy (Envoy) que faz monitoração e expõe APIs já bastante utilizadas. Será interessante ver a evolução e integração com o Cloud Map (a parte de Health Check e monitoração parecem sobrepostos);
• CloudWatch Insights: como o próprio nome já diz, consulta padrões e traz insights de uma massa de fontes de dados distintas. Estas consultas são feitas por meio de queries e para produtos que geram logs no CloudWatch (CloudTrail, Lambda, VPC, etc). É possível construir queries novas. Esperamos ver no futuro AI aplicada para reconhecer padrões e fazer correlações entre logs distintos (algo que produtos como SumoLogic, Splunk já fazem);
• Well Architected tool: baseado no famoso documento de Well architected, tem o objetivo de ajudar a seguir o checklist de arquitetura e avaliar se realmente foi implementado e se há desvios ao longo do tempo;
• Elemental MediaConnect: broadcast de conteúdo de vídeo – alinhado aos outros produtos de mídia da família Elemental;
• Websockets para API Gateway: bastante festejado no anúncio do Werner, mantem uma conexão persistente com o API Gateway e amplia a gama de possibilidade de ações real time, notificações, etc
• Kafka: serviço de streaming de dados baseado no Apache Kafka. O Kinesis é uma boa plataforma, mas muitos desenvolvedores preferem o Kafka por conta de funcionalidades e limitações que o Kinesis possui. Bom movimento do AWS dentro da filosofia de gerenciar os componentes mais utilizados pelo mercado.

Notas técnicas

Foram mais de 2.000 palestras. Comento aqui o que conseguimos assistir e das conversas que tivemos:

• EFS: novo tier (como o S3) mais barato para onde são movidos arquivos com pouco uso. Também suporta o acesso de vários contas e de outras VPCs. O grande desafio do EFS sempre foi o backup – que ainda não há solução além de replicar os arquivos em outro EFS (sem tier e portanto pode ficar caro).
• ALB como endpoint para Lambda e IPs – talvez uma das melhorias mais sutis e mais importantes e que poderia ter tido mais destaque. Com um único ALB será possível roteador tráfego para EC2, IP (sistema on premise, ECS/ECK por que não?) e Lambdas! Imagine fazer uma migração dentro de um domínio e precisar somente reapontar os paths do lado do cliente. Diferencialmente mudar estrutura e arquitetura, usar green/blue, testar POCs à medida que vai reapontando as URLs. Entendedores irão captar rapidamente o poder desta feature :);
• Firecracker: muito interessante, escrito em Rust (segundo pesquisa muitos desenvolvedores acham a linguagem dificil e há conceitos novos como ‘lifetimes’ e ‘borrowing’). Já vi twits de gente começando a implantar em outros clouds – natural e saudável dado que irá melhorar o produto e no fim quem se beneficiará mais é o próprio AWS;
• Hypervisor Nitro: o Nitro já havia sido apresentado anteriormente e mais detalhes foram aos poucos sendo liberados. É sabido que as instâncias bare metal rodam em cima do Nitro, que ele está melhor integrado ao hardware e aos protocolos de rede próprios do AWS, tem um overhead próximo de zero, latência de I/O de disco reduzida e camadas de segurança extras. Ele também permite rodar vários tipos de instâncias dentro do mesmo servidor permitindo um planejamento de capacidade muito melhor – imagine poder colocar t3.nano onde há espaço e não precisar de um servidor que somente rode t3s. Deve ser um ganho de escala e de produtividade significativos dentro da estrutura global. O interessante é que o Firecracker (container) – pelo menos a versão open source – foi feito com integração próxima a KVM e cgroups. Não sabemos se há uma versão de Firecracker rodando em cima do Nitro…
• z1d – é a instância mais rápida e com melhor performance para ‘single thread’;
• Cardápio de banco de dados. Um discurso forte do AWS durante todo o evento e que será repetido continuamente é de que o banco de dados relacional não é solução para tudo – “right tool for the right job”. Esqueçamos da alternativa do NoSQL momentaneamente, e imaginem problemas que envolvem gestão de IDs (autorização e autenticação), redes sociais (grafos), mudanças de estado de sensores ao longo do tempo (série temporais), ledgers com transações imutáveis assinadas digitalmente (parte do blockhain…). Tudo isto dá para fazer utilizando RDBMS, mas com performance sub ótima, excesso de código e lógica ‘acomodada’ (para não dizer outra coisa). Com os lançamentos de banco de dados, há um tipo de banco para cada caso: Cognito (ID), Neptune (grafos), Timeseries (séries temporais), QLDB (ledgers). Do ponto de vista de usuário, será mais fácil resolver os desafios. Veremos com o tempo como será a integração com outros bancos de dados e a gestão de um Data Lake (já tem algo surgindo com o Lake Formation…). Quem sabe um RDBMS (Aurora logicamente…) centralizado com data links de grafos, timeseries e outros?
• S3: como o novo lançamento dos tiers S3/Glacier, o AWS ruma para o custo de US$1,00 por 1 TB ao mês.
• Blockchain: algumas empresas que implementam Blockchain ficaram incomodadas com o respectivo produto pelo AWS. O consenso é que no AWS é uma tecnologia com as features que o Blockchain precisa, mas que isto é apenas uma pequena fração na implementação de uma cadeia completa. Blockchain no final tem mais processo e regulação do que tecnologia em si;
• Kubernetes: várias palestras sobre K8 e ECS. Segundo o AWS, 51% das implementações K8 rodam por lá. O AWS está investindo muito em ‘compatibilidade’ do K8 em sua plataforma com a liberação de diversos plugins (CNI, segurança – kube2iam, etc) open source para a comunidade, facilitando a integração com os serviços. Interessante é que o EKS (gestão do contole plane) é cross account nativo (ENI cross accounts) e é possível segmentar os conjuntos por conta AWS;
• Spot: é permitido ‘parar’ um servidor SPOT mediante um comando/API. Anteriormente o AWS era o responsável por destruir ou colocar o servidor em modo ‘hibernate’. Agora o cliente pode pedir para o servidor ‘parar’ (por enquanto somente alguns tipos de Linux) e depois religá-lo. Este procedimento permitirá novas oportunidades de redução de custos. A desvantagem é que o AWS está popularizando o mercado de spots – antes era um mercado mais voltado para HPC e servidores stateless – e agora pode ser usado para qualquer caso de uso praticamente sem risco, já que não há perda de dados ou servidores sendo destruidos a qualquer momento. Esta popularização eleva o preço de leilão e a tendência é que se aproxime mais do preço sob demanda. Bom para o AWS, não tão bom para o cliente – mas diga-se de passagem o mercado SPOT sempre foi um ‘plus’ para o usuário mais avançado e que conseguia reduzir os custos muitas vezes com muita criatividade;
• AI: como não poderia deixar de ser, há um investimento pesado em tornar o uso de AI o mais fácil. Desde o uso dos dados (trazer os dados, filtrar, normalizar, estruturar, etc), compilação, escolha do modelo e deploy do modelo em quaisquer endpoints. O uso de GPUs está sendo otimizado com adaptação dos frameworks populares (TensorFlow, MXNet e outros) para rodar com maior paralelismo e ocupar praticamente 100% do processamento. Há ainda o uso de GPUs com processadores normais (Elastic Inference) e processador próprio (P2/P3/AWS Inferentia).
• Ferramental: vale buscar pelas palestrar sobre CI/CD e novas ferramentas de desenvolvimento (como o AWS Amplify Console). O console das ferramentas de desenvolvimento está reorganizado. Os pipelines com CodeCommit e CodeBuild ficaram mais flexíveis com suporte ao GitHub como source e integração com CloudWatch Events para disparar eventos dependendo do que ocorrer – um erro de build por exemplo;
• Log Analytics: o standard parece ser uma composição de Elastic Search com Kibana (ESK). Algumas palestras sobre este cenário e diversos citações que após gerar os dados, eles caem em um ‘ESK’;
• Metadata protection: assistimos uma palestra muito interessante de um ataque que rouba o metadata de um servidor EC2 que roda com SSM habilitado. Ele poderia pegar as credenciais temporárias e usá-las para acessar a infraestrutura. Foi dividido em 2 partes: como identificar um ataque e como mitigar. Veja mais neste post;
• São Paulo: nossa região continua sendo subpriorizada. Infelizmente muitos dos lançamentos não suportam a região. A boa notícia é que não está estagnado e aos poucos as novidades vem chegando – recentemente o Glacier foi disponibilizado que já era pedido há anos.

Cases:

• Fortnite: eventos com até 8.3 milhões de acessos simultâneos. Novos games como Food Fight;
• F1: Formula 1 utilizará recursos de processamento de dados em real-time e AI para mostrar estatísticas e probabilidades de manobras;
• GE: utilizando SageMaker para criar/treinar modelos de AI e depois fazer o deploy no ‘edge’ – equipamentos de raio X, ultrassom e outros;
• Global Telecom Filipinas: migrando all-in para cloud;
• Sumologic: previsão que mundo irá gerar 16 zettabytes em 2020;
• Allians Germany: “10% digital + human touch” – estratégia digital com forte componente de relacionamento e atendimento humano, seja por meio de app de celular ou postos físicos;
• Guardian Life Insurance: empresa de 158 anos de idade que trata de seguros, está se reinventando e inovando apesar da cultura legada e conservadorismo;
• VMWare: CEO da VMWare compartilhou o lançamento do AWS Outposts;
• S3: a diretora diretamente responsável pelo S3 discorreu sobre arquitetura e sobre a importância da segurança e durabilidade – testes contínuos de integridade dos objetos armazenados são realizados constantemente. A durabilidade é levada muito a sério, a ponto de se o AWS perder um data center inteiro, os dados não deveriam ser afetados;
• Brasil: Nubank (STP15), comunidades (DIG204 – temos comunidades entre as mais ativas do mundo!)

Enfim, novas oportunidades foram criadas e mais desafios para o dia a dia de todos.

Contem com o Cloud8 para ajudá-los neste ônus administrativo e de automação, bem como tirar vantagem da atualização constante da nossa plataforma! Há muitas funcionalidades que podemos e iremos implementar para melhorar ainda mais a plataforma.

Fiquem à vontade para compartilhar este post! Dúvidas, críticas ou sugestões, entre em contato.

Obrigado
Renato Weiner
CIO/Founder

Conheça o Cloud8! Acesse nossa calculadora e simule o seu cenário, ou crie sua conta para um teste de 15 dias sem compromisso clicando aqui.