© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Heitor Vital, Arquiteto de Soluções - AWS Brasil
Setembro 2016
Arquitetura Serverless
para Microserviços com AWS
O Que Esperar da Apresentação
• Evolução Arquitetura
• Serviços
• AWS Lambda
• Amazon API Gateway
• Amazon Simple Storage Service (S3)
• Amazon DynamoDB
• Zombie Chat
Evolução Arquitetura – Cloud Pública
InfraInstancias
Código Aplicação
Evolução Arquitetura – Containers
InfraInstancias
Código AplicaçãoContainers
Evolução Arquitetura – Serverless
Código Aplicação
Benefícios
• Nenhum Servidor para gerenciar
• Planejamento de capacidade
• Planejamento de Auto Scaling
• Atualizações
• Patches
• Maior Produtividade
• Escalabilidade Nativa
• Custo <> Número de acesso
• Evolução Arquitetura
• Serviços
• AWS Lambda
• Amazon API Gateway
• Amazon Simple Storage Service (S3)
• Amazon DynamoDB
• Zombie Chat
AWS Lambda
Serverless, event-driven compute service
microservice sem servidores
Como Funciona
1. Upload do código
2. Configure evento e
permissões
3. Lambda executa em
resposta a eventos
4. Pague somente quando
a fução for executada
Integrações
Lambda
Backend
SNS
Cognito
Kinesis
Dynamo
S3
SDK
Mobile, Alexa
…
API Gateway
SES
CloudWatch
CloudFormation
AWS Config
Scheduled events
SOURCE
data
Pool de servidores para
coletar mudanças
Listening to source Pushes Pull
Pool de Servidores/Workers
para processar dados
Workers
com ASG
S3 objects
Amazon Kinesis records
DynamoDB tables
SNS messages
IoT devices
…
Replicação
Cross-AZ
Load
Balancer
Data Processing – Arquitetura com Servidores
Código Aplicação
SOURCE of
data
Attach a Lambda function
Só Isso!
Funções do Lambda:
Listening/Polling
Queuing
Auto Scaling
Redundância
Load balancing
Código Aplicação
Data Processing – Arquitetura sem Servidores
• Evolução Arquitetura
• Serviços
• AWS Lambda
• Amazon API Gateway
• Amazon Simple Storage Service (S3)
• Amazon DynamoDB
• Zombie Chat
Proliferação de APIs
O número de APIs publicadas está crescendo rapidamente
2418
10302
0
2000
4000
6000
8000
10000
12000
Jun-05
Nov-05
Apr-06
Sep-06
Feb-07
Jul-07
Dec-07
May-08
Oct-08
Mar-09
Aug-09
Jan-10
Jun-10
Nov-10
Apr-11
Sep-11
Feb-12
Jul-12
Dec-12
May-13
Oct-13
* Dados do ProgrammableWeb
Na AWS, nós rodamos muitas APIs
…Com o passar do tempo, nós aprendemos algumas lições
Seu feedback
Gerenciar múltiplas versões e estágios de uma API é difícil.
Seu feedback
Gerenciar múltiplas versões e estágios de uma API é difícil.
Monitorar acessos de desenvolvedores terceiros consome tempo.
Seu feedback
Gerenciar múltiplas versões e estágios de uma API é difícil.
Monitorar acessos de desenvolvedores terceiros consome tempo.
Autorizar acessos é desafiador.
Seu feedback
Gerenciar múltiplas versões e estágios de uma API é difícil.
Monitorar acessos de desenvolvedores terceiros consome tempo.
Autorizar acessos é desafiador.
Picos de tráfego geram um peso operacional.
Seu feedback
Gerenciar múltiplas versões e estágios de uma API é difícil.
Monitorar acessos de desenvolvedores terceiros consome tempo.
Autorizar acessos é desafiador.
Picos de tráfego geram um peso operacional.
E se eu não quiser nenhum servidor?
Amazon API Gateway
Hospede múltiplas versões e ambientes das suas APIs
Crie e distribua chaves de API para desenvolvedores
Beneficie-se da Sigv4/JTW/OAuth para autorizar acesso às APIs
Controle e monitore requisições para proteger o backend, Cache ..
Use AWS Lambda!
Fluxo de uma chamada API
Internet
Mobile
apps
Websites
Serviços
API
Gateway
Funções
AWS
Lambda
AWS
API
Gateway
cache
Endpoints
na Amazon
Qualquer outro
endpoint
acessível
Amazon
CloudWatc
h
Configuração da API
Você pode criar APIs
Definir recursos da API
Definir métodos para o recurso
• Métodos são recurso + HTTP verb
Pet Store
/pets
/pets/{petId}
• GET
• POST
• PUT
Deploy da API
Configuração da API pode ser implantado em
um ambiente (stage)
Stages são ambientes diferentes; por exemplo:
• Dev (e.g., example.com/dev)
• Beta (e.g., example.com/beta)
• Prod (e.g., example.com/prod)
Pet Store
dev
beta
gamma
prod
Gerencie múltiplos ambientes e versões de sua API
API 1 (v1)
Stage (dev)
Stage (prod)
API 2 (v2)
Stage (dev)
Segurança – Custom Authorizer
Caching API responses
API Gateway
Back end
GET - /sayHello
AWS
Lambda
fn_sayHello
/sayHello
{
“message” : “hello world”
}
<xml>
<message>
Hello world
</message>
</xml>
#set($root = $input.path('$'))
<xml>
<message>
$root.message
</message>
</xml>
Input/output transforms
Outras Funcionalidades
Mock Integration
Importador de Swagger
Gere SDKs a partir de sua API
Custom Domain / HTTPS
Client-Side SSL Authentication
Link lambda version
• Evolução Arquitetura
• Serviços
• AWS Lambda
• Amazon API Gateway
• Amazon Simple Storage Service (S3)
• Amazon DynamoDB
• Zombie Chat
Amazon Simple Storage Service (S3)
• Seguro
• Criptografia em transito - HTTPS
• Criptografia em respouso (Amazon S3 key, client key, AWS KMS)
• Durável
• Projetado para 99.999999999% de durabilidade
• Escalável
• Milhões de request por segundo
• Trilhões de objetos
• Evolução Arquitetura
• Serviços
• AWS Lambda
• Amazon API Gateway
• Amazon Simple Storage Service (S3)
• Amazon DynamoDB
• Zombie Chat
Amazon DynamoDB
• NoSQL database
• Documento
• Chave Valor
• Totalmente gerenciado
• Latência dentro de 1 dígito de ms
• Escalabilidade massiva
• Modo de Usar
• Crie tabela
• Defina capacidade de leitura e escrita
Latência baixa e previsível
Latência consistente em 1 dígito de ms mesmo em escalas massivas
The Zombie Apocalypse Survival
Instruções disponível em:
http://bit.ly/reinvent-wrk305
High-level Zombie Chat architecture
Bucket com uma
single-page app
HTML5
Funções
GetMessagesFromDynamoDB
WriteMessagesToDynamoDB
Web client
/zombie/messages
API com métodos
GET e POST
Tabela ‘messages’
com informações
de grupo,
timestamp, UUID,
nome e texto
Referencias
• AWS Serverless Multi-Tier Architectures
• Whitepaper: http://bit.ly/2cSeOR4
• Surviving the Zombie Apocalypse with Serverless Microservices
• BlogPost: http://amzn.to/2cugn2T
• GitHub: http://bit.ly/2cHgkQZ
• Serverless Bookmark
• GitHub: http://bit.ly/2cug6gf
• Reference Architectures and Sample Code
• Web Applications: http://bit.ly/2d8cBAp
• Mobile Backends: http://bit.ly/2d5PxiO
• IoT Backends: http://bit.ly/2d23imu
• File Processing: http://bit.ly/2d5OVtv
• Stream Processing: http://bit.ly/2cEQGiT
Obrigado!
Heitor Vital, Arquiteto de Soluções - AWS Brasil

AWS

  • 1.
    © 2016, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Heitor Vital, Arquiteto de Soluções - AWS Brasil Setembro 2016 Arquitetura Serverless para Microserviços com AWS
  • 2.
    O Que Esperarda Apresentação • Evolução Arquitetura • Serviços • AWS Lambda • Amazon API Gateway • Amazon Simple Storage Service (S3) • Amazon DynamoDB • Zombie Chat
  • 3.
    Evolução Arquitetura –Cloud Pública InfraInstancias Código Aplicação
  • 4.
    Evolução Arquitetura –Containers InfraInstancias Código AplicaçãoContainers
  • 5.
    Evolução Arquitetura –Serverless Código Aplicação
  • 6.
    Benefícios • Nenhum Servidorpara gerenciar • Planejamento de capacidade • Planejamento de Auto Scaling • Atualizações • Patches • Maior Produtividade • Escalabilidade Nativa • Custo <> Número de acesso
  • 7.
    • Evolução Arquitetura •Serviços • AWS Lambda • Amazon API Gateway • Amazon Simple Storage Service (S3) • Amazon DynamoDB • Zombie Chat
  • 8.
    AWS Lambda Serverless, event-drivencompute service microservice sem servidores
  • 9.
    Como Funciona 1. Uploaddo código 2. Configure evento e permissões 3. Lambda executa em resposta a eventos 4. Pague somente quando a fução for executada
  • 10.
  • 11.
    SOURCE data Pool de servidorespara coletar mudanças Listening to source Pushes Pull Pool de Servidores/Workers para processar dados Workers com ASG S3 objects Amazon Kinesis records DynamoDB tables SNS messages IoT devices … Replicação Cross-AZ Load Balancer Data Processing – Arquitetura com Servidores Código Aplicação
  • 12.
    SOURCE of data Attach aLambda function Só Isso! Funções do Lambda: Listening/Polling Queuing Auto Scaling Redundância Load balancing Código Aplicação Data Processing – Arquitetura sem Servidores
  • 13.
    • Evolução Arquitetura •Serviços • AWS Lambda • Amazon API Gateway • Amazon Simple Storage Service (S3) • Amazon DynamoDB • Zombie Chat
  • 14.
    Proliferação de APIs Onúmero de APIs publicadas está crescendo rapidamente 2418 10302 0 2000 4000 6000 8000 10000 12000 Jun-05 Nov-05 Apr-06 Sep-06 Feb-07 Jul-07 Dec-07 May-08 Oct-08 Mar-09 Aug-09 Jan-10 Jun-10 Nov-10 Apr-11 Sep-11 Feb-12 Jul-12 Dec-12 May-13 Oct-13 * Dados do ProgrammableWeb
  • 15.
    Na AWS, nósrodamos muitas APIs …Com o passar do tempo, nós aprendemos algumas lições
  • 16.
    Seu feedback Gerenciar múltiplasversões e estágios de uma API é difícil.
  • 17.
    Seu feedback Gerenciar múltiplasversões e estágios de uma API é difícil. Monitorar acessos de desenvolvedores terceiros consome tempo.
  • 18.
    Seu feedback Gerenciar múltiplasversões e estágios de uma API é difícil. Monitorar acessos de desenvolvedores terceiros consome tempo. Autorizar acessos é desafiador.
  • 19.
    Seu feedback Gerenciar múltiplasversões e estágios de uma API é difícil. Monitorar acessos de desenvolvedores terceiros consome tempo. Autorizar acessos é desafiador. Picos de tráfego geram um peso operacional.
  • 20.
    Seu feedback Gerenciar múltiplasversões e estágios de uma API é difícil. Monitorar acessos de desenvolvedores terceiros consome tempo. Autorizar acessos é desafiador. Picos de tráfego geram um peso operacional. E se eu não quiser nenhum servidor?
  • 21.
    Amazon API Gateway Hospedemúltiplas versões e ambientes das suas APIs Crie e distribua chaves de API para desenvolvedores Beneficie-se da Sigv4/JTW/OAuth para autorizar acesso às APIs Controle e monitore requisições para proteger o backend, Cache .. Use AWS Lambda!
  • 22.
    Fluxo de umachamada API Internet Mobile apps Websites Serviços API Gateway Funções AWS Lambda AWS API Gateway cache Endpoints na Amazon Qualquer outro endpoint acessível Amazon CloudWatc h
  • 23.
    Configuração da API Vocêpode criar APIs Definir recursos da API Definir métodos para o recurso • Métodos são recurso + HTTP verb Pet Store /pets /pets/{petId} • GET • POST • PUT
  • 24.
    Deploy da API Configuraçãoda API pode ser implantado em um ambiente (stage) Stages são ambientes diferentes; por exemplo: • Dev (e.g., example.com/dev) • Beta (e.g., example.com/beta) • Prod (e.g., example.com/prod) Pet Store dev beta gamma prod
  • 25.
    Gerencie múltiplos ambientese versões de sua API API 1 (v1) Stage (dev) Stage (prod) API 2 (v2) Stage (dev)
  • 26.
  • 27.
  • 28.
    API Gateway Back end GET- /sayHello AWS Lambda fn_sayHello /sayHello { “message” : “hello world” } <xml> <message> Hello world </message> </xml> #set($root = $input.path('$')) <xml> <message> $root.message </message> </xml> Input/output transforms
  • 29.
    Outras Funcionalidades Mock Integration Importadorde Swagger Gere SDKs a partir de sua API Custom Domain / HTTPS Client-Side SSL Authentication Link lambda version
  • 30.
    • Evolução Arquitetura •Serviços • AWS Lambda • Amazon API Gateway • Amazon Simple Storage Service (S3) • Amazon DynamoDB • Zombie Chat
  • 31.
    Amazon Simple StorageService (S3) • Seguro • Criptografia em transito - HTTPS • Criptografia em respouso (Amazon S3 key, client key, AWS KMS) • Durável • Projetado para 99.999999999% de durabilidade • Escalável • Milhões de request por segundo • Trilhões de objetos
  • 32.
    • Evolução Arquitetura •Serviços • AWS Lambda • Amazon API Gateway • Amazon Simple Storage Service (S3) • Amazon DynamoDB • Zombie Chat
  • 33.
    Amazon DynamoDB • NoSQLdatabase • Documento • Chave Valor • Totalmente gerenciado • Latência dentro de 1 dígito de ms • Escalabilidade massiva • Modo de Usar • Crie tabela • Defina capacidade de leitura e escrita
  • 34.
    Latência baixa eprevisível Latência consistente em 1 dígito de ms mesmo em escalas massivas
  • 35.
    The Zombie ApocalypseSurvival Instruções disponível em: http://bit.ly/reinvent-wrk305
  • 36.
    High-level Zombie Chatarchitecture Bucket com uma single-page app HTML5 Funções GetMessagesFromDynamoDB WriteMessagesToDynamoDB Web client /zombie/messages API com métodos GET e POST Tabela ‘messages’ com informações de grupo, timestamp, UUID, nome e texto
  • 37.
    Referencias • AWS ServerlessMulti-Tier Architectures • Whitepaper: http://bit.ly/2cSeOR4 • Surviving the Zombie Apocalypse with Serverless Microservices • BlogPost: http://amzn.to/2cugn2T • GitHub: http://bit.ly/2cHgkQZ • Serverless Bookmark • GitHub: http://bit.ly/2cug6gf • Reference Architectures and Sample Code • Web Applications: http://bit.ly/2d8cBAp • Mobile Backends: http://bit.ly/2d5PxiO • IoT Backends: http://bit.ly/2d23imu • File Processing: http://bit.ly/2d5OVtv • Stream Processing: http://bit.ly/2cEQGiT
  • 38.
    Obrigado! Heitor Vital, Arquitetode Soluções - AWS Brasil

Notas do Editor

  • #11 verify data formats, audit out-of-range values, filter and copy data to other tables - Add in API Gateway here as that is a huge use case. You may want to ensure you have the complete list of integrated services. - You may want to talk a bit about the push versus pull model of invocation, as well as the request response
  • #13 [57 MINUTES] Great use case from Greg and the team at CarSales. So you can see that Lambda has utility in any scenario where you have short-lived, ad-hoc function calls and don’t want to run a fleet of EC2 instances to process an event. It allows you to create event-driven architectures and let AWS worry about the infrastructure to run your code. Lambda has huge potential to simplify and decouple your application architecture, whether you are working in Mobile/IoT or any application space To recap: … Focus on business logic, not infrastructure Upload your code, and let Lambda handle: Capacity Scaling Deployment Fault tolerance Logging & Monitoring Security patching
  • #24 Let’s look in details at the hierarchical structure of an API The top level element is the API itself, we call it a REST API. A rest API can contain many resources, resources are typed objects that are part of your API’s domain. They also represent the path through which the objects will be accessible You can nest resources, in our example the /pet/{petId} represents an individual pet and is a nested resource of the /pets/ resource. Each resource can declare methods. Methods are the combination of a resource + an HTTP Verb. We support 7 standard HTTP Verbs, For example, a method is the POST to the /pets/{petId} resources – this would be used to create a new pet
  • #25 Now that we have declared an API with its resources and methods, we can deploy it to make it accessible to 3rd party developers APIs are deployed to a Stage Stages represent environments, for example development of production In API Gateway Stages are like tags, and developers can create as many stages as they want. A stage is just an alphanumeric string Stages are part of the path that will be used to reach sources and methods, for example the prod stage will be available at execute-api.apigateway.com/stage/resource
  • #26 This is a visual representation of how versions and stages are managed by the API Gateway, and how customers can leverage these features for their APIs The first thing we’ll do is declared a V1 API and start configuring its resources and methods The next step is to deploy the API to a development stage, we’ll keep deploying to development as we evolve our API At a certain point, when we are ready for 3rd party developers to access this API, we will publish it to a production stage and distribute API Keys and generated SDKs All along we will keep deploying APIs to both dev and prod including new features and bug fixed Eventually we’ll want to make some breaking changes, and work on a much improved v2 API. However, we cannot make breaking changes to the API in production because we have thousands of developers using it. To manage this situation we’ll simply clone the current state of the v1 API into a new API called v2, and begin development of the new version By cloning we can keep publishing bug fixes to the first release and supporting users that are calling it with a gentle, gradual deprecation “… developers feel like they can deliver what they want, when they want to – and that makes for an extremely valuable tool …”
  • #27 API Gateway uses throttling to help protect customer backends and send only request that they can handle To implement throttling we use the token bucket algorithm Customers can set the number of RPS calls they know their backend can handle, and a rate at which the bucket is refilled
  • #28 Let’s put the two together and look at the execution path of an API call First, when we receive a request, we will check the dedicated cache (if it’s been configured) If we have an item in the cache then we can handle the request regardless of the throttling configuration, it will have no effect on our customer’s backend Next, if we don’t have a cache, we check the throttling configuration and the current throttling state (our bucket) If we are above the limit we will return a 429 response Otherwise we will execute the backend call and return the result As we mentioned our generated SDKs automatically know how to handle throttling responses, and they will perform an exponential backoff while retrying the call
  • #29 Example of a simple transformation flow API Gateway + Lambda = Server-less backend Use AWS Lambda to run business logic Use API Gateway to expose the AWS Lambda functions as endpoints Transforms Lambda’s JSON output to XML for their APIs
  • #30 API Gateway can generate client SDKs based on a customer’s API definition. Simply select the deployment the SDK should target, the platform, and setup a couple of parameters and the API Gateway generates an SDK and makes it available to download through an API or the management console SDK are model-aware and also come with the built-in AWS core that allows them to handle throttling responses and sign requests using AWS Credentials
  • #32 Store 10 thousand objects – lose one object every 10 million years
  • #34 Store 10 thousand objects – lose one object every 10 million years
  • #35 The latency characteristics of DynamoDB are under 10 msec and highly consistent. Most importantly, the data is durable in DynamoDB, constantly replicated across multiple data centers and persisted to SSD storage.