0
1
00:00:02,350 --> 00:00:02,700
All right.
1

2
00:00:02,770 --> 00:00:03,960
See the next question.
2

3
00:00:04,920 --> 00:00:10,770
Hill says right now I run five different war files and Jay boss when I which I then connect to Postgres
3

4
00:00:10,770 --> 00:00:15,090
database is on some server I am looking at compose actually going through that course at the moment
4

5
00:00:15,090 --> 00:00:16,310
to set it up.
5

6
00:00:16,320 --> 00:00:21,600
The question I have is should I create multiple J Bos containers with compose or just continue running
6

7
00:00:21,630 --> 00:00:26,310
all five in one in production we have five different J servers
7

8
00:00:28,580 --> 00:00:29,690
so
8

9
00:00:33,440 --> 00:00:35,140
I would say try both.
9

10
00:00:35,420 --> 00:00:41,290
If you have five different war files and J boss without being a Java expert I mean you're the Java guy.
10

11
00:00:41,330 --> 00:00:41,880
What do you think.
11

12
00:00:42,500 --> 00:00:44,870
Yeah I can talk a little bit into this anyways.
12

13
00:00:46,240 --> 00:00:56,650
So my recommendation is it's typically been all right don't don't boil the ocean and Bret says this
13

14
00:00:56,650 --> 00:01:00,880
often fancy do what you're already comfortable with do what you already know.
14

15
00:01:00,920 --> 00:01:05,510
If that's where you have lots of tooling and everything around we've got a single J Bar server that
15

16
00:01:05,510 --> 00:01:10,410
has lots of war files in it and we know how to work with that we know how to instrument it and everything.
16

17
00:01:10,820 --> 00:01:15,170
Great to get that containerized and start working from there.
17

18
00:01:15,200 --> 00:01:21,950
Personally I'm a fan of splitting that out into multiple containers and so that would probably be a
18

19
00:01:21,950 --> 00:01:30,940
long term approach because I imagine for the most part your if you update one do you need to redeploy
19

20
00:01:30,950 --> 00:01:32,140
the other four.
20

21
00:01:32,350 --> 00:01:37,880
And so if they're all in separate containers you can deploy one you can roll out updates to one without
21

22
00:01:37,880 --> 00:01:39,620
having to bring down the others.
22

23
00:01:39,650 --> 00:01:41,260
They're all independent from each other.
23

24
00:01:41,270 --> 00:01:45,260
Yes that means you have additional overhead you're now running five day Vos servers instead of just
24

25
00:01:46,130 --> 00:01:50,550
one but I think at the end of the day there's not that much difference.
25

26
00:01:50,580 --> 00:01:58,200
I mean the jailhouse application server sure does have some overhead but I would and again I don't know
26

27
00:01:58,200 --> 00:02:04,230
your app at least in my experience the amount of overhead from the application server in comparison
27

28
00:02:04,230 --> 00:02:11,010
to the app itself is quite low that most of the CPU memory utilization all that stuff is coming from
28

29
00:02:11,010 --> 00:02:17,280
the app not from the server itself so running multiple instances of J Bos probably using it to hurt
29

30
00:02:17,280 --> 00:02:17,390
you.
30

31
00:02:17,420 --> 00:02:20,380
But again I don't know your your exact situation too.
31

32
00:02:20,450 --> 00:02:26,520
Yeah and I think that you know getting getting server resources for that is probably easier.
32

33
00:02:26,520 --> 00:02:32,610
Probably less of an issue than the fact the game the abilities you gain by having the flexibility right
33

34
00:02:32,610 --> 00:02:36,920
like you can have scale one without scaling the others you can replace one without replacing the others.
34

35
00:02:37,320 --> 00:02:42,250
I think this is in general this question is very similar right to other questions we get about a couple
35

36
00:02:42,270 --> 00:02:47,070
a couple weeks ago we had people asking well if I have a bunch of Apache Web sites should I run them
36

37
00:02:47,070 --> 00:02:51,780
all in Apache virtual servers or should I split them out in the separate containers and my answer was
37

38
00:02:51,780 --> 00:02:56,070
very similar to yours Michael that I would have video that it all would work in one but eventually I
38

39
00:02:56,070 --> 00:03:00,450
would be splitting the mountain separate containers because containers provide that level of isolation
39

40
00:03:00,450 --> 00:03:02,420
and artifacts.
40

41
00:03:02,430 --> 00:03:08,130
That gives me the flexibility for distributed computing where I can you know we can't really ever get
41

42
00:03:08,130 --> 00:03:13,050
to and to micro services and this necessary it doesn't mean that your boss is micro servers yet but
42

43
00:03:13,710 --> 00:03:20,010
you know to me there is there's a there's a wide array of size of applications and as we start splitting
43

44
00:03:20,010 --> 00:03:27,520
things up or making different you know applications that run separately whether it's a war file or something
44

45
00:03:27,520 --> 00:03:28,260
else.
45

46
00:03:28,360 --> 00:03:34,360
The more we split these and isolate these things out generally the more flexibility the easier it is
46

47
00:03:34,360 --> 00:03:37,250
to get uptime the easier it is to troubleshoot it.
47

48
00:03:37,270 --> 00:03:41,070
It's not perfect then not everything is better right.
48

49
00:03:41,230 --> 00:03:45,020
You have sometimes duplication of effort you end up with more things you've got to manage.
49

50
00:03:45,020 --> 00:03:49,480
You got maybe a little bit harder network troubleshooting depending on how your apps work it might affect
50

51
00:03:49,480 --> 00:03:52,620
performance if they're across the network instead of in the same machine.
51

52
00:03:52,630 --> 00:03:58,690
So there's lots of things to consider but in general we're all evolving into a way where we're splitting
52

53
00:03:58,690 --> 00:04:01,010
things out more and more and more when it makes sense.
53

54
00:04:01,010 --> 00:04:04,210
And yeah and from my experience too.
54

55
00:04:04,240 --> 00:04:07,610
Again this may not be your experience or it's going on here.
55

56
00:04:07,880 --> 00:04:14,920
But know we've had several Tomcat containers or a tomcat servers that had lots of war files in it and
56

57
00:04:14,920 --> 00:04:20,080
we simply did that because it was convenient at the time to spin up a new machine dish up the new Tomcat
57

58
00:04:20,080 --> 00:04:25,210
and since all that stuff was it was a lot of overhead in the past and so it's fine I don't want to do
58

59
00:04:25,210 --> 00:04:28,750
that I'm just going to deploy another war files so this other one it's already running it's good enough
59

60
00:04:29,850 --> 00:04:36,460
and so that was more to reduce the OPs overhead and the amount of time to speed things up but now as
60

61
00:04:36,750 --> 00:04:43,570
you become more familiar with containers and everything that overhead doesn't really exist anymore because
61

62
00:04:43,570 --> 00:04:47,860
now it's early in the process you're building these container images and it's easier to spend things
62

63
00:04:47,860 --> 00:04:48,020
up.
63

64
00:04:48,040 --> 00:04:55,210
So yeah that's yeah it is a good question.
64

65
00:04:55,390 --> 00:04:59,860
Yeah I mean we get the same question about databases should I put all of my databases into one my sequel
65

66
00:04:59,860 --> 00:05:03,940
server or should I have multiple my sequel containers and I would say this depends.
66

67
00:05:04,110 --> 00:05:08,770
What is your motivation that the cheapest thing to do is to put them all in one because it's lower memory
67

68
00:05:08,770 --> 00:05:09,390
overhead.
68

69
00:05:09,390 --> 00:05:15,340
It's you know probably a little less redundancy in on in terms of the necessary things you need to run
69

70
00:05:15,370 --> 00:05:20,520
but most of us are splitting things out when we can in order to gain flexibility.
70

71
00:05:20,750 --> 00:05:20,980
Really.