Concrete Logo
Hamburger button

Amazon News – Qual a mensagem do re:Invent 2014 e os lançamentos da AWS

  • Blog
  • 24 de Novembro de 2014
Share

O re:Invent 2014 foi ainda maior que o do ano anterior. Mas antes de falar sobre o que aconteceu lá e sobre minhas opiniões e conclusões, saiba que todo o conteúdo do evento está disponível publicamente. Você pode ver as apresentações do re:Invent 2014 no Youtube. E se quiser os slides, eles estão disponíveis no slideshare.

Ao ver os dois keynotes, do Andy Jesse no primeiro dia aberto ao público e do Werner Vogels no segundo dia, a mensagem mais forte é a da importância de Configuration Management para a AWS.
No keynote exclusivo para os parceiros, vimos como Configuration Management foi importante para as campanhas da Coca-Cola passadas do “Big Game”.

O conceito que não se pode mais deixar passar é o de Infrastructure as Code…

Em vez de montarmos uma infraestrutura, utilizamos código fonte e esse código monta a infraestrutura para nós, integrada ao nosso ciclo de desenvolvimento e ao processo de deployment e testes. A sua infraestrutura, junto ao que considerávamos o sistema, passam a ser versionados juntos, e o hardware é consequência de um commit no controle de versão.
E é apenas assim que nossa gestão de configuração passa para outro nível, no qual podemos alavancar a alta disponibilidade e a escalabilidade que IaaS (Infrastructure as a service) podem proporcionar de fato. E o mais importante: prover ao negócio a flexibilidade e agilidade necessárias para reagir.

Indo além, a discussão sobre containers e suas facilidades em estratégias de blue-green deployments é o grande assunto na cloud, sendo liderados, é claro, pelo Docker.

E veja bem: quando o painel de VCs do evento para e discute Docker, sabemos que não estamos falando de algo apenas técnico, estamos falando algo com profundo impacto sobre a capacidade das empresas de fazer negócios e manter um diferencial competitivo.

Veja agora quais foram os lançamentos feitos no evento, e como podem ser úteis para você:

O AWS Key Management Service vai te ajudar a manter chaves de acessos para seus sistemas e subsistemas. Mais do que isso, faz ainda a rotação destas chaves com a mesma tecnologia usada para garantir a segurança do S3.
Ou seja, as chaves de criptografia que garantem a segurança dos cartões de crédito dos seus clientes podem contar com a mesma segurança utilizada pela própria AWS, que tem a confiança do DoD americano (Department of Defense).
Então, enquanto sua infraestrutura se transforma em código, não passamos a guardar as chaves criptográficas de acessos no controle de versão, a infraestrutura consome as chaves necessárias de um serviço feito para isso.
Com segurança e muita governança, sendo completamente auditável por meio do CloudTrail.

No AWS Config podemos ver cada mudança feita em nossa infraestrutura. O que foi mudado, quando e por quem. É um produto que ainda está em sua infância, mas acredito que será fundamental para uma melhor governança dos nossos ambientes.

O AWS EC2 Container Service talvez tenha sido o lançamento mais badalado e comentado do evento. Até agora, para usar Docker na AWS tinhamos duas formas: construir nossa infra no EC2 e conviver com a complicação de acionar o Docker por meio de scripts de CloudFormation ou usar no Elastic BeanStalk e conviver com a limitação de ter apenas um container por instância…
Neste Container Service trabalhamos em um nível mais alto de controle, ou seja, programamos o cluster, que tipo de resposta queremos que o cluster tenha, e o deployment passa ser apenas uma questão de trocar a imagem que estamos usando.

Se você não sabe ainda o quanto o Docker pode te facilitar os deployments relâmpagos, veja isso aqui:

O AWS Service Catalog também te ajuda na governança dos seus stacks. O objetivo é dar autonomia aos desenvolvedores sem perder a governança necessária sobre quais serviços são oferecidos aos usuários finais e sob quais condições estes serviços são oferecidos.
Ou seja, o serviço procura oferecer a normatização e controle que um produto SOA te oferece, mas sem abrir mão da autonomia do seu time de desenvolvimento e da flexibilidade, escalabilidade e etc. providos pela nuvem.

O AWS CodeDeploy era, sinceramente, o produto que eu aguardava com mais ansiedade. Ele é baseado no Apollo, um produto que era usado internamente pela Amazon para deployment, e que agora está disponível também para nós.
Junto com o CodePipeline e o CodeCommit, o avanço dos serviços da AWS para complementar nossa engenharia de software é grande.
Uma das utilidades do CodeDeploy está na simplificação de rolling deployments. Imagine que você tem uma versão nova para fazer deployment, e ao mesmo tempo, seu sistema em produção está atendendo a milhares de requisições atrás de um ELB. Dentre outras situações, gostaríamos de fazer o deployment sem interromper o serviço. Podemos fazer o deployment de cada servidor, esperar o resultado do deployment e tomar alguns cuidados na interrupção de cada servidor usando nossos scripts. E agora também poderemos fazer isso com o CodeDeploy.

Com o CodePipeline teremos uma nova opção para integração contínua, com uma grande vantagem e não precisamos de um servidor EC2 com nossa instalação de uma máquina de build! Será que o Jenkins vai se aposentar ?

Jenkins

Por sua vez, com o CodeCommit teremos um forte concorrente ao GitHub e ao BitBucket da Atlassian, com a vantagem de termos arquivos atendidos com a qualidade de serviço do S3. Então, o velho dilema do que fazer com os arquivos de media ou com fontes binárias deve diminuir, pelo menos um pouco.
Parte do problema do que fazer com as fontes dos arquivos do photoshop, videos, imagens em alta definição, etc. deve ser resolvida com uma infraestrutura melhor. Veremos… Esse foi apenas anunciado para o início de 2015, nos resta esperar.

Por fim, outros 2 lançamentos também importantes foram feitos e é importante citá-los aqui.

O Aurora é um novo serviço do RDS. Um banco de dados relacional, baseado no engine do mySQL, porém com a intenção de entregar uma performance “Enterprise” por um décimo do preço.
Saiba mais sobre o Aurora:

E por fim, o AWS Lambda, que preenche uma lacuna importante. Normalmente na AWS quando queremos tratar um evento precisamos de ao menos uma máquina no EC2 programada para fazer coisas para nós. Por exemplo, colocamos algo em um DataPipe para ser tratado. E gostaríamos de não ter um servidor no EC2 apenas para monitorar o DataPipe e iniciar nosso job de tratamento.
Com o AWS Lambda temos uma forma simples de tratar eventos e já integrada com vários dos serviços disponíveis.

Está com dúvidas sobre algum dos lançamentos ou seus impactos ? Comente aqui embaixo!