/blog

AWS re:Invent 2018 – resumo e análise

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 RubyC++ 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

Database news! RDS, Aurora Serverless, Google Cloud SQL, Azure SQL

RDS: melhorias Aurora e suporte a Aurora Serverless

O RDS é um componente praticamente imprescíndivel nos projetos de cloud, mas também é um dos que implica em maiores custos. O Cloud8 já vem ajudando na redução de custos por meio de iniciar e parar bancos de dados (ambiente de testes por exemplo) e upgrade/downgrade, bem como mudança entre MultiAz/SingleAz.

Outro fator preponderante é a segurança de dados. E nisto ajudamos com toda a gestão do ciclo de backup, disaster recovery (cópia para outra região) e backup off site (cópia cofre).

O Aurora – versões compatíveis ao MySQL e PostgreSQL do AWS – tem-se tornado muito popular e o AWS aumentou significantemente a opção de tipos. Com isto se tornou economicamente viável utilizar o Aurora para ambientes de testes com os tipos menores. A pedido dos clientes, incrementamos o suporte a automação de redução de custos e segurança para o Aurora.

Novidades Aurora:

  • Tão logo o AWS passou a suportar stop/start de instâncias Aurora, o Cloud8 também já suportou;
    Upgrade e downgrade;
  • Backup manual – permite que escolha precisamente o momento do backup, retenção flexível (AWS limita a retenção diária com o máximo de 35 dias) e a frequência de limpeza;
  • Cópia para outra região;
  • Cópia-cofre/backup offsite para uma outra conta AWS.

Aurora Serverless

  • Backup manual e políticas de retenção;
  • Catálogo, backup status e monitoração de eventos;
  • Análise de custos detalhada para cada instância;
  • o Aurora Serverless ainda não suporta cópia entre regiões e nem cópia cofre – mas tão logo o AWS libere o suporte já estamos preparados para suportar

Já para o RDS em geral, melhoramos o suporte a todas as ações quando há encriptação com KMS.

Suporte a Google Cloud SQL

O serviço de banco de dados relacional do Google Cloud é o Cloud SQL. O Google suporta o MySQL (primeira e segunda gerações – 5.6/5.7) e o PostgreSQL de forma gerenciada. Não é necessário instalações de componentes, atualizações, configurações, etc. O próprio Google entrega uma instância com todas as funcionalidades prontas para uso.

O Cloud8 suporta as seguintes automações de redução de custos e segurança:

  • Análise de custos por instância (e não agrupado no produto inteiro como no console GCP);
  • Inventário, informações detalhadas e edição de tags;
  • Suporte a agendamento por escolha de tags;
  • Ligar/desligar para redução de custos;
  • Métricas de CPU, conexões ao bancos, etc;
  • Backup manual e agendado;
  • Relatórios de Backup Status, backups realizados, etc;
  • Políticas de retenção GFS: escolha a frequência que quer manter os backups para fins de auditoria, retenção, complaince;
  • Exclusivo: Exportar os dados de um ou mais banco de dados para um arquivo SQL dentro de um bucket do Cloud Storage à escolha;
  • Cópia-cofre/backup offsite para um outro projeto GCP – se escolher um bucket em outro projeto (e der a permissão), tem os dados replicados offsite!

Suporte a Azure SQL Databases

A Microsoft como não podia deixar de ser, possui um serviço gerenciado do seu produto SQL Server conhecido como “Azure SQL Databases”. Nele é possível criar diversos bancos de dados SQL Server em diversos tiers com custos compatíveis com o nível de serviço: Basic, Standard e Premium. Além disto é possível escalar em termos de tamanho e número de ‘elastic pools’.

Suportamos o inventário de bancos SQL e a análise de custos individual de cada banco de dados. O Cloud8 não cobra por Azure SQL pois ainda queremos implementar mais funcionalidades de automação de redução de custos e de segurança.

Nota: o uso de banco de dados (RDS, Cloud SQL e Azure SQL) não é obrigatório no Cloud8. Você pode configurar as regiões que deseja incluir e excluir na sincronização de banco de dados – basta entrar na lista de provedores e clicando em “Configurar” escolher as regiões monitoradas.

Tem algo que gostaria de ver suportado em banco de dados? Conte-nos!

Agendador de Workflows: suporte a tags e integração com provisionamento

O agendador de Workflows é sem sombra de dúvidas uma das funcionalidades mais populares da nossa plataforma. Com ele, os clientes tem reduzido custos significantemente seja parando/iniciando servidores e/ou realizando upgrade/downgrade nos horários de baixo uso e em picos programados. Também, tem cuidado de toda a estratégia de backups, criando backups recorrentes com parâmetros à escolha, políticas de retenção corporativas e estratégias de disaster recovery e business continuity (cópia cofre para outra conta, no caso do AWS). Além disto há uma série de outras tarefas como execução de scripts SSM sendo utilizada para se fazer backups no S3, orquestração em conjunto a Load Balancers, checagem de serviços internos, mudança de DNS, cópia e replica de ambiente de testes e assim por diante.

O agendador sempre foi pensado como um componente estratégico e missão crítica dentro do seu cloud e um dos maiores pedidos que tínhamos era como integrá-lo a operação do dia a dia sem a necessidade de execução de procedimentos manuais, sujeitos a erro e difíceis de documentar. Em um primeiro momento, abrir APIs para o agendador parecia lógico, mas criamos uma forma muito mais fácil e imediata de qualquer um fazer esta integração.


A ideia é usar Tags. Vale para todos os componentes atualmente suportados – Servidores, Banco de Dados, Discos e Aplicações Auto Scaling – e todos os clouds – AWS, Azure e GCP.

Siga este roteiro para utilizar tags e as templates de agendamento.

1. Crie as ‘Templates’ de agendamentos que pretende utilizar. Não há limite para o número e se aplica a todos os componentes. Exemplos:

  • Parar servidores fora do horário comercial – ‘desligarpadrao’
  • Backup recorrente diário + cópia cofre – ‘backup-diario’
  • Iniciar servidores todas as manhãs – ‘iniciomanha’
  • Fazer um checkup de segurança semanal (via SSM) – ‘ssmcheckup’
  • Upgrade/downgrade dos bancos de dados com pouco acesso em fins de semana – ‘downgradefimdesemana’

Utilize nomes de fácil identificação, pois eles serão usados como ‘valores’ dentro das tags.

Nota: no GCP, as tags (ou labels) não podem ser maiúsculas e ter espaços, então se for usar uma tag junto a ele, escolha algo como ‘parar’, ‘backup-diario’, etc

2. Defina as tags que irá cadastrar em todas as contas e clouds.

  • Nome: ‘Agendamento homologacao’
  • Nome: ‘Agendamento producao’
  • Nome: ‘Protecao maxima’
  • Nome: ‘Escala Beanstalk’
  • Ou simplesmente: ‘agendamento’, ‘scheduler’, ‘cloudscheduler’, etc

3. Crie as tags nos componentes, com nome e valor de acordo com o planejado. Ex: ‘agendamento’ -> ‘backup-diario’

4. Faça a associação pelo Cloud8. No botão ‘Templates/Tags’ do agendador, escolha ‘Tags <-> Templates’.

Nesta tela cadastre o nome da Tag. Em seguida mapeie com os templates e defina quais contas (por segurança) farão uso destas tags.

Sempre que o Cloud8 encontrar uma tag ‘agendamento’ -> ‘backup-diario’, etc, automaticamente iremos executar os agendamentos.

Nota: para cada tipo de componente por componente use a visão do componente (caixa de escolha ‘Componentes’) e depois faça a associação.

5. Integração com provisionamento: nos scripts de CloudFormation, Terraform, Azure Templates, etc, basta cadastrar o par nome/valor da Tag no componente e assim pode deixar sua topologia documentada. Quando o componente for criado, automaticamente, os agendamentos são criados sem mais necessidade de nem logar no Cloud8.

5.1. Funciona com qualquer ferramenta de provisionamento e você ainda pode usar o mesmo conjunto de tags para várias contas e vários clouds!

CloudFormation: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-ec2.html
Azure Templates: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-templates-resources
GCP Deployment Manager: https://cloud.google.com/deployment-manager/docs/step-by-step-guide/create-a-template
Salt – https://medium.com/devopslinks/automating-aws-infrastructure-using-saltstack-2b40aeadc7a9
Terraform: AWS – https://www.terraform.io/docs/providers/aws/r/instance.html , GCP – https://www.terraform.io/docs/providers/google/r/compute_instance_template.html , Azure – https://www.terraform.io/docs/providers/azurerm/r/virtual_machine.html

Bônus: 1. Você visualiza os agendamentos feitos pelas tags assim como os manuais. Desta forma, não corre o risco de duplicar ou criar conflitos.

2. Você pode usar as templates sem as tags. Uma vez que cadastre templates, no momento de criar um novo agendamento, pode aplicar esta template. Se posteriormente, editar a template (por exemplo, mudar a hora do agendamento), você pode escolher mudar todos os agendamentos que a utilizaram! Muito prático para ganhar ainda mais produtividade.


Sintam-se à vontade para críticas e sugestões! Obrigado!
Equipe Cloud8
Gestão MultiCloud – AWS, Azure e GCP

Redução de custos: Beanstalk, AS e t2.unlimited, Azure EA e muito mais!

Redução de custos AWS: capacidade em Auto Scaling e Beanstalk

O Cloud8 possui diversos mecanismos para redução de custos. Alguns qualitativos, como entender as métricas de uso de acordo com o negócio com a finalidade de mexer nos tamanhos de componentes. E há meios dinâmicos já amplamente conhecidos e utilizados: início e desligamento de instâncias (EC2, RDS, Azure, GCP) em horários sem uso, upgrade/downgrade de perfil quando se exige menos capacidade. limpeza de backups antigo, componentes sem uso (discos, IPs e LBs), entre outros.

Criamos agora mais uma forma de economizar: alterar os parâmetros sobre capacidade dos servidores nas aplicações com Auto Scaling e/ou Beanstalk. A ideia é mexer nos números de mínimo, máximo e valor desejado de capacidade de servidores para que o AS crie mais ou menos instâncias dependendo do horário de uso. É possível até mesmo parar uma aplicação beanstalk ou ASG.

Veja alguns casos de uso:

  • Ambiente de desenvolvimento: se possui um beanstalk que é desenvolvimento, você pode pará-lo fora do horário comercial, colocando ‘0’ como valor desejado da capacidade. Para retornar, basta reconfigurar para um valor como ‘1’ ou ‘2’;
  • Picos programados: aumentar a capacidade máxima e desejada para um valor que atenderá as requisições sem precisar fazer um ‘warm up’ prévio;
  • Redução de custos em produção: ao invés de parar o ambiente, é possível reduzir a capacidade para 2 instâncias (uma em cada AZ para disponibilidade) e depois aumentar para a necessária.

Esta funcionalidade está disponível no agendador de workflows sem custos adicionais e suporta quaisquer tipos de Auto Scaling. Esperamos no futuro incluir Azure e GCP e mais tipos de aplicações que possuem auto scaling embutido.

Redução de custos AWS: mudança de t2.unlimited

Recentemente o AWS lançou um recurso muito interessante de se transformar uma instância do tipo t2 em ‘unlimited’. Isto é, não há mais limite de créditos de CPU e sendo assim não há preocupações de que a instância possa vir a performar mal justamente por falta destes créditos.

Se estiver enfrentando esgotamento de créditos, mas não deseja mudar o tamanho da instância para pagar mais, pode usar o recurso de t2.unlimited. Pode atualizar a instância para rodar sempre como ‘unlimited’ ou deixar agendado nos horários mais ocupados para economizar ainda mais.

Este recurso está disponível no agendador de workflows para os componentes ‘Servidores’.

Suporte a análise de custos para Azure EA e simplificação de PAYG

O Cloud8 analiza custos do Azure por meio das visões de produtos, tags, resource groups e multidimensional para os 3 modelos de assinatura da Microsoft: EA (enterprise agreement), CSP (Cloud Solution Provider) e PAYG (Pay as you go).

Passamos a suportar o EA com a tabela de preços combinada junto à Microsoft. Os custos, resource groups, tendências, estimativas e anomalias refletem valores reais pagos ao fim do período e não mais aproximações.

Para o caso do PAYG, simplificamos ainda mais o processo, não sendo mais necessário informar o código da oferta (OfferId). Basta escolher a opção PAYG e ativá-la.

Backup Azure e GCP: introduzindo conceito de imagem

Aproveitamos o conceito de AMI (imagem/template) que o AWS possui e o aplicamos para Azure e GCP. Quando realiza um backup de um servidor Azure ou GCP, o Cloud8 criará snapshots de todos os discos e os agrupará em uma definição lógica no banco de dados que chamamos de ‘imagem’. Ele servirá como um mapeamento de quais snapshots pertencem a quais servidores e discos e em que momento foram gerados.

Esta forma de organizar os snapshots permite que se restaure e se apague mais facilmente os backups já que estão relacionados logicamente. Gerenciar snapshots independentes é mais complexo e associá-lo ao servidor no momento da criação pode estar sujeitos a erros.

Dentro das listas de “Backups” e “Templates” verá estes backups, mas eles só existem logicamente dentro do Cloud8. Os snapshots individuais de cada disco são visualizados dentro dos portais do Azure e GCP. Ações como classificar e destruir são possíveis. Estamos trabalhando para no futuro poder restaurar todo o servidor a partir deste conjunto de snapshots a partir da interface do Cloud8.

GCP: billing consolidado de projetos

Quando possui múltiplos projetos no GCP, os dados de custos ficam agrupados em um único banco BigQuery. O Cloud8 já suporta analisar dados destes projetos mesmo que a conta consolidada não esteja sincronizada na nossa plataforma. Você possui livre escolha para sincronizar somente os projetos que desejar.

KMS

Agora mostramos as chaves KMS junto com as chaves privadas de EC2 para fins de inventário. Em breve integraremos com o KMS de todos os clouds e as operações de automação (muitas delas já funcionam de forma transparente sem a necessidade de ficar especificando chaves KMS).

Para incluir o KMS é necessário ter permissão na credencial para listar e acessar os detalhes (o AWS nunca fornece diretamente a chave, então não há problemas de segurança!) – https://www.cloud8.com.br/ajuda/avancado/utilizando-o-cloud8-com-uma-credencial-customizada-de-seguranca/

​Perfil: auditoria

Dentro dos inúmeros perfis que se pode criar dentro do Cloud8, desde contas cloud, específicos para servidores+ações, agora pode criar um perfil para ver a auditoria. Casos de uso:

  • Equipe de segurança ou complaince precisa acessar;
  • Times que possuem a conta de ‘homologação’ por exemplo, precisa conhecer eventos;
  • Acesso aos logs MultiCloud.

Outras novidades:​

  • AWS: análise de custos com suporte a Amazon Translate, Amazon Transcribe, AWS Secrets Manager, DAX, IOT Device Management, AWS Elemental MediaStore, AWS Certificate Manager;
  • Azure: análise de custos com suporte a Postgresql e MySQL gerenciados;
  • GCP: análise de custos com suporte a Support;
  • AWS: cópia cofre oficializada e fim do beta;
  • Azure: preços carregados para todos os tipos e todas as regiões;
  • Azure: discos que foram migrados de unmanaged para managed aparecem na auditoria;
  • AWS: exportação de inventário de Load Balancers reformatada para melhores informações com target groups de ALB;
  • AWS: integração com CloudTrail inclui eventos de RDS como start/stop e apagar snapshot de banco de dados ou cluster (Aurora);
  • Azure e GCP: opção de ‘Conectar ao servidor’ suportada na lista de servidores;
  • Azure: inclusão das novas regiões da França e Australia Central;
  • AWS: inclusão da zona disponibilidade D para o Japão;
  • AWS: no attach de um volume no AWS, permite utilizar mapeamento de root – /dev/sda1;
  • AWS: Load Balancer: busca por servidor – possível encontrar todos os lbs que um servidor está conectado;
  • AWS: na lista de servidores pode buscar por on demand e/ou spot;
  • GCP: edição de tags para servidores e discos;
  • Todos: na análise de custos, opções de Multidimensional são acertadas conforme o cloud;
  • Todos: relatório agendado de backup status mais organizado com coluna de provedor;
  • Todos: backup manual de servidor sugere nome para não gerar mensagem de nome repetido;

Muitas novidades: CloudTrail, cópia cofre, custos, LBs, RIs e agendador!

 

Segurança: melhoria na integração com CloudTrail

O Cloud8 atualmente integra diversos eventos reportados pelo AWS CloudTrail, principalmente os que dizem respeito à segurança: logins no console, mudanças IAM, chaves de acesso, roles, entre outros.

Continuamos a capturar mais e mais eventos técnicos e traduzi-los em linguagem de negócios. Isto é, por meio da auditoria você pode entender o que acontece no seu cloud com uma terminologia mais acessível e não restrita aos nomes das APIs utilizadas nos eventos.

Os novos eventos mapeados são os que apagam componentes: servidores, buckets S3, load balancers, discos, snapshots e imagens. No log você encontra informação de qual credencial realizou a remoção, mesmo que tenha sido externa ao Cloud8.

Esperamos trazer muito mais visibilidade do que ocorre no seu Cloud. Ao longo das próximas semanas devemos sempre incluir novos eventos.

Segurança: cópia cofre para todos os tipos de servidores

Em um post anterior,  havíamos anunciado o recurso de copia-cofre: cópiar um backup para uma outra conta AWS com credenciais super seguras para fins de business continuity. Dada a ótima receptividade incluimos suporte a todos os tipos de servidores, além de Linux e RDS que inicialmente eram suportados: Windows, Redhat, Suse e produtos do MarketPlace.

Agora não há mais poréns para não ter uma estratégia de business continuity!

Novos relatórios de custos

Melhoramos a visibilidade da evolução diária do custo do seu cloud.

Há serviços que o AWS só publica os custos em D+1 ou D+2. Por exemplo, backup, pois é necessário aguardar o término dos processos. Com isto, mostrando somente a foto do dia atual e do dia anterior distorcem-se tendências e análise.

Assim publicamos o histórico de 5 dias no relatóriopor email. Veja um exemplo:


As tendências ficam muito mais claras e facilita a análise.

Se você possui várias contas AWS, o relatório consolidado de custos também traz melhorias como ordenar pelos que tiveram maior variação de custos.

Agendador: busca e performance

Novidades aguardadas pelos clientes:

  • busca de eventos: busca pelo nome do agendamento que destaca os eventos:

  • performance: a criação de eventos recorrentes demora apenas alguns segundos e não há mais necessidade de aguardar;
  • múltiplas tarefas de conexão e desconexão de Load Balancers ficam mais claras dentro do Workflow;
  • suporte a 15 tarefas dentro de um workflow;

Consumo de RIs mais claro

Alinhamos novamente o Cloud8 com a evolução do modelo de RI (instâncias reservadas) do AWS. Caso um servidor (EC2 ou RDS) esteja consumindo horas de instância reservada, mostramos na coluna ‘Info’ como está o consumo no mês.

O consumo é representado por um medidor que informa a porcentagem de horas utilizada.

É possível fazer buscas por servidores que não possuem RI ou cujo consumo seja menor 25%, 50% e 75% ou que ainda esteja consumindo 100%.

Se precisar de um relatório mais detalhado para verificar o consumo geral, no menu esquerdo há a aplicação “Controle de RIs”. Este relatório ganhou uma forma simplificada de verificar todas as RIs e visualizar um resumo detalhado de como as horas são consumidas. Também colocamos mais uma coluna para dizer se a RI é do tipo “Standard” ou “Convertible”.

Melhoria no suporte a Load Balancer

O Cloud8 suporta Load Balancers Clássico e Application. Confiram as melhorias:

  • healthcheck: mostra se há algum servidor com problema – com a visão unificada multi-conta e multi-região fica muito mais imediato diagnosticar e tirar relatórios sobre custos, LBs sem uso, LBs com problema e assim por diante;
  • healthcheck: indica se é problema no LB ou em algum servidor associado a ele;
  • melhor identificação na lista quando é Classic vs Application;
  • exportação para inventário contém target groups (application) e servidores;
  • sincronização imediata – ao clicar em “Forçar imediatamente”, o Cloud8 verifica os provedores selecionados e atualiza todos os dados; LBs, Target Groups, instâncias conectadas, Health Checks, indicadores;
  • possibilidade de destruir um LB pelo painel do Cloud8;

Mais novidades

Continuamos a implementar novas melhorias em todas as funcionalidades do Cloud8.

  • Billing: suporte a AWS Cost Explorer, Cloud HSM, CodeDeploy;
  • Workflow: execução de script SSM agora tem time-out de 10 minutos se a opção for síncrona;
  • Aurora PostgreSQL: ajustes;
  • Backup report: não traz servidores que fazem parte de Auto Scaling, evitando falso-positivo;
  • Perfil read-only permite download do inventário dos componentes;
  • Filtro de snapshots sem política de retenção atrelada e portanto não serão apagados pelo Cloud8
  • Auditoria: stop de servidor inclui parâmetro indicando se foi parado à força;
  • Informação de servidor mostra quais discos são encriptados (já mostrava em discos);
  • Suporte a novo formato de ID (https://aws.amazon.com/about-aws/whats-new/2018/02/longer-format-resource-ids-are-now-available-in-amazon-ec2/) do AWS;
  • RDS: alerta de performance_schema corrompido;
  • Retenção de backups/imagens e snapshots seja por tempo ou GFS fica mais transparente nas listas de componentes.

Boas festas, novidades, tags/untagged, top 10 custos, manutenções AWS

Boas festas e expectativas para 2018

O Cloud8 (https://www.cloud8.com.br) faz 5 anos. Agradeço a todos os clientes pela confiança em nossos serviços ao longo desta jornada. A empresa que começou com o intuito de ajudar na gestão de Cloud, hoje é missão crítica para centenas de empresas de todos os portes. Sentimos muito orgulho de ajudar na economia de custos em um país com tantos desafios, melhorar a gestão de segurança e a continuidade de negócios.

Em 2018, esperamos fazer muito mais. Temos diversas novidades a serem lançadas no 1 trimestre que vão expandir escopo e beneficiar ainda mais os parceiros. Convido a todos a enviarem sugestões para nosso roadmap!

Boas festas e uma ótima passagem de ano!
Renato Weiner
CIO/Founder


Custos – componentes sem tags (Untagged)

As tags dos componentes tem sido cada vez mais usadas para controlar a alocação de custos. Se ainda não está utilizando ou quer melhorar o controle, seguem algumas dicas antes de falarmos de Untagged.

Dicas de uso de Tags

  • uma tag é definida por um par “Nome” e “Valor”. Ex: Nome -> Departamento. Possíveis valores: “Marketing”, “Financeiro”, “TI”, etc;
  • tenha uma política/processo de taggear tudo: servidores, RDS, discos e load balancers, etc -> tudo mesmo 🙂
  • defina como taggear sempre que um recurso novo é criado: Servidor, Disco, RDS, LB, etc
  • escolha as tags de acordo com o seu negócio: se trabalham por projeto, por cliente, por departamento, por centro de custos, por ambiente (producao/desenvolvimento), por equipe de devops, etc.
  • sugestões de “Nomes” de tags: ‘Ambiente’, ‘Aplicacao’, ‘Cliente’, ‘Custo’, ‘Empresa’, ‘Produto’, ‘Responsavel’, ‘Servico’, ‘CentroDeCusto’, ‘Stack’, ‘Tecnologia’, ‘Departamento’, etc
  • dá para usar múltiplas tags (não economizem 🙂 )
  • pode usar tags técnicas tb: Sistema Operacional, Banco de dados, NoSQL, WebFront, Cache, Tier, etc…

Limitações de uso:

  • o AWS não consegue pegar as tags de forma retroativa, então se mudar no meio do mês, ela começa zerada e no fim do mês vai ter uma parcial. Por isto é bom fechar de vez o conjunto de nomes e tentar mudar pouco;
  • não são todos os produtos que suportam tags. Ex: instâncias reservadas. Mas está melhorando a cada mês – o Cloud8 vai mostrar o que é taggeável e o que não é (ver Untagged abaixo)
  • maiúsculo, minúsculo: não misture maiúsculo e minúsculo, espaços em branco, acentos. Os nomes das tags são sensíveis aos caracteres e são tratadas de forma independente. Ex: “Cliente” e “cliente” são considerados tags diferentes.

Untagged – acompanhar o que não está taggeado

Criamos uma aplicação nova em “Análise de Custos”, aba “All – Untagged”. A idéia é mostrar todos os componentes que não possuem tags e que aparecem nos custos.

Veja algumas características da aplicação:

  • Pesquisar por tags – selecione uma ou mais tags e o relatório trará os componentes que não a possuem;
  • Dividimos em 2 partes: os serviços que o AWS não suporta cost allocation (ou seja, nem adianta perder muito tempo além de saber quais são) e os produtos em que há componentes sem tags – listamos os IDs;
  • à medida que vão arrumando as tags, o relatório de “IDs” deve diminuir. A edição de novas tags pode ser feita pelo console ou pelo próprio Cloud8 (nos componentes suportados por enquanto);
  • exportar os componentes que não possuem tags no formato CSV;
  • por default o Cloud8 vai trazer todos os componentes que não tiverem sido taggeados por vocês (isto é, ignoramos tags que começam com “aws:” e “rds:” que são tags que o AWS inclui automaticamente);
  • agendar o recebimento de um relatório diário (ou com a frequência que quiser) dos componentes que não possuem tags. Basta ir no agendador, e no combo “Componentes”, escolher “Relatórios”. Lá encontrarão o “Relatório: Recursos com ID não taggeados”.


Idéia de processo simples:

  • configurar o relatório com frequencia de 2 em 2 dias;
  • à medida que receber o email, taggear os componentes;
  • identificar algum cenário de provisionamento, auto-scaling que cria componentes sem tags e arrumar;
  • usar o relatório completo de tags (Dashboard -> Ícone relatórios -> Tags) para extrair o rateio de custos;

Tags + Perfis de acesso

É possível delegar a gestão das tags para outro time, como o financeiro, sem que eles tenham permissão para alterar a infraestrutura.

Dentro dos perfis de usuários, há ações que permitem a edição de tags.

Para criar um perfil financeiro + edição de tags, façam o seguinte para deixar mais organizado e flexível para o futuro:

  • no menu “Perfil de acesso”, crie um perfil “Finance” – com acesso a tudo ou somente um ou mais “Provedores” à escolha;
  • perfil “Servidores (Ações e Workflow)” conforme imagem acima;
  • perfil “DNS (Custom)” com as ações:”Editar Tags”, “Visualizar custos detalhados”;
  • perfil “Banco de dados (Ações)” com as ações: “Editar Tags”, “Visualizar custos detalhados”;
  • criar um usuário novo, associem os 4 perfis: Finance + Servidores + DNS + Banco de dados.

Análise top 10

Outra aplicação que criamos dentro de “Custos – Analytics”, chamamos de “top 10”. Inclui:

  • top 10 mais caros;
  • top 10 variações dos períodos selecionados (por default mês atual e mês anterior)

O objetivo é saber quais custos/uso que mais variam entre períodos. Há casos em que o aumento de um serviço é compensado pela diminuição em outro. Isto pode mascarar tendências e o entendimento dos custos que mais sofreram variações ajuda a um melhor controle.

A dinâmica funciona assim:

  • selecione a aba Top 10;
  • o top 10 variações mostra as variações do primeiro nível: produtos AWS ou tags nome/valor, etc;
  • baseado no que variou mais, pode expandir o nó da direita e reselecioná-lo em seguida – o top 10 é atualizado automaticamente;
  • avalie o top 10 mais caro, as variações e repitam a operação para detalhar a análise

Há opções de mudar entre “Custo” e “Uso” e o valor – por default colocamos 0.5 para tirar as variações enormes que podem ocorrer com serviços que estão próximos de zero. Mas nada impede de setarem o valor em 100 por exemplo, para pegar os maiores valores e assim por diante.

Filtro de manutenções AWS

O AWS enviou literalmente uma enxurrada de manutenções de servidores para as próximas semanas.

Para identificar se possui algum servidor nesta condição, pode usar um novo filtro da coluna “Info” da lista de servidores -> “Manutenção agendada”. Os servidores que tiverem manutenção aparecem com ícone de relógio . Ao passar o mouse, verá os detalhes de quando ela será realizada pelo AWS.

Caso queira antecipar esta manutenção – recomendado – basta realizar um stop/start da instância (ou mesmo reboot em alguns casos) que ela deve sumir. Pode ser feito manualmente (console ou Cloud8) ou usando as tarefas do agendador. Não esqueça de fazer backup antes!

Mais novidades

Continuamos a implementar novas melhorias em todas as funcionalidades do Cloud8.

  • Billing: suporte a Pinpoint, Cloud Directory, AWS Glue, Macie, Guard Duty, Comprehend, SageMaker, MQ, Alexa for Business e ECS;
  • Novos tipos EC2: g3, f1, x1e, x1, m5, c5 e h1;
  • Suporte a Aurora PostgreSQL;
  • Suporte a nova região de Paris (eu-west-3);
  • Billing: análise mostra SQS com IDs e tags, já que AWS agora suporta;
  • Métricas: suporte as dimensões CPUCreditUsage e CPUCreditBalance para tipos t2;
  • RIs: alerta de expiração de RI de Redshift;
  • IAMs: melhoria no relatório de IAMs com exportação melhor organizada e diagramada;
  • IAMs: inclusão de campo de MFA e busca por usuários que não usam;
  • Agendador mostra fim de semana com outra cor;
  • Cópia cofre: retenção com uso de GFS e opção de ‘não apagar’.

Obrigado!
Equipe Cloud8

AWS re:Invent 2017 – resumo e curiosidades

AWS re:Invent 2017

Fomos ao AWS re:Invent e novamente trazemos as impressões e curiosidades. Este ano, segundo o AWS, foram mais de 40k participantes e 1.000 sessões técnicas.

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

Detalhes das informações técnicas 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

Em termos de inovação, este re:Invent escolheu focar em Inteligência Artificial – para ser mais correto e preciso, em Machine Learning – e evangelizar Serverless. Destaques ainda para banco de dados e preenchimento de lacunas de funcionalidades de diversos produtos além de integração global (multi-região).

Os keynotes foram bem interessantes. O Andy Jassy sempre ressaltando a liderança do AWS com gráficos do Gartner, ritmo de inovação, números gigantescos e os novos lançamentos. Este ano ele fez uma analogia dos ‘builders’ (desenvolvedores) com os músicos e explorou temas como totalidade de funcionalidades, inovação, liberdade, etc com um tema musical para ponto ressaltado. Casos de sucesso como Expedia, Goldman Sachs estão com estratégia ‘All-In’. Interessante notar que instituições bancárias estão migrando 100% para Cloud.

Já o Werner focou em evangelizar o uso do Lambda e do Alexa. Contou sobre a evolução dos serviços e que o AWS não impõe uma forma de desenvolver e sim, possui diversas ferramentas para se criar do modo que for melhor dentro da sua cultura. Frisou que a realidade atual do mundo corporativo é a ‘digitalização’ com o exemplo clássico da General Electric (GE) – era uma empresa de manufatura e um dia acordaram uma empresa de software e o mesmo ocorre com o Goldman Sachs, onde 1 em 4 funcionários é um engenheiro desenvolvedor. Em mundo onde os recursos estão disponíveis para todos (pelo menos em termos técnicos e não financeiros), o diferencial é a estratégia e execução – o ‘como’ usar estes recursos. Outro ponto realmente válido é que hoje as interfaces são centradas em dispositivos (machine-centric) e quando migram para human-centric, o seu apelo é muito maior e mais abrangente. Pessoas que não possuem acesso digital, especialmente nos lugares mais pobres do planeta, teriam muito
mais acesso a serviços por meio da interação por voz. Um caso de uso entre agricultores de arroz das Filipinas foi mostrado onde após a adoção de aplicação de voz, o sistema de escolha de ajuda no plantio foi realmente utilizado e os objetivos do governo finalmente alcançados. O Alexa é a implementação desta visão e agora vem com a versão business: Alexa for business. Ou seja, investimento pesado no Alexa e consequentemente um ciclo virtuoso: automação corporativa e caseira que puxa IOT, que puxa EC2 e Lambda, banco de dados, analytics e assim gira o AWS.

Na área de IA e Machine Learning, o AWS excedeu expectativas novamente. Dado que para o estado da arte de ML são necessários conhecimento e experiência profundos, o AWS procura popularizar e massificar o seu uso. Por meio do lançamento do SageMaker e ML Labs, basta (teoricamente) possuir uma massa de dados de boa qualidade, o AWS ajuda a definir e treinar o modelo preditivo de redes neurais, dinamicamente avaliando e melhorando a parametrização. Particularmente acredito que deva funcionar na grande maioria dos casos, mas a aplicação específica de frameworks e algoritmos pré-definidos pode não representar o ponto ótimo – mas enfim, se você tem a capacidade de mexer em nível mais aprofundado ou um parceiro especializado, talvez o SageMaker não precise estar no seu radar. A polêmica sobre esta ‘terceirização’ de AI já começou a gerar bastante discussão.

Cobrindo alguns gaps de outros recursos de inteligência artificial, foram lançados ainda produtos para transcrição, tradução e compreensão de textos, bem como reconhecimento de vídeo. Agora está nivelado com as APIs que o Google já possui (apesar de o suporte a línguas ainda não contemplar nosso português). Dado o histórico de integração com outros produtos, imagine o que a automação de tarefas de linguagem poderá fazer quando for integrada ao serviço de Call Center (Connect) ou com a criação de bots?

O que particularmente impressionou foi na área de banco de dados e o Andy Jassy não podia deixar de fazer suas tradicionais piadas sobre a Oracle e o Larry Elisson… Esta motivação de destronar a Oracle, está trazendo uma gama enorme de novas funcionalidades para o Aurora e o DynamoDB. Pois bem, lançaram o Aurora Multi Master e em breve o Aurora Serverless (mais detalhes nos destaques). O DynamoDB vem replicação multi-região (global) e backup – não podemos esquecer do Cloud Spanner do Google e o do CosmosDB do Azure que já são globais. Vai dar pra fazer query (select) no S3 e acreditem… no Glacier! Nem GraphQL escapou – novo produto Amazon Neptune. Enfim, banco de dados está realmente bem servido no AWS.

Serverless, anunciado no fim de 2014, teve um salto no suporte e casos de uso. Já começa a ficar mais robusto e definido. Lambda é utilizado em funções simples de negócios, analytics, processamento de dados (imagens, textos, etc), mapeamento em APIs, devops e diversos outros tópicos. O suporte a linguagens foi estendido com a adição de .NET 2.0 Core e Go. Várias outras melhorias foram incorporadas, desde um novo ambiente de desenvolvimento online – Cloud9 (perguntem ao George Harrison e não a mim o porquê do nome 🙂 ), refatoração do console, SAM local, etc (mais detalhes neste newsletter). Enfim, facilitadores para a adoção do desenvolvimento. Entretanto, por mais claro que sejam os benefícios, Lambda não é solução para tudo – muito pelo contrário, sistemas com regras de negócios complexos e interações com banco de dados SQL, baixa latência por conta destas regras, legados, etc tem que ser estudados
cuidadosamente para implantar Lambda – possivelmente alguns processos, mas dificilmente o sistema inteiro. Por fim, há a questão do ‘Lock in’. Se existe a intenção de continuar com liberdade, deve-se avaliar usar funções que possam ser executadas em um Lambda e em um servidor independente. Logicamente há muito espaço para discussões e polêmicas sobre prós e contras, mas este não é o lugar – talvez em um futuro newsletter.

Destaques e lançamentos

Muitos serviços e melhorias. Veja a lista oficial completa. Abaixo, nosso resumo e comentários.

  • EC2 Compute. Lançamento de novos tipos – c5, m5, h1, i3m (bare metal). Novo placement: ‘spread placement’ – garante que 2 ou mais VMs não caiam no mesmo servidor físico e assim evitar uma pane geral em caso de falha. Launch templates – pré-configurações de instâncias EC2 com todos os parâmetros possíveis e ainda permissionamento para usuários IAM de autorizar ou não o uso – simplifica muito o processo de gestão de criação dos servidores. Apesar de todo o hype em torno de Lambda, EC2 ainda é o principal serviço e o investimento continua. Os novos tipos rodam em cima de um novo
    hypervisor e são muito mais performáticos em termos de rede e latência – em um mundo de microserviços e arquitetura distribuída, uma rede rápida é requisito básico. Estes tipos novos com ENA (Elastic Network Adapter) resolvem um problema de latência de rede e jitter e faz o AWS novamente competitivo frente a rede do Google;
  • T2 Unlimited. o AWS resolveu um problema que os usuários de instâncias T2 podem sofrer: servidor pode não funcionar bem uma vez que os créditos de CPU são consumidos. Para evitar que isto ocorra, agora você marcar uma instância T2 como ‘unlimited’. Se houver mais uso do que o permitido, AWS irá cobrar um ‘extra’ – logicamente ainda é necessário dimensionar o servidor. Um t2.nano com ‘unlimited’ usando picos o tempo todo, ficaria muito mais caro que um t2.medium por exemplo;
  • EC2 Spot. o AWS facilitou a utilização do EC2 Spot Market – criar instâncias em um mercado de preço variável baseado na disponibilidade de computação. Já dá para lançar um novo servidor sincronamente sem especificar o preço e o AWS irá utilizar o melhor custo para você. Como é o AWS quem escolhe o preço, ele pode hibernar a instância no lugar de terminá-la (novidade!) a qualquer momento (a variação do preço do Spot também deve mudar para ficar menos sujeita a grandes variações – novidade também!). O efeito desta popularização do spot é que o preço médio do mercado já subiu… veja o histórico de uma instância c4.large em Virgínia pelo console. Os usuários pesados de Spots no modelo antigo não vão ficar muito felizes;
  • Aurora Multi Master. o Aurora é um dos serviços que cresceu mais rapidamente dentro do AWS. Compatível com MySQL ou PostgreSQL, suporta qualquer software que faz uso destes bancos. A novidade é retirar da topologia atual o ponto único de falha (ainda que se tenha Multi-AZ e o chaveamento de falha leve alguns segundos) introduzindo o Multi Master – espalhar servidores que aceitam transações em diversas zonas de disponibilidade acabando com este problema. Estamos ansiosos para usar a versão global – multi-região – que deve vir em 2018;
  • Aurora Serverless: versão do Aurora que escala automaticamente dependendo da quantidade de transações/requisições. O modelo é bem parecido com o DynamoDB, onde é definido a capacidade por ‘unidades’ e o AWS faz o auto-scaling automático. Será interessante testar como a escalabilidade acontecerá, já que a contrário de um Auto-Scaling de servidores onde a criação de novas instâncias pode levar alguns segundos, um pico de banco de dados tem que ser tratado de imediato, em milisegundos, caso contrário, a aplicação pode se perder;
  • DynamoDB Global Tables e backup/restore: como o próprio nome já diz, as tabelas DynamoDB podem ser configuradas para serem globais (multi-região), não só read-only, mas transacional. O fim da replicação “manual”!. O benefício imediato é alta disponibilidade entre regiões e latência minimizada. O AWS preenche uma lacuna e não fica mais atrás do Cosmos DB da Microsoft e o do Cloud Spanner do Google (se bem que este último tem SQL, mas com o Aurora Multi-Master entre regiões, isto também deve ser resolvido). E finalmente, o imprescindível lançamento do backup/restore de tabelas – difícil imaginar como demorou tanto e como as empresas lidavam com suas soluções caseiras… – mas enfim, ponto extremamente positivo!
  • S3 e Glacier Select. Capacidade de fazer queries dentro de objetos do S3 e do Glacier. Não é necessario acessar objeto por objeto e inspecionar o conteúdo. Com linguagem SQL, você pode encontrar dados mais facilmente. Imagine a quantidade de casos de uso que podem ser criados com esta função;
  • Neptune e App-Sync. Suporte a GraphQL. Mais uma forma de manipular dados, especialmente mobile. Ajuda quando se tem vários “data sources” (banco de dados) e no push real-time de atualizações para diversos dispositivos;
  • SageMaker: quem já experimentou criar modelos de Machine Learning ou análise preditiva, sabe que como é difícil, demorado e frustrante encontrar a parametrização com melhores resultados. Como mencionado na parte de ‘Estratégia’, o SageMaker procura resolver este ciclo treinando a massa de dados fornecida e criando o melhor modelo automaticamente. Acredito que seja interessante testar e dependendo do resultado e aprendizado, buscar descer um nível, compreender os frameworks e algoritmos ou buscar um parceiro para avançar no modelamento;
  • IA: Translate, Transcribe e Comprehend: mais um conjunto de serviços para preencher a lacuna de linguagem natural. O AWS já possuia serviços de reconhecimento de voz e construção de bots (Lex) e agora fica mais completo, se igualando ao Google. Como o próprio nome indica são serviços de tradução, transcrição de voz para texto e compreensão (para não deixar muito aberto, o foco aparentemente é análise de sentimento, mas também há mapeamento de palavras chaves e entidades). O grande ponto pendente ainda é o suporte a Português que ainda não há previsão infelizmente;
  • IA: Video Rekognition: reconhecimento de padrões dentro de vídeo. Como bem apontado pelo Matt Wood, reconhecimento dentro de vídeo é bem mais complexo do que imagem estática e a ideia é trazer os labels e as taxas de confiabilidade ao longo do tempo do vídeo. E dado que vídeo pode gerar um stream de dados realtime com muita informação, lançaram o Kinesis Video Stream para facilitar. Combinado com o Transcribe e Comprehend para análise de sentimento dá para pensar em muitos casos de uso. Aliás, fico imaginando se o Amazon Go não utiliza exatamente esta combinação de serviços e desta forma estaria viabilizando a implementação de clones…;
    * Fargate: gestão automática dos containers. Retira a liberdade de se usar os tipos de instâncias que pode usar, mas se ganha escalabilidade automática. Também faz cobrança por segundo como no modelo de controle das tarefas com instâncias EC2. É perfeitamente possível ter um ambiente com tarefas/containers gerenciados via ECS e outro por Fargate;
  • Kubernetes: um dos anúncios mais comemorados foi o lançamento de gerenciamento de Kubernetes – o AWS gerencia, atualiza e escala automaticamente clusters de containers com Kubernetes. Segundo o AWS, como já rodam mais Kubernetes que qualquer outro provedor, é natural que façam a gestão. Na sessão ‘Deep dive in Kubernetes’, ficou claro que ainda há muito trabalho a fazer: melhor integração com rede, suporte a Windows, upgrades major, Multi-region, híbrido, etc, mas a sinalização de ter um componente a menos para gerenciar já deixou a comunidade animada. Vai ser integrado ao AWS Fargate;
  • VPC Peering global: capacidade de fazer peering, isto é interconectar, VPC de diversas regiões e integrá-las sem a necessidade de roteamento para IPs públicos e outros componentes como gateways, NATs, que aumentam a complexidade e inserem pontos de falha na topologia de rede;
  • Alexa for business: Utilização do Alexa em ambiente de negócios. Casos de uso principal é um assistente pessoal para o dia a dia: reuniões, calendário, alertas. Integrado a aplicativos como Office 365, G-Suite, Exchange, Salesforce, etc. Procura resolver o desafio que é sempre se juntar a um conference call – PINs, URLs, softwares, etc. O vídeo exemplo mostrou que este processo é transparente no momento da reunião. Não funciona com português e não foi passado nenhum horizonte quanto ao suporte;
  • Private Link: ideia interessante de conectar produtos de parceiros – SalesForce, Twilio, etc – dentro da sua VPC privada, sem precisar sair para internet com IPs públicos, ainda que o tráfego seja encriptado. Expande radicalmente o conceito dos Private Endpoints para os serviços AWS. Com o AWS já suportando peering global entre VPCs (ainda não suporta para São Paulo), será interessante testar se seremos capazes de chegar em um private link diretamente do Brasil!
  • Guard Duty: serviço de detecção de anomalias de segurança. A ideia é por meio de diversos logs gerados pelo AWS – VPC flows, CloudTrail, DNS, etc verificar possíveis ameaças e alertar o administrador. Vale verificar os custos antes de usar;
  • Snapshots: em uma sessão de melhores práticas de snapshots, o gerente de produtos do AWS mostrou que existe uma possibilidade de falha de 0,1-0,2% nos discos – https://aws.amazon.com/ebs/details/ – ou seja, é imprescíndivel ter backups períodicos pois o AWS não se responsabiliza por perda de de dados;
  • CloudFormation: melhoria apontadas – CF pode ser configurado para não remover componentes quando o stack é destruido, stacksets para representar pedaços da arquitetura, multi-account e multi-região, suporte a quase todos os produtos (inclui IOT, Lambda e ECS), policies em vários níveis (stack, resource level), checagem de mudanças antes do commit, integração com AWS Config. O melhor foi o anúncio para 2018, do que foi chamado de ‘Drift detections’, quando será lançado a detecção de mudanças no stack comparado ao ambiente que está sendo executado. Muito útil para manter o template atualizado e controlado;
  • AWS Amplify: framework em javascript que funciona com React e o novo App-Sync (GraphQL) para criação de aplicações web/mobile. O demo mostrou que é muito poderoso e de fácil uso. Para conferir – https://github.com/aws/aws-amplify;
  • Governança e Complaince: tópicos menos populares mas mais importantes em geral. AWS sempre fala sobre o ferramental: Service Catalog, SSM + Parameter Store (interessante – vale conferir para guardar parametros como senhas encriptados com KMS e centralizados em um repositório para reuso), CloudFormation, AWS Config, Inventory, CloudTrail. Gestão não pode ficar em segundo plano comparado ao desenvolvimento;
  • Serverless: lançamentos de suporte a .NET 2.0 Core e Go. Cloud9 – IDE de desenvolvimento web. Aumento de memória para 3GB e melhorias no console. Dead queue process (se Lambda falhar, joga para uma fila SQS). Criação de um repositório de lambdas onde se pode reutilizar ou aprender com o código de terceiros, uma espécie de MarketPlace;
  • IOT: evolução dos serviços com lançamento de diversas melhorias: 1-Click, Device Management, Device Defender (sobre segurança em dispositivos, evitar os famosos DDOS feitos por ‘torradeiras’…), Analytics. O ponto alto foi o lançamento de uma versão do FreeRTOS – sistema operacional de dispositivos que possuem um microcontrolador – com suporte direto aos serviços AWS. Isto amplia enormemente as possibilidades de conexão de dispositivos ao AWS;
  • VMWare e Hyper-V: a integração continua acontecendo, com a disponibilização do VMWare na região de Virgínia. Também foi anunciado que o serviço de migração de VMs suporta Hyper-V ;
  • HPC: anunciado bibliotecas MPI otimizadas para arquitetura AWS;
  • Lightsail: Load Balancer com preço definido para LightSail – infelizmente ainda não há LightSail na região do Brasil;
  • Time Sync Service: novo serviço de NTP (chrony) para sincronizar relógio de máquinas. Acessível via VPC e não precisa rotear para a internet, diminuindo complexidade de rede e aumentando segurança;
  • MarketPlace: no evento de parceiros, foram anunciadas algumas novidades para o MarketPlace – suporte a produtos com múltiplos AMIs, preços privados (isto é, com desconto para quando se tem escala), bem como um SAAS Factory a ser anunciado em 2018 que pretende ajudar a levar softwares para a nuvem em modelo multi-tenant;
  • AWS Elemental. Conjunto de funcionalidades para trabalhar com vídeo. Novidades e criação de uma camada de gerenciamento no topo de produtos já existentes (Transcoder, S3, etc);
  • Siemens Mindsphere: a Siemens anunciou uma parceira com o AWS para IOT. Para quem trabalha com manufatura e IOT vale avaliar;
  • Integração com Office 365: é fato consumado a relevância e importância do Office 365. Para evitar que os clientes usem o AD do Azure, o AWS investe em integração. Uma palestra discorreu sobre os passos de conexão e também sugeriu um tutorial. Notem que é longe de ser trivial, mas é possível. Na sessão ficou claro que ainda há muito o que fazer e a idéia é facilitar o trabalho conjunto;
  • Múltiplas contas. Em diversas apresentações o uso de múltiplas contas no AWS para uma mesma empresa ou parceiro, já é tratado com bastante naturalidade. A funcionalidade de organização permite criar contas facilmente com o billing já consolidado. Exemplos de contas foram desde as tradicionais contas de ‘produção’ e ‘desenvolvimento’, a conta exclusivas para rodar Active Directory, Banco de dados, etc. Sempre com a ideia de segmentação de ambientes por equipe, segurança, custos, facilidade de gerenciamento, controle de custos, cópias cofre. Se ainda não tentou trabalhar desta forma, faça um teste;
  • Anti-patterns: uma das melhores formas de aprender é procurar entender o que não fazer e aprender com os erros – casos de sucesso são interessantes, mas podem não contar toda uma estória. Assisti uma sessão (GPSTEC302) sobre problemas frequentes muito interessante. Foram listados 4 anti-patterns: perda de controle (quando credenciais se espalham, há riscos de segurança e eventual disrupção de algum serviço – daí a importância de fazer cópias cofre para outras contas AWS), controle de atualizações (pode ser mitigado pelo AWS Config e por ferramentas terceiras), DR automatizado (CloudFormation é uma excelente alternativa e minimizar o uso do console para mudanças manuais – sim… o engenheiro do AWS falou para não usar o console 🙂 ), teste de backups (o seu backup só é válido depois que testar, enquanto isto, não dá para afirmar se funcionou). Particularmente, ficamos muito orgulhosos por entender que o Cloud8 ajuda em todos os 4 anti-patterns e que corrobora o nosso roadmap de lançamentos!
  • AWS Well Architected: melhores práticas de arquitetura no AWS. É uma coleção de dicas ou ‘musts’ se preferir, sobre como usar melhor o AWS – operational excelence, security, reliability, performance efficiency e cost optimization. Vários tópicos podem ser encontrados no treinamento online e gratuito.

Curiosidades

Como não podia deixar de ser, uma enorme quantidade de curiosidades foi dita ao longo do evento. Selecionei algumas interessantes:

  • Novo hypervisor: O AWS não usa mais o Xen e passou a usar KVM. Mas ao que tudo indica desenvolveram o próprio, com codinome Nitro, que é uma camada mínima entre kernel, VM e hardware. Rede, por exemplo, acessa diretamente o hardware, sem subsistemas virtualizados – algo parecido com o Andromeda 2.1 do Google (só hypervisor, sem contar protocolos privados de rede e hardware próprios);
  • Cloud9. o AWS adquiriu uma empresa que possui uma IDE online – www.c9.io e integrou ao Lambda e ao CodeStar com todo o ferramental de ALM, CI/CD. O nome se deve, provavelmente, a um disco do George Harrison ou a expressão de ‘felicidade extrema’. Cloud8 foi escolhido por conta do número 8, em alusão ao símbolo matemático de infinito para indicar múltiplas funcionalides e integrações;
  • Segurança é responsabilidade de todos: o Werner insistiu na co-responsabilidade de todos em relação a segurança. Como infra, devops e desenvolvimento ficam estrelaçados, a responsabilidade por pensar e agir de forma segura não pode ser desacoplada para uma equipe dedicada;
  • Diversidade. Muito gratificante ver o AWS trazendo várias mulheres para palestrar e divulgar o seu trabalho. O Brasil também foi representado pelo Danilo Araujo em uma sessão sobre diversidade, apresentando o seu trabalho no AWS Meetup de São Paulo e Cloud Girls São Paulo;
  • Matt Wood, responsável agora pelo linha de inteligência artificial, mostrou um artigo de Machine Learning, onde um dos autores era a Kristen Stewart, a Bella do Crepúsculo (sic);
  • DeepLens – é uma nova câmera com capacidade de rodar modelos de machine learning embutidos (Greengrass ML Inference) em seu hardware e se conectando ao SageMaker. O Matt Wood mostrou a arquitetura de hardware e ideias para casos de uso – percebeu algo, dispara um Lambda. Quem diria que a Amazon atropelaria Google e Apple em Home Automation. Em pré-sale no amazon.com ;
  • Neural Style Translator: aplicar redes neurais com o estilo de um autor a uma imagem – https://deepart.io/ – muito bacana! Para referência de um projeto open source com TensorFlow – https://github.com/anishathalye/neural-style;
  • ML Labs: AWS lançou um Lab para quem quiser submeter casos de uso de IA. A ideia é ajudar a desenvolver o modelo e soluções em conjunto;
  • MapBox: descobrimos quem foi o primeiro cliente do SnowMobile (lembram do caminhão com dezenas de SnowBalls?) – MapBox. Eles moveram 100 PB de dados para o AWS;
  • Esportes: 2 cases de aplicação de inteligência artificial em esportes. Vídeos: NFL Next Gen Stats e UFC (simulação de luta ao vivo bem bacana!). E claro também tem para futebol – HUDL ;
  • Quotes:
    + “We are responsible for the security of the cloud.” – Werner Vogels, CTO do AWS;
    + “Dance like no one is watching, Encrypt like everyone is” – Werner Vogels;
    + “Security is everyone’s job” – Werner Vogels;
    + “Chaos doesn’t cause problems, it reveals them”. – Nora Jones, Netflix Engineer
    + “There’s no compression algorythm for experience” – Andy Jassy, CEO do AWS – antiga, mas ele sempre repete…;

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!

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

Obrigado
Renato
CIO/Founder

Novidade: continuidade de negócio / Cópia cofre

Novidade: + Continuidade de negócios / cópia cofre

Dados são tecnicamente a parte mais importante do seu negócio. Processos, proteções, contingências são termos de ordem responsável e vitais. Não é simples desenhar estes processos e contingências, mas estar em um Cloud como o AWS facilita e viabiliza tudo isto.

O Cloud8 já suporta diversos aspectos que ajudam na continuidade do seu negócio:

  • inventário de componentes;
  • auditoria e documentação de configurações de infraestrutura;
  • backups e snapshots;
  • cópias para outras regiões para fins de Disaster Recovery;
  • execução automática de scripts em servidores;
  • monitoração de acessos e mudanças;

Entretanto, mesmo que tenha cobertura técnica e de processos em sua totalidade, ainda há o risco de segurança ao se manter tudo em uma única conta – imagine que apesar de todos os processos e esforços que realize, um login ou uma credencial seja perdida e um acesso indevido é feito ao seu Cloud. Com má intenção, haveria a possibilidade de destruição de todos os componentes e dados….

Nota importante: este risco deve ser mitigado com melhores práticas de segurança: políticas e trocas constantes de senhas e chaves de acesso, uso preferencial de IAM Role, MFA habilitado, não usar conta Root, VPC gateways, monitoração de acessos e mudanças, etc.

Com estas premissas em mente, lançamos a cópia de segurança de backups (cópia cofre) para outras contas AWS.

O princípio é simples: realizar a cópia de um backup EC2 e/ou RDS para outra conta AWS de forma manual e/ou automatizada/agendada.

Esta outra conta AWS deve ter políticas e processos de segurança ainda mais restritos que as contas principais. Por exemplo: senhas restritas a poucos profissionais, política de retenção com mais dias, acessos de pontos ultra seguros, monitoração contínua e por aí vai.

Esta funcionalidade já está habilitada em todas as contas no Cloud8, sem custo adicional. Tanto para EC2 e RDS. O requisito para usá-la é possuir uma outra conta AWS, de preferência criada para ser utilizada exclusivamente como ‘cofre’.

É muito fácil criar esta conta no AWS – na opção ‘Organization’ do console AWS, crie uma conta AWS nova. Depois sincronize com o Cloud8 (na lista de ‘Provedores’, clique em ‘Novo’).

Após a criação da nova conta AWS e sincronização no Cloud8, é necessário habilitar as permissões de segurança:

  • na conta onde são realizados os backups: ec2:ModifyImageAttribute, ec2:ModifySnapshotAttribute, rds:ModifyDBSnapshotAttribute e rds:ModifyDBClusterSnapshotAttribute
  • na conta nova, destino da cópia de segurança: ec2:CopyImage, rds:CopyDBSnapshot, rds:CopyDBClusterSnapshot

A criação dos agendamentos também é simples. Pode criar novos ou editar um agendamento de backup existente e incluir uma nova tarefa “Cópia de segurança” no fim deste workflow.

Com a cópia armazenada na outra conta, pode recriar servidores e ainda recuperar os dados caso sua organização precise.

Planejamos diversas outras funcionalidades para copiar dados de uma conta AWS a outra. Aguardem!

Suporte a ALB, novos perfis, tags, relatórios de gestão

Suporte a ALB

O AWS lançou a nova geração do seu Load Balancer, o Application Load Balancer – ALB. A sua principal característica é o roteamento de tráfego na camada de URL/Domínio – na prática, rotear as requisições dos clientes para grupos de servidores respeitando regras, como “/application”, “/images” e/ou “dominio.com.br”, “dominionovo.com.br”. Estas novas rotas e regras são mapeadas por ‘Target Groups’ que determinam um ‘de-para’: chegou uma requisição, aplicam-se regras e esta é entregue para um dos servidores conectados ao Target Group. Um ALB pode ter múltiplos Target Groups e assim rotear tráfego de URLs distintas para endpoints distintos e especializados.

O antigo, Clássico, roteia somente para “portas”, como 80 (HTTP) e/ou 443 (HTTPS).

Dado o ganho de flexibilidade e escalabilidade, o uso do ALB se tornou bem popular e agora o Cloud8 já o suporta assim como já suportávamos o Load Balancer clássico.

Veja o que já é possível fazer:

  • visualizar os detalhes: Target Groups, servidores conectados, zonas de disponibilidade e VPC subnets;
  • conectar e desconectar servidores a um Target Group específico;
  • alertas se há problemas com Connection Draining e/ou política de SSL escolhida;
  • edição de tags (veja próximo tópico sobre as tags);
  • visualização dos grupos de segurança aos quais o LB está conectado no gerenciamento de SGs;
  • visualizar e analisar os custos detalhadamente;
  • agendamentos de conexão e desconexão.

Confira os agendamentos para ALB:

Há diversos casos de uso para se usar agendamentos com Load Balancers:

  • otimização/economia de recursos ao consolidar o tráfego para menos servidores em um determinado horário;
  • orquestração para upgrade/downgrade de servidores. Workflow: desconectar do LB -> parar servidor -> (que tal um backup assíncrono?) -> upgrade/downgrade -> ligar servidor -> conectar ao LB. Repetir para o segundo servidor apos 15 minutos e assim por diante;
  • integração contínua com execução de EC2 Commands e conexão/desconexão a LBs em um workflow programado toda a noite;
  • o seu caso de uso!

Perfis: novas ações

Já havíamos anunciado anteriormente o suporte a perfis com ações do agendador para servidores EC2. Agora já suportamos para ações de RDS como parar/iniciar – delegue a gestão da economia para os times e/ou responsáveis.

Além disto, criamos mais ações por perfis e auditáveis no log:

  • edição de tags dos componentes;
  • edição de grupos de segurança conectados a servidores – somente grupos que estejam conectados a servidores à sua escolha;
  • visualização de discos conectados aos servidores com permissão;

Caso de uso interessante: temos clientes que criaram usuários que combinam perfil ‘financeiro’ (com permissão de análise de custos) e com perfis de edição de tags de todos os componentes. Com esta configuração, o próprio pessoal do financeiro pode gerenciar a alocação das tags sem onerar tempo e recursos de TI.

Nota: se utilizar o Cloud8 na forma WhiteLabel (https://painel.cloud ou URL própria), pode produtizar o agendador e oferecer mais funcionalidades para o seu cliente final. É possível combinar este perfil com outros como gerenciar DNS, Banco de dados, métricas, etc – customize um painel de controle por usuário/cliente!

Tags: Load Balancer e Route53

Uma das melhores práticas recomendadas pelo AWS é o uso de tags em todos os componentes. Seja para fazer o rateio ou para acompanhar o custo e consumo de um determinado recurso.

O Cloud8 passa a suporte a edição de tags nos Load Balancers (seja Clássico ou Application LB) e nas zonas de DNS do Route53 – este último é particularmente difícil de fazer pelo console AWS (sic – deveria ser simples, mas não é…) e que geralmente é deixado de lado na maioria dos clientes que encontramos. Não deixa de usar tags nos domínios!

Novos relatórios de gestão

O Cloud8 lançou recentemente relatórios de gestão que permitem o acompanhamento em forma de resumo e dados de gestão de diversos cenários:

  • Backup status – quem está sem backup;
  • Tempo ligado dos servidores – habilitado a pedido;
  • Inventário de backups/snapshots por período;
  • Resumo dos custos de todas as contas AWS e estimativas;
  • Rateio do próprio Cloud8 para fins de multi provedor- habilitado a pedido;
  • Servidores parados há muito tempo;

Nesta nova versão, habilitamos mais 2 relatórios:

  • Agendamentos executados por período – pode optar por receber todos ou somente que apresentaram erro no AWS ou algum tipo de alerta;
  • Componentes sem tags – mais detalhes no próximo post!

Precisa de mais algum relatório? Fale conosco!

Outros

Seguem outras melhorias e correções que merecem destaque:

  • Suporte a nova zona de disponibilidade em EUA-Virgínia – us-east-1f;
  • Suporte a nova zona de disponibilidade na Alemanha – eu-central-1c;
  • Custos: análise de custos para AWS Lambda mostra custos e uso quebrado por região e nome da função chamada;
  • Custos: análise de custos para ElastiCache mostra custos e uso quebrado por região e nome do cluster;
  • Custos: suporte a Chime Dialin;
  • Dashboard de componentes não utilizados mostra o custo acumulado do quanto pode ser economizado;
  • Refactoring da aplicação de custos (Custos EC2/RDS) para ficar mais rápida e com melhor controle sobre os filtros;
  • RDS: suporte a mais eventos de erro como falha de option groups, instalação de Oracle em tipo não compatível. migração para Aurora com falhas, falta de capacidade no AWS para upgrade/downgrade;

Dúvidas, críticas, sugestões? Entre em contato!

Att
Equipe Cloud8

Novidade: Suporte a start/stop de RDS. Muito mais economia!

Uma das principais vantagens do Cloud Computing é pagar somente pelo recurso que utiliza.

No caso de servidores EC2, instância ligada é cobrada as horas de uso, desligada não. E para gerar este tipo de economia deve-ser ter uma forma de sempre de desligar e ligar a infraestrutura. Pode se fazer de forma manual, com scripts internos ou então utilizar um produto focado em trazer economia como o Cloud8.

Desde o começo de nossa operação, temos trazido esta economia com workflows agendados de ligar e desligar servidores EC2 (bem como upgrade/downgrade) e, no RDS, com upgrade/downgrade e ativação/desativação de MultiAZ. Confira o histórico:

https://www.cloud8.com.br/blog/como-economizar-na-nuvem-aws-da-amazon-usando-o-agendador-do-cloud8/

https://www.cloud8.com.br/blog/rds-economia-com-upgradedowngrade-automatizado-nova-regiao-frankfurt/

Quem passou a usar esta estratégia, imediatamente passou a economizar e diminuir os custos. Mas sempre ficou uma pergunta no ar… será que não dava para parar RDS também? Pois bem, o AWS acaba de lançar a funcionalidade de stop/start de RDS e já suportamos!

Aproveite os fins de semana e horários não comerciais, pare suas instâncias RDS e economize.

Desligando aos fins de semana (sexta 19:50 as seg 07:05): > 30%
Desligando aos fins de semana (sexta 19:50 a seg 07:05) + horário comercial (19:50 as 07:05): > 55%!

Suportamos de forma manual e agendada dentro de um workflow. Veja como ficou a lista de tarefas para montar o seu workflow agendado de RDS:

A configuração é imediata: entre no agendador, mude a visualização de componentes para ‘Banco de dados’ e selecione os servidores que deseja parar/iniciar.

Nota: só é possível parar um banco configurado como SingleAZ. Neste cenário, monte o seu workflow com uma primeira tarefa de Upgrade/Downgrade desmarcando o MultiAZ e logo em seguida uma tarefa de parar o banco de dados.

Não perca tempo e esforço desenvolvendo scripts, monitoração, auditoria, acompanhando atualizações de APIs e fazendo tratamento de erros inesperados!

Att,
Equipe Cloud8

PS. Se você utiliza uma credencial IAM customizada para o Cloud8, insira 2 permissões:
rds:StopDBInstances
rds:StartDBInstances

O Cloud8 cobra R$0,019/h (1,9 centavos/h) para uma instância RDS ligada. Para RDS desligado, cobramos R$0,009/h (0,9 centavos/h). Ou seja, usando o Cloud8 para economizar no AWS, também economiza no próprio!
Ainda não é cliente do Cloud? Faça um trial gratuito e completo sem compromisso!