1 00:00:00,090 --> 00:00:01,470 ‫So let's talk about the Beanstalk 2 00:00:01,470 --> 00:00:03,300 ‫deployment options whenever you're doing 3 00:00:03,300 --> 00:00:05,520 ‫an update to your application. 4 00:00:05,520 --> 00:00:07,170 ‫So you have several ones, and each of them 5 00:00:07,170 --> 00:00:09,330 ‫is going to be described with diagrams 6 00:00:09,330 --> 00:00:11,370 ‫in the next few slides, so don't worry about it. 7 00:00:11,370 --> 00:00:12,900 ‫But I just wanna give you an overview 8 00:00:12,900 --> 00:00:15,330 ‫of what they are before we dive into them. 9 00:00:15,330 --> 00:00:17,070 ‫So the first one is all at once, 10 00:00:17,070 --> 00:00:18,750 ‫where you deploy all in one go. 11 00:00:18,750 --> 00:00:21,180 ‫It's the fastest, but then your instances 12 00:00:21,180 --> 00:00:23,550 ‫are going to be down because they will be updating, 13 00:00:23,550 --> 00:00:25,740 ‫and so you'll have some downtime. 14 00:00:25,740 --> 00:00:27,360 ‫You have rolling, where you update 15 00:00:27,360 --> 00:00:29,790 ‫a few instances at a time, and then you move on 16 00:00:29,790 --> 00:00:32,610 ‫to the next set of instances, called a bucket, 17 00:00:32,610 --> 00:00:34,950 ‫once the first bucket is healthy. 18 00:00:34,950 --> 00:00:36,750 ‫You can also do rolling with additional batch. 19 00:00:36,750 --> 00:00:39,630 ‫This is just like rolling, but you spin up new instances 20 00:00:39,630 --> 00:00:42,690 ‫to update instances over time so that you'll still have 21 00:00:42,690 --> 00:00:45,750 ‫the old application available with the same capacity. 22 00:00:45,750 --> 00:00:46,890 ‫You have immutable. 23 00:00:46,890 --> 00:00:48,750 ‫This is when you have instances in Auto Scaling group. 24 00:00:48,750 --> 00:00:50,760 ‫You deploy new instances altogether. 25 00:00:50,760 --> 00:00:53,190 ‫You deploy the version to these instances, 26 00:00:53,190 --> 00:00:54,990 ‫and then you swipe out all the instances 27 00:00:54,990 --> 00:00:56,880 ‫when everything is healthy. 28 00:00:56,880 --> 00:00:58,620 ‫You have blue/green, where you create 29 00:00:58,620 --> 00:01:01,020 ‫a whole new environment altogether, 30 00:01:01,020 --> 00:01:03,330 ‫and then you switch over when ready. 31 00:01:03,330 --> 00:01:05,220 ‫And finally, we have traffic splitting. 32 00:01:05,220 --> 00:01:06,390 ‫This is for canary testing. 33 00:01:06,390 --> 00:01:08,430 ‫Canary testing is when you send a small percentage 34 00:01:08,430 --> 00:01:12,450 ‫of the application traffic to a brand new deployment. 35 00:01:12,450 --> 00:01:13,710 ‫So all these things, obviously, 36 00:01:13,710 --> 00:01:15,210 ‫you're going to learn in the next few slides, 37 00:01:15,210 --> 00:01:17,040 ‫so don't worry, this is just an overview, 38 00:01:17,040 --> 00:01:20,280 ‫and you'll learn about the diagrams for all of these. 39 00:01:20,280 --> 00:01:21,960 ‫So let's talk about all at once. 40 00:01:21,960 --> 00:01:24,600 ‫Here is our four EC2 instances, 41 00:01:24,600 --> 00:01:26,490 ‫and they all run the version one, 42 00:01:26,490 --> 00:01:29,070 ‫which is blue, of our application. 43 00:01:29,070 --> 00:01:31,290 ‫Then we are going to do an all at once deployment. 44 00:01:31,290 --> 00:01:32,940 ‫So we want deploy v2. 45 00:01:32,940 --> 00:01:35,460 ‫And what happens, that first Elastic Beanstalk 46 00:01:35,460 --> 00:01:39,180 ‫will just stop the applications on all our EC2 instances. 47 00:01:39,180 --> 00:01:42,300 ‫So then I put it as gray, as in they don't run anything. 48 00:01:42,300 --> 00:01:45,510 ‫And then we will be running the new V2, 49 00:01:45,510 --> 00:01:49,560 ‫because Elastic Beanstalk will deploy V2 to these instances. 50 00:01:49,560 --> 00:01:50,820 ‫So what do we notice? 51 00:01:50,820 --> 00:01:51,810 ‫Well, it's very quick. 52 00:01:51,810 --> 00:01:53,310 ‫It's the fastest deployment. 53 00:01:53,310 --> 00:01:55,050 ‫The application, though, has downtime, 54 00:01:55,050 --> 00:01:57,330 ‫because you can see in the middle they're all gray, 55 00:01:57,330 --> 00:01:59,880 ‫and so they can't serve any traffic. 56 00:01:59,880 --> 00:02:02,460 ‫I think it's great for when you have quick iterations 57 00:02:02,460 --> 00:02:04,530 ‫and development environments when you wanna deploy your code 58 00:02:04,530 --> 00:02:07,620 ‫fast and quickly, and you don't really care about downtime. 59 00:02:07,620 --> 00:02:10,653 ‫And finally with this setup, there's no additional cost. 60 00:02:11,700 --> 00:02:13,710 ‫Now let's talk about rolling. 61 00:02:13,710 --> 00:02:17,010 ‫The application will basically be running below capacity, 62 00:02:17,010 --> 00:02:19,710 ‫and we can set how much below we want to set, 63 00:02:19,710 --> 00:02:20,760 ‫like running the capacity. 64 00:02:20,760 --> 00:02:22,140 ‫So that's called the bucket size. 65 00:02:22,140 --> 00:02:23,640 ‫And so let's have a look. 66 00:02:23,640 --> 00:02:25,890 ‫We have four instances running v1, 67 00:02:25,890 --> 00:02:28,170 ‫and the bucket size will be two for the example. 68 00:02:28,170 --> 00:02:31,650 ‫So what happens is that the first two instances 69 00:02:31,650 --> 00:02:32,520 ‫will be stopped... 70 00:02:32,520 --> 00:02:34,920 ‫Not the instances, sorry, the application on the instances 71 00:02:34,920 --> 00:02:36,510 ‫will be stopped, and so they're gray. 72 00:02:36,510 --> 00:02:40,050 ‫But we still have the other two instances running v1. 73 00:02:40,050 --> 00:02:43,170 ‫So you can see we have maybe half capacity here. 74 00:02:43,170 --> 00:02:46,170 ‫Then these first two instances will be updated, 75 00:02:46,170 --> 00:02:50,160 ‫so they'll be running v2, and then we will roll on 76 00:02:50,160 --> 00:02:52,800 ‫to the next bucket, or to the next batch. 77 00:02:52,800 --> 00:02:54,750 ‫And so that's why it's called rolling. 78 00:02:54,750 --> 00:02:57,210 ‫As you can see now, the bottom two instances 79 00:02:57,210 --> 00:03:00,480 ‫will have their application v1 taken down to some gray, 80 00:03:00,480 --> 00:03:02,520 ‫and then updated to v2. 81 00:03:02,520 --> 00:03:06,210 ‫And so at the end, we have all the EC2 instances 82 00:03:06,210 --> 00:03:09,540 ‫that have been updated to run the v2 application code. 83 00:03:09,540 --> 00:03:11,940 ‫So as you can see now, the application, 84 00:03:11,940 --> 00:03:13,740 ‫at some point during the deployment, 85 00:03:13,740 --> 00:03:16,950 ‫is running both versions simultaneously. 86 00:03:16,950 --> 00:03:18,660 ‫And there is no additional cost, okay? 87 00:03:18,660 --> 00:03:21,600 ‫You still have the same number of EC2 instances 88 00:03:21,600 --> 00:03:23,310 ‫running in your infrastructure. 89 00:03:23,310 --> 00:03:25,860 ‫And so if you set a very small bucket size 90 00:03:25,860 --> 00:03:28,500 ‫and you have hundreds and hundreds of instances, 91 00:03:28,500 --> 00:03:31,770 ‫it may be a very long deployment, okay? 92 00:03:31,770 --> 00:03:32,700 ‫Right now, in this example, 93 00:03:32,700 --> 00:03:35,400 ‫we have a bucket size of two and four instances, 94 00:03:35,400 --> 00:03:38,820 ‫but we can have a bucket size of 2 and 100 instances. 95 00:03:38,820 --> 00:03:41,673 ‫It will just take a very long time to upgrade everything. 96 00:03:42,630 --> 00:03:43,920 ‫Now, there's an additional mode 97 00:03:43,920 --> 00:03:46,920 ‫called rolling with additional batches. 98 00:03:46,920 --> 00:03:50,010 ‫And so in this case, the application is not running 99 00:03:50,010 --> 00:03:51,540 ‫under capacity, just like before. 100 00:03:51,540 --> 00:03:54,120 ‫Before, at some point, we were only running 101 00:03:54,120 --> 00:03:55,770 ‫two instances out of four. 102 00:03:55,770 --> 00:03:58,140 ‫So that was below capacity. 103 00:03:58,140 --> 00:04:00,660 ‫In this mode, we run at capacity, 104 00:04:00,660 --> 00:04:02,550 ‫and we can also set the bucket size. 105 00:04:02,550 --> 00:04:04,500 ‫And basically our application will still be 106 00:04:04,500 --> 00:04:06,750 ‫running both versions simultaneously, 107 00:04:06,750 --> 00:04:09,000 ‫but at a small additional cost. 108 00:04:09,000 --> 00:04:11,220 ‫That additional batch, that we'll see in a second, 109 00:04:11,220 --> 00:04:14,040 ‫will be removed at the end of the deployment. 110 00:04:14,040 --> 00:04:17,070 ‫And again, the deployment is going to be long. 111 00:04:17,070 --> 00:04:20,010 ‫It's honestly a good way to deal with prod. 112 00:04:20,010 --> 00:04:21,180 ‫So let's have a look. 113 00:04:21,180 --> 00:04:24,270 ‫We have our four v1 EC2 instances, 114 00:04:24,270 --> 00:04:25,680 ‫and the first thing we're going to do 115 00:04:25,680 --> 00:04:28,620 ‫is deploy new EC2 instances, 116 00:04:28,620 --> 00:04:31,170 ‫and they will have the v2 version on it. 117 00:04:31,170 --> 00:04:34,350 ‫So now, from four instances, Elastic Beanstalk 118 00:04:34,350 --> 00:04:37,170 ‫automatically created six instances for us, 119 00:04:37,170 --> 00:04:38,430 ‫so an additional two. 120 00:04:38,430 --> 00:04:40,140 ‫and you can see that the additional two 121 00:04:40,140 --> 00:04:43,140 ‫are running, already, the newer version. 122 00:04:43,140 --> 00:04:46,380 ‫Now we take the first batch to the first bucket of two 123 00:04:46,380 --> 00:04:49,260 ‫and they get stopped, the application gets stopped, 124 00:04:49,260 --> 00:04:52,950 ‫and the application gets updated to v2, excellent. 125 00:04:52,950 --> 00:04:55,470 ‫Then the process repeats again, just like in rolling. 126 00:04:55,470 --> 00:04:58,320 ‫So the application running v1 gets stopped, 127 00:04:58,320 --> 00:05:01,140 ‫and then the application is updated to v2. 128 00:05:01,140 --> 00:05:02,730 ‫And so at the end, you can see, 129 00:05:02,730 --> 00:05:06,270 ‫we have six EC2 instances running v2. 130 00:05:06,270 --> 00:05:08,820 ‫And so at the end of it, the additional batch 131 00:05:08,820 --> 00:05:11,130 ‫gets terminated and taken away. 132 00:05:11,130 --> 00:05:12,030 ‫So why would you do this? 133 00:05:12,030 --> 00:05:15,840 ‫Well, now we can see that we are running always at capacity. 134 00:05:15,840 --> 00:05:18,720 ‫The lowest number of EC2 instances running the application 135 00:05:18,720 --> 00:05:20,760 ‫we have at any time is four. 136 00:05:20,760 --> 00:05:24,390 ‫So sometimes we are running at over capacity, obviously, 137 00:05:24,390 --> 00:05:27,150 ‫and this is why you have a small additional cost. 138 00:05:27,150 --> 00:05:29,250 ‫It's very small, but there is an additional cost. 139 00:05:29,250 --> 00:05:31,200 ‫And sometimes the exam asks you, 140 00:05:31,200 --> 00:05:33,930 ‫is there an additional cost to this kind of stuff? 141 00:05:33,930 --> 00:05:37,080 ‫Then we have immutable type of deployments. 142 00:05:37,080 --> 00:05:39,810 ‫And these deployments are also zero downtime, 143 00:05:39,810 --> 00:05:42,570 ‫but this time the new code is going to be deployed 144 00:05:42,570 --> 00:05:44,250 ‫to new instances. 145 00:05:44,250 --> 00:05:45,960 ‫So before, it was on previous instances, 146 00:05:45,960 --> 00:05:48,120 ‫now it's deployed on new instances. 147 00:05:48,120 --> 00:05:50,370 ‫And where do these instances come from? 148 00:05:50,370 --> 00:05:52,920 ‫Well, they come from a temporary ASG. 149 00:05:52,920 --> 00:05:54,810 ‫So there's a high cost, you double the capacity 150 00:05:54,810 --> 00:05:56,370 ‫because you get a full new ASG, 151 00:05:56,370 --> 00:05:58,770 ‫and it's the the longest kind of deployment. 152 00:05:58,770 --> 00:06:01,590 ‫As a bonus though, you get a very quick rollback 153 00:06:01,590 --> 00:06:04,500 ‫in case of failures, because to just mitigate failure, 154 00:06:04,500 --> 00:06:05,700 ‫you just have to terminate. 155 00:06:05,700 --> 00:06:07,410 ‫Not you, but Elastic Beanstalk 156 00:06:07,410 --> 00:06:09,333 ‫will just terminate the new ASG. 157 00:06:10,530 --> 00:06:11,760 ‫So it's a great choice for prod, 158 00:06:11,760 --> 00:06:14,760 ‫if you're willing to take a little bit more cost. 159 00:06:14,760 --> 00:06:15,990 ‫So here's the idea. 160 00:06:15,990 --> 00:06:19,650 ‫We have a current ASG with three applications v1 161 00:06:19,650 --> 00:06:21,390 ‫running on three instances. 162 00:06:21,390 --> 00:06:23,370 ‫And then we're going to have a new 163 00:06:23,370 --> 00:06:25,320 ‫temporary ASG being created. 164 00:06:25,320 --> 00:06:29,190 ‫At first, Beanstalk will launch one instance on it, 165 00:06:29,190 --> 00:06:31,020 ‫just to make sure that one works. 166 00:06:31,020 --> 00:06:33,120 ‫And if it works and it passes the health checks, 167 00:06:33,120 --> 00:06:35,250 ‫it's going to launch all the remaining ones. 168 00:06:35,250 --> 00:06:37,320 ‫So right now, three instances. 169 00:06:37,320 --> 00:06:40,200 ‫When it's happy, it's going to sort of merge 170 00:06:40,200 --> 00:06:42,270 ‫the ASG with a temporary ASG. 171 00:06:42,270 --> 00:06:45,600 ‫So it's going to move all the temporary ASG instances 172 00:06:45,600 --> 00:06:46,740 ‫to the current ASG. 173 00:06:46,740 --> 00:06:50,250 ‫So now, in the current ASG, we have six instances, okay? 174 00:06:50,250 --> 00:06:53,790 ‫And when all of this is done and the temporary ASG is empty, 175 00:06:53,790 --> 00:06:54,843 ‫then we have the current ASG 176 00:06:54,843 --> 00:06:58,830 ‫that will terminate all the v1 applications, 177 00:06:58,830 --> 00:07:01,500 ‫while the v2 applications are still there. 178 00:07:01,500 --> 00:07:04,400 ‫And then, finally, the temporary ASG will just be removed. 179 00:07:05,430 --> 00:07:07,710 ‫Finally, there's something you may hear in the exam 180 00:07:07,710 --> 00:07:09,960 ‫or in the white papers, it's called blue/green, 181 00:07:09,960 --> 00:07:12,330 ‫and it's not a direct feature of Elastic Beanstalk, 182 00:07:12,330 --> 00:07:14,520 ‫but I'll try to give you my best version of it. 183 00:07:14,520 --> 00:07:15,870 ‫It's basically a zero downtime, 184 00:07:15,870 --> 00:07:17,610 ‫and it helps with the release facility, 185 00:07:17,610 --> 00:07:19,740 ‫allows for more testing, et cetera, et cetera. 186 00:07:19,740 --> 00:07:21,660 ‫And so the idea is that you wanna deploy 187 00:07:21,660 --> 00:07:23,160 ‫a new stage environment. 188 00:07:23,160 --> 00:07:26,040 ‫So it's just another Elastic Beanstalk environment, 189 00:07:26,040 --> 00:07:27,930 ‫and you'll deploy your new v2 there. 190 00:07:27,930 --> 00:07:29,730 ‫So before, all the deployment strategies 191 00:07:29,730 --> 00:07:31,170 ‫were within the same environment, 192 00:07:31,170 --> 00:07:33,660 ‫here, we create a new environment. 193 00:07:33,660 --> 00:07:36,030 ‫And so the new environment stage, or green, 194 00:07:36,030 --> 00:07:38,820 ‫can be validated independently in our own time 195 00:07:38,820 --> 00:07:40,860 ‫and then roll back if issues. 196 00:07:40,860 --> 00:07:43,350 ‫And then we can use something like Route 53, for example, 197 00:07:43,350 --> 00:07:48,030 ‫to prevent the traffic from going into the two directions. 198 00:07:48,030 --> 00:07:50,190 ‫So we can set up weighted policies 199 00:07:50,190 --> 00:07:51,900 ‫and redirect a little bit of traffic 200 00:07:51,900 --> 00:07:54,660 ‫to the stage environment so we can test everything. 201 00:07:54,660 --> 00:07:56,130 ‫And then when we're happy using 202 00:07:56,130 --> 00:07:57,540 ‫the Elastic Beanstalk console, 203 00:07:57,540 --> 00:08:01,140 ‫you can swap URLs, when done, with a test environment. 204 00:08:01,140 --> 00:08:03,420 ‫So this is not a very direct feature, 205 00:08:03,420 --> 00:08:05,850 ‫and it's actually very manual to do. 206 00:08:05,850 --> 00:08:08,100 ‫It's not embedded into Elastic Beanstalk, 207 00:08:08,100 --> 00:08:11,130 ‫so some documentation will say there is blue/green, 208 00:08:11,130 --> 00:08:15,030 ‫some will say it's not there, but overall it's very manual. 209 00:08:15,030 --> 00:08:17,310 ‫So just one graph, I try to make it simple. 210 00:08:17,310 --> 00:08:19,590 ‫But in the blue environment, running into one 211 00:08:19,590 --> 00:08:22,320 ‫Elastic Beanstalk environment, we have all the v1, 212 00:08:22,320 --> 00:08:24,810 ‫and then we'll deploy a green environment 213 00:08:24,810 --> 00:08:26,910 ‫with all the v2, okay? 214 00:08:26,910 --> 00:08:29,640 ‫And they're both running at the same time, just very fine. 215 00:08:29,640 --> 00:08:32,238 ‫And then in Route 53 we're going to set up a weighted 216 00:08:32,238 --> 00:08:35,940 ‫type of policy to send 90% of the traffic to blue. 217 00:08:35,940 --> 00:08:37,770 ‫So just keep most of the traffic going 218 00:08:37,770 --> 00:08:39,450 ‫to the instances we know work, 219 00:08:39,450 --> 00:08:42,630 ‫and maybe only 10% of the traffic to the green environment, 220 00:08:42,630 --> 00:08:44,640 ‫just to test it out and make sure it's working 221 00:08:44,640 --> 00:08:46,590 ‫and the users aren't having any problems. 222 00:08:46,590 --> 00:08:50,610 ‫And so the web traffic basically gets split 90/10, 223 00:08:50,610 --> 00:08:53,010 ‫but it's whatever you want, as far as the weight goes. 224 00:08:53,010 --> 00:08:54,690 ‫And so when you're happy where you're testing, 225 00:08:54,690 --> 00:08:56,130 ‫when you measured everything you want 226 00:08:56,130 --> 00:08:58,920 ‫with your v2 environment and you think you got it, 227 00:08:58,920 --> 00:09:01,470 ‫then you basically shut down the blue environment 228 00:09:01,470 --> 00:09:05,160 ‫and swipe the URL to make the green be the main environment. 229 00:09:05,160 --> 00:09:06,930 ‫So that's it for blue/green, right? 230 00:09:06,930 --> 00:09:08,490 ‫And it's pretty complicated, 231 00:09:08,490 --> 00:09:10,260 ‫and I think pretty manual, Elastic Beanstalk, 232 00:09:10,260 --> 00:09:11,370 ‫but that's the way it is. 233 00:09:11,370 --> 00:09:14,460 ‫Another kind of deployment you can do with Elastic Beanstalk 234 00:09:14,460 --> 00:09:16,230 ‫is called traffic splitting. 235 00:09:16,230 --> 00:09:18,180 ‫And this will be used for canary testing. 236 00:09:18,180 --> 00:09:20,400 ‫So if you see canary testing on the exam, 237 00:09:20,400 --> 00:09:22,110 ‫think traffic splitting. 238 00:09:22,110 --> 00:09:23,670 ‫So what is canary testing? 239 00:09:23,670 --> 00:09:26,220 ‫Well, a new application version is going to be deployed 240 00:09:26,220 --> 00:09:29,550 ‫to a temporary Auto Scaling group with the same capacity. 241 00:09:29,550 --> 00:09:31,650 ‫So we have the main Auto Scaling group 242 00:09:31,650 --> 00:09:34,380 ‫and a temporary Auto Scaling group with the same capacity. 243 00:09:34,380 --> 00:09:36,480 ‫So three instances in the main one, 244 00:09:36,480 --> 00:09:38,760 ‫and three instances in the temp. 245 00:09:38,760 --> 00:09:40,860 ‫So it doubles the capacity. 246 00:09:40,860 --> 00:09:42,930 ‫And what's going to happen is that a small percentage 247 00:09:42,930 --> 00:09:46,980 ‫of the traffic is going to be sent to the temporary ASG 248 00:09:46,980 --> 00:09:49,050 ‫for a configurable amount of time. 249 00:09:49,050 --> 00:09:51,247 ‫So we have an ALB, and we're going to say, 250 00:09:51,247 --> 00:09:54,937 ‫"Okay, 90% of the traffic goes to my main ASG," 251 00:09:54,937 --> 00:09:58,920 ‫"while 10% of the traffic goes to my temporary ASG." 252 00:09:58,920 --> 00:10:00,720 ‫And all of this is automated. 253 00:10:00,720 --> 00:10:04,800 ‫The deployment health of the new temporary ASG 254 00:10:04,800 --> 00:10:06,450 ‫is going to be monitored. 255 00:10:06,450 --> 00:10:08,790 ‫And in case there is a deployment failure, 256 00:10:08,790 --> 00:10:11,280 ‫or there is a metric that goes wrong, 257 00:10:11,280 --> 00:10:13,680 ‫this will trigger an automated rollback, 258 00:10:13,680 --> 00:10:15,300 ‫which will be very, very quick 259 00:10:15,300 --> 00:10:18,090 ‫because the main ASG is already here, 260 00:10:18,090 --> 00:10:19,440 ‫and all we have to do to roll back 261 00:10:19,440 --> 00:10:24,120 ‫is to stop sending 10% of the traffic to this temporary ASG. 262 00:10:24,120 --> 00:10:26,220 ‫So there is no application downtime. 263 00:10:26,220 --> 00:10:29,070 ‫And then once everything is stable and correct, 264 00:10:29,070 --> 00:10:31,740 ‫then the new instances are going to be migrated 265 00:10:31,740 --> 00:10:36,600 ‫from the temporary ASG to the main original ASG. 266 00:10:36,600 --> 00:10:39,000 ‫And then the old application version 267 00:10:39,000 --> 00:10:40,980 ‫is going to be terminated. 268 00:10:40,980 --> 00:10:44,160 ‫So I really like that, because all of this is automated, 269 00:10:44,160 --> 00:10:45,840 ‫and this could be a big improvement 270 00:10:45,840 --> 00:10:49,020 ‫on top of the blue/green technique that I just described 271 00:10:49,020 --> 00:10:50,640 ‫in the previous lecture. 272 00:10:50,640 --> 00:10:52,920 ‫So if you wanted to compare all of those, 273 00:10:52,920 --> 00:10:55,710 ‫there is this link on the Beanstalk documentation, 274 00:10:55,710 --> 00:10:57,180 ‫which shows you the difference 275 00:10:57,180 --> 00:10:59,940 ‫between all the deployment methods I just explained. 276 00:10:59,940 --> 00:11:00,840 ‫And this is really cool, 277 00:11:00,840 --> 00:11:02,580 ‫because it gives you the method name, 278 00:11:02,580 --> 00:11:04,830 ‫the impact of a failed deployment, 279 00:11:04,830 --> 00:11:07,470 ‫the deploy time, if it's zero down time, 280 00:11:07,470 --> 00:11:10,530 ‫if there's a DNS change, what is the rollback process, 281 00:11:10,530 --> 00:11:12,420 ‫and where the code is deployed to. 282 00:11:12,420 --> 00:11:13,920 ‫So if you understood this lecture, 283 00:11:13,920 --> 00:11:16,200 ‫this table should make sense to you. 284 00:11:16,200 --> 00:11:18,960 ‫So what I recommend for you is to just explore this link, 285 00:11:18,960 --> 00:11:21,660 ‫have a read through, and make sure the table makes sense, 286 00:11:21,660 --> 00:11:25,350 ‫because the exam will give you one or two scenario questions 287 00:11:25,350 --> 00:11:28,110 ‫around the kind of deployment mechanism for Beanstalk 288 00:11:28,110 --> 00:11:30,226 ‫based on the constraints and requirements 289 00:11:30,226 --> 00:11:32,400 ‫of the deployment itself. 290 00:11:32,400 --> 00:11:34,500 ‫So that's it for this lecture, I hope you liked it. 291 00:11:34,500 --> 00:11:36,990 ‫You should be a deployment expert now, 292 00:11:36,990 --> 00:11:38,940 ‫and I will see you in the next lecture.