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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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