1
00:00:03,640 --> 00:00:03,990
‫Pun.

2
00:00:04,010 --> 00:00:09,320
‫I've been getting told a lot recently not to worry about getting the D.B. Postgres running in a docker

3
00:00:09,320 --> 00:00:16,590
‫container that it may be better to keep the DB on bare metal thoughts especially with replication.

4
00:00:17,720 --> 00:00:23,510
‫OK so if you're running your DBS today on bare metal and they're working fine then you've got to ask

5
00:00:23,510 --> 00:00:30,170
‫yourself are you container rising for just because it seems cool or you container rising for a specific

6
00:00:30,170 --> 00:00:32,310
‫reason to gain something you need.

7
00:00:32,390 --> 00:00:33,480
‫Right.

8
00:00:33,530 --> 00:00:36,800
‫Databases are probably They run great in containers.

9
00:00:36,800 --> 00:00:40,080
‫I should say that also gate lots of containers are running databases.

10
00:00:40,100 --> 00:00:43,070
‫I run on my databases in containers when I have to.

11
00:00:43,160 --> 00:00:47,380
‫The option I prefer is to just use the cloud hosting of the database for themselves.

12
00:00:47,380 --> 00:00:52,990
‫In other words if it's on a W.S. and I can use RDX for their own solution I'd rather do that.

13
00:00:53,000 --> 00:00:58,220
‫I'd rather not have to run and maintain my own database servers because most of us are not full time

14
00:00:58,220 --> 00:01:03,300
‫DB as the cloud engineers that run the cloud tend to be better DB days and we are.

15
00:01:03,320 --> 00:01:08,540
‫So I always prefer running my databases in cloud stuff right.

16
00:01:08,540 --> 00:01:14,950
‫That being said if this is just a personal project or if you're not allowed to do that or if you have

17
00:01:14,960 --> 00:01:20,990
‫very very specific reasons not to price should not be one of them because I in most cases can clearly

18
00:01:20,990 --> 00:01:26,210
‫argue that it's going to be cheaper for you to host that on their storage in their environment because

19
00:01:26,210 --> 00:01:29,660
‫you're going to get automatic redundancy you're going to get better logging and monitoring out of it

20
00:01:29,660 --> 00:01:32,560
‫out of the gate and otherwise you have to do all that yourself.

21
00:01:32,570 --> 00:01:37,120
‫And if you don't do all that yourself you're probably more expensive than the cloud storage itself.

22
00:01:37,490 --> 00:01:43,370
‫So just the hosting itself may be more expensive than a bare metal server but you cost something to

23
00:01:43,610 --> 00:01:47,270
‫the organization and you managing all this stuff yourself costs something.

24
00:01:47,270 --> 00:01:53,300
‫So I would much rather get my time back to work on other things that maybe the cloud doesn't do great

25
00:01:53,300 --> 00:01:55,880
‫for me and one of things they can do well is databases.

26
00:01:55,910 --> 00:02:02,930
‫So that being said if need to run your databases a database in bare metal and a database on that same

27
00:02:02,990 --> 00:02:07,060
‫bare metal in a container will not be any difference in performance.

28
00:02:07,130 --> 00:02:15,890
‫There is with with the exception of a very few rare cases in the way that maybe your volumes work.

29
00:02:15,890 --> 00:02:22,100
‫And as long as you're properly storing your database logs and in volumes themselves and assuming that

30
00:02:22,100 --> 00:02:26,660
‫that volume is on the same storage that you had in the bare metal case you know because obviously storage

31
00:02:26,690 --> 00:02:31,370
‫Io would change if you moved the file somewhere else then everything will be the same.

32
00:02:31,370 --> 00:02:37,670
‫There is no layer of emulation or delay or some sort of shim in the middle of a container.

33
00:02:37,730 --> 00:02:40,730
‫It's bare metal it's running on the host OS right.

34
00:02:40,730 --> 00:02:42,710
‫So if that host OS and that host

35
00:02:45,360 --> 00:02:50,370
‫kernel are on bare metal that it's gonna get bare metal performance and I can say this with confidence

36
00:02:51,000 --> 00:02:55,050
‫because I did this in fact over on my Docker resources page

37
00:02:58,470 --> 00:03:06,340
‫if you search HP e HP there's a white paper that I did a couple of years ago with Docker and Hewlett-Packard

38
00:03:06,400 --> 00:03:09,640
‫HP Hewlett-Packard Enterprise I think is what that stands for.

39
00:03:09,910 --> 00:03:18,870
‫And we did a my sequel performance across three different scenarios using databases one like one database

40
00:03:18,870 --> 00:03:23,300
‫one database engine in a VM and then multiple victims on a single host.

41
00:03:23,310 --> 00:03:23,490
‫Right.

42
00:03:23,490 --> 00:03:25,140
‫Which is the cloud model most people.

43
00:03:25,170 --> 00:03:32,970
‫That's the model they do the traditional model or having a few VM with many containers all running a

44
00:03:32,970 --> 00:03:35,000
‫separate my single instance.

45
00:03:35,070 --> 00:03:42,600
‫So that means fewer OS is but the same number of overall my sequel engines or running that same number

46
00:03:42,600 --> 00:03:47,370
‫of my sequel engines on bare metal in containers without any virtualization.

47
00:03:47,370 --> 00:03:47,630
‫Right.

48
00:03:47,640 --> 00:03:53,370
‫So we did three different models that were most likely the models that you would use as you move from

49
00:03:53,370 --> 00:03:59,850
‫traditional vacuums to containers and without a doubt bare metal wins hands down.

50
00:03:59,850 --> 00:04:06,020
‫It wins in terms of performance and wins in terms of management overhead because you only have one OS

51
00:04:06,030 --> 00:04:11,320
‫now instead of potentially eight or more OS is depending on how many mice equal volumes you create.

52
00:04:11,490 --> 00:04:18,360
‫It also saves you lots of space and memory resources because you don't have to run each OS and use you

53
00:04:18,360 --> 00:04:22,190
‫know gigs of RAM just to run the operating systems over and over again.

54
00:04:22,200 --> 00:04:22,750
‫Right.

55
00:04:22,770 --> 00:04:26,590
‫So if you think about efficiency it was way better on my bare metal.

56
00:04:26,700 --> 00:04:28,920
‫That's containers running in bare metal.

57
00:04:28,920 --> 00:04:34,560
‫If I'd have run that database on bare metal without a container then I probably wouldn't want to run

58
00:04:34,560 --> 00:04:37,220
‫multiple database engines on that same OS.

59
00:04:37,260 --> 00:04:37,590
‫Right.

60
00:04:37,590 --> 00:04:45,850
‫So now if you're not using containers on bare metal you must either one need all the resources of that

61
00:04:45,850 --> 00:04:47,440
‫one physical machine.

62
00:04:47,520 --> 00:04:47,730
‫Right.

63
00:04:47,740 --> 00:04:52,450
‫So maybe it gets a really large database or you're just not able to fully utilize the resources of it

64
00:04:52,480 --> 00:04:57,640
‫because you're not able to stack up you know five different my single instances all on the same bare

65
00:04:57,640 --> 00:04:58,200
‫metal.

66
00:04:58,210 --> 00:05:03,790
‫So that's the advantage I see in containers is it allows you to discreetly isolate separate database

67
00:05:03,790 --> 00:05:05,580
‫engines all in the same bare metal.

68
00:05:05,710 --> 00:05:06,520
‫And why not.

69
00:05:06,520 --> 00:05:09,420
‫When I do that if you have access to very metal then you're willing to do that.

70
00:05:09,430 --> 00:05:13,780
‫So I would not go running and putting Postgres into containers just because I thought would cool it

71
00:05:13,780 --> 00:05:14,280
‫was cool.

72
00:05:14,290 --> 00:05:20,410
‫I would definitely come up with a list of pros and cons and a pro is it's isolated.

73
00:05:20,410 --> 00:05:25,900
‫You can add more things to it like more containers and you have to worry about them conflicting with

74
00:05:25,900 --> 00:05:26,670
‫each other.

75
00:05:26,700 --> 00:05:31,300
‫And but if your database is going to have dedicated hardware and it's not going to have any sharing

76
00:05:31,300 --> 00:05:34,990
‫of resources then maybe the container isn't necessary.

77
00:05:35,110 --> 00:05:37,740
‫Maybe you can get away with that now eventually.

78
00:05:37,870 --> 00:05:39,010
‫Everything you have.

79
00:05:39,010 --> 00:05:42,640
‫Once they're all in containers you're going to wish that everything else was in containers too.

80
00:05:42,640 --> 00:05:42,850
‫Right.

81
00:05:42,850 --> 00:05:46,000
‫You're gonna have all your management tools looking for containers.

82
00:05:46,000 --> 00:05:48,340
‫So there's pros and cons there.

83
00:05:48,380 --> 00:05:48,800
‫Right.

84
00:05:48,820 --> 00:05:54,280
‫I wouldn't just go running into the container land but I certainly would not say that taking something

85
00:05:54,280 --> 00:05:58,930
‫from an OS and then putting it in a container on that OS to me doesn't usually change the performance

86
00:05:59,170 --> 00:05:59,830
‫at all.

87
00:05:59,860 --> 00:06:02,820
‫It's really the same process on the same OS.

88
00:06:02,890 --> 00:06:05,400
‫It's just has a security boundary around it.

89
00:06:05,400 --> 00:06:11,590
‫Now that limits its resource access potentially and it limits its ability to do other things on the

90
00:06:11,590 --> 00:06:12,380
‫machine.

91
00:06:12,380 --> 00:06:13,160
‫All right.

92
00:06:13,480 --> 00:06:18,820
‫Hopefully that helps narrow down but that's a great question about databases and if you're interested

93
00:06:18,820 --> 00:06:24,400
‫more definite go check out those a couple of white papers there on my Docker page and at Brett Fisher

94
00:06:24,400 --> 00:06:29,590
‫dot com slash doctor and you can read about their mental performance versus the In Performance for databases.