1 00:00:00,330 --> 00:00:06,960 In this section, we are going to learn how event driven architectures fits with the ADA, Lambda and 2 00:00:06,960 --> 00:00:08,070 invocation types. 3 00:00:08,760 --> 00:00:10,380 Let's start with learning. 4 00:00:10,380 --> 00:00:13,950 Event driven architectures and event driven architectures. 5 00:00:13,950 --> 00:00:20,670 Uses events to trigger and communicate between decoupled services and is common in modern applications 6 00:00:20,670 --> 00:00:22,410 will be to microservices. 7 00:00:22,900 --> 00:00:29,100 An event is a change in state or an update like an item being placed in a shopping cart on ecommerce 8 00:00:29,100 --> 00:00:36,570 web application events can either carry the state, for example the item purchased, item price changed 9 00:00:36,570 --> 00:00:40,380 and so on, or event can be an identifier. 10 00:00:40,380 --> 00:00:45,810 For example, a notification that an order was placed or an order was shipped and so on. 11 00:00:46,230 --> 00:00:51,540 So if you look at the image on the slide event, the ribbon architectures have three key components 12 00:00:51,750 --> 00:00:55,560 event producers, event authors and event consumers. 13 00:00:56,310 --> 00:01:02,400 Basically, a producer publish an event to the router which filters and pushes the events to the consumers. 14 00:01:03,060 --> 00:01:09,810 Producers, services and consumer services are decoupled, which allows them to be scaled update and 15 00:01:09,810 --> 00:01:11,310 deployed independently. 16 00:01:11,310 --> 00:01:14,430 So this is the main benefit of event driven architecture. 17 00:01:14,430 --> 00:01:17,970 So deploy independently for all parties. 18 00:01:17,970 --> 00:01:23,520 Event producer, event, consumer and event structure can be scaled independently. 19 00:01:24,000 --> 00:01:32,010 If you look at the benefits of the event driven architectures, we can say that scale and fail independently 20 00:01:32,280 --> 00:01:34,470 with decoupling or services. 21 00:01:34,470 --> 00:01:38,150 They are only aware of the event rather not each other. 22 00:01:38,160 --> 00:01:45,330 This means that our services are interoperable, but if one service has a failure, the rest will keep 23 00:01:45,330 --> 00:01:45,900 running. 24 00:01:45,930 --> 00:01:52,740 The event router acts as an elastic buffer that will accommodate sorts in workloads, so another benefit 25 00:01:52,740 --> 00:01:54,660 is developed with agility. 26 00:01:55,260 --> 00:01:59,310 No longer need to write custom code to pull, filter and draw events. 27 00:01:59,310 --> 00:02:03,120 The event router will automatically filter and push events to the consumers. 28 00:02:03,210 --> 00:02:09,720 The router also removes the need of heavy coordination between producer and consumer services, speeding 29 00:02:09,720 --> 00:02:13,620 up the development process so these provide the developing with agility. 30 00:02:14,040 --> 00:02:17,100 Another benefit is audit with easy. 31 00:02:17,130 --> 00:02:22,320 An event router acts as a centralized location to audit our application and define policies. 32 00:02:22,500 --> 00:02:29,070 These policies can restrict who can publish and subscribe to a router and control which users and resources 33 00:02:29,070 --> 00:02:31,230 have permission to access our data. 34 00:02:31,230 --> 00:02:34,950 We can also include our events both in transit and rest. 35 00:02:35,340 --> 00:02:38,040 So another benefit is cutting the cost. 36 00:02:38,070 --> 00:02:44,190 Event driven architectures are push based, so everything happens on demand as the event presents itself 37 00:02:44,190 --> 00:02:45,060 in a router. 38 00:02:45,150 --> 00:02:49,710 This way you are not paying for continuous polling to check for an event. 39 00:02:49,710 --> 00:02:56,340 This means less network bandwidth consumption, less CPU utilization and less idle time. 40 00:02:56,340 --> 00:02:58,860 So this will come with a cutting to cost. 41 00:02:59,100 --> 00:03:06,210 So if you look at the example on the slide image here, you can see the example architecture of the 42 00:03:06,210 --> 00:03:09,180 event driven architecture for ecommerce application. 43 00:03:09,180 --> 00:03:14,700 This architecture enables the site to react to change from a variety of resources during the time of 44 00:03:14,700 --> 00:03:21,450 the peak demand without crushing the application or provisioning resources because every services communicate 45 00:03:21,450 --> 00:03:22,980 with using the event backbone. 46 00:03:22,980 --> 00:03:26,790 This provides event driven architecture and the compose services. 47 00:03:28,050 --> 00:03:32,880 So let's see a list, even three services. 48 00:03:33,390 --> 00:03:38,760 There are two main types of routers used in the event driven architectures, which is the event buses 49 00:03:38,760 --> 00:03:39,990 and event topics. 50 00:03:40,080 --> 00:03:47,640 So in a place, a place basically offers the messaging and ISP line in here and you can see the service 51 00:03:47,640 --> 00:03:52,040 part services in here, which is the event sense and case. 52 00:03:53,100 --> 00:03:56,250 So basically Amazon offers. 53 00:03:57,240 --> 00:03:59,220 Event Bridge to build event buses. 54 00:03:59,220 --> 00:04:05,220 And Amazon also offers SNS, which is the simple notification service to build event topics. 55 00:04:05,310 --> 00:04:07,140 So let me explain one by one. 56 00:04:07,180 --> 00:04:12,120 Amazon Event Update is recommended when you want to build an application that reacts to events from 57 00:04:12,120 --> 00:04:12,580 the source. 58 00:04:12,620 --> 00:04:19,470 Applications, Adobe Services and any custom applications event which use a predefined schema for events 59 00:04:19,470 --> 00:04:25,140 and allows you to create rules that are applied across the entire event body to filter before pushing 60 00:04:25,140 --> 00:04:26,160 the consumers. 61 00:04:26,940 --> 00:04:28,710 Now let's talk about Amazon. 62 00:04:28,740 --> 00:04:34,740 Since Amazon, RSNs is a recommended one, you want to build an application that works to high throughput 63 00:04:34,740 --> 00:04:39,270 and low latency events published by other applications, microservices and so on. 64 00:04:39,360 --> 00:04:46,170 So basically it is implementing fan out pattern with using the sense topics that is applying the event 65 00:04:46,170 --> 00:04:48,420 schema with using the panel pattern.