Architectures and Strategies for Building Modern Applications on AWS

Slide 1

Slide 1 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Nathan Peck Developer Advocate, Container Services @nathankpeck SRV 205 Architectures and Strategies for Building Modern Applications on AWS

Slide 2

Slide 2 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Key Primitives of a Cloud Native “…application is container-based” “…dynamically managed…” …microservice oriented…” Application?

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Key Building Blocks for Success Containers + Functions Cloud Culture

Slide 5

Slide 5 text

Key Building Blocks for Success Cloud Culture Containers + Functions

Slide 6

Slide 6 text

The fast companies are 440x faster than the slow We found that, compared to low performers, high performers have: 46x more frequent code deployments 440x faster lead time from commit to deploy 96x faster mean time to recover from downtime 5.0x lower change failure rate (changes are 1/5 as likely to fail) Time to Value

Slide 7

Slide 7 text

Ship features, not just code

Slide 8

Slide 8 text

Low performers High performers Deploy frequency (# of deploys per year) 0 400 800 1,200 1,600 2014 2015 2016 2017 Containers Enable Fast Deployments

Slide 9

Slide 9 text

0 20 40 60 80 100 2014 2015 2016 2017 0 20 30 40 50 60 10 Mean time to recover (hours) Change failure rate (percentage) Low performers High performers 2014 2015 2016 2017 Containers Enable Immutable Changes/Rollback

Slide 10

Slide 10 text

Cloud Native Principle #1 Cloud Native Applications enable high functioning organizations to build and ship features faster!

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Cloud Native Architecture Pay as you go Self- Service Elastic

Slide 13

Slide 13 text

Data Center Native DATA CENTER Architecture

Slide 14

Slide 14 text

Data Center Native Architecture Lives for years DATA CENTER

Slide 15

Slide 15 text

Cloud Migration Pay as you go DATACENTER Applications and data

Slide 16

Slide 16 text

Cloud Migration Pay as you go DATACENTER Applications and data Pay up front and depreciate over three years Pay a month later for the number of seconds used

Slide 17

Slide 17 text

Cloud Native Principle #2 Pay for what you used last month, not what you guess you will need next year. Enable teams to experiment and fail fast, without significant investment.

Slide 18

Slide 18 text

File tickets and wait for every step Self service, on-demand, no delays ! VS !

Slide 19

Slide 19 text

File tickets and wait for every step Self service, on-demand, no delays ! VS ! ! Deploy by filing a ticket and waiting days or weeks Deploy by making an API call self service within minutes

Slide 20

Slide 20 text

Cloud Native Principle #3 Self service, API driven, automated. Move from request tickets at every step to self-service APIs and tools that empower teams.

Slide 21

Slide 21 text

Elasticity DATA CENTER Hard to get over 10% utilization— need extra capacity in case of peak. CLOUD Target over 40% utilization— and scale on demand for any size workload.

Slide 22

Slide 22 text

Cloud Native Principle #4 Turn it off when it’s idle. Scale for workloads of any size. Many times higher utilization. Huge cost savings.

Slide 23

Slide 23 text

Blast Radius Loosely Coupled Geographically Distributed Resiliency

Slide 24

Slide 24 text

Microservices limit “blast radius” for software incidents Build and deploy loosely coupled services. Enable teams to move fast independently. Reduce blast radius via service and deployment isolation.

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

Cloud Native Principle #5 Microservices reduce blast radius, can improve MTTR, and support globally distributed deployment models.

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

“…teams build software that patterns their organizational structure…” —Conway’s Law Organization Transformation

Slide 30

Slide 30 text

“You build it, you run it.” —Werner Vogels, VP & CTO Amazon.com

Slide 31

Slide 31 text

“Not what happens IF it fails, but what happens WHEN it fails.” —Nora Jones, Author, and Sr. Chaos Engineer at Netflix

Slide 32

Slide 32 text

Principals of Modern, Cloud Native Apps Containers + Functions Cloud Culture

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Lambda Bring your own code • Node.js, Java, Python, C#, Go • Bring your own libraries (even native ones) Simple resource model • Select power rating from 128 MB to 3 GB • CPU and network allocated proportionately Flexible use • Synchronous or asynchronous • Integrated with other AWS services Flexible authorization • Securely grant access to resources and VPCs • Fine-grained control for invoking your functions

Slide 35

Slide 35 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Lambda Authoring functions • WYSIWYG editor or upload packaged .zip • Third-party plugins (Eclipse, Visual Studio) Monitoring and logging • Metrics for requests, errors, and throttles • Built-in logs to Amazon CloudWatch Logs Programming model • Use processes, threads, /tmp, sockets normally • AWS SDK built in (Python and Node.js) Stateless • Persist data using external storage • No affinity or access to underlying infrastructure

Slide 36

Slide 36 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. FINRA performs 500 Billion validations daily using AWS Lambda “Using AWS Lambda, we’ve increased cost efficiency by a factor of two” —Tim Griesbach, Senior Director of Technology, FINRA

Slide 37

Slide 37 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. … Amazon RDS Incoming files to be audited On-premises data center NAS FTP Controller on EC2 Amazon SQS Amazon SQS Amazon SQS Amazon S3 Logs to CloudWatch Logs Lambda preforms record validations Consumers Copy files to S3 Controller manages Lambda process

Slide 38

Slide 38 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Elastic Container Service (ECS) Container-Level Networking Advanced task placement Deep integration with AWS platform ECS CLI … { } Global footprint Powerful scheduling engines Auto scaling CloudWatch metrics Load balancers

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Critical Business Requirements Speed to market Scalability and reliability Multi-country support and integration Cost sensitivity

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon RDS ElastiCache (Redis) Amazon S3 Amazon SQS Auto Scaling Group Multi-AZ Auto Scaling Group Multi-AZ Microservice 1 Microservice 2 Amazon ECS McD API Middleware Third-party Delivery Platforms Menu and Restaurant Master Restaurant Application Load Balancer

Slide 43

Slide 43 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Built entire system in months, all on AWS Out of the box integration and deployment models with ECS simplified DevOps pipeline Open platform that integrates with any restaurant and global delivery partners Over 20K transactions per second, sub 100 millisecond latency Cost effective, even with extremely low transaction values

Slide 44

Slide 44 text

Enable Focus on Applications

Slide 45

Slide 45 text

Introducing AWS Fargate!

Slide 46

Slide 46 text

Simple, easy to use, powerful consumption model Resource based pricing Fargate No instances to manage Container native API

Slide 47

Slide 47 text

Running a Container

Slide 48

Slide 48 text

Running Containers EC2 Instance Task Task Task Task EC2 Instance Task Task Task Task EC2 Instance Task Task Task Task EC2 Instance Task Task Task Task EC2 Instance Task Task Task Task

Slide 49

Slide 49 text

EC2 Instance ECSTask ECSTask ECSTask ECSTask ECS AMI Docker agent ECS agent

Slide 50

Slide 50 text

Availability Zone #1 Availability Zone #2 Availability Zone #3 Scheduling and Orchestration Cluster Manager Placement Engine Running Containers at Scale with ECS E C S Amazon

Slide 51

Slide 51 text

Scheduling and Orchestration Cluster Manager Placement Engine E C S Amazon

Slide 52

Slide 52 text

Get Started in Minutes

Slide 53

Slide 53 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Entire website runs as microservices. Ruby & GraphQL backend with node.js frontend Needed ability to scale quickly, schedule multi- container workloads, network layer control All in on AWS—Moved entire infrastructure to AWS and Fargate in Jan 2018 Fargate scales quickly with traffic spikes, running ~25 tasks at baseline in production

Slide 54

Slide 54 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Public Subnet Private Subnet CDN External ALB Backend Web External API External Frontend Web External Card/Scraper Service Background Job Queues Background Workers Internal ALB Background Web Internal

Slide 55

Slide 55 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. “We moved to Fargate because we need the ability to scale quickly up from baseline, run multi-container workloads, and get fine-grained network control, without having to manage our own infrastructure.”

Slide 56

Slide 56 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Elastic Container Service for Kubernetes (EKS) Managed Kubernetes Control Plane Upstream and certified conformant Native AWS Integrations Built with the community Global footprint Highly available On-demand upgrades Generally available in 2018

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Monitoring: Amazon Cloudwatch • Get metrics on key resources • Observe application and operational health • Monitor custom metrics and log files Monitor • SNS notifications • Automated alarm actions • Event-driven corrective actions Act • Visualize through Dashboards • 1-sec granularity • Unified operational view • 15-months of data retention Analyze

Slide 61

Slide 61 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed Tracing • Analyze and debug performance of distributed applications • View latency distribution and identify performance bottlenecks • Ready to use in production with low latency in real-time AWS X-Ray • Identify specific user impact across an application • Works across AWS and non-AWS services