1 00:00:10,700 --> 00:00:15,090 Welcome back to Backspace Academy. In this lecture we'll have a look at the 2 00:00:15,090 --> 00:00:19,680 application integration and customer engagement services will then have a 3 00:00:19,680 --> 00:00:23,490 look at some examples and finally we'll finish up with a hands-on lab where 4 00:00:23,490 --> 00:00:30,329 we're going to use the SES service to send an email attributes step functions 5 00:00:30,329 --> 00:00:35,310 makes it easy to coordinate the components of distributed applications 6 00:00:35,310 --> 00:00:41,190 and micro services using a visual workflow for example you may want a 7 00:00:41,190 --> 00:00:46,830 second function to always follow the first and only run if and when the first 8 00:00:46,830 --> 00:00:52,530 succeeds and you may want to execute two functions in parallel for example you 9 00:00:52,530 --> 00:00:58,500 define your application visually as a series of steps you define the process 10 00:00:58,500 --> 00:01:05,150 flow of those steps and then you can deploy your application automatically 11 00:01:05,150 --> 00:01:09,990 Amazon simple workflow service works in a similar way to step functions in 12 00:01:09,990 --> 00:01:15,780 coordinating multiple components of a business process for new applications 13 00:01:15,780 --> 00:01:22,890 it's recommended to use step functions not the swf service Amazon 14 00:01:22,890 --> 00:01:29,190 simple notification service or SNS for short is a flexible fully managed pub/sub 15 00:01:29,190 --> 00:01:34,950 messaging service what that means is that you can create a topic and users 16 00:01:34,950 --> 00:01:40,770 subscribe to that topic and when you publish a message to the topic the users 17 00:01:40,770 --> 00:01:45,870 that have subscribed to that topic will receive that message it can also be used 18 00:01:45,870 --> 00:01:51,810 for push notifications for mobile devices Amazon simple queue service or 19 00:01:51,810 --> 00:01:57,960 sqs for short is a fully managed Message Queuing service and that makes it easy 20 00:01:57,960 --> 00:02:03,869 to decouple your applications from demand what that means is that it allows 21 00:02:03,869 --> 00:02:09,750 messages to build up in a queue until the processing server that processes 22 00:02:09,750 --> 00:02:14,810 those messages can catch up with the demand 23 00:02:14,960 --> 00:02:20,370 so let's have a look at an example of using these services to decouple our 24 00:02:20,370 --> 00:02:25,830 application from its demand so let's just say we have an application and it's 25 00:02:25,830 --> 00:02:31,680 running on an auto scaling group of ec2 instances and that application is a 26 00:02:31,680 --> 00:02:36,510 process server it's not a web server it's processing messages as they come in 27 00:02:36,510 --> 00:02:40,620 and those messages could have information on an image that needs to be 28 00:02:40,620 --> 00:02:45,030 processed or a video that needs to be processed or a cryptography problem that 29 00:02:45,030 --> 00:02:51,000 needs to be solved and so those messages come in and as that demand increases or 30 00:02:51,000 --> 00:02:54,960 the number of messages coming in increases then the auto scaling group 31 00:02:54,960 --> 00:03:02,010 will also add more instances to cope with that increasing demand so what 32 00:03:02,010 --> 00:03:07,470 happens if the increase in demand occurs over a one-second period and that is a 33 00:03:07,470 --> 00:03:13,230 very large spike our auto scaling group cannot handle that sort of scenario 34 00:03:13,230 --> 00:03:18,630 because it's going to take at least five or ten minutes for instances to launch 35 00:03:18,630 --> 00:03:23,459 and be up and running so what happens in the meantime is a problem for us 36 00:03:23,459 --> 00:03:29,400 in a similar way that a bank has a queue and so when people come into a bank and 37 00:03:29,400 --> 00:03:34,110 the teller is too busy to serve them they can build up in a queue until such 38 00:03:34,110 --> 00:03:40,080 point in time that the teller can reach them we can do the same thing with the 39 00:03:40,080 --> 00:03:44,970 sqs or simple queue service we can let those messages come in and they can 40 00:03:44,970 --> 00:03:51,270 build up in a queue until such time that our auto scaling group of ec2 instances 41 00:03:51,270 --> 00:03:57,720 can get to that queue and empty out the queue and that is great because we have 42 00:03:57,720 --> 00:04:04,440 now decoupled our demand from our application and so if spikes come in our 43 00:04:04,440 --> 00:04:10,760 application can handle it but what happens when the average demand 44 00:04:10,760 --> 00:04:15,600 exceeds what our capacity is so I'll give you an example so we've got our 45 00:04:15,600 --> 00:04:21,870 bank and all of a sudden we had five tellers and four of those tellers have 46 00:04:21,870 --> 00:04:27,030 become sick they've got influenza or whatever but the same amount of people 47 00:04:27,030 --> 00:04:30,069 are coming through the door and the queue is going to build up and 48 00:04:30,069 --> 00:04:34,599 build up and the queue will never decrease it will continue to increase in 49 00:04:34,599 --> 00:04:41,169 size indefinitely the same thing can happen in this architecture for example 50 00:04:41,169 --> 00:04:46,439 we might have a whole heap of unhealthy instances and all of a sudden our 51 00:04:46,439 --> 00:04:51,460 capacity cannot meet demand and so that sqs queue is going to grow indefinitely 52 00:04:51,460 --> 00:04:57,310 or we may have done an update to our application that is faulty and that sqs 53 00:04:57,310 --> 00:05:04,870 queue continues to increase so what we can do is that we can set up a cloudwatch 54 00:05:04,870 --> 00:05:11,590 metric and that will alert us with an SNS email notification that our sqs 55 00:05:11,590 --> 00:05:17,729 queue is continue continuing to grow and that we need to investigate that further 56 00:05:17,729 --> 00:05:23,590 now normally we would use a metric on the instances to signal that those 57 00:05:23,590 --> 00:05:28,479 instances are overloaded and we need to increase our capacity of our auto 58 00:05:28,479 --> 00:05:32,560 scaling group now in this situation that's probably not going to happen 59 00:05:32,560 --> 00:05:37,690 because these messages are just going to build up in the queue and so we need a 60 00:05:37,690 --> 00:05:43,529 way of notifying the auto scaling service that the queue is increasing and 61 00:05:43,529 --> 00:05:49,360 the way we can do that is whether again a cloud watch metric that will alert the 62 00:05:49,360 --> 00:05:56,560 auto scaling group that the sqs queue is too big and to put on more instances to 63 00:05:56,560 --> 00:06:01,539 reduce the size of the queue and at the same time when the queue is empty 64 00:06:01,539 --> 00:06:06,729 cloudwatch can send a metrics to the auto scaling group to reduce the number 65 00:06:06,729 --> 00:06:13,260 of instances and terminate those so that we're not wasting those resources 66 00:06:13,260 --> 00:06:18,410 let's have a look at some customer engagement services Amazon Connect is a 67 00:06:18,410 --> 00:06:23,430 self-service contact center in the AWS cloud and that is delivered on a 68 00:06:23,430 --> 00:06:27,510 pay-as-you-go pricing model it has a drag-and-drop 69 00:06:27,510 --> 00:06:32,430 graphical user interface and that allows you to create process flows that define 70 00:06:32,430 --> 00:06:38,580 customer interactions without having any coding at all Amazon Pinpoint allows 71 00:06:38,580 --> 00:06:44,400 you to send email SMS and mobile push messages for targeted marketing 72 00:06:44,400 --> 00:06:49,920 campaigns as well as direct messages to your individual customers for example an order confirmation 73 00:06:49,920 --> 00:06:55,230 Amazon simple email service or SES for short is a 74 00:06:55,230 --> 00:07:00,630 cloud-based bulk email sending service and coming up next we're going to be 75 00:07:00,630 --> 00:07:06,480 doing a lab using the simple email service to send an email so make sure 76 00:07:06,480 --> 00:07:13,040 that you download the introduction to AWS lab notes and let's get into it 77 00:07:16,450 --> 00:07:19,789 in the AWS management console we go to 78 00:07:19,789 --> 00:07:24,289 services and over on the right-hand side here we've got messaging services we 79 00:07:24,289 --> 00:07:32,720 click on SES and the first thing we need to do is we need to verify our email 80 00:07:32,720 --> 00:07:37,190 address so we just go to email addresses and we'll put in our or we click on here 81 00:07:37,190 --> 00:07:47,210 to verify a new email address and then we click on verify this email address so 82 00:07:47,210 --> 00:07:53,630 what's happened now is that AWS has sent an email to us to verify our email once 83 00:07:53,630 --> 00:08:01,880 we click on that link we'll be able to continue to use the SES service 84 00:08:01,880 --> 00:08:06,310 ok so when you've clicked on the verification link to the email you'll get a 85 00:08:06,310 --> 00:08:10,159 congratulations message that you've verified your email so just click out of 86 00:08:10,159 --> 00:08:16,610 that and go back into the SES management console if we refresh the screen we can 87 00:08:16,610 --> 00:08:24,229 see that it has now been verified so what we can do now is that we can send a 88 00:08:24,229 --> 00:08:28,550 test email so just click on send a test me you know we'll put in what I'm going 89 00:08:28,550 --> 00:08:34,490 to do is just send a message from myself to myself so that I don't have to verify 90 00:08:34,490 --> 00:08:39,260 any further or any additional email addresses and just put the subject is 91 00:08:39,260 --> 00:08:49,730 test and we'll send that test email and that will be happening and so what we 92 00:08:49,730 --> 00:08:52,940 can do is we'll go into our email account and we'll see that that test 93 00:08:52,940 --> 00:08:59,870 email will have been sent. OK so I've just gone and checked my email account and 94 00:08:59,870 --> 00:09:04,579 yes that test email went through fine, now you might be questioning what do we do now 95 00:09:04,579 --> 00:09:08,300 it's one thing to send a single email but that's not much good to us we 96 00:09:08,300 --> 00:09:15,290 want to send out bulk email now obviously sending out bulk email is well 97 00:09:15,290 --> 00:09:20,089 it can be can be spam so AWS is mindful of that 98 00:09:20,089 --> 00:09:25,880 and so there is a process that you have to go through to apply to use the 99 00:09:25,880 --> 00:09:31,250 SES service to send our bulk email. So the way you do that is you go into 100 00:09:31,250 --> 00:09:33,870 sending statistics here and 101 00:09:33,870 --> 00:09:40,500 you can see there is a link there to request a sending limit increase, so just 102 00:09:40,500 --> 00:09:46,850 reading off if so your Amazon SES account has sandbox access in 103 00:09:46,850 --> 00:09:54,870 region US East Virginia and so that is very limited to what you can do and so if 104 00:09:54,870 --> 00:09:58,710 you're going to be using this in for example in in an enterprise application 105 00:09:58,710 --> 00:10:05,550 then you would want to go there and request a sending limit increase and so 106 00:10:05,550 --> 00:10:09,720 just click on that and it will take you to a form that you fill out with all 107 00:10:09,720 --> 00:10:14,280 your details and and you just submit that to the AWS support department and 108 00:10:14,280 --> 00:10:19,350 they will make that happen for you so that's all I need to show you now on the 109 00:10:19,350 --> 00:10:26,450 SES service and I look forward to seeing it in the next one