1 00:00:00,330 --> 00:00:03,270 Memi: Our next topic is monitoring. 2 00:00:03,270 --> 00:00:06,691 Using monitoring, you can get the status of your API 3 00:00:06,691 --> 00:00:10,200 and you can know whether there are any problems with it 4 00:00:10,200 --> 00:00:14,580 or whether there are developing problems with the API. 5 00:00:14,580 --> 00:00:17,087 Now to understand the importance of monitoring 6 00:00:17,087 --> 00:00:19,290 let's have a little game. 7 00:00:19,290 --> 00:00:23,100 What do you think is the cost of downtime at Amazon? 8 00:00:23,100 --> 00:00:26,550 So if the Amazon website will go down 9 00:00:26,550 --> 00:00:28,320 how much will Amazon lose? 10 00:00:28,320 --> 00:00:30,120 Take a few seconds to think about it 11 00:00:33,330 --> 00:00:35,730 and let's see the answer. 12 00:00:35,730 --> 00:00:38,479 So Forbes digital calculation for us 13 00:00:38,479 --> 00:00:43,290 and based on Amazon's financial reports, it found out 14 00:00:43,290 --> 00:00:47,006 that if the Amazon's website will go down for 13 minutes 15 00:00:47,006 --> 00:00:49,697 then Amazon will lose $2,646,501 16 00:00:53,329 --> 00:00:56,324 and that for 13 minutes downtime. 17 00:00:56,324 --> 00:00:57,930 Now, that's right. 18 00:00:57,930 --> 00:00:59,490 Not all of us are Amazon, 19 00:00:59,490 --> 00:01:02,010 but still having our API not working 20 00:01:02,010 --> 00:01:05,160 will definitely impact our client's experience 21 00:01:05,160 --> 00:01:07,560 and we don't want that to happen. 22 00:01:07,560 --> 00:01:10,727 So monitoring is the solution for such downtime. 23 00:01:10,727 --> 00:01:12,583 With monitoring, we can know 24 00:01:12,583 --> 00:01:15,840 about problems before they occur. 25 00:01:15,840 --> 00:01:19,724 So for example, if we see the CPU utilization is climbing 26 00:01:19,724 --> 00:01:24,724 or the memory, the RAM is going higher and higher 27 00:01:25,380 --> 00:01:28,165 or a heavy load is developing on the API 28 00:01:28,165 --> 00:01:31,266 then we can know something bad might be happening. 29 00:01:31,266 --> 00:01:34,710 In addition, if we didn't catch the problem on time 30 00:01:34,710 --> 00:01:36,705 then monitoring will let us know 31 00:01:36,705 --> 00:01:39,750 that there is currently a problem and 32 00:01:39,750 --> 00:01:43,380 that some or all of our API is not working. 33 00:01:43,380 --> 00:01:45,540 In addition, monitoring can provide us 34 00:01:45,540 --> 00:01:48,840 with general information of what's going on with our API. 35 00:01:48,840 --> 00:01:51,334 For example, how many users are using it, 36 00:01:51,334 --> 00:01:54,990 where are they from, what are they doing, et cetera. 37 00:01:54,990 --> 00:01:55,823 It's important to understand 38 00:01:55,823 --> 00:02:00,210 that monitoring is not nice to have addition to the API. 39 00:02:00,210 --> 00:02:04,470 It is very important because our clients expect the API 40 00:02:04,470 --> 00:02:07,230 to always work no matter what. 41 00:02:07,230 --> 00:02:09,840 The same way that we expect websites such 42 00:02:09,840 --> 00:02:13,920 as Amazon or Netflix to simply work and we don't care 43 00:02:13,920 --> 00:02:18,570 about server outages or software bugs or things like that. 44 00:02:18,570 --> 00:02:21,479 This is what we want our clients to think about our API. 45 00:02:21,479 --> 00:02:24,120 So it should simply work. 46 00:02:24,120 --> 00:02:27,508 And in order to do that, we have to have monitoring 47 00:02:27,508 --> 00:02:30,630 because without monitoring it won't happen. 48 00:02:30,630 --> 00:02:33,330 Our API will not just work. 49 00:02:33,330 --> 00:02:35,501 So monitoring is really, really important 50 00:02:35,501 --> 00:02:38,553 and we must implement it for our API.