1 00:00:00,270 --> 00:00:06,480 In this video, we are going to talk about Amazon event, which core concepts, which are the events, 2 00:00:06,480 --> 00:00:08,700 event, bosses, rules and the targets. 3 00:00:09,150 --> 00:00:10,860 You can see the image on the slide. 4 00:00:10,890 --> 00:00:18,030 These are the main core concepts of Amazon event, which basically the event which is creating rules 5 00:00:18,030 --> 00:00:20,140 that brought events to the target. 6 00:00:20,160 --> 00:00:27,120 So that means the event sources publish events to the event bosses and event bosses, routing to events 7 00:00:27,120 --> 00:00:31,710 to the targets, but evaluating the rules inside of the Amazon event page. 8 00:00:32,310 --> 00:00:38,220 So let's learn our core concepts of Amazon event events, event places, rules and the target. 9 00:00:39,940 --> 00:00:44,350 So basically the first core concept is Amazon oriented events. 10 00:00:44,710 --> 00:00:51,910 So an event indicates a change in an environment such as an environment or a source, partner, source 11 00:00:51,910 --> 00:00:55,280 or application or one of your application or services. 12 00:00:55,300 --> 00:00:58,720 The important thing is event is indicating a change. 13 00:00:59,080 --> 00:01:06,340 For example, of event is Amazon, etc. generates an event one the state of the instance change from 14 00:01:06,340 --> 00:01:07,480 panic to running. 15 00:01:07,570 --> 00:01:15,190 So this is the an event to changing an instance of the issue to or in our basket checkout event generate 16 00:01:15,190 --> 00:01:17,230 an event to the Amazon event with plus. 17 00:01:17,240 --> 00:01:22,720 So we will develop serverless ecommerce application basket, microservices, publish and event, which 18 00:01:22,720 --> 00:01:24,520 is the basket checkout event. 19 00:01:25,980 --> 00:01:32,970 Events are represented as a JSON object and they are have a similar structure and the same top level. 20 00:01:33,990 --> 00:01:40,590 The context of the detailed top level field are different depending on which service generated the event 21 00:01:40,590 --> 00:01:42,450 and what is the event is. 22 00:01:43,110 --> 00:01:49,650 So the combination of the source and the detail type fields serve to identify the fields and values 23 00:01:49,650 --> 00:01:51,300 found in the detailed type. 24 00:01:51,660 --> 00:01:58,320 For example, I would like to show an event which is coming from the Amazon event with its events generated 25 00:01:58,320 --> 00:01:59,790 by the sources. 26 00:01:59,850 --> 00:02:03,480 Let me show you the event JSON format in here. 27 00:02:03,510 --> 00:02:06,690 You can see this, see the image on the slide. 28 00:02:06,780 --> 00:02:11,040 Here is the an example, JSON, which includes some attributes. 29 00:02:11,130 --> 00:02:18,180 As we said before, event has some attributes that source and detail type and it is identifying the 30 00:02:18,180 --> 00:02:18,780 fields. 31 00:02:18,780 --> 00:02:26,850 And according to incoming event from different sources, these event JSON format structure can be differentiate. 32 00:02:27,600 --> 00:02:31,260 But basically we have some default attributes. 33 00:02:31,260 --> 00:02:39,720 For example, version version is always including all the events object which incoming from the Amazon 34 00:02:39,720 --> 00:02:40,500 event page. 35 00:02:41,530 --> 00:02:44,820 This is by default the zero in all events. 36 00:02:44,830 --> 00:02:50,670 So in this case also the version is zero and the second one is ID ID eight. 37 00:02:50,670 --> 00:02:57,910 It is important because this is using the the version four of UUID Library that's generated for every 38 00:02:57,910 --> 00:02:58,390 month. 39 00:02:58,420 --> 00:03:03,670 You can use this ID to trace events as they move through the rules to target. 40 00:03:03,670 --> 00:03:12,220 So if you would like to follow this specific event, you can follow these ID information from the rules 41 00:03:12,220 --> 00:03:14,530 and the targets in the Amazon event page. 42 00:03:15,160 --> 00:03:18,850 And another attribute type is very important detail type. 43 00:03:19,700 --> 00:03:25,430 It is basically identifies in a combination with the source field, the fields and values that appear 44 00:03:25,430 --> 00:03:26,590 in the detailed field. 45 00:03:26,600 --> 00:03:35,810 So you can see the detail, type and source indicate that which events trigger from the which will source 46 00:03:35,810 --> 00:03:39,200 and which detail type including this information. 47 00:03:39,530 --> 00:03:46,130 For example, in this example, this is the easy to insert state change notification and the source 48 00:03:46,130 --> 00:03:53,000 is a double is easy to so according to different sources we will see different source and detail type 49 00:03:53,000 --> 00:03:53,870 in this area. 50 00:03:54,410 --> 00:03:56,750 And another attribute is source. 51 00:03:57,470 --> 00:04:00,800 It is identifies the service that generated the event. 52 00:04:00,890 --> 00:04:07,700 You can see that this is the event source and this is identifies the generate event from which system? 53 00:04:07,730 --> 00:04:12,080 All events that come from the AWG sources began with the A list. 54 00:04:12,080 --> 00:04:18,950 So if you see see that it is starting with a W so that means this event generated from the resources. 55 00:04:20,540 --> 00:04:23,040 And also we have different attributes. 56 00:04:23,060 --> 00:04:25,640 For example, you can see resources in here. 57 00:04:25,910 --> 00:04:32,630 This is basically adjacent array that contains a resource that identify resources that are involved 58 00:04:32,630 --> 00:04:33,470 in the event. 59 00:04:33,920 --> 00:04:36,080 And also, we have detail attribute. 60 00:04:36,110 --> 00:04:42,130 This is also important and this is a JSON object that contains information about the event. 61 00:04:42,140 --> 00:04:49,010 So in our case, we are sending an easy to instance change event and this detail type, including the 62 00:04:49,010 --> 00:04:51,050 event details event data. 63 00:04:51,050 --> 00:04:57,440 We can see instance ID of the AC two and the state changed the value terminated. 64 00:04:57,530 --> 00:05:03,770 So detail type is very important for us because we will move also basket check out JSON data in the 65 00:05:03,770 --> 00:05:12,680 detail of Amazon event which you can see the the image event which is the indicating and illustrating 66 00:05:12,680 --> 00:05:20,420 an example event in Amazon event page that indicates an Amazon easy to instance being terminated, so 67 00:05:20,420 --> 00:05:24,950 Amazon easy to state change to the terminated OC. 68 00:05:25,040 --> 00:05:32,120 If you come back to our core concepts, the second core concept is the Amazon event rules. 69 00:05:32,660 --> 00:05:37,490 So it will match incoming events and send them to the target for processing. 70 00:05:37,880 --> 00:05:42,620 A single rule can send an event to multiple targets which then run in parallel. 71 00:05:43,070 --> 00:05:47,210 So rules are based either on an event pattern or a scheduled. 72 00:05:47,420 --> 00:05:54,290 An event button defines the event structure and the fields that are rule, match and rule that are based 73 00:05:54,290 --> 00:05:57,620 on a scheduled perform an action at a regular intervals. 74 00:05:58,560 --> 00:06:01,020 So that means rules can be two types. 75 00:06:01,050 --> 00:06:05,010 The first type is event pattern, and the second type is cycle. 76 00:06:05,040 --> 00:06:10,380 We will also use event pattern in order to route the events to the target system. 77 00:06:11,390 --> 00:06:18,260 Edible Services can create and manage event rules in our edibles account that are needed for the certain 78 00:06:18,260 --> 00:06:20,030 functions in those services. 79 00:06:20,030 --> 00:06:22,640 And these are called managed rules. 80 00:06:22,640 --> 00:06:28,910 So there is also many rules and managed by the edible is services that we can use when defining our 81 00:06:28,910 --> 00:06:29,480 rules. 82 00:06:30,770 --> 00:06:37,490 Basically, when a service creates a managed rule, it can also create an IAM policy that grants permission 83 00:06:37,490 --> 00:06:39,980 to that service to create the rule item. 84 00:06:39,980 --> 00:06:46,820 Policies creates this way are scoped narrowly within resource level permissions in order to allow this 85 00:06:46,820 --> 00:06:49,130 creation of to only the necessary rules. 86 00:06:49,310 --> 00:06:52,930 So these are the details of the Amazon event we rules. 87 00:06:52,940 --> 00:06:56,750 And also you can see the rules in this picture rules in here. 88 00:06:56,780 --> 00:07:03,950 We are evaluating the rules in order to calculate which target system we are going to send this event 89 00:07:03,950 --> 00:07:07,970 and we can send multiple targets with evaluating these rules. 90 00:07:08,360 --> 00:07:13,970 So now the another core concept is the Amazon event, which targets. 91 00:07:15,200 --> 00:07:17,930 So a target is a resource or endpoint. 92 00:07:17,930 --> 00:07:23,960 That event which sends an event to when the event makes the event pattern defined for a rule. 93 00:07:24,080 --> 00:07:31,640 So we basically wrote the event to the target system if the event pattern is a matched in our rule. 94 00:07:31,910 --> 00:07:38,630 So the rule is processed the event data and sends the relevant information to the target in order to 95 00:07:38,630 --> 00:07:45,440 deliver event data to a target event which needs permission to access the target resources. 96 00:07:46,010 --> 00:07:53,420 You can define up to five target for each rule when you add targets to a rule, and that rule runs soon 97 00:07:53,420 --> 00:07:58,160 after, any new or updated targets might not be immediately invoked. 98 00:07:59,000 --> 00:08:03,530 It is basically allow a short period of time for change to take effect. 99 00:08:03,710 --> 00:08:06,380 So this is the Amazon event breach targets. 100 00:08:06,380 --> 00:08:11,420 And the last thing for the code concept is the Amazon event with each event plus. 101 00:08:12,710 --> 00:08:19,470 So basically an event bus is a pipeline that receives events, rules associated with the event bus. 102 00:08:19,490 --> 00:08:23,480 Evaluate the events as they arrive and send to the target systems. 103 00:08:23,780 --> 00:08:27,530 Each rule check to weather an event match the rules criteria. 104 00:08:27,530 --> 00:08:31,790 So that means is the event pattern is matching to rule or not. 105 00:08:32,090 --> 00:08:37,180 And according to that, it is basically associate a rule with a specific event pass. 106 00:08:37,190 --> 00:08:40,920 So the rule only applies to the event received by that event. 107 00:08:40,960 --> 00:08:47,450 Plus, in order to manage permissions for an event bus, you can configure a resource based policy for 108 00:08:47,450 --> 00:08:47,870 it. 109 00:08:48,230 --> 00:08:53,900 A resource based policy specifies which events to allow and which entities have permission to create 110 00:08:53,900 --> 00:08:56,720 or modify rules or target for an event. 111 00:08:57,950 --> 00:09:04,190 For example, you can use a policy on an event bus in order to allow or deny events from the source, 112 00:09:04,190 --> 00:09:08,930 such as a rule or an event bus in a different place or region. 113 00:09:09,110 --> 00:09:15,260 By using policies, you can aggregate all events from your application or organization in a single account 114 00:09:15,260 --> 00:09:16,130 and region. 115 00:09:16,820 --> 00:09:24,260 As you can see that we have learned the core concepts which are the event sources, events, event buses, 116 00:09:24,260 --> 00:09:25,730 rules and the targets. 117 00:09:25,970 --> 00:09:29,810 In the next video, we are going to learn serverless patterns.