Arquiteturas serverless permitem que você possa construir e executar aplicativos e serviços sem a necessidade de gerenciar a infra-estrutura que necessita. Com arquiteturas serverless na AWS sua aplicação é executada mas toda a administração é da AWS.
Neste webinar, você vai aprender a construir aplicações e serviços que utilizam a arquitetura serverless ou "sem servidor". Discutiremos como utilizar AWS Lambda para a execução de código de qualquer aplicação ou serviço de back-end, utilizar o Amazon DynamoDB para armazenar os dados com escalabilidade e redundância e usar Amazon API Gateway para criar e gerenciar pontos de conexão de API com segurança. Também vamos ver uma demonstração de como construir uma arquitetura serverless e discutir as melhores práticas e padrões utilizados por nossos clientes para executar servidores de aplicativos.
Objetivos de aprendizagem:
• Compreender as noções básicas de arquiteturas serverless
• Aprenda a usar Lambda, API Gateway e DynamoDB para executar aplicativos
Os benefícios de migrar seus workloads de Big Data para a AWS
Conceitos básicos das arquiteturas Serverless
1. 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
7. Ferramentas para ajudar esse padrão são VASTAS
Servidores da Web
Bibliotecas de código
Estrutura de web services/aplicativo
Ferramentas de gerenciamento de
configuração
Plataformas de gerenciamento de API
Padrões de implantação
Padrões de CI/CD
Contêineres
Etc. Etc. Etc.
8. A AWS ajudou também!
Amazon EC2
EC2 Auto-Scaling
AWS Elastic Load Balancer
EC2 Auto-Recovery
AWS Trusted Advisor
AWS Elastic Beanstalk
AWS OpsWorks
AWS EC2 Container Service
Etc. Etc. Etc.
10. 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 servidores
devo orçar?
Qual SO meus servidores
devem 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 decidir
escalonar meus servidores?
Como devo lidar com alterações na
configuração do servidor?
Como o aplicativo lidará com falha
de hardware do servidor?
11. 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
13. Serviço de computação Serverless, orientado por evento
Lambda = microsserviço sem servidor
14. 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
15. 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 Lambda
válida e completa
16. 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
17. 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).
18. 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
20. Muitas das formas existentes de abstrair servidores
SaaS
PaaS
MBaaS
*aaS
Mecanismos/plataformas de aplicativos
21. 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 comunidade
Integração com o ecossistema de serviços da AWS!
• Escala
• Triggers
22. 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
24. 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
25. “Mas…
Para usar o Lambda, preciso mesmo
arquiteturar aplicativos orientados
para eventos?” – você (talvez)
35. 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)
36. 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 Integrations
2. 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)
37. 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.