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

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
2

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.
3

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
4

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
5

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

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

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

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

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

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.
11

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.
12

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
13

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.
14

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

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
16

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
17

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
18

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
19

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

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.
21

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
22

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

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
24

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

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
26

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

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.
28

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
29

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
30

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.
31

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.
32

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

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

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
35

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

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
37

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

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
39

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

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

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

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
43

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

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
45

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

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

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
48

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

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
50

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.
51

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
52

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

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

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

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

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
57

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

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

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
60

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

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

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
63

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
64

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

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
66

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

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

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.
69

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
70

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

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.
72

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
73

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

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
75

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

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

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

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.
79

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

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

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

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

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
84

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
85

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

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

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

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
89

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

91
00:06:12,380 --> 00:06:12,910
All right.
91

92
00:06:12,910 --> 00:06:13,160
All right.
92

93
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

94
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

95
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.