1
00:00:00,580 --> 00:00:03,380
‫Into this section on architecting on AWS

2
00:00:03,380 --> 00:00:05,960
‫and the AWS ecosystem.

3
00:00:05,960 --> 00:00:07,370
‫So first we're going to talk about

4
00:00:07,370 --> 00:00:09,079
‫the well architected framework

5
00:00:09,079 --> 00:00:11,530
‫and the general guiding principles.

6
00:00:11,530 --> 00:00:15,320
‫So in the cloud, when you want to have a good architecture

7
00:00:15,320 --> 00:00:18,100
‫you need to stop guessing your capacity needs.

8
00:00:18,100 --> 00:00:19,990
‫Instead, you should use auto scaling

9
00:00:19,990 --> 00:00:23,750
‫and scale the based on what the actual demand

10
00:00:23,750 --> 00:00:25,560
‫on your system is going to be.

11
00:00:25,560 --> 00:00:29,420
‫You should also test your system at production scale.

12
00:00:29,420 --> 00:00:30,253
‫In the cloud

13
00:00:30,253 --> 00:00:32,260
‫you can create as many resources as you want

14
00:00:32,260 --> 00:00:33,780
‫very, very quickly.

15
00:00:33,780 --> 00:00:35,770
‫And as such there is no reason why,

16
00:00:35,770 --> 00:00:37,270
‫for example, for one hour

17
00:00:37,270 --> 00:00:40,220
‫you couldn't test a system at production scale.

18
00:00:40,220 --> 00:00:43,060
‫This allows you in the future to make sure that your system

19
00:00:43,060 --> 00:00:46,520
‫is ready when you actually publish it to your customers.

20
00:00:46,520 --> 00:00:48,300
‫Now, it's also very important

21
00:00:48,300 --> 00:00:51,760
‫to automate to make architectural experimentation easier.

22
00:00:51,760 --> 00:00:53,890
‫So for this CloudFormation is very important

23
00:00:53,890 --> 00:00:55,840
‫because if you get infrastructure as code

24
00:00:55,840 --> 00:00:58,580
‫then you can easily create an architecture

25
00:00:58,580 --> 00:01:00,950
‫on different accounts and different regions.

26
00:01:00,950 --> 00:01:02,740
‫Also using platform as a service,

27
00:01:02,740 --> 00:01:04,930
‫such as Beanstalk could be very helpful

28
00:01:04,930 --> 00:01:06,640
‫to experiment quickly.

29
00:01:06,640 --> 00:01:10,000
‫You should also allow to make your architecture evolve.

30
00:01:10,000 --> 00:01:12,810
‫So you need to design based on changing requirements.

31
00:01:12,810 --> 00:01:14,700
‫That means that when you migrate a workload

32
00:01:14,700 --> 00:01:17,070
‫from on premises to the cloud,

33
00:01:17,070 --> 00:01:19,550
‫maybe at first you make it match one to one,

34
00:01:19,550 --> 00:01:20,850
‫but then you try to rethink

35
00:01:20,850 --> 00:01:22,610
‫how can I leverage the cloud better,

36
00:01:22,610 --> 00:01:24,880
‫making it serverless for example.

37
00:01:24,880 --> 00:01:27,260
‫Then drive architectures using data.

38
00:01:27,260 --> 00:01:28,340
‫It's not good to guess.

39
00:01:28,340 --> 00:01:30,650
‫It's good to look at what the actual usage is.

40
00:01:30,650 --> 00:01:31,483
‫What are the patterns?

41
00:01:31,483 --> 00:01:32,430
‫What are the queries?

42
00:01:32,430 --> 00:01:34,300
‫And then drive your architecture

43
00:01:34,300 --> 00:01:37,710
‫and use the right services based on what you actually need

44
00:01:37,710 --> 00:01:39,370
‫based on this data.

45
00:01:39,370 --> 00:01:40,980
‫Also improve through game days.

46
00:01:40,980 --> 00:01:42,670
‫So that means that you simulate applications

47
00:01:42,670 --> 00:01:45,510
‫for flash sale days, and this will stress your system.

48
00:01:45,510 --> 00:01:46,990
‫And by stressing your system

49
00:01:46,990 --> 00:01:49,200
‫you will know if you are doing well.

50
00:01:49,200 --> 00:01:50,810
‫So for example, I'll give you an example,

51
00:01:50,810 --> 00:01:53,110
‫Netflix they have something called the chaos monkey

52
00:01:53,110 --> 00:01:57,270
‫and it's a program that's in their EC2 environment

53
00:01:57,270 --> 00:02:00,580
‫goes ahead and terminates EC2 instance at random

54
00:02:00,580 --> 00:02:01,640
‫in production.

55
00:02:01,640 --> 00:02:04,530
‫And they see thanks to this chaos monkey

56
00:02:04,530 --> 00:02:06,080
‫if they are ready for failures

57
00:02:06,080 --> 00:02:07,290
‫if they're ready for big spikes,

58
00:02:07,290 --> 00:02:08,730
‫if they're ready for errors.

59
00:02:08,730 --> 00:02:09,740
‫So it's super important

60
00:02:09,740 --> 00:02:11,700
‫to think that now you are in the cloud,

61
00:02:11,700 --> 00:02:12,810
‫you have new capabilities.

62
00:02:12,810 --> 00:02:14,780
‫So you need to start you need to start thinking

63
00:02:14,780 --> 00:02:16,620
‫like you are using the cloud.

64
00:02:16,620 --> 00:02:18,590
‫So the design principles

65
00:02:18,590 --> 00:02:20,800
‫when using the cloud and the best practices.

66
00:02:20,800 --> 00:02:22,610
‫The first one is to be scalable.

67
00:02:22,610 --> 00:02:25,140
‫So we've seen the vertical scalability

68
00:02:25,140 --> 00:02:27,610
‫and the horizontal scalability

69
00:02:27,610 --> 00:02:30,870
‫also because we can easily create and remove servers.

70
00:02:30,870 --> 00:02:32,690
‫We have disposable resources.

71
00:02:32,690 --> 00:02:35,550
‫So your servers should be easily disposable

72
00:02:35,550 --> 00:02:37,110
‫and easily configured.

73
00:02:37,110 --> 00:02:40,030
‫If you put too much configuration onto a server

74
00:02:40,030 --> 00:02:42,440
‫and somehow that server, if lost

75
00:02:42,440 --> 00:02:44,390
‫will be losing its resource as well

76
00:02:44,390 --> 00:02:46,600
‫you will need to have maybe three days of work again

77
00:02:46,600 --> 00:02:47,830
‫to reconfigure that server

78
00:02:47,830 --> 00:02:50,000
‫if you haven't done things properly.

79
00:02:50,000 --> 00:02:52,370
‫In the cloud everything is supposed to be disposable

80
00:02:52,370 --> 00:02:54,670
‫including your infrastructure.

81
00:02:54,670 --> 00:02:56,790
‫And so you need to make sure to back up your data

82
00:02:56,790 --> 00:02:59,000
‫you need to make sure that you back up your configuration

83
00:02:59,000 --> 00:03:01,030
‫and that you have ways to very, very quickly

84
00:03:01,030 --> 00:03:03,760
‫reconfigure your entire architecture.

85
00:03:03,760 --> 00:03:04,593
‫Automation.

86
00:03:04,593 --> 00:03:07,580
‫So these are guided by the principles of serverless,

87
00:03:07,580 --> 00:03:10,830
‫infrastructure as a service, auto scaling and so on.

88
00:03:10,830 --> 00:03:12,670
‫Loose coupling, which is very important.

89
00:03:12,670 --> 00:03:14,792
‫So when you have an application at first,

90
00:03:14,792 --> 00:03:16,300
‫(mumbles) it's called a monolith.

91
00:03:16,300 --> 00:03:18,930
‫That means it's an application that can do everything.

92
00:03:18,930 --> 00:03:21,090
‫And over time, the more you add onto the application

93
00:03:21,090 --> 00:03:22,330
‫the bigger it becomes.

94
00:03:22,330 --> 00:03:23,760
‫And because it's a monolith

95
00:03:23,760 --> 00:03:27,010
‫it could be difficult to maintain and difficult to scale.

96
00:03:27,010 --> 00:03:29,880
‫Instead, you should break it down into smaller

97
00:03:29,880 --> 00:03:33,160
‫loosely coupled components so that maybe they will be linked

98
00:03:33,160 --> 00:03:36,350
‫through SNS or SQS or by other means.

99
00:03:36,350 --> 00:03:39,670
‫And the idea is that a change or a failure in one component

100
00:03:39,670 --> 00:03:42,360
‫should not cascade to the other components

101
00:03:42,360 --> 00:03:43,620
‫because in the cloud, again

102
00:03:43,620 --> 00:03:46,640
‫things can fail and you need to be prepared for failure.

103
00:03:46,640 --> 00:03:49,910
‫Finally, think in services, not servers.

104
00:03:49,910 --> 00:03:52,840
‫So you could just use EC2 but it's not recommended.

105
00:03:52,840 --> 00:03:55,600
‫EC2 would be to translate whatever you have on premises

106
00:03:55,600 --> 00:03:58,190
‫in the cloud but think in terms of services

107
00:03:58,190 --> 00:04:01,210
‫what managed services can you use databases, serverless

108
00:04:01,210 --> 00:04:04,160
‫et cetera, that can make your life a lot easier.

109
00:04:04,160 --> 00:04:06,790
‫So this is where the well architect framework

110
00:04:06,790 --> 00:04:09,340
‫which is made of six pillars comes in.

111
00:04:09,340 --> 00:04:11,780
‫The first one is operational excellence.

112
00:04:11,780 --> 00:04:13,019
‫The second one is security.

113
00:04:13,019 --> 00:04:15,060
‫The third one, reliability,

114
00:04:15,060 --> 00:04:17,380
‫the fourth one performance efficiency,

115
00:04:17,380 --> 00:04:21,670
‫fifth one cost optimization and six one sustainability.

116
00:04:21,670 --> 00:04:24,700
‫And the idea is that by acting with these six pillars

117
00:04:24,700 --> 00:04:28,060
‫you are having good architecture on AWS.

118
00:04:28,060 --> 00:04:30,030
‫So they're not something you want to balance

119
00:04:30,030 --> 00:04:32,490
‫and compromise between them or trade offs,

120
00:04:32,490 --> 00:04:33,890
‫they're actually a synergy.

121
00:04:33,890 --> 00:04:37,160
‫So for example, when you prove your operational excellence

122
00:04:37,160 --> 00:04:40,089
‫you're probably also improving your cost optimization.

123
00:04:40,089 --> 00:04:42,330
‫So the next six lectures are all about

124
00:04:42,330 --> 00:04:44,180
‫doing a deep dive into all of these

125
00:04:44,180 --> 00:04:46,710
‫to understand what they mean in AWS.

126
00:04:46,710 --> 00:04:47,790
‫I hope you're excited

127
00:04:47,790 --> 00:04:49,740
‫and I will see you in the next lecture.