Arquitetura Serverless para Microserviços
•Transferir como PPTX, PDF•
0 gostou•280 visualizações
A apresentação discute a arquitetura serverless para microserviços com AWS. Apresenta a evolução da arquitetura de nuvem pública para containers e serverless. Detalha os serviços AWS Lambda, API Gateway, S3 e DynamoDB e mostra um exemplo de chat zombie implementado com esses serviços.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Arquitetura Serverless para Microserviços
Semelhante a Arquitetura Serverless para Microserviços (20)
Mais de melidevelopers
Mais de melidevelopers (20)
Arquitetura Serverless para Microserviços
- 1. © 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
- 2. 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
- 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 Servidor para 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-driven compute service microservice sem servidores
- 9. 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
- 10. Integrações Lambda Backend SNS Cognito Kinesis Dynamo S3 SDK Mobile, Alexa … API Gateway SES CloudWatch CloudFormation AWS Config Scheduled events
- 11. 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
- 12. 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
- 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 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
- 15. Na AWS, nós rodamos muitas APIs …Com o passar do tempo, nós aprendemos algumas lições
- 16. Seu feedback Gerenciar múltiplas versões e estágios de uma API é difícil.
- 17. Seu feedback Gerenciar múltiplas versões e estágios de uma API é difícil. Monitorar acessos de desenvolvedores terceiros consome tempo.
- 18. 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.
- 19. 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.
- 20. 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?
- 21. 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!
- 22. 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
- 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çã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
- 25. Gerencie múltiplos ambientes e versões de sua API API 1 (v1) Stage (dev) Stage (prod) API 2 (v2) Stage (dev)
- 26. Segurança – Custom Authorizer
- 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 Importador de 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 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
- 32. • Evolução Arquitetura • Serviços • AWS Lambda • Amazon API Gateway • Amazon Simple Storage Service (S3) • Amazon DynamoDB • Zombie Chat
- 33. 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
- 34. Latência baixa e previsível Latência consistente em 1 dígito de ms mesmo em escalas massivas
- 35. The Zombie Apocalypse Survival Instruções disponível em: http://bit.ly/reinvent-wrk305
- 36. 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
- 37. 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
- 38. Obrigado! Heitor Vital, Arquiteto de Soluções - AWS Brasil
Notas do Editor
- 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
- [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
- 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
- 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
- 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 …”
- 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
- 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
- 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
- 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
- Store 10 thousand objects – lose one object every 10 million years
- Store 10 thousand objects – lose one object every 10 million years
- 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.