1 00:00:02,400 --> 00:00:06,050 Now, I do have a note about using databases 2 00:00:06,050 --> 00:00:10,570 with Docker and deploying them most importantly. 3 00:00:10,570 --> 00:00:15,180 You absolutely can manage your own database containers 4 00:00:15,180 --> 00:00:17,180 as we're doing it at the moment. 5 00:00:17,180 --> 00:00:20,600 Because at the moment we do have this MongoDB container 6 00:00:20,600 --> 00:00:21,550 up and running. 7 00:00:21,550 --> 00:00:22,790 And as you've learned, 8 00:00:22,790 --> 00:00:26,220 also when we used it locally on our host machine, 9 00:00:26,220 --> 00:00:30,600 this container internally creates a database, starts it, 10 00:00:30,600 --> 00:00:34,623 and allows us to connect to it through port 27017. 11 00:00:36,200 --> 00:00:37,910 Now, we can absolutely use 12 00:00:37,910 --> 00:00:40,600 and manage our own database containers, 13 00:00:40,600 --> 00:00:45,600 but there are a couple of potential downsides and issues. 14 00:00:46,390 --> 00:00:49,650 For example, scaling and managing availability 15 00:00:49,650 --> 00:00:51,130 can be challenging. 16 00:00:51,130 --> 00:00:55,370 Since it's a database, we need to be prepared that multiple 17 00:00:55,370 --> 00:00:59,700 read/write operations could occur simultaneously. 18 00:00:59,700 --> 00:01:02,770 So we might need multiple database containers 19 00:01:02,770 --> 00:01:05,319 with the same configuration and working on 20 00:01:05,319 --> 00:01:09,320 the same database files up and running simultaneously, 21 00:01:09,320 --> 00:01:11,870 which poses brand new challenges. 22 00:01:11,870 --> 00:01:14,650 Because we of course also then need to ensure 23 00:01:14,650 --> 00:01:18,070 that these different database containers work 24 00:01:18,070 --> 00:01:20,410 on one and the same database. 25 00:01:20,410 --> 00:01:23,290 So that they are synchronized across each other. 26 00:01:23,290 --> 00:01:25,940 And one database is not managing data 27 00:01:25,940 --> 00:01:28,350 which another database doesn't know. 28 00:01:28,350 --> 00:01:31,200 So scaling database containers means more 29 00:01:31,200 --> 00:01:34,940 than just running two containers at the same time. 30 00:01:34,940 --> 00:01:37,830 In addition, and related to that, 31 00:01:37,830 --> 00:01:40,720 we could have problems with performance, 32 00:01:40,720 --> 00:01:42,890 especially during traffic spikes. 33 00:01:42,890 --> 00:01:45,750 Especially if we don't handle scaling 34 00:01:45,750 --> 00:01:48,120 and we just have one database container 35 00:01:48,120 --> 00:01:50,640 which you should do all the work. 36 00:01:50,640 --> 00:01:55,640 And even if we leave aside this performance scaling issue 37 00:01:55,770 --> 00:01:59,560 another problem we could be facing is that we have 38 00:01:59,560 --> 00:02:03,520 to take care about backups and security. 39 00:02:03,520 --> 00:02:06,610 That means that we of course wanna ensure that our data 40 00:02:06,610 --> 00:02:11,320 is secure and can't accessed without our permission. 41 00:02:11,320 --> 00:02:13,930 And we also need to ensure that the data 42 00:02:13,930 --> 00:02:17,260 is backed up regularly so that we can roll back 43 00:02:17,260 --> 00:02:21,280 to an older backup in case some data should be lost. 44 00:02:21,280 --> 00:02:25,540 And these are all database-specific challenges 45 00:02:25,540 --> 00:02:27,400 we have to be aware of. 46 00:02:27,400 --> 00:02:29,930 And we ultimately have to tackle 47 00:02:29,930 --> 00:02:34,010 if we are using a database in production. 48 00:02:34,010 --> 00:02:35,980 Locally on our host machine, 49 00:02:35,980 --> 00:02:38,560 these problems all don't matter. 50 00:02:38,560 --> 00:02:40,990 We don't have traffic spikes there. 51 00:02:40,990 --> 00:02:43,100 We don't care about backups there, 52 00:02:43,100 --> 00:02:45,420 but in production they do. 53 00:02:45,420 --> 00:02:49,040 And that's why for databases specifically, 54 00:02:49,040 --> 00:02:53,220 you again might wanna consider switching from managing 55 00:02:53,220 --> 00:02:56,930 your own databases and bringing your own database containers 56 00:02:56,930 --> 00:02:59,603 to a managed database service. 57 00:03:00,520 --> 00:03:05,210 For relational databases, like MySQL databases, 58 00:03:05,210 --> 00:03:08,930 DREs, AWS RDS for example. 59 00:03:08,930 --> 00:03:11,730 Another service offered by AWS. 60 00:03:11,730 --> 00:03:15,700 RDS stands for Relational Database Service. 61 00:03:15,700 --> 00:03:19,910 For MongoDB, there is MongoDB Atlas as service offered 62 00:03:19,910 --> 00:03:21,623 by the MongoDB company. 63 00:03:22,660 --> 00:03:25,300 And this is something which you might wanna consider 64 00:03:25,300 --> 00:03:28,090 if you are building your own application. 65 00:03:28,090 --> 00:03:31,470 You can always manage everything on your own. 66 00:03:31,470 --> 00:03:34,040 It's the same discussion we had earlier 67 00:03:34,040 --> 00:03:36,610 about deployment in general. 68 00:03:36,610 --> 00:03:37,443 But with that, 69 00:03:37,443 --> 00:03:39,590 we are back to this trade off here 70 00:03:39,590 --> 00:03:41,070 in the bottom right corner. 71 00:03:41,070 --> 00:03:43,420 You can manage everything on your own. 72 00:03:43,420 --> 00:03:45,300 And if you know what you're doing, 73 00:03:45,300 --> 00:03:49,020 this might be perfect because then you have full control 74 00:03:49,020 --> 00:03:52,260 and you can fine-tune everything exactly as you need it. 75 00:03:52,260 --> 00:03:55,733 And you might be able to achieve a great solution. 76 00:03:56,680 --> 00:03:58,970 But if you're not an expert on the topic, 77 00:03:58,970 --> 00:04:00,700 you might mess things up. 78 00:04:00,700 --> 00:04:03,110 You might end up with a suboptimal 79 00:04:03,110 --> 00:04:05,730 and maybe also a more expensive solution. 80 00:04:05,730 --> 00:04:07,563 And that of course would be bad. 81 00:04:08,480 --> 00:04:12,690 That's why as I've just mentioned for relational databases 82 00:04:12,690 --> 00:04:16,560 you could look into services like AWS RDS, 83 00:04:16,560 --> 00:04:18,589 of course other cloud providers 84 00:04:18,589 --> 00:04:21,230 also have their own solutions for that. 85 00:04:21,230 --> 00:04:26,070 And for MongoDB specifically, you can visit mongodb.com, 86 00:04:26,070 --> 00:04:28,800 the website of the MongoDB company 87 00:04:28,800 --> 00:04:31,040 where you don't just learn how to work 88 00:04:31,040 --> 00:04:34,600 with MongoDB and how you could install it locally. 89 00:04:34,600 --> 00:04:38,200 But where you can also dive into MongoDB Atlas. 90 00:04:38,200 --> 00:04:40,430 One of the solutions they are offering, 91 00:04:40,430 --> 00:04:43,830 which is a cloud-based MongoDB service 92 00:04:43,830 --> 00:04:46,960 which already takes care about scaling, performance, 93 00:04:46,960 --> 00:04:48,670 and backups for you. 94 00:04:48,670 --> 00:04:52,980 And which therefore makes using MongoDB very, very easy. 95 00:04:52,980 --> 00:04:55,490 This has nothing to do with containers. 96 00:04:55,490 --> 00:04:58,720 I mean, maybe they use containers under the hood. 97 00:04:58,720 --> 00:05:00,930 We don't know, but you don't need to bring 98 00:05:00,930 --> 00:05:03,100 your own Mongo container for that. 99 00:05:03,100 --> 00:05:07,490 But it will make working with MongoDB way easier for you 100 00:05:07,490 --> 00:05:11,150 if you're not a MongoDB administration expert, 101 00:05:11,150 --> 00:05:13,160 which you most likely aren't. 102 00:05:13,160 --> 00:05:14,143 I ain't one either.