2016, Amazon Web Services, Inc. ou Afiliadas. Todos os direitos reservados.

Renato Barbosa, Arquiteto de Soluções, AWS

30 de Novembro de 2016

Conceitos básicos das arquiteturas Serverless

Pauta

HistóricoAWS LambdaAmazon API GatewayDemonstraçãoPadrões de arquitetura sem servidorMelhores práticas sem servidor

HistóricoComo os padrões de arquitetura Serverless com o AWS Lambda são a próxima evolução do design de aplicativos

A arquitetura monolítica

A arquitetura orientada a serviços

Camada de apresentação Camada lógica

Nível de dados

A arquitetura de microsserviços

Ferramentas para ajudar esse padrão são VASTAS

Servidores da WebBibliotecas de códigoEstrutura de web services/aplicativoFerramentas de gerenciamento de configuraçãoPlataformas de gerenciamento de APIPadrões de implantaçãoPadrões de CI/CDContêineresEtc. Etc. Etc.

A AWS ajudou também!

Amazon EC2EC2 Auto-ScalingAWS Elastic Load BalancerEC2 Auto-RecoveryAWS Trusted AdvisorAWS Elastic BeanstalkAWS OpsWorksAWS EC2 Container ServiceEtc. Etc. Etc.

Mas….Várias dessas ferramentas e inovações ainda estão aliadas a muitas dependências...

Servidores (AAHHHHHHHHH!!)Qual tamanho de servidor

é adequado para o meu orçamento?

Quantos usuários criam excesso carga para os meus

servidores?

Qual capacidade disponível têm meus servidores?

Como posso detectar se um servidor ficou comprometido?

Quantos servidoresdevo orçar?

Qual SO meus servidoresdevem executar?

Quais usuários deveriam ter acesso aos meus servidores?

Como posso controlar o acesso dos meus servidores?

Como eu manterei os os patches do SO do meu

servidor?

Como o novo código seráimplantado nos meus

servidores?

Como poderei aumentar a utilização dos meus

servidores?

Quando devo decidir escalonar meus servidores?

Que tamanho de servidor é adequado para o meu

desempenho?

Devo ajustar as configurações de SO para otimizar meu aplicativo?

Quais pacotes devem ser "baked" nas minhas imagens do servidor?

Quando devo decidirescalonar meus servidores?

Como devo lidar com alterações na configuração do servidor?

Como o aplicativo lidará com falha de hardware do servidor?

Arquitetar para ser Serverless

Totalmente gerenciado• Sem provisionamento• Administração zero• Alta disponibilidade

Produtividade do desenvolvedor• Foco no código que importa• Inovação rápida• Redução do time-to-market

Escalabilidade contínua• Automaticamente• Escalabilidade para mais

ou menos

AWS Lambda

Serviço de computação Serverless, orientado por evento

Lambda = microsserviço sem servidor

Componentes do Lambda

• Uma função do Lambda (código) • Uma fonte de evento• O serviço do AWS Lambda• O ambiente de rede de execução

A função do Lambda

• Seu código (Java, NodeJS, Python)

• O IAM role que o código assume durante a execução

• A quantidade de memória alocada para seu código (afeta CPU e rede também)

Uma função do Lambdaválida e completa

Uma fonte de evento

• Quando sua função deve ser executada?

• Muitos serviços da AWS podem ser uma fonte de evento:

• S3• Kinesis• SNS• DynamoDB• CloudWatch• Config Rules• Amazon Echo• Etc.• …e o Amazon API

Gateway

O serviço do AWS Lambda

• Executa seu código de função sem você gerenciar ou escalonar servidores.

• Fornece API para chamar a execução da sua função.• Garante que a função seja executada quando chamada,

em paralelo, independentemente de escala.• Fornece outros recursos para sua função (logs,

monitoramento).

O ambiente de rede de funções

Default – é fornecido a execução da função no ambiente de uma VPC padrão.

• Acesso à internet sempre permitido para sua função

• Sem acesso a ativos implementados na VPC

VPC do cliente – Sua função é executada dentro do contexto da sua própria VPC.

• Comunique-se privadamente com outros recursos dentro da VPC.

• Configuração e comportamento conhecidos com:– Sub-redes– Elastic Network Interfaces (ENIs)– Security Groups do EC2– Tabelas de rotas (Route Tables)

da VPC– NAT Gateway

“Espere…” – você (talvez)

Muitas das formas existentes de abstrair servidores

SaaSPaaSMBaaS*aaSMecanismos/plataformas de aplicativos

O que é único em relação ao Lambda?

Abstração do nível de código/função (flexível, familiar)O modelo de segurança (IAM, VPC)O modelo de preço A comunidadeIntegração com o ecossistema de serviços da AWS!

• Escala• Triggers

Várias opções sem servidor na AWS

Armazenamento Banco de dadosRede

Computação Entrega de conteúdoSistemas de mensagens e filasSegurança

Gateways

Gerenciamento de usuários Monitoramento e registro

Internet das Coisas

Machine Learning

Analytcs do streaming

Exemplo de arquitetura Serverless

PlayOn! Sports – processamento de streaming de vídeo

Codifica-dores de laptop

HLS

Reproduzir S3

Cliente móvel do

VOD Stream

Streaming do

CloudFront

Streaming em tempo

real do cliente móvel

CloudFront

S3 Ingest

Transcodi-ficar 480p

Copiar HQ

Transcodi-ficar 360p

Transcodifica-ção

somente do áudio

Miniatura

Análise de QOS

Funções do Lambda em cascata

http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda

“Mas… Para usar o Lambda, preciso mesmo arquiteturar aplicativos orientados para eventos?” – você (talvez)

O SOA ainda funciona.

Amazon API Gateway

Um serviço totalmente gerenciado para suas APIs

Crie Configure Publique

Mantenha Monitore Proteja

Demonstração

Função do AWS

Lambda

navegador da web

Amazon S3

Conteúdo dinâmico

Website sem servidor

Amazon API

Gateway

Conteúdo estático

Amazon DynamoDB

Padrões de arquitetura Serverless

Microsserviços

Back-end móvel

Mecanismo de análise em tempo real

Melhores práticas Serverless

Melhores práticas do AWS Lambda

1. Limite o tamanho da sua função – especialmente para Java (iniciar o JVM leva tempo)

2. Nó – lembre-se de que a execução é assíncrona.

3. Não pressuponha reutilização do contêiner da função – mas aproveite quando isso ocorrer.

4. Não se esqueça do disco (diretório /tmp de 500 MB fornecido a cada função)

5. Use apelidos ("Aliases") da função para liberação.

6. Use o logger incluído (inclua detalhes do contexto fornecido pelo serviço)

7. Crie métricas personalizadas (centradas em operações e em negócios)

Melhores práticas do Amazon API Gateway

4. Use modelos de mapeamento de solicitação/resposta em todos os lugares dentro da razão, não passagem.

5. Assuma propriedade dos códigos de resposta de HTTP

6. Use importar/exportar Swagger para compartilhamento entre contas

1. Use Mock Integrations2. Combine com Cognito para

controle de acesso baseado em usuário final.

3. Use variáveis de estágio (injete valores do config da API nas funções do Lambda para registro, comportamento)

Melhores práticas adicionais

1. Use convenções de nomes estratégicos e consumíveis (nomes da função do Lambda, funções de IAM, nomes da API, nomes do estágio da API, etc.)

2. Use convenções de nome e versionamento para criar automação.

3. Externalize autorização para funções de IAM sempre que possível

4. Privilégio mínimo e funções de IAM separadas

5. Externalize a configuração – o DynamoDB é ótimo para isso.

6. Entre em contato com suporte da AWS em case de grandes eventos de escalabilidades conhecidos

7. Tenha ciência de estrangulamento de serviço, fale com o suporte da AWS em caso positivo.

Call-to-action

Vá construir algo!

Amazon API Gateway

AWS Lambda AmazonDynamoDB

Obrigado!