Build planetary scale applications with compartmentalization

Size: px

Start display at page:

Download "Build planetary scale applications with compartmentalization"

Ruby Nash
5 years ago
Views:

2 Software is taking over the world

3 SaaS impacts the entire value chain Scale Global Reach Efficiency

4 From a single global platform Centralized Stable Highly available Global Platform Industrialized Focused on efficiency

5 AWS Well Architected Framework Performance Reliability Security Cost Efficiency Operational Excellence

6 To a mesh of collaborating platforms Decentralized and replicated Fully automated Fault tolerant and isolated Global Platforms Highly customizable Focused on effectiveness

7 AWS provides a wide set of services AWS CloudFormation Amazon VPC Amazon DynamoDB Amazon CloudFront SDK Automation Control Data Protection Extensibility Evolution

Intuit Cuts Costs to Run Key Consumer App by 6X Using AWS AWS is strategic to our business and is playing a critical role in driving our business growth.

8 Intuit Cuts Costs to Run Key Consumer App by 6X Using AWS AWS is strategic to our business and is playing a critical role in driving our business growth. Intuit is a leading provider of financial management software for consumers and small businesses Moved TurboTax AnswerXchange app to AWS when on-premises lease expired Tayloe Stansbury SVP & CTO Pay-as-you-go AWS model cut costs to host and manage the app by factor of 6 Intuit is a leading provider of financial management software for consumers, small businesses, and accounting professionals. It is based in Mountain View, CA. Set up new platform in 1/5 th the time compared to old environment Positive experience led Intuit to move another 33 apps and 26 services to AWS

10 Start with a simple app instance AZ A Aurora Master Region #1

11 Make it a bit more reliable instance AZ A Aurora Master Application Load Balancer instance AZ B Aurora Master instance AZ C Aurora Master Region #1

12 We can also scale it further

13 To millions of users

15 Customers will want Disaster Recovery instance AZ A Aurora Master Application Load Balancer instance AZ B Aurora Master SQL seconday AZ A Region #2 instance AZ C Aurora Master Region #1

16 Globally available applications instance AZ A Aurora Master Amazon CloudFront Application Load Balancer instance AZ B Aurora Master SQL seconday AZ A Region #2 instance AZ C Aurora Master Region #1

17 Or truly global applications Amazon Route 53 Application Load Balancer instance AZ A Aurora Master Application Load Balancer instance AZ A Aurora Secondary Region #1 Region #3 Application Load Balancer instance AZ A Aurora Secondary queue Region #2

18 They will want more! Different regions Dedicated hardware Regulatory constraints More customers mean more ideas!

19 Challenges How to update the application, the database? How to handle failure? How to test new features, elements? At scale, this becomes an operational burden

21 What do we want? Adapt quickly to specific needs Control our blast radius Benefit from industry best practices Think 100x

22 We overall want to avoid this Scheduled Maintenance Notification Maintenance planned: This entire weekend, the platform will be entirely unavailable due to ongoing maintenance on our application. Enjoy the weather and see you Monday! Oops, we re over capacity We have a catastrophic success, and our application can t handle the load. Please come back later as we are working to fix the platform.

23 Each region will contain compartments T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

24 Each compartment contains customer data T1 T2

25 What s a cell A completely autonomous environment Single or multi region / account Has its own configuration Responds to its own constraints Contains one or multiple customers (But) One customer is usually hosted in a single cell (also, much simpler to say than compartment)

26 Cells remains largely unchanged instance AZ A Aurora Master Application Load Balancer instance AZ B Aurora Master instance AZ C Aurora Master Region #1

27 What features we need? A routing layer, assigning customers to cells Create and update a cell Migrate a customer between cells

29 Routing layer Region #1 Region #2 Amazon Route 53 Region #3

30 Routing layer Amazon API Gateway Lambda function table table Lambda function Amazon API Gateway Region #1 Region #2 Amazon API Gateway Lambda function table DynamoDB Global Table Region #3

32 Key points for deployment Fully automated Used everywhere, from dev to prod Configurable

33 CI / CD Source Build Test Production Continuous integration Continuous delivery Continuous deployment

34 How to deploy? Pipelines: automated actions and transitions; from check-in to production Think 100x (still)

35 Infrastructure as code For everything, including the deployment process, and across multiple regions

36 Deployment T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

37 Test in 1 cell in 1 region T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

38 Expand to another region T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

39 Keep on expanding T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

40 and again T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

41 and again T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

43 A/B Testing T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

44 A/B Testing (test phase) T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

45 A/B Testing (final phase) T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

46 A/B Testing (rollback) T1 T2 T3 T2 T3 T4 Region #1 Region #3 T3 T4 T5 Region #2

48 Why migration? For technical reasons Denial of service Failure management For business reasons Customer will change during their lifecycle Free tier S/M/L/XL customers

49 Migrate a customer between cells T1 T2 routing table T1 T2 T2 T1 T3 T3

50 Migrate a customer between cells T1 T2 routing table T1 T2 T2 T1 / T2 T3 T3

51 Migrate a customer between cells T1 T2 routing table T1 T2 T2 T2 / T1 T3 T3

52 Migrate a customer between cells T1 T2 routing table T1 T2 T2 T2 T3 T3

53 Key points for migration Migration can be within or across regions / accounts Migration happens as a backend process Some customers will exist in multiple cells

55 Handling failure T1 T2 T3 Region #1

56 Handling failure T1 T2 T3 Region #1

57 Recovering from Failure T1 T2 T3 Region #1

59 Balancing load T1 T2 T3 Region #1

60 Balancing load T1 T2 T3 Region #1

61 Balancing load T1 T2 T3 Region #1

62 Balancing load T1 T2 T3 Region #1

64 Key points for designing cells How small is too small? How big is too big? What justifies the creation of a cell? Should all services have the same cell design?

65 How to get to this design First step has to be easy: 1 cell per customer Automate deployment Work on routing and migration Update your services Measure, tune, repeat

66 What do we gain? Controlling the growth of your environment Agility, adaptability and performance Reliability Cost management

67 Services making it easier Amazon Route 53 Amazon API Gateway AWS Lambda Amazon RDS AWS Organizations AWS CodePipeline AWS CloudTrail AWS Config

68 There s more to it Networking Encryption Cost optimization Observability

70 References

ARCHITECTING WEB APPLICATIONS FOR THE CLOUD: DESIGN PRINCIPLES AND PRACTICAL GUIDANCE FOR AWS

ARCHITECTING WEB APPLICATIONS FOR THE CLOUD: DESIGN PRINCIPLES AND PRACTICAL GUIDANCE FOR AWS Dr Adnene Guabtni, Senior Research Scientist, NICTA/Data61, CSIRO Adnene.Guabtni@csiro.au EC2 S3 ELB RDS AMI