Architecting your applications for millions of users.

Slide 1

Slide 1 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Adrian Hornsby Cloud Architecture Evangelist – Amazon Web Services Architecting your Applications for Millions of Users @adhorn Romain Cornu SRE / Devops engineer - Ouicar @ romain_cornu #awssummit

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. FOCUS ON BUSINESS LOGIC LEVEL OF ABSTRACTION Physical Machines • Requires “guess” planning • Lives for years on-prem • Heavy investments (CAPEX) • Low innovation factor • Deploy in months Computing evolution

Slide 4

Slide 4 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. FOCUS ON BUSINESS LOGIC LEVEL OF ABSTRACTION Physical Machines Computing evolution • Hardware independence • Faster provisioning speed (minutes/hours) • Trade CAPEX for OPEX • More scale • Elastic resources • Faster speed and agility • Reduced maintenance Virtual Machines Virtual Servers in Datacenters

Slide 5

Slide 5 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. FOCUS ON BUSINESS LOGIC LEVEL OF ABSTRACTION Physical Servers in Datacenters Physical Machines Computing evolution Virtual Servers in Datacenters Virtual Machines Virtual Servers in Datacenters Containerization • Platform independence • Consistent Runtime Environment • Higher resource utilization • Easier and faster deployments • Isolation and sandboxing • Start speed (deploy in seconds)

Slide 6

Slide 6 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. FOCUS ON BUSINESS LOGIC LEVEL OF ABSTRACTION Physical Servers in Datacenters Physical Machines Computing evolution Virtual Servers in Datacenters Virtual Machines Virtual Servers in Datacenters Containerization Serverless • Continuous scaling • Fault tolerance built-in • Event-driven • Pay per usage • Zero maintenance

Slide 7

Slide 7 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Happier Customers Better Products More Innovations Faster Release Cycles Decouple Software Systems (micro-services) Focus on Business Logic We are witnessing a paradigm shift

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. about me Romain CORNU Paris, France rcornu romain_cornu (passive reader, do not follow me) romain-cornu (you might want to get in touch, someday)

Slide 12

Slide 12 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. ouicar Pioneer in collaborative consumption, Ouicar is an internet platform that links car owners with their future tenants since 2012. more than 1 000 000 users, 30 000 cars registered, and thousands rentals each month

Slide 13

Slide 13 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. ouicar One responsive website and one application on each mobile plateforme. Three feature teams and more than 20 people (tech, quality, data, …).

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. initial state Application (MVC) handle both presentation and business layers. Business logic is organized in several modules in order to be then split into several services. Database is placed on dedicated servers with read replicas.

Slide 16

Slide 16 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. intermediary state Presentation is now a frontend service, a stand alone React application wrapped into a Docker container stack. Zend legacy application exposes business logic through an API, in order to be used by the frontend services.

Slide 17

Slide 17 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. final state Our API is now splitted in several services written in Symfony, NodeJS or Python, wrapped into a Docker container stacks. Services mainly talk to each other through asynchronus events. Each service has and manages its own database. Each service can now be updated independently or scaled regarding load.

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. frontend We take advantage of S3 static website hosting to forward trafic from alternative domains to ouicar.fr without writing a single line of code. Cloudfront and WAF helps us to optimize caching and performances without adding complexity to our application.

Slide 20

Slide 20 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. gateway Even if there is no cache on our API, we use a Cloudfront instance to protect ourself from several attack types. Cloudfront also improves our network performances.

Slide 21

Slide 21 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. microservices Compute layer services, such as Ouicar microservices or Lambda are stateless. Every data layer services, such as databases, elasticsearch or redis, is a AWS managed service.

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. managed data services From RDS to Elasticache - Redis, including Elasticsearch and SQS, every statefull component is managed by AWS. Helping us to save time by providing reliable services based on a solid configuration with a great setup / startup time.

Slide 24

Slide 24 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. two dimensions scaling Horizontal scaling, at infrastructure level, adds or removes EC2 instances. Vertical scaling, at application level, adds or removes ECS service instances (tasks). Two dimensions scaling helps us to quickly respond to any load.

Slide 25

Slide 25 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. blue green deployment ECS always keeps a healthy version of each service. So when a new version is pushed, ECS waits for the new version instances to be healthy before shutting down previous ones. Using this deployment strategy we no longer have any downtime.

Slide 26

Slide 26 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. logs ECS service can send logs to Cloudwatch using awslogs connector. Then using a Lambda function, logs are tagged and sent to Logmatic API. This allow us to easily analyse logs on an environment, service, container, …

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. next steps X-Ray is of course a part of our technical roadmap in order to easily track where latency is coming from. Rekognition is also something that we want to dig in, image moderation and text in image could help us to analyse photo and IDs.

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. CAP Theorem Consistency Availability Partition Tolerance Data is consistent. All nodes see the same state. Every request is non-failing. Service still responds as expected if some nodes crash. Distributed System In the presence of a network partition, you must choose between consistency and availability!

Slide 33

Slide 33 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Eventual Consistency … if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. Availability An eventually consistent system can return any value before it converges!! https://en.wikipedia.org/wiki/Eventual_consistency Distributed System Every request is non-failing.

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Web Instances Worker Instance Worker Instance Queue API Instance API Instance API Instance API: {DO foo} PUT JOB: {JobID: 0001, Task: DO foo} API: {JobID: 0001} GET JOB: {JobID: 0001, Task: DO foo} Cache Result: { JobID: 0001, Result: bar }

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. RDS DB Instance Active (Multi-AZ) Availability Zone Elastic Load Balancer Web Instance Web Instance Amazon Route 53 User Amazon S3 Amazon Cloudfront ElastiCache Worker Instance Worker Instance Full Decoupling Queue Amazon SNS

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Read / Write Sharding RDS DB Instance Read Replica App Instance App Instance App Instance RDS DB Instance Master (Multi-AZ) RDS DB Instance Read Replica RDS DB Instance Read Replica

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Aurora multi-master - scale out reads & writes First MySQL compatible DB service with scale-out across multiple data centers Zero application downtime from ANY instance failure Zero application downtime from ANY AZ failure Faster write performance and higher scale Sign up for single-region multi-master preview today; Multi-Region Multi-Master coming in 2018 Availability Zone 1 Scale out both reads and writes Availability Zone 2 Availability Zone 3 Application Read/Write Master 1 Shared distributed storage volume Read/Write Master 2 Read/Write Master 3

Slide 48

Slide 48 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon DynamoDB Global Tables (GA) First fully managed, multi-master, multi-region database Build high performance, globally distributed applications Low latency reads & writes to locally available tables Disaster proof with multi-region redundancy Easy to set up and no application rewrites required Globally dispersed users Replica (N. America) Replica (Europe) Replica (Asia) Global App Global Table

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Circuit Breaker • Wrap a protected function call in a circuit breaker object, which monitors for failures. • If failures reach a certain threshold, the circuit breaker trips. https://martinfowler.com/bliki/CircuitBreaker.html

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. • Monitoring, metrics, and logging • What are customers saying? • Try to squeeze as much performance out of each service/component Make it ridiculously easy to start monitoring a new metric! 1 line of code rule

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Steady State • ”normal” behavior of your system • Business Metric https://medium.com/netflix-techblog/sps-the-pulse-of-netflix-streaming-ae4db0e05f8a

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. Testing to the next level: Failure Injection • Start small & build confidence • Application level • Host failure • Resource attacks (CPU, memory, …) • Network attacks (dependencies, latency, …) • Region attacks!